tdms_index pitfall

[Götz Becker]

Hi,

last week I had to hunt down a strange bug in a LV 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 LV 8.5.1 Windows.

Download File:post-1037-1218464169.vi

Greetings

Götz

crossposted in NI Forums: tdms_index pitfall