+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenerfassung (DAQ) (/Forum-Datenerfassung-DAQ)
+---- Thema: Triggern und Meßdaten loggen (/Thread-Triggern-und-Messdaten-loggen)
Triggern und Meßdaten loggen - canix - 16.04.2007 18:46
Hallo,
wie an anderer Stelle bereits angedroht, benötige ich Euren Rat!
Kurz umrissen:
In meinem Messprogramm (Meßturm_MAIN.vi) habe ich eine While-Schleife + Metronom (50msec). Ich überwache Meßkanäle und warte auf Triggerbedingungen (Zeit od. Wertüberschreitung). Im Triggerfall werden die eingehenden Meßdaten alle 250msec weggespeichert. Liegt keine Triggerbedingung vor nur alle 10sec.
Meine Lösung: Ich nutze die Schleifeniteration und schreibe die Meßdaten entweder jeden 5ten Schleifendurchlauf weg (5*50msec=250msec) oder nur jeden 200ten Schleifendurchlauf (200*50msec=10sec) - mit Hilfe einer Modulofunktion.
Ein Arbeitskollege sagt, daß das ganz großer Mist wäre! Seine Begründung, meine Schleife könnte gegebenenfalls viel länger dauern als 50msec und damit könnte ich meine Vorgaben nicht einhalten. Stimmt Ihr ihm zu?
Damit man sich die Sache besser vorstellen kann, poste ich mein (noch unfertiges) Meßprogramm an dieser Stelle. Ich fange noch nicht alle Fehler ab, wenn man aber nicht zweimal denselben Kanal einrichtet, sollte man keine Probleme kriegen. Man kann Alternativ auch den Default.ini File laden.
[attachment=32731:Messturm.zip]
Ich benutze die simulierte NI PCI 6229 Karte und nenne das Device "Dev2"
Wäre Euch für kritische Anmerkungen sehr dankbar.
Gruß
Jens
Triggern und Meßdaten loggen - eg - 16.04.2007 22:03
Hallo Jens,
als Erstes wollte ich sagen, dass ich mich mit DAQ nicht so gut auskenne.
Zu deiner Frage kann ich aber etwas sagen. Lass deinen Kollege das nachlesen:
Waits until the value of the millisecond timer becomes a multiple of the specified millisecond multiple. Use this function to synchronize activities. You can call this function in a loop to control the loop execution rate. However, it is possible that the first loop period might be short. Wiring a value of 0 to the milliseconds multiple input forces the current thread to yield control of the CPU. This function makes asynchronous system calls, but the nodes themselves function synchronously. Therefore, it does not complete execution until the specified time has elapsed.
Und das:
Waits the specified number of milliseconds and returns the value of the millisecond timer. Wiring a value of 0 to the milliseconds to wait input forces the current thread to yield control of the CPU. This function makes asynchronous system calls, but the nodes themselves function synchronously. Therefore, it does not complete execution until the specified time has elapsed.
Du benutzt die erste davon. Soweit ich es versten habe, versucht die erste Fkt, das Timing in der Schleife zu halten, solange die Ausführung nicht länger als die eingestellte Zeit dauert. Die zweite dagegen, wartet die eingestelle Zeit, egal was die Ausführung im Loop dauert. ABER ich kann mich irren. Mir war die Zeit nie so wichtig, da das Zeitverhalten im Windoof unterschiedliches Verhalten aufweist und ist trotz aller Mühe nicht vorhersagbar ist.
Du könntest aber auch die Zeit messen mit Tick Count und vergleichen, ob du bessere Ergebnisse rauskriegst ist auch fraglich.
Sag deinem Kollege noch, dass man mit LV fast genauso gut programmieren kann, wie mit anderen Programmiersprachen, mit wenigen Ausnahmen. Diese Ausnahmen haben aber nichts mit dem Zeitverhalten zu tun. Dafür programmiert man LV halt viel schneller.
eg
P.S. vergiss nicht das Dataflow Principle
Triggern und Meßdaten loggen - canix - 17.04.2007 08:07
Hallo Eugen,
danke für die schnelle Antwort!
' schrieb:Du benutzt die erste davon. Soweit ich es versten habe, versucht die erste Fkt, das Timing in der Schleife zu halten, solange die Ausführung nicht länger als die eingestellte Zeit dauert.
' schrieb:Du könntest aber auch die Zeit messen mit Tick Count und vergleichen, ob du bessere Ergebnisse rauskriegst ist auch fraglich.Wenn ich also dafür Sorge trage, daß meine Ausführungen in der Schleife <50msec dauern, ist das Betriebssystem der einzige Risikofaktor, um meine Vorgaben (250msec, 10sec) vielleicht nicht einhalten zu können? Das gleiche Problem hätte ich dann ja auch beim Tick Count o.ä.. Die Argumentation meines Kollegen, ging wohl auch mehr dahin, daß ich vielleicht später meine Schleife um irgendeine Funktionalität erweitern will/muß und dadurch mein Timing in Gefahr geraten könnte. Allerdings kann ich die Dauer der Schleifendurchgänge messen und sehe dann ja, ob es kritisch wird - sollte sich schliesslich auch abfangen lassen. In erster Linie will ich allerdings versuchen timing-kritische, dynamische Vorgänge zu vermeiden...
Eine parallele Schleife, die z.B. über Melder die Daten aus der Mess-Schleife erhält (meinetwegen zur Anzeige im Graphen), hat doch keinen Einfluß auf das Timing in meiner Mess-Schleife oder?
' schrieb:P.S. vergiss nicht das Dataflow PrincipleWas ist das?! ;-) Hab ich das irgendwo vernachlässigt?
Gruß
Jens
Triggern und Meßdaten loggen - eg - 17.04.2007 09:16
' schrieb:Eine parallele Schleife, die z.B. über Melder die Daten aus der Mess-Schleife erhält (meinetwegen zur Anzeige im Graphen), hat doch keinen Einfluß auf das Timing in meiner Mess-Schleife oder?Jawohl, guter Ansatz.
' schrieb:Was ist das?! ;-) Hab ich das irgendwo vernachlässigt?Ja, du musst die Reihenfolge
Programmausführung in der Schleife <-> Warten
beachten. Zur Zeit kann es passieren, dass LV im ersten Schleifendurchlauf wartet und dann den Rest ausführt und im zweiten Schleifendurchlauf zuerst die Operationen in der Schleife ausführt und dann wartet.
eg