Hallo zig,
Zitat:Entsprechend erwarte ich, dass der Durchflusssensor 50 Werte (dt = 0,1) liefert. Leider sind es bei Letzterem immer etwas weniger.
Worauf beruht diese Erwartung?
Probleme:
- Wieso nennst du einen Notifier "Queue1"?
- Du schreibst Zufallswerte in diesen Notifier und wartest dann auf ein zufälliges Vielfaches von Miilisekunden. Dummerweise wird diese Wartezeit stark variieren und nur selten etwas mit der gewollten Wartezeit zu tun haben!
- Diesen Notifier fragst du dann mit einem TimeOut von 95ms ab. Hast du mal geprüft, ob/wie oft du in den TimeOut hineinläufst? Wie verträgt sich dieser TimeOut mit deiner Erwartung von dt=0.1?
- Auch bei einem TimeOut wertest du den Pulszähler aus…
Zitat:Die zweite Frage
Es gibt da den Beispielfinder. Und dar hat auch Beispiele zum synchronen Starten von DAQmx-Tasks…
Zitat:Zitat:Entsprechend erwarte ich, dass der Durchflusssensor 50 Werte (dt = 0,1) liefert. Leider sind es bei Letzterem immer etwas weniger.
Worauf beruht diese Erwartung?
Darauf, dass das Programm keine nennenswert komplexe Operationen beinhaltet und daher die einzelnen Komponenten im Millisekundenbereich (meinetwegen auch im Zehntelsekunden-Bereich) abgearbeitet werden müssten. Daher sollten die beiden Gruppen maximal einen unterschied von 1/10 bis 2/10 Sekunden aufweisen. Es sind allerdings einige Sekunden.
Ich konnte das ganze verbessern, in dem ich die "Datenerfassung" der ersten Schleife nicht durch eine lokale Variable beende, sondern dann, wenn die DAQ/Analyse-Queue zerstört wird.
Zitat:- Wieso nennst du einen Notifier "Queue1"?
Copy-Paste-Fehler
Zitat:- Du schreibst Zufallswerte in diesen Notifier und wartest dann auf ein zufälliges Vielfaches von Miilisekunden. Dummerweise wird diese Wartezeit stark variieren und nur selten etwas mit der gewollten Wartezeit zu tun haben!
Ja, genau so ist das beabsichtigt. Wenn du dich erinnerst, liefert der Durchflussmesser eine dem Durchfluss äquivalente Samplerate, die also nicht konstant ist. Um dieses verhalten schnell und einfach zu simulieren, ist mir auf anhieb nix besseres eingefallen.
Zitat:- Diesen Notifier fragst du dann mit einem TimeOut von 95ms ab. Hast du mal geprüft, ob/wie oft du in den TimeOut hineinläufst? Wie verträgt sich dieser TimeOut mit deiner Erwartung von dt=0.1?
Im realen Programm sollte das hinkommen. D.h. liefert der Sensor weniger als 1 Wert pro 100 ms wird dies als kein Durchfluss interpretiert. Klar verliere ich ein kleines Stück der unteren Messbereich, aber das sollte vernachlässigbar sein. Zumal der Sensor selbst erst ab einem gewissen Mindestdurchfluss arbeitet.
Zitat:- Auch bei einem TimeOut wertest du den Pulszähler aus…
Ja, um den null-Durchfluss abzufangen, s.o.
Zitat:Es gibt da den Beispielfinder. Und dar hat auch Beispiele zum synchronen Starten von DAQmx-Tasks…
Ja, dort sind exakt zwei Beispiele vorhanden. Das eine bringt mir nix, da die verschiedenen Sensoren in einem Task zusammengefasst sind. Und beim anderen wird die Synchronisation nach der Art der Geräte eingestellt - dummerweise sind meine Geräte (cDAQ) nicht enthalten.
Hallo zig,
Zitat:Ja, dort sind exakt zwei Beispiele vorhanden.
Da gibt es schon ein paar mehr (zumindest bei installiertem RT/FPGA-Modul)…
Ich meinte das "Multi-Function-Synch AI-AO"-Beispiel. Hier wird mit einem Starttrigger gearbeitet - und du könntest testen, ob das mit deiner Hardware auch funktioniert…
(06.10.2014 09:05 )GerdW schrieb: [ -> ]Ich meinte das "Multi-Function-Synch AI-AO"-Beispiel. Hier wird mit einem Starttrigger gearbeitet - und du könntest testen, ob das mit deiner Hardware auch funktioniert…
Und falls es dieses Bsp unter
nicht mehr gibt, dann
schau mal hier.
hm... wenn ich im Beispiel-Finder danach suche wird nix gefunden. Laut Lizenzmanager ist das FPGA-Modul aktiviert. Kann es dennoch nicht installiert sein, falls ja wie prüfe ich das?
Kannst du das Bespiel-VI hier hochladen? (keine Ahnung wie das rechtlich aussieht
)
ich hab das Beispiel im Netz gefunden (glaube ich). Allerdings habe ich das so bereits ausprobiert. Das Problem ist, dass das alles mit Countern nicht zu funktionieren scheint.
argh, sorry! Wollte eigentlich den oberen Post editieren...
Also, nachdem ich nun ewig im Netz, hier im Forum und auf der NI-Seite gesucht habe und wirklich nirgendwo ein passendes Beispiel (oder eines, das man modifizieren könnte) gefunden habe (also keines, was mit CI - Frequenz funktioniert) muss ich die Frage nochmal etwas allgemeiner formulieren:
Angenommen ihr habt einen analogen (z.B. 4-20 mA) Drucksensor und einen Durchflusssensor mit einem digitalen Signal, bei dem Volumenstrom = f(Frequenz) und demnach auch die Sample-Rate variabel ist. Jetzt wollt ihr beide Sensoren synchron und in einer gemeinsamen Zeitachse erfassen und schreiben. Wie würdet ihr das konkret machen?
Hallo zig,
ich löse das meist so:
Beide DAQ-Task erfassen parallel voneinander Werte. Beide schreiben ihre aktuellen Werte in einen Buffer. Eine weitere Schleife liest die Buffer dann (quasi) zeitgleich aus. Für mich reicht das bei 10Hz Samplerate aus…
Das gleiche Prinzip habe ich
auch Patrick vorgeschlagen.
Ok, genau das habe ich, nach deinen Hinweisen, ja gemacht: Füge das VI aus Beitrag # 21 und das letzte aus Beitrag # 30 gedanklich zusammen. Dann kannst du die "Zufalls-DAQ-Simulations"-Schleife aus dem letzten VI ersetzen.
Da ich keinen Weg gefunden habe, den Counter-Task mit den AI Tasks (Letztere wurden durch die Signal-Simulieren-VIs ersetzt, also bitte hinzudenken
) zu synchronisieren bleibt eine letzte Idee: Ich packe alle Task-Starten-VIs (AI und CI) in einen Rahmen einer flachen Sequenz. Somit sollten doch alle Tasks weitestgehend gleichzeitig starten, da nichts mehr dazwischen funken kann?
Davon unabhängig (also ohne Sequenz) konnte ich feststellen, dass die verschiedenen AI-Tasks auch ohne explizite Synchronisation weitestgehend homogen laufen.
Hallo zig,
Zitat:dass die verschiedenen AI-Tasks auch ohne explizite Synchronisation weitestgehend homogen laufen.
Vielleicht weil sie intern auf
dieselbe BaseClock zugreifen?