Zeitschleife läuft zu schnell oder zu langsam

Guten Abend zusammen,

ich hätte eine kurze Frage zu der Zeitschleife. Bei dem von mir erstellten Programm befindet sich das Einlese VI der Messgeräte sowie der Schreibvorgang in ein Textfile in einer Zeitschleife. Mit meinem Programm möchte ich in 10 Sekunden 20.000 Messwerte erfassen an 5 Spannungseingängen. Nun habe ich die Schrittweite der Schleife auf 0,5 Millisekunden gestellt und eine 1kHz Taktung ausgewählt.
Zusätzlich lasse ich noch über den Wert Verstrichene Zeit über das gleichnamige VI in die Datenerfassungsdatei schreiben. Klappt auch soweit alles super, außer das das Programm meist schon nach 8 Sekunden durchgelaufen ist. Die Werte schwanken aber auch mal weniger, mal stärker. Wenn man das ganze mit 1 ms macht und 10.000 Durchläufen in der Zeitschleife, dauert der Spaß etwa 10 Sekunden, aber auch hier sind Schwankungen enthalten im 100 ms Bereich.

Die Zeitschleife enthält ja auch Ausgangsdaten, unter anderem auch:
- Erwartetes Ende
- Tatsächliches Ende

Diese Werte stimmen auch fast exakt mit der aufgezeichneten Zeit des VI´s "Verstrichene Zeit" überein.
Also eigentlich weiß die Zeitschleife, das sie zu schnell oder zu langsam läuft, und ist trotz alledem falsch

Ist LabVIEW mit so einer hohen Abtastrate einfach überfordert oder hab ich da was grundsätzliches falsch gemacht. In Fachliteratur hab ich gelesen, das die Zeitschleife eigentlich extra dafür entwickelt wurde, dieses Problem das eigentlich bei einer simplen While-Schleife mit Verzögerung auftreten kann zu beheben.
Über Antworten würde ich mich sehr freuen :-)

Mein Programm kann ich leider nur sehr schlecht hier posten. Hoffe man versteht trotz alledem mein Problem :-)

Beste Grüße

Anzeige

Rückfrage:
Wo lässt du diese Timed-Loop laufen. So wie ich es verstehe, auf Windows (nicht einem Real-Time-Target). Dort ist die theoretische Auflösungsgrenze 1 ms. Schrittweite 0,5 ms ist somit nicht zulässig!
Wo kommen eigentlich deine Daten her?

Und das Schreiben in eine Datei würde ich auch nicht in einer Timed-Loop machen. Daten lieber per Queue an eine andere Schreibe-Schleife übergeben.

Genaueres lässt sich ohne Screenshot oder noch besser VI-Upload nicht sagen...

Gruß, Jens

' schrieb:Wo kommen eigentlich deine Daten her?

Na, die werden in genau dieser Schleife eingelesen: 0,5ms bei 10s macht 20.000 Werte.

Ich würde das ja ganz anders machen. DAQmx-Task erstellen, die mit 2kHz die Daten sampelt. In einer parallelen While-Schleife mit Raster 50ms wird mittels DAQmx-Read der DAQmx-Puffer ausgelesen (= leer gelesen!). Die ausgelesenen Daten kann man aufsummieren, per Queue oder Melder versenden - oder vieles mehr.

LV ist gerade zu prädestiniert genau diese Aufgabe zu lösen. Du musst nur das richtige Verfahren anwenden.

' schrieb:Rückfrage:
Wo lässt du diese Timed-Loop laufen. So wie ich es verstehe, auf Windows (nicht einem Real-Time-Target). Dort ist die theoretische Auflösungsgrenze 1 ms. Schrittweite 0,5 ms ist somit nicht zulässig!
Wo kommen eigentlich deine Daten her?

Und das Schreiben in eine Datei würde ich auch nicht in einer Timed-Loop machen. Daten lieber per Queue an eine andere Schreibe-Schleife übergeben.

Genaueres lässt sich ohne Screenshot oder noch besser VI-Upload nicht sagen...

Gruß, Jens

Hallo Jens,

Das mit der Auflösungsgrenze hörst sich schon mal ziemlich Interessant an :-)
Hmm, vielleicht würde es ja funktionieren, wenn man einen Frequenzgenerator als Triggerquelle verwendet ...

Die Daten kommen von einem NI USB 6211

Also ich bin dir ziemlich dankbar, weil das mit der Auflösungsgrenze ein ausgezeichnetes Argument für mich ist, da hätte ich wahrscheinlich stundenlang irgendwelche Fachliteratur wälzen müssen um da mal zufällig drauf zu stoßen :-)
Damit hab ich mal etwas wo ich weiter ansetzen kann. Ich werde das mal ausprobieren und dann hier posten was rausgekommen ist ;-)

Noch einen schönen Abend

Grüße

' schrieb:Wo kommen eigentlich deine Daten her?

' schrieb:Na, die werden in genau dieser Schleife eingelesen: 0,5ms bei 10s macht 20.000 Werte.

Ich wollte wissen, von welcher Hardware diese Daten kommen. Bisher hat MC_Garnickl nur was von "Einlese VI der Messgeräte" geschrieben, das kann alles Mögliche bedeuten. Vielleicht hat er gar keine NI-DAQ-Karte im Einsatz.

Moment, wo ist die Glaskugel, Mist, schon wieder defekt

Gruß, Jens

EDIT: Ah, neue Info, USB-6211, dann trifft natürlich der Tip von IchSelbst ins Schwarze. Daten mit dem internen Hardware-Takt der DAQ-Karte einlesen, und immer schön in Paketen von z.B. 50ms oder ähnlich abholen.

' schrieb:Na, die werden in genau dieser Schleife eingelesen: 0,5ms bei 10s macht 20.000 Werte.

Ich würde das ja ganz anders machen. DAQmx-Task erstellen, die mit 2kHz die Daten sampelt. In einer parallelen While-Schleife mit Raster 50ms wird mittels DAQmx-Read der DAQmx-Puffer ausgelesen (= leer gelesen!). Die ausgelesenen Daten kann man aufsummieren, per Queue oder Melder versenden - oder vieles mehr.

LV ist gerade zu prädestiniert genau diese Aufgabe zu lösen. Du musst nur das richtige Verfahren anwenden.

Hey,

das klingt ja gleich noch viel besser. Also doch nicht ganz so auswegslos :-)
Also das werde ich auf jeden Fall auch noch ausprobieren. Dann war wohl die unterschiedliche Taktung das Problem

Auch dir vielen Dank für die schnelle Antwort

Am Montag komme ich ins Labor, dann werde ich gleich mal alles ausprobieren und hier schreiben ;-)

Beste Grüße

Anzeige

Ich versteh' da was nicht ...

' schrieb:In einer parallelen While-Schleife mit Raster 50ms wird mittels DAQmx-Read der DAQmx-Puffer ausgelesen (= leer gelesen!). Die ausgelesenen Daten kann man aufsummieren, per Queue oder Melder versenden - oder vieles mehr.

Parallele While-Schleife zu was denn? Wenn er 20k Samples in 10 Sekunden haben will, warum stellt er nicht einfach den Modus auf endliche Anzahl, die Anzahl der Samples beim 'DAQTiming VI' auf 20k und beim 'DAQRead VI' auf z.B. 50 Samples und die Sampling-Rate auf 2kHz und fertig. Wozu braucht man jetzt 'ne Queue oder Melder?

' schrieb:Parallele While-Schleife zu was denn?

Zum Rest des Universiums, also seines Programmes.
Man kann jede Applikation aus Modulen zusammenbauen. Ein modularer Aufbau hat diverse Vorteile. Einer davon ist, dass man ein Modul als Standalone-Paket betrachten kann, das dann selbstsicher programmiert werden kann. Module können auch als eigenständige Task innerhalb des Gesamtsystems laufen. Sie werden dann im Timesharing-System ausgeführt, sodass alle Module PARALLEL ausgeführt werden. Ein Nachteil des modularen Aufbaus: Man muss eine Schnittstelle zwischen den Modulen explizit definieren => Queues, Melder, FGVs (keine globalen Variablen). Ein weiteren Nachteil: Der Programmieraufwand ist größer als die Modul-Funktion in den Datenfluß zu integrieren.

Zitat:Wenn er 20k Samples in 10 Sekunden haben will, warum stellt er nicht einfach den Modus auf endliche Anzahl, Anzahl der Samples auf 20k beim 'DAQTiming VI' und z.B. auf 50 Samples beim 'DAQRead VI' und die Sampling-Rate auf 2kHz und fertig.

Kann er natürlich machen. Aber:
Streng genommen ist er dann von vorne herein wegen der festen Parameter in der Konfiguration und im Ablauf festgelegt. Ein Modul würde parametriert sein und somit frei in der Konfiguration. Außerdem ist das Modul allgemeiner einsetzbar. Man könnte z.B. Online-Werte unabhängig vom Ablauf und kontinuierlich ansehen.

Zur Entscheidung "Modul oder Datenfluß" muss man eigentlich den Zweck und die Größe der Applikation betrachten. (Nur weis das ein Anfänger am Anfang noch nicht.) Mach ich einen komplexen Dauerlaufprüfstand (also eine EXE) und die auch noch im Kundenauftrag, wird das mit "im Datenfluß" nie funktionieren respektive größte Probleme geben. Wenn ich aber eine Laboranwendung für eigene Zwecke brauche, dann ist es mir egal, ob da ab und zu mal der Graph ruckelt, weil ich mein Timeing wegen zuviel Last im Datenfluß überlastet habe. Dann ist es mir auch egal ob das BD etwas größer und/oder unübersichtlicher wird oder nicht.

' schrieb:Ich versteh' da was nicht ...
Parallele While-Schleife zu was denn? Wenn er 20k Samples in 10 Sekunden haben will, warum stellt er nicht einfach den Modus auf endliche Anzahl, die Anzahl der Samples beim 'DAQTiming VI' auf 20k und beim 'DAQRead VI' auf z.B. 50 Samples und die Sampling-Rate auf 2kHz und fertig. Wozu braucht man jetzt 'ne Queue oder Melder?

Viele hier programmieren nicht nur schnell mal eine Laboranwendung wo das VI gestartet wird, etwas tut und danach sich selber beendet, sondern komplette Applikationen. Die startet man, wonach sie auf Benützereingaben warten, allenfalls nach Bestätigung des Benützers eine Messung tun, diese dem Benützer in unterschiedlicher Weise darstellen, verschiedene Baerbeitungen auf die gemessenen Daten zulassen, all die daraus entstehenden Resultate als Datenbestand auf Disk schreiben lassen, um gleich danach die folgende Messung zu starten. Und während all dem sollte man auch noch jederzeit jegliche Operation unterbrechen oder ganz abbrechen können.

Für sowas sollte man die Datenerfassung, Verarbeitung und Presentation, sowie die Abhandlung der Benützereingaben in seperate Tasks aufteilen, um das Ganze noch handhabbar zu machen. Und um zwischen diesen Tasks zu kommunizieren verwendet man Melder, Queues oder dergleichen.

Aber ich gebe Dir Recht, für eine reine Laboranwendung die nur mal Daten erfassen soll und sonst nichts, ist der direkte lineare Programmieransatz viel einfacher. Das Problem hierbei ist das viele solcher Applikationen nach einer gewissen Zeit evolvieren und wenn man dann nicht schon eine gute Grundarchitektur hat wirds entweder ein riesiges Gebastel, wo bei jeder kleinsten Erweiterung oder Anpassung gleich 5 andere Dinge plötzlich nicht mehr gut funktionieren, oder aber man ist gezwungen alles fortzuschmeissen und doch noch mal von Grund auf neu mit einer guten Architektur zu beginnen.

:yahoo:Mein Beitrag war war schneller.