LabVIEW
TDMS Measurement best practice
Yeah TDMS has an API that can buffer data for efficiency. When using the DAQmx streaming, you won't see the file have any real size until it is flushed to disk, which will happen when the file is closed, or when the API feels like it. That last one has several variables associated with it but NI wants you to not worry about it. Logging to a TDMS file will not eat up all of your RAM until it crashes, it will flush to disk if you have really long running tasks. But if you are conserned you can force a new file as Ben mentioned.
I presented on TDMS at NI Week 2016, here is the content, sorry no video. I think what you will find is that TDMS can be a large topic. There's plenty of things to avoid (like unnecessary writes), but doing these things won't generally break things, it just might result in a poor experience, or you might not even notice. The design and structure is up to you and that might be one place where people make mistakes since they don't really know what works and what doesn't when they first try it out. If you have N devices should you have N TDMS files? or N groups in a single TDMS file? Or just all the data in one group? What properties should I write to the channel? Group? File? These all depend on the application and I can make suggestions based on a design but until you use it for a little while generating data, and seeing how the other users consume that data, you won't know if the design was a good one. Sorry for such a long answer when I could have just said "It's up to you".
@isitthereur wrote:
The DAQmx TDMS logging feature is excellent but what if I have 2 separate sync tasks?
I'd suggest logging to two separate files, and then merge the two TDMS files at the end. You could also not use the built in logging and read the DAQ then write them separately but I imagine it would be better to merge them. Merging is a pretty fast process and is mentioned in the linked presentation.
Splitting isn't as straight forward. You can split a TDMS file at every segment but if you defrag your file there will only be one segment. If your files are getting to large, just close the file and start a new one mid test. Also if you defrag at the end of the test your file size is generally going to be reduced. There are other methods of splitting files that are less straight forward, and require more resources but can be split in very custom ways like ever N samples.
@isitthereur wrote:
Also I will have large TDMS files which will need to be split into smaller managable sizes.
The DAQmx TDMS Streaming allows for this. Just use a DAQmx Read property node and write to the Logging->Samples Per File property. And new TDMS file will be created ever X samples automagically for you.
