LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to record user interface inputs along with measured data in a TDM file?

Solved!
Go to solution

Hello,

 

I have built an user interface to monitor and control a pump test bench, I am using the USB-6212 in a Windows PC with the newest SW and drives.

Now I am trying to collect all the measured data, and the control values entered in the user interface, continuously at 1kHz, and write them into a single TDM file.

 

The problem is that only the measured signals get logged correctly, but only a few values at the beggining of the file are saved from the user interface; then is all blank.

 

I have tried everything, generating waveforms, synchronize them with the measured data to get the same timestamps, aling & resample, and collector blocks from the Signal Express toolbox, but there is always some data missing from the user interface.

 

In my original configuration, shown in the post, I have configured the Analog Input block to read continuously at 1kHz with 100 samples, while the Analog and Digital Outputs to On Demand writting. I have included the complete file, just in case some block is causing the disturbance.

 

Test Bench.vi Block Diagram.png

TDM file values

 

0 Kudos
Message 1 of 6
(3,544 Views)
Solution
Accepted by topic author gonzaro

Your DAQ express VIs will likely be reading/writing multiple samples for each execution, whereas you wire only a single value for your setpoints. The use of the dynamic signal data type hides this information from you (which is why no-one uses them once they become more familiar with LabVIEW).

 

You need to either take only the single latest value from the dynamic data, or pad your setpoints so they are the same size as your dynamic data. If you're reading/writing 100 samples at a time, then you will only have your setpoints once per 100 values. You'd need to create an array/waveform of 100 points with the same value.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 6
(3,530 Views)

Thank you very much for the quick response. I have implemented the suggetion of the 100 element array, and it seems to work fine.

 

My doubt now would be, if my implementation ensures that the setpoints, and measured data are synchronize?

Also about, if it is possible to get less samples per read than 1/10th (100S on 1kHz)? in order to reduce the array size, not to have too much padding (more accurate synchro between inputs and outputs).

Does this depends on the application cycle time?

 

 

2016-01-25 22_33_57-Test Bench.vi Block Diagram _.png

0 Kudos
Message 3 of 6
(3,497 Views)

Your doubts are correct.

 

 

With 100 samples at 1kHz, your loop will, in theory, run at about 100ms per iteration. If you make that 10 samples then it will be about 10ms per iteration. I say 'about' because you are doing your control on Windows which is not a deterministic OS (you should use LV Real Time for that).

 

It may also be that the Express VI is initialising/closing the device each time and you of course have some additional operations you are performing in the loop such as the filtering, setting signal attributes and the logging to file (which is normally quite slow). The producer/consumer architecture sends the data to be logged to a different loop so the DAQ/control loop can run faster and is less likely to be interrupted/slowed down by file I/O operations.

 

Also, for control applications, you would typically only want to act on the latest data (or the value after it has been filtered/averaged).

 

You can easily benchmark your application (i.e. to determine your actual loop rates) with some timing VIs and a shift register/feedback node.

 

I would of course, always recommend that you switch over from using Express VIs to using the VIs from the DAQmx palette to allow you to initialise the device outside of the loop and therefore improve the performance inside the loop.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 4 of 6
(3,483 Views)
Solution
Accepted by topic author gonzaro

I you want to save some storage, you can also choose to store the GUI buttons to a secondary TDMS file and storing all the channel data together with a timestamp only when the GUI changes.

 

So instead of xx channels at 1 khz for the buttons, you store them only when they change.

Later you can copy the second file into the first file using a different groupname.

Floris Reinders
Senior Project Engineer / CLA
0 Kudos
Message 5 of 6
(3,453 Views)

In case you are storing always a new file whenever the GUI buttons are changing - including channel data -. And put the GUI Button status as properties to the file. You can then later use DataFinder to search for files with a specific GUI button status. And then do whatever you want to do with these files (concat, compare, statistical analysis)...

0 Kudos
Message 6 of 6
(3,393 Views)