Götz Becker Posted August 12, 2008 Report Posted August 12, 2008 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 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.