LabVIEW
Save to TDMS file an array of clusters with different sample rates
@mrMesteves wrote:
However, I'm not able to store an array of clusters with tdms.
Well you can but it probably isn't what you want. You likely want to come up with a way to flatten the data a bit into data for the specific channels.
If you are dealing with data of different sample rates, there are a couple ways to log data. One method is to have a different group for each sample rate, and have a single channel in that group define "Time" for those samples, so something like this:
- Temperature Data [Group]
- Temperature Time [Channel]
- Temperature 1 [Channel]
- Temperature 2 [Channel]
- Voltage Data [Group]
- Voltage Time [Channel]
- Voltage 1 [Channel]
- Voltage 2 [Channel]
This works well if you only have a couple of different sample rates and multiple signals at each rate. If every signal is sampled at different times then it would probably be best to log those all separately, either as their own waveforms where a property can log the start time and the times between samples, or give each channel their own time channel for data that doesn't come in at defined periodic rates.
- Data [Group]
- Temperature 1 Time
- Temperature 1 Data
- Temperature 2 Time
- Temperature 2 Data
- Voltage 1 Time
- Voltage 1 Data
- ...
And in all of these cases "Time" can be a timestamp, or relative time from something like test start. Or you could choose to have two time channels one as absolute and one as relative. There are lots of options with TDMS, so much so that it can be hard to decide what format you want and most of the time I'll start out thinking about how something will be used or read later to help guide the design of the file layout.
In that case what is wrong with flattening all the data and putting it all in one group? Yeah Position will store the same value but the data will be on the same time scale as everything else. You could write code that looks for if position has changed, and only log the data when it has but I think that would make consuming the data more difficult on other tools.
Thank you for you answer.
Yes, you are right, and what you show as an example is what I want.
However, I do not have this type of structure available .
My" sines and cosines" are get from this Analog while loop.
I thought that would be better putting the "Acquired Data" variable (which is the position" into this while loop, and I created an array of clusters.
Is it possible to have the data as you suggested at LogTDMS.vi hooovahh ?
I started with Labview 2 weeks ago. it is possible that I'm making a lot of mistakes.
I do see a lot of local variables which isn't necessarily bad but can lead to things like race conditions. And I assume this is one of those places that this is happening. You have a loop just acquireing data, and another loop aggravating the data I assume for logging, but they aren't synchronized in any way. What if you acquire 1000 times, and then log once? Well you will record the last time you acquired and the other 999 times you acquired the data will not be logged and will be lost. This isn't the original question you asked but I assume it is one place you are having issues. If you know your logging of data takes a short amount of time compared to the time it takes to acquire you can have your logging function in the same acquire loop. Alternatively you can have a separate loop of acquire and log, but have some kind of method of sending data to the logging loop like a queue, or a channel that is lossless.
As for the structure of the TDMS file. You can log your array of waveforms without any real issue, but your Acquired Data has no time associated with it, and you don't even have a way of knowing what the delta between samples is. Even if you logged the Acquired Data separately, there isn't any time information with it, and the number of samples between the Array Waveforms, and the Acquired Data likely won't be the same size.
Attached is one way to log the waveforms at least. It keeps all the acquired data in an array of waveforms, and keeps appending data to it until it reaches a size, and then logs them all to disk and clears the buffer. This way memory doesn't just continue increasing forever and crash. I still don't know how to handle the position encoding and I'm not familiar with how it is read so I just am reading single point positions, and getting the time then logging all those times and values in a new TDMS group at the end.
If I were to do this application I would have choose a different design, and used more subVIs and State Machines. I'm sure it doesn't help too much beyond the basics but there are lots of free training things online to learn more about LabVIEW if you're interested. But honestly the way I learn best is by shadowing someone else and you don't really get that from these training videos.
Oh and once you have a TDMS file checkout Scout by SignalX, the TDMS Excel Importer, or the TDMS Viewer on the palette.
State Machines aren't 1337. They are a very basic computer engineering concept, and one that makes life much much easier. I'm sure you have little desire to become a LabVIEW expert and just want it to work, but taking the shortest path to this type of goal is the wrong way to go about doing this. You will pull your hair out and spend hours going in circles changing things you don't fully understand. It won't be satisfying work, and you likely won't learn anything.
