Data acquisition with queue structure mechanics

[balazsmore]

Hello!

I currently work on my thesis and I need to make a measurement program to save data from 5 different sensors. I attached a file which is my first try with triggers etc., but these triggers cut the saved data. (I have 5 measurement in one cycle), the attached file is important for to see the sensor inputs, so there are 2 devices, and that VI is not good,so take that with a grain of salt. Others are working on this project too, so the measurement cycle should be stored in one tdms with no cuts. My consultant said, it could be possible to do the task with queue structure (producer and consumer loops). The task I need to do is, with a button press the measurement should start ( it's the easy part xD) and keep measuring, till another mouse button is hit, and write the middle section to a *.tdms file. But parallel with the measuring, the program should notice the part of the measurement, where the machining starts (the program is used in milling operation). So my first thought was, like I could give a smaller datasize what I enqueue, then doing moving average on it. If it is above a certain level, the datasize which I enqueue should grow to a specific number of data (which I can define before the measurement), after this bigger data is stored, I want to throw it in a matrix and doing some things with that ( like getting its RMS value and other similar things). But after this, the datasize I enqueue should go back to the smaller value, and keep checking for changes like before that, and doing this 4 more times. I am new to this part of LabView, like the daqmx and this queue structure, so I just want to ask that, is it even possible to do a program like this. I found a code example for data acqusition with queue structure, which I planned to use, but this kind of data analysis parallel with the measurement, and the changing queue size is not so clear to me, so I don't know it is possible or not. 

Thanks,

Balázs

[ZYOng]

I am trying to understand your description of the requirements. Please correct me if I am wrong. There are three stages of the acquisition:

1. Low sample rate monitoring with moving average, waiting for a threshold

2. Threshold is met, high sample rate logging and data processing with RMS value (for how long?)

3. Repeat steps 1 and 2 for a total of 5 times.

[balazsmore]

Yeah, I am sorry, I tried to put too much information in short text. So it is almost the case. 

What I tried to explain:

1. Monitoring with moving average, waiting for the threshold, the low sample rate is not necessary, but could be, but the sample size is the critical element. In the picture you can see the measured data from a previous measurement, where the measured data value is around 0, there would be a small sample size, so for example 100 datapoints get in the buffer. Then looking for change in the moving average continuously.

2. If the treshold is met, I want to change the size of the sampled data to for example 10 000 datapoints. After I get the 10 000 data, I want to process those data, and also getting back to the 100 data sample size, and waiting for the treshold to met again.

3.Repeat these steps.

[ZYOng]

In my opinion, I think that the easiest approach would be acquiring the data at a fixed rate of 10k and enqueue the data in the producer loop. In the consumer loop, you can do any data post-processing, including resampling the data to a smaller sampling rate, moving average or RMS etc.

[santo_13]

My recommendation also aligns with ZYong's.

Acquire at a fixed rate as you don't save time or anything (may be couple of MB memory) by sampling at a slower rate, you can downsample it by skipping samples or averaging or other techniques in the processing loop (consumer loop).

[balazsmore]

Hello!

I don't know, that I get it right, but I tried to make a VI with that. So the first device, which is connected to 2 sensors (in this case a microphone and an accelerometer). So in the upper while loop I get that DAQmx Read, which is getting the data, then it goes 2 ways, one is the save to *.tdms file, and the other is to Enqueue the data. Below that while loop, there is another while loop, which is I assume the so-called consumer loop. There I dequeue the data, and doing the moving average, to get the "action" data, where the sensor signal are not close to 0. The attached program is doing like the sound data processing, and I should make it to the other 4 sensors, but if the logic is right, that would be the easy part.

Did I get your advice right? Or am I far away from the solution?

Thanks,

Balázs