02-27-2014 09:59 AM
Thanks Zaizhou.
Zaizhou & Karl: I assume that it is not a good idea to attempt a TDMS Defrag while the file is still open for wrting or reading elsewhere? Again, neither the standard or advanced TDMS write seem to support writing to multiple groups in a single write and writing to one group followed by a write to another group, even in the same loop, generates a new header. In my arrangement I want to write to multiple groups with each write, to avoid the additional header of writing separately as well as for program organization. I will be writing the exact number of data to the exact same channels to the exact same groups. Is it not possible to do this in a single write, buffered or not, decimated or interleaved, advanced or standard TDMS commands?
02-28-2014 05:42 PM
I think your instincts on not defragging the file while it is open for recording is probably a safe bet. I would only attempt the operation at the end of the data collection. I would keep experimenting with the TDMS Advanced functions. I will attempt to replicate some of this behavior next week and will hopefully have some more answers for you.
Have a good weekend!
03-04-2014 08:28 PM
You are right. It should close the file first then defrag the file. For STD TDMS, I believe you cannot write to channels under different groups by a single write. For Adv TDMS, it could do so. Please refer to the attached VI.
03-05-2014 02:36 PM
Thanks Karl.
Zaizhou, that's great info and thanks for the example. When I use a hex editor to look at the TDMS file created with your example, I noticed that there is considerable space (filled with zeros) between the TDMS header and the start of the data. If I change the File Open in the example to 'Open or Create' and run the vi multiple times, this "wasted space" is repeated. Do you have an idea why?
03-05-2014 07:42 PM - edited 03-05-2014 07:50 PM
Adv TDMS is designed for performance. On Windows OS, in order to use 'disable system buffering' for writing performance, it require sector-align data for very write to disk. So, Adv TDMS will create a 4 KB header and fill the gap with zeros.
The best use case for ADV TDMS should be that set the header information at the beginning and then keep logging the same-layout raw data. If you need to call the 'set channel information' repeatedly for your scenarios, then STD TDMS is more suitable.
03-07-2014 08:11 AM
Thanks for the explanation Zaizhou. I was aware that you could align with sectors using advanced writes but thought that you had to configure/program it to do so. In my case I will be recording for 24 hours at a time and was concerned about the file size growing with this zero padding and possible redundant headers. Since I will be repeating the same writes (mostly) this should not be a problem. There will be occasion when I will write some data intermittently different than the repeating data, thus I plan to defrag the file after closing it. I need to continuously sample but close the file after 24 hours and then defrag that file while continuing to write to the new file. The LabVIEW help for TDMS Defragment does not have an example nor does the Example Finder. Could anyone suggest the best approach or point me to another discussions or sample code? This seems like something that other programmers would encounter frequently but I cannot find an example.
03-10-2014 04:41 PM
For your specific case, I would modify the data collection code you have and write data more frequently to simulate a longer test. This way you can monitor the need for the TDMS defragmentation (file sizes may be acceptable as-is), and if it is necessary, find the defragmentation's effects on your data.