Continous Sampling of PXIe-6378

[emckiller33]

Hi,

It is the first time for me to touch multifunction I/O cards, in my application, I want to continously sampling 16-channel  analogue signals, with sample rate 1MS/s, sample number is 100K or 10k,  So I choosed PXIe-6378,   When I try in NI max Test Panel, it show error:  the program can not keep steps with the sampling data.   

I wonder that whether multifunction I/O card can realise continous sampling?  Does anyone know about that?  Sorry for this naive question, But I can not catch some manual to show how to use multifunction I/O card.

[crossrulz]

You should be fine with a number of samples being 100k since that is 100ms worth of data (the general vicinity of my rule of thumb).  The 10k would be cutting it close since that is only 10ms worth of data.  Can you show a screen shot of your settings?  I am thinking you have some mistake somewhere in there and you are not setting things to what you think.

[emckiller33]

Hi,

Please check the recorder-sample.vi

Thanks.

[crossrulz · Accepted solution]

From this VI, here are a few things you can do:

1. Do not even wire up the "Samples per Channel" at the DAQmx Timing VI.  The default is usually plenty of space.

2. Get rid of the Wait inside of your loop.  Let the acquisition timing limit your loop rate.

3. Tell the DAQmx Read to read a set number of samples.  Based on a 1MS/s rate, I would go with 100kS.

4. Use a Producer/Consumer to put your processing of the data into a parallel loop.

[emckiller33]

Thanks very much for your reply.

Yes,  I tried to your way.  it looks it works in one channel with continously sampling.

However, when 16 channels work simuitanously, it works only in a few seconds (less than 30 seconds) in my computer.  then one error shows:  your task can not be completed for no enough memory.  

Please check my example.vi

[crossrulz]

Those are pretty large FFTs you are performing.  You might want to reduce the number of samples you are reading to something more like 1024 or 2048.  FFTs are also more efficient if you have a power of 2 samples.

The other option is to just log the data straight to a file and process all of the data later.

[Kevin_Price]

I don't see any of the usual suspects for "out of memory" such as continuously growing arrays.  I think it must be the queue itself.  If your consumer loop can't keep up, the producer keeps adding items to the back of the queue and memory usage keeps growing.

To Diagnose:

- put a call to "Get Queue Status" in the consumer loop and wire "# elements in queue to an indicator".  If my theory is right, you'll see that number grow continuously until you get your error

To Fix:

- the consumer loop has to be able to iterate and consume data faster.  Period, end of story, no way around it.

- the only candidates are the time-based waveform chart, the freq-based waveform graph, and the express vi used to do spectral analysis.  It seems most likely to me that the spectral analysis function will be the biggest offender but I would definitely not rule check into the graph and chart as well since they're being updated with many MB/sec of data.

- the suggestion from crossrulz to log the data and do post-processing later should definitely be viable

- if you need a real-time look at the data behavior, I'd try the following:

    Drastically decimate the time data (a factor of 1000x or more) before sending it to the chart.  Do not use averaging.   Also, take a small subset of the original data and only send that much to the spectral analysis function.

    These steps will give you a real-time glimpse at what's going on while drastically reducing the cpu demand of the consumer loop.

-Kevin P