回复： TDMS file length does not match lead-in data

[Sara_J]

My project uses a TDMS file each test run to record numeric data.  The basics here:

- Tests can be stopped and later resumed, appending the new data to the existing TDMS files.

- TDMS files are viewable during tests.  This is done by making a copy of the file (temp.tdms) so that the test can continue writing to the "real" data file while the user is also able to review the data.

- TDMS file viewing is accomplished via LabVIEW's TDMS file viewer; we're not using any special custom ting for that.

- All operations are advanced TDMS, asynchronous writes.

We are seeing some odd behavior, however.  Viewing the data file works just fine if the test is running for the first time (has never been stopped/resumed).  It also works after the test has been stopped as long as the test is not running (before being resumed or after being resumed and then stopped again/finished).  However, if the user stops the test, resumes the test, and then tries to view the data file while the test is still running, the TDMS viewer reports error -2503, "Specified file does not comply with TDMS file format standards."

I have found the detailed description of the TDMS internal file format structure provided by NI, and I have been able to determine what the problem is.  The Next Segment Offset recorded in the file's lead-in does not match the actual length of the data present in the file.  There appears to be one extra record which is not accounted for in the Next Segment Offset.  (My confirmation of this theory:  If I open the file in a text editor and remove the final 88 bytes--one record's worth--manually, the file opens just fine again.)

My problem is that I cannot for the life of me figure out how this is happening.  Has anyone else had this problem?  Any ideas about how it might be happening?  I think it must be something in the way the file is opened when the test is resumed (as the file is fine when the test is running), but I can't see anything that looks out of place. 

I am not at liberty to post the code itself, but here is the sequence of VIs--any unspecified values are left at default:

Initial opening/creation of file:

- TDMS Advanced Open.vi, buffers NOT disabled

- TDMS Configure Asynchronous Writes.vi, max asynch writes 1, data type DBL

- TDMS Set Channel Information.vi, group Data, channel names 1D array of 11 strings, data layout interleaved, samples per channel 1, data type DBL

Opening the file for resume:

- TDMS Advanced Open.vi, buffers NOT disabled

- TDMS Configure Asynchronous Writes.vi, max asynch writes 1, data type DBL

- TDMS Set Next Write Position.vi, group name Data, channel name (name of first channel), from end

Data records are then written using TDMS Advanced Asynchronous Write.vi with an array of 11 DBL values as the input.  The file is closed using TDMS Advanced Close.vi when the user chooses to stop the test or the test is complete.  These operations are performed using the same VIs regardless of whether the test has been started new or resumed.

None of the above generate any errors; the error only happens when attempting to view the temporary copy of the data file after the test has been stopped and resumed.

Any help you can give would be very much appreciated.  Thanks.

--Sara

[deppSu]

Hi Sara, For some performance reason, TDMS will update "Next Segment Offset" in Close function of TDMS Flush function. In other words, you can't copy a temporary TDMS file while logging and view it. However, TDMS supports open the exact same file and view it while it is logging. Another solution is that, you can call Flush before the copy. BTW, I noticed that you set max async writes to 1 for TDMS Configure Asynchronous Writes, in that case it almost equals to synchronous write. For the best performance of TDMS Asynchronous I/O, you could set multiple asynchronous writes/reads and use Reserve file size node.

[Sara_J]

Thanks!  That definitely gives me something to look at.

As for the asynch write count, I suspected as much.  ::sigh::  This is code that was written prior to my involvement with the project, the programmer who wrote it is no longer around, and we're close enough to finally having it all working that I'm hesitant to change something that essentially works unless the client specifically requests trying to improve the performance.  But I do appreciate the info, it will help me in future projects.