DAQ-Anzeige in seperatem VI und Speicherung in TDMS Format

Racecondition und FGV:
Ich möchte vermeiden, dass ich Daten auslese verändere und danach die veränderten Daten wieder zurück ins FGV schreibe (Aktion 1), da in der Zwischenzeit ein anderes VI auf die selbe Weise darauf hätte zugreifen können und fälschlicherweise die unveränderten Daten entnimmt, wodurch Aktion 1 ignoriert worden wäre. Soweit verstanden.

Zitat:Die Lösung an sich ist ganz einfach:
Einen weiteren Case (Enumerator) in der FGV definieren, und die Daten per Variant in die FGV schieben: Die FGV aufrufen und in ihr arbeiten kann immer nur einer - der andere muss warten.

Was für ein zusätzlicher Case? Diese grundsätzlichen Funktionen "Auslesen" und "Reinschreiben" kann ich ja nicht umgehen.

Solange ich aus dem FGV nur Daten auslese, oder solange die reingeschriebenen Daten unabhängig von den vorigen Daten im FGV sind, kommts erstmal zu keinen Problemen, soweit ich das sehe.
Bei dem Bild "GanzBöseRaceCondition" ist es ja beispielsweise auch egal, ob zwischen diesen Aufrufen irgendein anderes VI auf das FGV zugegriffen hat.
1. Aufruf: Liest das Cluster aus, um es für die Funktion "BundleByName" als "Clustertyp" zu benutzen. Welche Werte im Cluster stehen ist egal, es ist nur wichtig, welche Variablen überhaupt im Cluster stehen und wie diese heißen.
2. Daten reinschreiben: Hier wurde das "BundleByName" Cluster mit Variablen gefüttert und überschreibt so bestimmte Variablen im FGV.

Dein Vorschlag ist nun Variant-Cluster einzulesen, und im FGV dieses Cluster zu typisieren und dann die richtigen Variablen zu überschreiben? oO


Kontinuierliche Erfassung Digitale Signale DAQmx:
Hatte in MAX ein paar simulierte Devices erwischt, die nur "On Demand" Signale erfassen konnten. Aber hat sich geklärt.

Datalogging Dateiformat:
Ich informier mich mal nochmal über TDMS, txt und CSV.