Hi,
last week I had to hunt down a strange bug in a LabVIEW app.
The usecase looks about like this.
The user can create a table with setpoint values in a small editor. As fileformat for this we choose TDMS-files with a waveform in it.
A host application transfers the file to a RT system (since all documentation calls the tdms_index files optional, we do not copy them). The RT app reads the wfm and uses the values for a motion control task.
So far so good a simple mechanism for a simple problem... but... a strange behaviour happened. _Sometimes_ the wfm weren´t completely read out of the TDMS file.
What happened is the following:
The user made a file (e.g. named "file1.tdms") with a wfm-length of 100 points. Transfered it to the RT (only the tdms file get´s copied) and starts the control task. At this point the TDMS-file functions recreated the tdms_index when reading the file for the first time. Then the user decides to alter the wfm in his editor on the host, creating a new one with a wfm-length of 1000 points saved under the same filename (file1.tdms). This file gets again transfered and read in by the RT app. But now the TDMS-file read returns only a wfm with 100 points!
The problem is the tdms_index file from the first read operation. It only knows about a "file1.tdms" with a wfm with 100 points. It looks like the TDMS function only use the filename to decide if and which _index should be used. No other check seem to involved!?!
Our quick and dirty workaround now is to try deleting the _index files before every load.
The attached VI shows the same behaviour under LabVIEW 8.5.1 Windows.
crosspost in LAVA:
tdms_index pitfall
LabVIEW user groep 