Data acquisition loop with queue

[secr1973]

What I would like to do is have a data acquisition loop that samples a load cell at 500Hz and have another loop that runs much slower to run a state machine and display some data in real time.  The reason I want to sample the load cell so fast is to filter out some noise.  Making producer/consumer loops with a queue kind of makes sense but I don't really care about all of the samples, I just want to be able to read a real time filtered signal at certain times.  I looked at having just two parallel loops, one to acquire the data and the other to run a test and retrieve a real-time signal when I want but not sure how to pass data between the loops without using a queue.  You can do it with local variables but you are at risk of a race condition.  I hope this make sense.  I am sure this is a simple problem I just don't know what direction to go.  Thanks

[RavensFan]

You can use a notifier to pass the data.  It will act basically like a 1 element queue.

You can also implement a lossy queue where you limit the size of the queue.

But I don't really understand your aversion to using a queue.

[Harold_Timmis]

use a notifier:

here this link may help:

http://forums.ni.com/ni/board/message?board.id=170&message.id=465715&query.id=1859561#M465715

ravens fan beat me too it

Message Edited by Harold Timmis on 03-12-2010 12:20 AM

[Charlie_P]

Good Evening secr1973,

It sounds like you are on the right track.  You already know about the producer/consumer architecture; this is almost always the first step to the separation that I think you are after.

The step that I think you are missing is a Case Structure around the enqueue element VI.  You likely have some event or specific pattern that you are looking for in the input signal.  You can have the output from this algorithm (likely a boolean) determine which case of the Case Structure to execute (Case 1: enqueue the element or Case 2: Do not enqueue the element).

This, of course, leads to processing being done in the producer loop, which is quite the opposite of what you are trying to accomplish with the producer/consumer architecture.  You will have to decide if your processing is very simple or more complicated.

If it is easy/fast, you can likely get away with doing this processing in the producer loop.  My guess is that your program falls under the category of do-it-all-in-the-producer loop because you are only acquiring at 500 Hz.

If the application requires faster acquisition rates or if the logic is going to require some processing, you may want to implement a double layer producer/consumer architecture.  In this setup, you would pass all of the data from the DAQ producer to a second loop (using queue #1) that determines what to do with the data (to enqueue or not to enqueue...) and, if appropriate, write to a queue (queue #2) that the third loop can read.  The third loop would be where your state machine executes.

If you have a quad core machine, each of these steps will execute on its own core.  If not, you will have a little more thread swapping; not a huge concern in most cases.  Here, we get into the art of programming more than the science.

In any event, I think you will be OK with a little processing for the enqueue or not algorithm in the producer loop.