LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

techniques for a synchronous long-life data acquisition

Hello All

I have a digitizer, which needs to run at a constant rate for ever. When some condition occur (reading exceed treshold level), other data processing must take place.

The data processing last for much longer time that the successive sampling, which means that I can not fit data processing in the same thread as the sampling process.

It looks like I need some kind of buffer, which will be filled and keep track of the sampled data, and another thread for data processing and analizying.

Can somebody give me a link, or advice about this kind of problems. What are the techniques for long-life data acquisition.

Thank you in advance.
Pawel
0 Kudos
Message 1 of 4
(2,621 Views)
Indeed a challenging application! Here is what has been done successfully in other applications:

1) to separate the DAQ task from other tasks, put the data into a Queue. This creates a second software buffer for your data.

2) for large buffers, so you can extract pre and post trigger data, use two files (a double buffered file buffer) and stream the data to each file successively within your DAQ VI.

3) when you detect the threshold trigger in your DAQ loop, note the block number and pass this as part of the queue

4) your processing loop, can then use the block number to get pre and post trigger blocks for further analysis.

Hope this helps you get started.

Preston Johnson
Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 2 of 4
(2,621 Views)
Hello Preston

The idea with a queue is a very good one. It allows to make a synchronous signal become asunchronous, since I can manage samples in any time I want.

However, I have a little problem with understanding, how you want to start datta processing of the queue if my state machine queue is bussy with sampling and storing the data to a queue or disk file?

In 4) you are writing about the processing loop. Is this loop is something else than a DAQ VI you mentioned in 2)?

If so, let me understand you well: We have a state machine loop ("acquisition loop"), which loads the DAQ data to a queue, together with the control words (detect treshold, stop processing, etc.
We pass the reference of the queue to another loop (processing loop), which is run
ning parralelly to the acquisition loop. In that loop we detect control words and do whatever we need to do.

Maybe it could be even better to run a processing loop in another vi and run it in different thread with lower priority? In this way my DAQ qill never loose any data.

Please let me know if this is what you ment.

kind regards
Pawel
0 Kudos
Message 3 of 4
(2,621 Views)
Yes,

you have the general architecture correct. Let us know how well the idea works for you.

Preston Johnson
Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 4 of 4
(2,621 Views)