LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

continuously save data of different hardware signals (fast and slow read-out intervals) to one TDMS file

I need to measure several signals (like preasure, resistance, phase, frequency, temperature). The read-interval differs between 50 ms per sample up to 1 s or more per sample. So I think I have to put them into seperate loops. I know how I could write the measured data for each loop into a tdms-file continuously. But I would end up with several tdms-files. I would prever to get all measurement data into one file. But I'm not sure how to do this. Here are 2 of my ideas:

 

- First save all the data in seperate temporary tdms-files (so I at least have the data if something goes wrong). At the end of the measurements somehow combine the temporary files into on tdms-file (but I don't know if thats even possible?).

 

- Use some kind of channels. All data is written in the fastest loop. The data from the other loops is provided via channels. But which channel-type should I use? The fastest loop cannot wait for the channel to have a value. Can I somehow read out the last sent value without emptying the channel? Or gete.g.  a NaN if the channel is "empty"?

 

What would be the best approach to solve this issue?

0 Kudos
Message 1 of 5
(719 Views)

Still not sure whats the best way to do this, but I finally used a User event (as a singleton) and so far it works for me.

0 Kudos
Message 2 of 5
(670 Views)

Hello, I'm a beginner and ran into the same problem.

My solution, which I'm sure is not optimal, was to break up the fast and slow tasks into two parallel loops. One loop handles all the slow tasks (RS-232 data, thermocouples, etc) and the other loop handles the fast tasks (analog and digital IO). I then use a 3rd parallel loop to write my TDMS file, this results in the slower data getting copied over and over again until it finally updates but it is all in one file that logs as fast as I need it to.


0 Kudos
Message 3 of 5
(641 Views)

Splitting things up into parallel loops was a good approach.  But it wouldn't have been necessary to write the slower data repeatedly.  That approach is the kind of the thing I've done when writing to a very simple text file like .csv format.   But one of the key benefits of the TDMS format is the ability to write different data at different rates and avoid such redundancy.

 

Overall good job though, using parallel loops as a self-professed beginner.   Dunno *how* you're getting data from the producer loops to the logging loop, but let me suggest you look over the QMH template, at least a little bit.  Key points: the use of queues as the mechanism for moving data, the use of a special cluster as the datatype for that queue.

    The idea is that the datatype carries both a "message" and a generic "payload".  There's a bit of a religious war over whether the message should be a string or an enum, and there are decent arguments both ways.  Either can work just fine.  The payload is purposefully generic so it can carry a wide variety of possible "payloads", each corresponding to whatever is needed by that particular message.

    In your case, you might have messages like "RS232 data", "Temperature data", "AI data", DI data".  Payloads would be the corresponding data.  Your logging loop could use the message as the channel name when writing to TDMS, and each source would be free to deliver data at different rates.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 5
(631 Views)

DPM@ch wrote:

I need to measure several signals (like preasure, resistance, phase, frequency, temperature). The read-interval differs between 50 ms per sample up to 1 s or more per sample. 


It is possible to take data of different sampling rates in the same loop - you just collect different numbers of samples so that the time between each data collection is the same. If you have data that has a sampling rate of greater than 1 s/sample this may not be desirable though, so separate loops is likely the best approach for your case.

 


DPM@ch wrote:

 

- First save all the data in seperate temporary tdms-files (so I at least have the data if something goes wrong). At the end of the measurements somehow combine the temporary files into on tdms-file (but I don't know if thats even possible?).


Don't do this. It's certainly possible but there's no need for it. 

 


DPM@ch wrote:

 

- Use some kind of channels. All data is written in the fastest loop. The data from the other loops is provided via channels. But which channel-type should I use? The fastest loop cannot wait for the channel to have a value. Can I somehow read out the last sent value without emptying the channel? Or gete.g.  a NaN if the channel is "empty"?


Don't do this either. Instead send data from ALL of the data acquisition loops to a logging loop. I agree with Kevin_Price that a QMH is a good way to accomplish this. This gives you simple control over the structure of the TDMS file. There's no need for the NaN if you structure everything correctly (every data type is saved separately).

0 Kudos
Message 5 of 5
(627 Views)