TDMS kontinuierliche Datenspeicherung

Hallo Labviewfans,

meine Daten sollen kontinuierlich gespeichert werden, so dass man während einer Messung, die z.B. 2 Wochen dauern kann, schon die Daten abrufen kann, oder bei z.B. Stromausfall nicht alle Daten verloren gehen. Dies möchte ich gerne mit Hilfe von TDMS machen. Nun habe ich folgendes Problem meine Eingänge in das "TDMS schreiben VI" sind unterschiedlich je nach dem was der Benutzer ausgewählt hat.

Der Prüfstand besteht aus einer beliebigen Anzahl aus Prüflingen. Man kann selber entscheiden, was an welchem Prüfling gemessen werden soll.

Die Daten:
von Netzteilen (Strom, Spannung...) insgesamt 5 Messwerte (fester Wert)
von NI Modulen (Spannung Temp) Anzahl Messwerte variable je nach dem wie viele Messstellen montiert.

Nun gibt es drei Fälle:
nur NI-Daten (variable Anzahl Messstellen)
nur Netzteil-Daten (5 Werte)
oder NI und NT Daten (5 Werte+ variable Anzahl an Messstellen)

Mein Problem besteht nun die variable Anzahl an Daten zu bündeln (Merge Signals, build Array?) und dann richtig in die TDMS zu speichern.
Richtig soll heißen, dass je Prüfling eine Registerkarte und je Messstelle eine Spalte vorgesehen ist mit der dazugehörigen Bezeichnung.

im Anhang habe ich meine erstellten Vis hochgeladen.

Über eure Hilfe und ein paar Tipps von euch würde ich mich sehr freuen.

Viele Grüße Henning

Anzeige

Mir ist gerade aufgefallen, dass der Button "Daten aufzeichnen" mit in die While schleife muss sonst funktioniert gar nichts. Das hat aber nichts mit dem eigentlichen Problem zu tun.

Viele Grüße

Bei der Datenbereitstellung kannst du entweder jeden Kanal einzeln schreiben oder mehrere Kanäle mit einem 2D-Array von Daten bzw. 1D-Array von Waveforms. Sobald die zu schreibenden Daten unterschiedlicher Länge sind ist 2D-Array mit Daten nicht mehr geeignet.

Beim TDMS-Format gibt es noch einige Besonderheiten zu beachten. Aufgrund des Streaming-Charakters werden bei jedem Schreiben von Daten auch Teile von Headerdaten (Gruppen- und Kanalzuordnung) mit geschrieben. Das führt dazu, dass bei sehr vielen Schreibvorgängen mit sehr wenigen Datenpunkten je Kanal der Overhead enorm werden kann. Das kann man im Nachgang dann über "TDMS Defrag" wieder beheben.

Bei deinen VIs stellt du eigentlich immer weniger Daten bereit wie du Kanalnamen angibst. Bei den NT-Daten sinds 5 Kanalnamen aber nur 4 Datenpunkte. Die NI-Daten dann unterschiedlich viele Kanäle aber immer nur 1 Kanal mit mehreren Datenpunkten.

Hallo Holy,
danke für deine Antwort ich habe das Problem jetzt so gelöst, wie im angehängten VI zusehen.
Die Daten werden nun in die richtigen Spalten geschrieben.
Bei dem Beispiel stimmte die Anzahl der Namen und der Datenpunkte nicht habe ich auch gesehen, ich habe das in dem Beispiel auch erst einmal so gelassen ist.
Im späteren Programm ist die Anzahl der Namen und Datenpunkte automatisch generiert.

Ich habe nun ein Synchronisationsproblem die NI- Daten sind viel schneller.
Ich habe das Timing auf kontinuierlich eingestellt mit 1000 Sample und beim auslesen auf -1, dass heißt er liest alles was vorhanden ist aus.
Für meine Speicherung bedeutet das aber nun, das er von den NTs immer nur ein Datensatz bekommt und von den NI-Daten immer ganze Arrays in denen mal 10 oder 11 oder auch keine Daten drin sind.
Bei der Speicherung sieht das dann so aus, das z.B. 10 Werte von den NI-Daten gespeicherten werden und von den NTs nur einer der Rest wird mir nullen gefüllt.
Habt ihr eine Idee wie ich das am geschicktesten ändere?

Vielen Dank und viele Grüße

Henning

Für die speziellen VIs würde ich vorschlagen die Schreibvorgänge für die NI und die NT Daten zu trennen, d.h. einmal Schreiben mit allen NT Daten und einmal Schreiben mit allen NI Daten. Je nach Datenpaket wird dann entweder einer der beiden Cases oder beide ausgeführt.
Da du aber Langzeitaufzeichnungen machen möchtest würde ich an deiner Stelle die Speicherstrategie im Allgemeinen aber nochmal überdenken. Über eine gewisse Zeit Daten zu sammeln und im Block zu schreiben ist hier immer sinnvoll. Um der Anforderung "Kein Datenverlust" gerecht zu werden sollte die Zeit dann natürlich nicht zu lang sein. Weiterhin würde mir in den Daten noch eine Zeitinformation fehlen. Entweder die Datenerfassung ist äquidistant dann eignen sich Waveforms oder sonst kann man für Kanäle die immer zum selben Zeitpunkt erfasst werden einen gemeinsamen Zeitkanal hinzufügen.

Ich habe es jetzt erst einmal so gelöst, dass immer ein Sample ausgelesen wird, sodass wenn bei einem Prüfling beides gemessen wird, jeweils nur ein Datensatz vorhanden ist.
Hierbei ist nur die Gefahr, dass ich einen Überlauf der Daten habe, das passiert aber erst, wenn man ca. 3000 Samples pro Sekunde erstellt.
Was für einen normalen Windows-Rechner sowieso nicht machbar ist oder?

An das Sammeln von Daten und blockweise Abspeichern habe ich auch schon gedacht.
Ich muss mal schauen ob ich noch Zeit finde das zu ändern, da ich meine Studienarbeit bald abschließen möchte.

Ein Zeitstempel ist zur Zeit nur bei den NI-Daten vorhanden, für die NT-Daten denke ich mir noch etwas aus.

Vielen Dank

Wenn du gepufferte Erfassung verwendest und nicht alles als Einzelpunkte verarbeitest kannst du 3000 Samples/Sekunde um ein vielfaches überschreiten.

Eine Sache noch zu NI TDMS und dauerhafter Datenaufzeichnung.
Beim häufigen Schreibaufrufen (mit wenigen Daten) wird normalerweise ein TDMS-Segment auf die Platte geschrieben. Das bedeutet das für z.b. 20 Byte Nutzdaten jeweils auch ein kleiner Header (40-50Byte afair) als Overhead geschrieben wird. Das bläht zum einen die .tdms Datei ziemlich auf, zum anderen legen die NI TDMS Funktionen eine Art Cache für die Header (.tdms_index) an. Diese Datei wächst dann auch mit jeder Schreiboperation mit an. Das beides wäre erstmal nur "Verschwendung" von (billigen) Plattenplatz, was es aber wirklich ärgerlich macht, ist dass die der Speicherverbrauch der Applikation etwa in der Größenordnung der tdms_index Datei mitwächst. Das sieht auf den ersten Blick dann wie nach einem Speicherleck aus, ist aber (broken) by Design. Wenn es blöd läuft, steht dann ein Prüfprogramm nach ein paar Tagen (üblicherweise kurz vor einem langen Wochenende) mit einer Fehlermeldung der VC++ Runtime.
Für einen solchen Anwendungsfall gibt es eine interne Bufferfunktion in der API ("NI_MinimumBufferSize"). Damit kann man den Speicherverbrauch zähmen. Allerdings landen die Daten dabei nicht gleich auf der Festplatte, bei einem Crash wären also einige Daten futsch (kaputte TDMS-Dateien sollten inzwischen aber nicht mehr vorkommen).
Anbei mal als Beispiel in deine Datenspeicherung integriert (aber nicht getestet).