LabVIEWForum.de

Hallo Leute,

ich benutze LabVIEW schon eine ganze Weile.
Eins ist mir nun etwas rätselhaft. Vielleicht kann einer von euch Licht ins Dunkel bringen.
Es geht um das Streamen von "Mess-"Daten in eine TDMS Datei.

Wenn ich fortlaufend in einen Kanal einer Gruppe schreibe wächst die TDMS-Datei "sehr" langsam an. Vor allem die *_index Datei bleibt sehr klein. Wenn ich nun eine weiteren Datensatz parallel in eine andere Gruppe / anderen Kanal schreibe wächst vor allem die *_index Datei fast in gleicher Geschwindigkeit mit. Ich habe eine Beispiel Datei erstellt und das mal ausprobiert. Wenn ich nur in einen Kanal streame wird die TDMS Datei einige hundert Kilobyte groß und die _index Datei knapp einen Kilobyte. Wenn ich nun wie im Bild noch einen Zeitkanal hinzunehme werden beide Dateien mehrere Megabyte groß.

Aufgefallen ist mir dieses Problem schon öfter. Bisher habe ich mir immer damit geholfen, dass ich die Daten in LV2-Variablen zwischengespeichert habe und nur sehr selten in der TDMS Datei abgelegt habe. Ich frage mich halt nur, ob es da nicht einen besseren Weg gibt. Zumal es bei der Variante mit dem Zwischenspeichern zu Datenverlust kommen kann.

Bin für eure Anregungen sehr Dankbar.
Gruß
Tobias

Bei Einzelwerten tut sich die TDMS API schwer. Das NI TDMS per USI ist wohl eher auf Highspeed Streaming optimiert. Das Problem mit den großen Dateien und vorallem mit den großen Index Dateien kommt daher, daß am Anfang eines jeden TDMS Segment ein Segment Header mit ca. 50 Byte mit geschrieben werden muss (+ alle Header landen im _index).
D.h. wenn man Einzelwert schreibt bläht das die Datei ziemlich auf. Dein Usecase müsste da jeweils 2 Segmente pro Iteration anlegen (1 TS Zeit und 1 I32 Test). Anscheinend spart sich die API die Segmentheader, wenn nur ein Kanal geschrieben wird (da gibt's so ne Magic Number für die Segmentlänge die bedeuted, daß diese Segment das letzte/offene ist).

Als Abhilfe gibt es die Minimum TDMS buffersize mit von der TDMS API Werte zwischengepuffert werden und dann Blockweise geschreiben werden.

Alternativ könntest du auch die G based TDMS benutzen, die schreibt keinerlei tdms_index, hat aber in der Orginalversion kein internes Buffering mit drinnen, d.h. Einzelwerte haben immer den Segmetheader Overhead mit dran.

Bei beiden Schreibmöglichkeiten wird dir das TMDS Defrag die Daten + _index wieder schön eindampfen. Mlgw. wäre das für deinen Usecase das Einfachste.

Ich würde dir im allgemeinen die G TDMS empfehlen. Mit der NI USI basierten TDMS API habe ich schon Pferde kotzen sehen. (Die aktuelle USI die mit LV2011 ausgeliefert wird, ist wohl recht stabil, habe ich mir sagen lassen )

Das hilft mir sehr weiter.
Das TDMS Defrag nutzt mir auf jeden Fall schon sehr.
Die Nummer mit dem G TDMS werde ich mal ausprobieren.
Vielen Dank auf jeden Fall.