help with acquiring processing and displaying multi channel data

[AzimJ]

In my L abview application I have a DAQ-MX task which continuously reads data from 5 AI channels and queues the data for processing, displaying and saving to disk.  The sampling rate for the task is 8kHz and I have a timed loop setup to read data from my DAQ at 1kHz giving me 8 data points per read.  This appears to be a one-dimensional array of waveforms which are queued for processing, saving and displaying in parrallel loops.

Since I don't need to display all the data but just update the front panel at a rate of 5-10Hz with a resampled version of the collected data from my 5 AI channels. I am not sure how to set this up.  Do I need to dequeue the 1d-waveform array concatenate using a shift-register.  Perhaps dequeuing data and only concatenated every 10th element in the queue.  

Secondly, I need another loop which can calculate the RMS value of the signal and then trigger a second device when the RMS value of channel 1 reaches a threshold.  The triggering should happen close to real-time so that within 10ms of the data reaching the threshold the VI should send a trigger out through a digital output line.  I know I can calculate the RMS value fast enough for 8 or 16 points of data.  

What references and resources should I focus on to help me figure out the appropriate design pattern for setting up the application?

[Hillman]

Hi zimR,

Thanks for your post and I hope your well today.

I think your considerations for your code are very fair and correct. I have posted an example producer / consumer pattern (LabVIEW 8.6) which collects data from an AI task, upon a certain theshold then produces a DO. I beleive the slave task should be able to react with 10ms. 

 

In terms of the update rate of the display, I don't beleive you should have any problems updating a chart constantly - as thats the idea. Have you had any problems with this?

Considering your rates are pretty low - I think your code would be fine.

Regarding some great resources for DAQmx have you seen:

Getting Started with NI-DAQmx: Main Page

http://zone.ni.com/devzone/cda/tut/p/id/5434

Contains, Basics and Advanced Topics, FAQ and examples! I would also recommend looking at the examples in the NI Example Finder to learn how they work to gain a better understanding. In your case maybe try, Help>>Find Examples>>Hardware Input/Output>>DAQmx..).

I hope this helps - let me know,

Message Edited by Hillman on 12-08-2008 04:46 PM

[AzimJ]

Hi James

Thank you for your response and for confirming that I am on the right track.  If I understand you correctly, then I shouldn't need to worry about displaying the data as it arrives either from the DAQ in the producer or loop or from the queue in the consumer loop, right?  

I do have one question about your solution. Since the producer loop runs at 10Hz  there is 100ms of data being queued for consumer loop.  So, am I right in concluding that in this case there is a possible 100ms delay between the signal coming in and the consumer loop analysing the data?  Of course, I could always speed up the producer loop and acquire less data per iteration.  

James said:

> In terms of the update rate of the display, I don't beleive you should have any problems updating a

> chart constantly - as thats the idea. Have you had any problems with this?

I did notice that when I was displaying the data in the consumer loop it ran significantly slower than the producer loop (measured by the number of iteration of each loop in a 10s run).   In this senario all consumer was only displaying data and not performing any other calculations.

[John_P1]

Hi zimR,

Welcome to the NI forums!  Since graphing data inside your processing or acquisition loop could slow down your loop rates, you might want to consider adding a third consumer loop if you want to ensure the processing occurs as quickly as possible (it sounds like you want to use this to control some sort of external circuit). 

You might consider the master/slave design template as well, using notifiers instead of queues.  Queues will grow in length and you will process the first values written (i.e. the oldest values).  Using notifiers, you will always process the most recent available data.  If your processing loop runs slower than your acquisition, you will simply throw away the older samples if you are not ready to process them.

The one part I am not too sure about is how you will make a meaningful RMS measurement with only a few samples.  I am guessing this is a safety feature, so I am not sure if implementing the processing in software would be the most reliable method.  If possible, you might consider checking for a maximum analog input threshhold value instead of RMS.  Depending on your hardware, you may then be able to use an Analog Reference Trigger and export the signal on a PFI line.  This would result in much less delay and a more reliable execution (i.e. not dependant on software).  If you are running a Real-Time operating system, you should be ok doing the processing in software as long as it can execute quickly enough for your needs.

What hardware are you using, and what is the overall objective of your application?  I can give better information if I know more about the big-picture of what your setup is.

-John 

[AzimJ]

Hi John P

Thanks for your reply and offer to help.  My current hardware is

    1.  Intel Core 2Duo CPU 3GHz w/ 2GB RAM

    2. DAQ  NI PCI-6034E connected to a BNC 2110 connector block

 John P said

> The one part I am not too sure about is how you will make a meaningful RMS measurement with only a few samples.

You are right 8 data points would be to small.  After meeting with the end users, the criteria has slightly changed.   So, they can accept 15ms feedback delay (time between actual signal reaches its trigger level and the computer responding with a digital output).  Actually, we would like to control the delay of the output trigger.  I think I will post a seperate question on how to do this.  

I did as you suggested and placed the display process in a third low priority loop and it works well. Thanks.

Azim