AM I Using Producer/Consumer correctly?

[nuassembly]

I am trying to read DAQ data from an external triggered events at 280Hz, and the data needed lasts about 2.8msec each evet, and I wish to analyze (average)  the data at the same rate. The normal sequential Vi will spend about 1msec for average/analyze the data, and therefore I will be dropping events.

I wish to read the new data while analyze the previous data, so that I could achieve the full 280Hz rate. After consulting our regional NI engineer, I was referred to use the Producer/Consumer template.

Enclosed, I attached the Vi LIB that I did using Producer/Consumer template with LV7.1.

The DAQ is external triggered at 280Hz, and each DAQ last about 2.8msec. I wish to be able to read and average the DAQ at maximum DAQ rate of 280Hz.

I measured the time to finish 10K averages, and trying to see the time difference when I changes the content in the Producer/Consumer

I found that if I remove the Plot in the Consumer, the time to finish 10K averages dropped from 48 seconds to 38 seconds. If I also remove the “0 delay” in the Producer(not in this vi's producer loop now, but was there originally from the NI template), the time dropped from 38seconds to 36 seconds. So, looks like both Producer and Consumer are rate limiting factors in this design. But, suppose the Producer should keep on producing without considering the Consumer’s speed? I wonder if the Queue is set up correctly?

[Neal M]

Hello nuassembly,

If I am understanding you correctly what you want to do is run a finite acquisition (2.8ms worth) every time a trigger occurs.  This trigger comes once every ~3.57ms (280Hz).  You then need to average this data on the fly (within the 3.57ms between triggers).

If this is correct, the producer consumer loop is probably the best way to go about this.  I would expect to see a significant drop in your consumer loop time by removing the graph because updating front panel indicators takes CPU and significant amount of time.  In this case (updating the front panel each loop), the consumer definitely appears to be the limiting factor.

Once you remove this, however, your consumer loops appears to run faster than your producer (you say ~1ms per average).  This would cause the producer to become the limiting factor since it is only providing a chunk of data every ~3.75ms.  If this occurs, what will happen is the consumer will wait until the producer puts something in the cue.  It will then take that and run the code on it.

Doing the math, I believe that the fastest you can expect the program to run is 35.7 seconds (10,000 avgs * 3.57ms = 35.7s). So it appears that your program is set up correctly.

[nuassembly]

thanks for the advices.
But, are you sure consumer should be the limiting factor here  if it has extra load of work? I thought producer will not wait for consumer in processing the data.

Sheng

[Neal M]

Hello again Sheng,

I guess I was not clear as to what my point was in my previous post.  What I was getting at is that the total runtime of your program is how long it takes for both loops to complete all of their tasks.  The reason that it appears that the consumer is the limiting factor (when updating the front panel) is that there is data building up in the queue from the producer (so you are not limiting its rate at all), but it takes more time to empty out the queue after the 10k acquisitions have completed.

This is what the producer-consumer structure is designed for.  The consumer (which takes time) does not limit the producer (which runs faster).  What we are using it for is really to run both at the same time.  We are essentially doing pipelining. We could also program with shift registers like this:



This would do essentially the same thing since the producer portion (the DAQmx vi) takes the longest and the sections do not require another portion to run first.

I hope this clears things up, please post back if I did not answer your question.


Message Edited by Neal M on 01-10-2008 02:03 PM