Datenerfassung - unterschied zwischen Samplerate und Tick Count

Hallo zusammen,

ich bin gerade dabei einen kleinen Versuchsstand aufzubauen. Dabei verwende ich LV 2019 und ein NI cDAQ 9174 mit folgenden Einschüben:
• NI 9222 4 Kanal Analoginput
• NI 9217 4 Kanal Temperaturmessung
• NI 9269 4 Kanal Analogoutput

Über den Analogoutput gebe ich einen Druck vor. Daraufhin werden 3 Signale (2x Druck, 1x Geschwindigkeit) über die analogen Spannungseingänge + die Temperatur gemessen. Die Messdaten inklusive Tick Count schreibe ich mittels einer While-Schleife und einem Schieberegister in ein Array, welches ich mir nach Beendigung der Messung in eine Textdatei schreibe. Soweit funktioniert alles prima - so wie es soll.

Meine Timingeinstellung für die AI sind eine kontinuierliche Datenerfassung mit 100 zu lesenden Werten und einer Abtastrate von 1000Hz, welche ich über einen Task im NI Max festgelegt habe.

Wenn ich nun die geschriebene Textdatei öffne, sehe ich das alle 2 ms zwei Werte geschrieben wurden, kann mir einer sagen woran das liegt? Hängt das mit dem Tick Count zusammen? Ist meine Schleife zu langsam, wenn ja wie könnte ich noch schneller werden? Fragen über Fragen.

Alternativ hatte ich auch schon eine zeitgesteuerte Schleife probiert. Darüber hatte ich dann meinen 1ms Schritt für die 1000Hz erreicht, allerdings waren dann sehr oft dieselben Daten hintereinandergestanden, was darauf hinweist das die Schleife nicht fertig durchlaufen werden konnte.

Ich hoffe mir kann jemand weiter helfen.

Anzeige

Hallo fritenschmiede,

das Timing für die Messwerte kommt von der Hardware. Du schreibst zusätzlich noch irgend einen anderen Zeitstempel in deine Datei - der hat aber reichlich wenig mit den Messwerten zu tun.
Baue das Ganze um und mache alles etwas langsamer. Es gibt keinen Grund bei 1kHz Sample Rate wie wild Sample für Sample einzulesen. Verwendet "Multiple Channels, Multiple Samples" und lese die Daten ganz gemütlich ein. Als Zeitstempel schreibst du nicht die Ticks, sondern die 1/SampleRate * SampleNummer * 1000ms/s, also bei 1kHz Sample Rate einfach die Sample Nummer (1,2,3,4,5 usw.).

Hallo schmiede,

Zitat:Dabei verwende ich LV 2019

Dann bitte !

Zitat:Meine Timingeinstellung für die AI sind eine kontinuierliche Datenerfassung mit 100 zu lesenden Werten und einer Abtastrate von 1000Hz, welche ich über einen Task im NI Max festgelegt habe.
Wenn ich nun die geschriebene Textdatei öffne, sehe ich das alle 2 ms zwei Werte geschrieben wurden, kann mir einer sagen woran das liegt?

Leider sieht man von deinen Timingeinstellungen überhaupt nichts im VI!
Genauer: dein VI kümmert sich überhaupt nicht um deine Taskeinstellungen, sondern liest immer nur ein Sample pro Iteration. Das kombinierst du mit einem Tickcount, der nur auf eine Miilisekunde auflöst und evtl. weniger genau ist…

Wenn dein VI deine Timingeinstellungen respektieren soll, dann solltest du bei DAQmxRead auf "N channels N samples" umstellen und gleich 100 Samples abfragen - dann kommst du auf eine (üblicherweise empfohlene) Iterationszeit von 100ms!

Dein ganzes VI sollte auch noch etwas überarbeitet werden:
- Im ersten Frame läuft die Schleife so schnell es nur geht: musst du wirklich so oft den exakt gleichen Wert auf den AO schreiben und dabei auf Userinput warten?
- Im zweiten Frame solltest du auf das Erstellen eines möglicherweise riesigen Arrays verzichten. Und wenn du schon ein "Array bauen" willst, dann verwende bitte auch BuildArray statt InsertIntoArray!
- Die Sequenzstruktur ist übrigens komplett unnötig - THINK DATAFLOW!
- Der Tickcount ist übrigens nicht die "Systemzeit", sondern ein einfacher Millisekundenzähler. Wenn du die "Systemzeit" wissen willst, solltest du GetDateTimeInSeconds verwenden!

Vielen Dank für den ganzen Input. Ich habe das mal versucht umzusetzen.
Durch die NChannels NSamples wird die Schleife deutlich schneller, dass hatte ich so nicht auf dem Schirm. Den Tick Count habe ich mir jetzt gespart und die Schleife mit einer 1 ms Wartezeit versehen – was dann den 1000Hz Samplerate entspricht – so hatte ich Martin.Henz verstanden. Das mit der Iterationszeit von 100 ms und 100 Sampels abfragen, so wie GerdW beschrieben hat, habe ich irgendwie nicht hinbekommen.

Ich möchte trotzdem nochmal nachfragen, nur damit ich es abschließend verstehe: Wenn ich in die Schleife jetzt nochmal Tick Count oder „High resolution relative seconds“ einbaue, dann ist der Zeitabstand ja trotzdem nicht immer genau die 1ms – woran liegt das? Kommt das aus der Diskrepanz zwischen Hardwaretakt und Quelle des Tick Count bzw. „High resolution relative seconds“?

Beste Grüße
Fritenschmiede

PS: ich habe gerade gesehen in dem Array habe ich noch einen Datentypfehler.

Hallo schmiede,

Zitat:Das mit der Iterationszeit von 100 ms und 100 Sampels abfragen, so wie GerdW beschrieben hat, habe ich irgendwie nicht hinbekommen.

Ist doch ganz einfach:
   
Hast du dir mal die ganzen DAQmx-BeispielVIs im Beispielfinder angeschaut?

Zitat:Wenn ich in die Schleife jetzt nochmal Tick Count oder „High resolution relative seconds“ einbaue, dann ist der Zeitabstand ja trotzdem nicht immer genau die 1ms – woran liegt das? Kommt das aus der Diskrepanz zwischen Hardwaretakt und Quelle des Tick Count bzw. „High resolution relative seconds“?

Ja, unter anderem.
Windows wird dir nie und nimmer eine stabile Iterationszeit von 1ms garantieren - das wird selbst auf einem RT-System nicht zu 100% garantiert! Windows macht da einfach zu viel im Hintergrund…

Außerdem fragst du alle Samples ab, die gerade im DAQmx-Buffer vorhanden sind: das können bei jeder Iteration unterschiedlich viele sein! IMHO ist das für die spätere Weiterverarbeitung von Daten aber eher ungünstig - mit konstanten Blockgrößen kann man viel effizienter arbeiten!

Hallo Gerd,

(23.10.2020 09:04 )GerdW schrieb:  

Zitat:Das mit der Iterationszeit von 100 ms und 100 Sampels abfragen, so wie GerdW beschrieben hat, habe ich irgendwie nicht hinbekommen.

Ist doch ganz einfach:

...

nicht ganz - das Problem liegt vor allem dort:

   

Das funktioniert so nicht, denn in dem Array stehen dann pro Messkanal nur ein Wert drin und nicht die etwa 100 Messwerte (je Kanal).

Anzeige

Hallo Fritenschmiede,

hmm, also eigentlich ist es ja deine Aufgabe das Ganze etwas in Ordnung zu bringen. Anstatt nun aber wortreich zu beschreiben, was du tun kannst, habe ich ein dein VI nebenbei etwas verändert. Dem Gerd habe ich noch genug zum meckern übrig gelassen

Mein Ansatz geht jetzt so, dass das Kram mit dem Dateiheader vor der While-Schleife in die Datei geschrieben wird und die Messdaten innerhalb der While-Schleife in die Datei geschrieben werden. Wenn du erst die Messdaten komplett sammelst, dann platzt irgendwann dein Rechner wenn die Messzeit sehr lange ist. Außerdem ist ja jede Menge Zeit bis die nächsten etwa 100 Samples gemessen wurden.

Hallo ihr zwei,

Zitat:Dem Gerd habe ich noch genug zum meckern übrig gelassen

Sieht doch schon deutlich netter aus!

Ich würde nur unbedingt beim DAQmxRead eben die "100 samples to read" vorgeben und dafür die Wartezeit in der Schleife entfernen. Eine kontinuierliche Datenerfassung verträgt sich eher weniher mit festen Wartezeiten: DAQmx kann hier selbst für das akkurate Timing sorgen…

Ansonsten ein Tipp:
Statt riesiger ConcatString-Nodes verwende ich lieber ein FormatIntoString mit einem ordentlichen Formatstring…

Hallo ihr zwei,

das schaut wirklich sehr gut aus. Vorallem mit dem kontinuierlichen wegschreiben der Daten gefällt mir.
Allerdings war in der Ausgabe noch ein Fehler, da im Ausgabe Array bei Martin irgendwann 100 Werte pro Zeile geschrieben wurden. Ich hab das nun so angepasst das jeder Messwerte in einer Spalte ausgegeben wird. Die Wartezeit habe ich wie Gerd gesagt hat entfernt und durch die "100 Samples to read" ersetzt.

Das läuft jetzt richtig gut. Vielen Dank für euren Support.

Beste Grüße und nochmal vielen Dank
Fritenschmiede

Hallo schmiede,

Zitat:Das läuft jetzt richtig gut.

Prima!

Noch ein Vorschlag:
Beim Chart "Druck 1&2" solltest du davor ein BuildArray anstatt des Bundle verwenden: ein Array of Waveform ist ein typische Datentyp für einen Chart! (Bei deinem Bundle bekommst du einen CoercionDot…)