LabVIEWForum.de

Hallo zusammen,

ich habe zwei Fragen - ein Problem und eine Frage "was wäre das praktischste":

Das Setting: Ich mache grade einen Versuchsaufbau, bei dem ich den unterschied im Frequenzgang von mehreren Materialien vermessen will. Dafür speise ich ein für alle gemeinsames Referenzsignal ein möchte hinter allen (in diesem Fall) 3 Materialien das Signal für eine feste Zeitdauer messen (für jede Frequenz ein "Sample" von z.B. 3 Sekunden).

Die Idee ist also ganz einfach: Ich habe die Standard State Machine von LV so umgebaut, dass bei "Klick" 4 DAQ Channel (ist ein USB-6003) mit einer vorgegebenen Samplerate gleichzeitig ausgelesen werden, für genau X Sekunden. Das Projekt ist im Anhang.

Ich möchte zum Schluss gerne einen Versuch machen, bei dem ich zu verschiedenen Zeitpunkten (Abstände von 30min.) pro Frequenzpunkt eine Messung (also z.B. von 1-50Hz in 1Hz Schritten) aufnehme und abspeichere.


Nun das Problem:
Die SM funktioniert zwar, "laggt" das DAQ signal hinterher! Für ein Beispiel siehe das Bild im Anhang. Ich nutze da ein Signal vom Wavegenerator meines Oszis (leider schrecklich 50Hz überlagert in niedrigen Frequenzbereichen).
Lege ich ein Signal an und mache eine messung - und klipse das signal dann ab und mache noch eine Messung, bekomme ich offensichtlich noch Samples aus dem DAQ Puffer, die den Übergang (Signal on->off) beinhalten.

Ich wette die Profis unter euch sehen in meinem VI direkt was schief läuft! Könnt ihr mich aufklären? Ich habe extra im "Wait for Event" state einmal DAQ Read (mit number of samples per channel =-1) implementiert in der hoffnung, dass wärend dem "wait" der buffer so immer aktuell gehalten wird.


Noch die Frage: Wie würdet ihr das Data Logging am besten umsetzen? Derzeit bekomme ich ja für jede Messung einen Cluster aus 4 Waveforms und ein paar Parametern (Zeit, gemessene Frequenz etc).
Ich weiß noch nicht, was das beste ist: Nach dem Versuch ein paarhundert Files (jede gemessene Frequenz zu jedem Zeitpunkt) oder etwas, das alles zusammenführt - nur da wüsste ich noch nicht, was das beste sein könnte!


Allerbesten Dank für jede Hilfe (und sonstige Anmerkungen zum VI)!!

Grüße

Alex

P.S. Derzeit ist noch kein Speichern implementiert, die Messdaten kommen also nur in den Graphen

THINK Dataflow, sag ich nur!!!

Was passiert:

• Im State "Initialize" definierst UND startest du den kontinuierlichen DAQ-Task. Der läuft also jetzt und schiebt lustig Daten in den FIFO.
• Dann kommt der State "Wait for Event": Da wird jetzt zwecks Event-Struktur solange gewartet, bis irgendein Button betätigt wird. Der DAQ-FIFO wird dabei 1x direkt beim Übergang in den State gestartet. Der DAQmx Task läuft dabei brav weiter und schiebt nach dem Auslesen wieder Daten in den FIFO (solange, bis er überläuft und Daten überschrieben werden).
• Jetzt wird z.B. Start gedrückt, deine State-Machine springt endlich in den Datenerfassungsschritt. Ausgelesen werden jetzt zuerst die ältesten Daten aus dem DAQmx FIFO Buffer, und nicht wie du vielleicht hoffst nur die Daten ab Drücken von "Start".
  

Gruß, Jens

Herzlichen Dank!
Ich hatte übersehen("überdacht") dass die der "wait for event" state ja gar nicht im loop durchlaufen wird (so hatte ich das sonst immer implementiert) und damit auch der einmalige DAQ-read task unnütz ist um den Buffer kontinuierlich zu leeren.

Mit Start / Stop im Measurement State sollte das ganze richtig sein - oder?

Beste Grüße

Alex

Ich denke schon.

Kritikpunkte am BD:
- aufräumen
- Index Array kann man nach unten aufziehen
- Das Wait kannst du dir sparen, wenn du am Eingang von DAQmx Read die Anzahl der Samples für 1 Sekunde anschließt. DAQmx Read übernimmt schon das Timing für dich. Damit fällt auch die Flat-Sequence weg
- Bitte keine PropertyNode zum Lesen und Schreiben von "Value", außer es ist unbedingt nötig. Dann lieber eine lokale Variable
- Wieso die Mean-Funktion aus dem wenig verbreiteten Extra-Toolkit? Die gibt es doch unter den Standard-Funktionen...

Gruß, Jens

Besten Dank, Vorschläge wurden umgesetzt!

Ergänzung zu "Index Array kann man nach unten aufziehen":
Man kann sich auch die Konstanten an den Indexeingängen sparen, wenn man bei Null beginnend hochzählt…

Ergänzung zu "Bitte keine PropertyNode … Dann lieber eine lokale Variable":
Du nutzt schon ein Schieberegister mit einem Cluster, um Einstellungen/Parameter zwischen States auszutauschen. Dort gehört auch die Samplerate hinein und wird dann mittels UnbundleByName ausgelesen!

Danke, ich gebe zu der property node war faulheit (das habe ich in QSM architekturen sonst auch so gemacht wie du gesagt hast).
Ich versuche mich zu bessern!