DAQ-Anzeige in seperatem VI und Speicherung in TDMS Format

(23.11.2015 23:57 )IchSelbst schrieb:  Ja, und jetzt halt zu den unangenehmen Sachen: Race-Conditions.

Siehe Bild RaceConditions: Auch FGVs, gerade wenn sie so verwendet werden, wie du es (bisher) tust, müssen sequenziert werden. Bedenke folgendes: genau in dem Moment, wenn die eine Sequenz die Daten aus der FGV herausgelesen hat und im Bundle bearbeitet, macht eine parallele, also nicht sequenzierte Task genau das selbe. Frage: welche Daten stehen letztendlich in der FGV und was ist mit den Daten der anderen Sequenz?

Ok, Verriegelung eingebaut. Nach diesen ganzen Initialisierungen kommt eine Sequenz in der 100ms gewartet wird, danach wird die Schleife gestartet.
Bzw. bei dem Clustern zur AVG/RMS/Peak-Wert-Berechung habe ich jetzt die Schieberegister eingebaut.

Zitat:Siehe Bild GanzBöseRaceCondition:
Theoretisch können die FGV-Zugriffe in den beiden Bildern gleichzeitig auftreten. Welche Daten stehen am Schluss in der FGV? Das Problem hierbei ist, dass es hier zu RaceConditions nur ganz, ganz selten kommt - und weil das so selten vorkommt, findest du das im Debugger nicht.

Den Teil hier verstehe ich allerdings nicht. Hier gibt es zwei Aufrufe der FGV, allerdings werden beim ersten Aufruf weder Werte im FGV geändert, noch entnommen. Das einzige, was als Datenausgang wichtig ist, ist der Clustertyp, also die Form in welcher die Daten im FGV gespeichert sind. Diese ändert sich aber im gesamten Programm nicht während der Laufzeit. Das ist nur für die "Bundle by Name" Funktion wichtig. Wo soll es hier zu einem Raceconditionfehler kommen?

Ich lasse mir die AI-Signale ja als Waveform ausgeben. (Ist dann ein Cluster mit den Infos: t0 (Startzeit der Messung), dt (Zeitdifferenz zwischen zwei Samples) und Y (einem Array aus N Samples)
Bei langen Betrieben führt das aber doch zu einer Ungenauigkeit, wenn nicht bei jedem Datenpaket ein eigener Zeitstempel dazu kommt, sondern die aktuelle Uhrzeit berechnet wird mit Jetztzeit = Startzeit + dt*N (mit N = Sampleanzahl)
Vor allem, wenn der Timer der Messbox asynchron zum Timer meines Rechners läuft. Dann gibt es weniger/mehr Samples wie eigentlich eingestellt.

Aktuell simuliere ich mit MAX ein AI-DAQ-Gerät. Dort habe ich einen Task eingestellt (Analoge Signalerfassung) im Kontinuierlichen Modus. Dazu gibt es noch zwei Einstellungen, die ich treffen kann: Samples to Read (Bufferspeicher) und Samplerate (Hz). Wenn ich in MAX den Task umstelle und oben links auf SPeichern drücke, scheint dies allerdings keine Auswirkung auf mein Labviewprogramm zu haben. Mein Sample-VI hat eine Zyklusdauer abhängig von der eingestellten Updaterate und Samplerate.
(Scheint als wär die Samplerate des AI-Tasks des simulierten Geräts auf 1kHz eingestellt.)
Bei einem zu lesenden Sample braucht mein Sample-VI 1ms. Bei einem vielfachen davon ein vielfaches.

Bist übrigens ne risengroße Hilfe.

ToDos:
- DAQmx für die Erfassung der DI-Signale (Kann ich in MAX nicht sehen, welches der dort aufgelisteten simulationsfähigen Devices mir eine kontinuierliche DAQ von DI-Signalen erlaubt? :/ Heißt wohl durchprobieren...)
- Prüfalgorithmen für diese programmieren. In welcher Form soll ich den Alarm speichern, wenn dieser aufgetreten ist? In einer Enum Variablen? Dann kann die Reaktion in einer Casestruktur abgehandelt werden.
- Thema Datenlogging: Ist Speichern in TDMS Format überhaupt sinnvoll? Was ist mit Datalog-Dateien? Oder einer simplen txt-Datei? Die Daten sollen später zum Beispiel leicht in Excel importiert werden. Hab die Anweisung bekommen, dass einfach in eine txt-Datei zu packen, allerdings kennt sich von denen auch niemand groß mit den verschiedenen Datentypen aus. Wäre auf jedenfall recht kompatibel und wieder einfach auszuwerten.

Anzeige-VI, Datenlogging:
So die Datenerfassung und deren Anzeige soll immer laufen, das Datalogging lässt sich durch den Benutzer starten/stoppen.
Ich habe ein Boolsches Control auf dem FP der Anzeige, bei True soll geloggt werden, bei False nicht.
In meinem FGV habe ich die wichtigen Daten wie Speicherort, Dateiname und wie viel % der gesammelten Samples auch gespeichert werden sollen.

Es ist bestimmt nicht sinnvoll in jedem Zyklus (während des Dataloggingprozesses) diese Informationen (Dateiname, Speicherort, etc.) aus dem FGV zu lesen. Soll ich in einer Eventstruktur im Anzeige-VI einen Value-Change der Boolschen Variable "Datalogging" feststellen und bei Start des Datalogging den Prüfalgorithmus einbauen, ob die Datei bereits besteht, sie gegebenfalls erstellen und dann die wichtigen Parameter (Dateiname, Speicherort, etc.) in lokale Variablen überschreiben?
Jeden Zyklus gibts dann eine Caseabfrage: Datalogging? (False: Nichts tun; True: Neuen Datensatz an die Datei anhängen)