exakten Zeitpunkt des Schreibens NI-cDAQ

Hallo zusammen,

Ich möchte für ein größeres Projekt, digitale + analoge Signale lesen und schreiben. Diese Werte sollen mit einem Zeitwert versehen werden und alle Daten sollen in einer TDMS geschrieben werden, die nach der Signalaufzeichnung ausgewertet werden können. Hierbei müssen mehrere Chassis und Module synchronisieren werden.

An sich habe ich es geschafft alle diese Punkte umsetzten. Ich nutze dafür hardwaregetaktetes Lesen und softwaregetaktetes Schreiben. Das Schreiben von Signalen muss nicht hardwaregetaktet sein, da nicht dauerhaft geschrieben werden muss. Wichtig für die Auswertung ist der exakte Zeitpunkt des Schreibens.

Probleme bereitet mir nur noch den exakten Zeitpunkt des Schreibens festzulegen. Aktuell schreibe ich meine Werte softwaregetaktet und als Zeitwert wird der Takt vom Lesesignal übertragen. Die Lesesignale habe erfolgreich mit einem externen Taktgenerator verifiziert und konnte eine Abweichung von nur +- 1ms nachweisen.

Für die Verifizierung des Schreibsignals habe das ausgehende Schreibsignal wieder mit einem Lesesignal gebrückt. Somit weiß man wann das Signal wirklich geschrieben wird. (+-1ms Leseabweichung)
Die Erwartungshaltung ist, dass die Differenz der beiden Zeitwerte möglichst nah an den +-1 ms liegen.

Die Praxis ist jedoch eine andere. Im Schnitt liegt die Abweichung bei 4-9 ms und zusätzlich entstehen Ausreiser von ca. 20 ms. Es scheint so als würde das tatsächliche Schreiben des Signals um wenige ms versetzt sein.

Gibt es eine Möglichkeit den exakten Schreibzustand zu ermitteln? (ohne das ausgehende Signal wieder einzulesen)

technische Daten:
- NI-9188 Chassis
- 4 x NI-9375 Module (16xDI/16xDO)
- LabView 2017

Im Anhang ist vereinfacht das Problem dargestellt. Ich schreibe nur die wirklich Werteänderungen in die TDMS Datei, um einfacher Signalwechsel zu sehen.

Ich danke euch jetzt schonmal.

Viele Grüße
Christian

Hab das Problem selber gelöst.

Natürlich muss ich den Ausgang vom Schreiben nutzen. In meinem Fall wird immer die Anzahl der Samples mit 1 zurückgeben.
Erst dann kann ich abfragen wieviel Samples im Lese-Buffer liegen.

Jetzt konnte ich eine vertretbare Abweichung von 0 bis 3ms nachweisen und das ohne Ausreiser.

Grüße
Christian

Hallo Christian,

schön, dass es für dich funktioniert.

Aufräumen könnte aber auch nicht schaden, bsw.:
   

Hallo Gerd,

danke für den Hinweis.

Das macht es etwas übersichtlicher und einfacher. Die Conditional Tunnels habe ich vorher noch nie verwendet.

Kann es jedoch sein, dass die Bestimmung des Lesezeitpunkts von der Bearbeitungszeit vom Schleifendurchlauf abhängt?

Ich hab dieses Prinzip auf mein Projekt übertragen und komme auf eine Differenz von ca. 18 ms.
Das ist meine Zykluszeit. Hab im obigen Beispiel eine Wartezeit von 100 ms eingebaut, dann ist das Lesesignal ebenfalls ca. 100 ms versetzt.

Meine Erwartung wäre gewesen, das es kein sonderlichen Einfluss hat, weil der Zeitpunkt gleich nach dem Rückgabewert ermittelt wird.

Kann ich da irgendwas optimieren, um möglichst unabhängig von der Zykluszeit zu kommen?

Grüße
Christian

Hallo Christian,

Zitat:Kann es jedoch sein, dass die Bestimmung des Lesezeitpunkts von der Bearbeitungszeit vom Schleifendurchlauf abhängt?
…
Kann ich da irgendwas optimieren, um möglichst unabhängig von der Zykluszeit zu kommen?

Ich sehe nirgends im VI eine Stelle, wo der "Lesezeitpunkt" (im Sinne eines Timestamps) bestimmt wird!?

Warum nimmst du nicht einfach von der digitalen Waveform den t0-Wert???

Hallo Gerd,

danke für deine schnelle Hilfe.

Ich bestimme über die feste Abtastrate die Zeit. Abtastrate * gemessenen Takte = gemessene Zeit in ms

Hmm, t0 ist ein Zeitstempel, wenn ich dich richtig verstehe, soll ich den Zeitstempel vom Lesezweig mit der Waveform bestimmen und jedes Mal t0 auswerten nach ein Schreib-Block? Im Anhang habe ich mal ein Konzept. Eine Berücksichtigung von einem Wechsel von Stunde und Tag habe ich erstmal weggelassen.

In der Grafik kann man sehen, dass ich die Differenz zwischen dem annähernd tatsächlichen Schreibsignal (Lesen) und dem ermittelten Schreibzeitpunkt gegenübergestellt habe. Man erkannt das die Differenz mit steigender Wiederholungszahl langsam steigt, wie kann das passieren, wenn der Startzeitpunkt immer konstant bleibt ... Könnte es vielleicht eine Abweichung vom Lesesignals sein? Hab zusätzlich vorm Auslesen des Buffers immer t0 ausgewertet, jedoch keine Besserung.

Grüße
Christian

Anzeige

Hallo Christian,

dir ist schon bewußt, dass LabVIEW mit Timestamps auch rechnen kann (dank Polymorphismus)?
Das man deswegen den Timestamp nicht erst in Strings für SS.sss und MM umwandeln muss, diese Strings dann wieder nach DBL, um dann mit der Startzeit die Differenz zu berechnen???

So in etwa:
   
Warum musst du überhaupt die Digitalwerte aus deinem DO-Task lesen, die du gerade erst mit der Funktion davor gesetzt hast?

Zum Bild mit dem Zeitdifferenz-Graph:
Sehe ich das richtig, dass du nach 3000 Iterationen eine Differenz von 7ms zum erwarteten Wert hast? Nachdem die Schleife schon 3000*100ms=300s=5min gelaufen ist?
Was daran stört dich? Wir reden hier über eine Genauigkeit der Zeitbasis von 0.007s/300s*100%=0.0023%…

Außerdem kann es sein, dass deine Schleife eben nicht mit exakt 10Hz iteriert: du verwendest die "normale" Wait-Funktion! Wenn die Schleife mal 102ms statt 100ms benötigt, dann hast du 2ms Fehler. Und dieser Fehler wird nie gecancelt, sondern immer weiter kummuliert! Wenn du dagegen "Wait for next multiple" verwenden würdest…
(Oder deine DAQmx-Tasks gleich in jeweils ihrer eigenen Schleife laufen würden, mitsamt vorgegebener Samplerate für den DO-Task…)

Zitat:Wichtig für die Auswertung ist der exakte Zeitpunkt des Schreibens.

Momentan bestimmst du den "exakten" Zeitpunkt des Lesens der DO-Werte…

Hallo Gerd,

Zitat:dir ist schon bewußt, dass LabVIEW mit Timestamps auch rechnen kann (dank Polymorphismus)?
Das man deswegen den Timestamp nicht erst in Strings für SS.sss und MM umwandeln muss, diese Strings dann wieder nach DBL, um dann mit der Startzeit die Differenz zu berechnen???

Danke für den Hinweis, dass ist von LabView ein echt schönes Feature. Ich bin noch ein LabView-Neuling, da sind mir sehr viele Feinheit noch nicht bewusst. Ich finde es gut, dass du mich darauf hinweist.

Zitat:Warum musst du überhaupt die Digitalwerte aus deinem DO-Task lesen, die du gerade erst mit der Funktion davor gesetzt hast?

Wie bekomme ich sonst t0 vom DO? Der DAQmx Write-Block besitzt kein Ausgang mit einer Waveform oder einem Zeitstempel. Wenn im Eingang eine Waveform mit einer definieren Startzeit von t0 setze, startet der Schreibprozess trotzdem eher. Vielleicht mache ich auch irgendwas nicht richtig. Änderung für t0 DO siehe Bild.

Zitat:Sehe ich das richtig, dass du nach 3000 Iterationen eine Differenz von 7ms zum erwarteten Wert hast? Nachdem die Schleife schon 3000*100ms=300s=5min gelaufen ist?
Was daran stört dich? Wir reden hier über eine Genauigkeit der Zeitbasis von 0.007s/300s*100%=0.0023%…

Für mein Projekt ist es vermutlich kein Problem. Es ist immer gut das Problem zu kennen.
Wichtig ist es, dass es zu keiner starken Streuung kommt und keine zufälligen Ausreisen entstehen.
Die Abweichung sollte unter 10 ms sein.

Zitat:Oder deine DAQmx-Tasks gleich in jeweils ihrer eigenen Schleife laufen würden, mitsamt vorgegebener Samplerate für den DO-Task…

Das ist eine gute Idee, an die ich auch schon gedacht habe, jedoch ist das mit vielen Änderungen im Projekt verbunden. Wenn es aber zwingend notwendig wird, dann muss ich den Schritt gehen.

Grüße
Christian

Hallo Christian,

Zitat:Wie bekomme ich sonst t0 vom DO? Der DAQmx Write-Block besitzt kein Ausgang mit einer Waveform oder einem Zeitstempel. Wenn im Eingang eine Waveform mit einer definieren Startzeit von t0 setze, startet der Schreibprozess trotzdem eher. Vielleicht mache ich auch irgendwas nicht richtig. Änderung für t0 DO siehe Bild.

Dies dürfte hinreichend genau sein:
   
Das parallele Ausführen von DAQmxWrite und GetDateTime dürfte genauso genau sein wie das serielle Ausführen von DAQmxWrite und DAQmxRead…