Kontinuierliche Datenerfassung mit USB 6003

Hallo,

es ist noch eine zusätzliche Frage aufgetaucht, die die Triggerung betrifft.
Folgende Anforderung: Am AI wird eine Spannung gemessen. Sobald diese sprunghaft abfällt, soll die Datenerfassung starten.
Gibt es eine Möglichkeit das Ganze zu realisieren? Beispielsweise so wie bei einem Oszilloskop, bei dem ich den Flankenanstieg- bzw Abfall einstelle und die Aufnahme dort beginnt?
In den Tutorials, die ich mir dazu angeschaut habe, wird immer nur über ein externen Trigger (z.B einen Taster) die Datenerfassung gestartet.
Kann mir da jemand weiter helfen?

Freundliche Grüße und ein schönes Wochenende
Tobolf

Anzeige

Hallo Tobolf,

Zitat:Folgende Anforderung: Am AI wird eine Spannung gemessen. Sobald diese sprunghaft abfällt, soll die Datenerfassung starten.
Gibt es eine Möglichkeit das Ganze zu realisieren?

Eine Möglichkeit gibt es immer…

"Bessere" DAQ-Hardware bietet analoge Trigger an, wie z.B. hier. Leider hast du keine "bessere" Hardware, sondern die "billige" "preiswerte", die sowas nicht kann…

Also kannst du dir eine analoge Schaltung basteln, die bei einer negativen Flanke deines Analogsignals einen Triggerpuls an den PFI-Pin deiner USB6003 liefert - oder selbst in LabVIEW dein analoges Signal überwachen!

Zitat:Sobald diese sprunghaft abfällt, soll die Datenerfassung starten.

Tipp/Hinweis: Der DAQ-Task selbst kann ja deutlich früher starten. Nur die Datenspeicherung sollte bei der negativen Flanke deines Signals starten!

(07.01.2017 13:55 )GerdW schrieb:  

Zitat:Sobald diese sprunghaft abfällt, soll die Datenerfassung starten.

Tipp/Hinweis: Der DAQ-Task selbst kann ja deutlich früher starten. Nur die Datenspeicherung sollte bei der negativen Flanke deines Signals starten!

Da hast du Recht. Und wie kann ich soetwas realisieren? Wie gesagt, ich habe leider keine Informationen dazu gefunden.
Aus dem Bauch heraus würde ich dieses VI nutzen.
Nur was genau muss ich tuen, sobald das VI ein true ausspuckt? Die Werte werden zwar in der Schleife durch die read.vi ausgelesen allerdings passiert doch das abspeichern der Werte in diesem TDMS-Aufruf vor der Schleife oder?

Freundliche Grüße

Hallo Tobolf,

Zitat:Aus dem Bauch heraus würde ich dieses VI nutzen.

Jein. Das Trigger-VI schaut nur auf den aktuellen Pegel, aber nicht auf die Steilheit von Flanken. Laut deiner Beschreibung willst du aber eher eine solche Flanke erkennen…

Zitat:Nur was genau muss ich tuen, sobald das VI ein true ausspuckt? Die Werte werden zwar in der Schleife durch die read.vi ausgelesen allerdings passiert doch das abspeichern der Werte in diesem TDMS-Aufruf vor der Schleife oder?

In deinem Fall erfolgt die Speicherung direkt durch den DAQmxTask - und zwar nur für die konfigurierten Kanäle.

Wenn man andere Anforderungen an die Datenspeicherung hat, muss man das entsprechend programmieren!
- Du könntest ausprobieren, ob man das Protokollieren über den Protokollmodus-Input (Aus vs. Protokoll&Lesen) evtl. dynamisch steuern kann. (Ich habe damit noch nicht gearbeitet und kann es hier auch nicht für dich testen.)
- Du könntest selbst die TDMS-Speicherung übernehmen und dann mit einer Producer-Consumer-Struktur arbeiten: die DAQmx-Schleife schickt (nur) die Daten, die gespeichert werden sollen, zur Logging-Schleife…

Leider habe ich bei der Speicherung der TDMS-Dateien und der Verarbeitung dieser ein paar Probleme.

Es muss doch eine einfache Möglichkeit geben, eine TDMS-Datei in eine .mat-Datei (Matlab) umzuwandeln.
Wenn ich meine Auswertung in Matlab schreibe, brauche ich auch dort meine Datensätze..
Die von mir beschriebene etwas unständliche Lösung auf Seite 1 in diesem Thread funktioniert leider nicht mit TDMS-Dateien, die größer als 500MB sind. Es kommt ein Fehler "Not enough memory to complete this operation".
Ist nun der richtige Weg, das Ganze versuchen zu splitten und die einzelnen kleineren Dateien dann zu konvertieren? Oder gibt es eine andere Möglichkeit?

Freundliche Grüße

Hallo Tobolf,

Zitat:Ist nun der richtige Weg, das Ganze versuchen zu splitten und die einzelnen kleineren Dateien dann zu konvertieren?

Ja, das wäre ein sinnvoller Weg.

Zitat:Oder gibt es eine andere Möglichkeit?

Einen größeren Rechner mit mehr Speicher?
Und/oder die 64bit-Variante von LabVIEW verwenden?

Anzeige

(30.01.2017 15:42 )Tobolf schrieb:  Ist nun der richtige Weg, das Ganze versuchen zu splitten und die einzelnen kleineren Dateien dann zu konvertieren?

In Ergänzung zu Gerds Beitrag: Dafür sorgen, dass erst gar nicht sooo große Dateien entstehen...

Gruß, Jens

Klar, das Ganze zu vermeiden wäre natürlich die einfachste Lösung. Allerdings brauche ich eine hohe Abtastrate über einen ziemlich langen Zeitraum.
Ich habe das nun mit einem Aufsplitten der TDMS-Dateien gelöst.

Eine weitere Frage ist gerade aufgetaucht:
Bei den TDMS-Dateien gibt es einen Zeitstempel t0 und ein delta_t woraus ich für jeden Datenpunkt nun meine Zeit berechne. Kann man davon ausgehen, dass dieses delta_t für alle Datenpunkte gleich groß ist?
Das Ni USB6003 wird mit 2 Channeln bei einer Abtastung von 50kS/s betrieben. Das ergibt ein delta_t von 2*10^-5s.
Gibt es vielleicht eine Möglichkeit das Ganze zu überprüfen? Mit der Systemzeit wird das Ganze wohl nicht funktionieren, lt. google ist die Genauigkeit im ms-Bereich. Woher bezieht eigentlich die 6003 die Zeit (also wann sie einen Messwert aufnehmen soll; Schwingquarz?)?

Freundliche Grüße

Hallo Tobolf,

Zitat:Woher bezieht eigentlich die 6003 die Zeit (also wann sie einen Messwert aufnehmen soll; Schwingquarz?)?

Ja.
Ansonsten Manual lesen: wann immer "hardware timed" genannt wird, erledigt die Hardware das Timing…