LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB6356 daqmx read.vi takes too much memory

Solved!
Go to solution

I am using USB 6356 for data acquisition, when I took data, the DAQmx read.vi took more and more PC memory. Until certain point, show "there is no enough memory to complete".  I set 2Ms/channel and 1M Hz rate, I know it is very big. But it takes daat for 6-7 times without problem. My PC has 3 G memory.

It seems that DAQmx read store more and more data in buffer. I attach my vi here, please check it what mistake I did here or how to improve it.

Thanks Liming

0 Kudos
Message 1 of 12
(3,592 Views)

First of all, DON'T start and stop DAQmx for every loop iteration.

Start DAQmx once before the while loop, and stop the DAQmx after the while has finished.

 

 

0 Kudos
Message 2 of 12
(3,585 Views)

Thank you very much for fast reply.

I use loop for multiple measurements. I want the program to take next 2M samples automatically after the first one if the USB6356 is triggered. My signal is pulses with 1 second interval. Because we have large amount of testing, I want it does 10 acquisitions continuously.

For what you modified, I can only take one acquisition. Can you advice how to do 10 acquisitions?

Thanks Liming

 

0 Kudos
Message 3 of 12
(3,577 Views)

Try to change the sampling mode from Finite Samples to Continuous Samples.

0 Kudos
Message 4 of 12
(3,571 Views)

Hi detech,

 

Your VI uses a waveform chart. This type of display keeps a history of your previous waveforms, and each time you write to it new data is appended to the end of the history.

 

So in the first iteration of the loop, your graph is storing and displaying 2 million points-per-channel. In the next iteration, it tries to store and display 4 million points, then 6 million, and it will continue in this fashion until you run out of memory.

 

Aside from the memory usage, trying to parse a 2-million point or larger array and graph it is very processor intensive, and this will only get worse each iteration of the loop. I suspect your system is also getting slower and slower as you run the VI.

 

You can use a waveform graph in place of the waveform chart, which will not keep a history of your previous display, and resolve your memory issues.

 

However, it sounds like you need some amount of logging for your application. Can you describe what your trying to do with the data you acquire, and also post what version of DAQmx you have?

 

There are several ways built into the DAQmx API and LabVIEW to deal with large amounts of data, and I'm sure we can find one that will work well for you.

 

William Earle
National Instruments R & D | Staff Software Engineer | DAQ Software

Message 5 of 12
(3,561 Views)

I take pulse (square waveform). I need 2M point at 1M/s rate for FFT need. After I have data I do FFT and find out some peaks in different band. And then output peak values.

Then to acquire another pulse by using trigger function. keep going on and on....

I have Labview 8.6 and 2010. I have  DAQmx ver 4.7.

 

As you say I can use a waveform graph in place of the waveform chart. Just wondering, waveform chart is after DAQmx read. I saw DAQmx Read (Analog Wfm 1Chan NSamp).vi took 16006.03k memory when I had error. Do you think change from chart to graph can change DAQmx memory usage? I attach the memory usage file here.

0 Kudos
Message 6 of 12
(3,544 Views)
Solution
Accepted by topic author detech

Hi detech,

 

DAQmx read is taking 16 MB of memory because it is allocating a buffer to return the data you are requesting. You are using the waveform data type, and requesting 2 million samples. Each element in the waveform data type is a double-precision floating-point value, which each take 8 bytes to store. So the 16 MB you are seeing used is (8 bytes per sample) x (2 million samples).

 

To acquire 2M samples, you will need to use this much memory, and there is not an easy way around this. However, the problem you are having is that every time your loop executes, you need an additional 16 MB of continuous data for the waveform chart, which is separate from the memory being used by DAQmx, because the waveform chart keeps a history.

 

If you can switch to a waveform graph, or just graph the result of your FFTs, I suspect your issues will be resolved, as you will only use 16MB (plus the overhead of LabVIEW and DAQmx) at any given time.

 

William Earle
National Instruments R & D | Staff Software Engineer | DAQ Software

Message 7 of 12
(3,532 Views)

It works great by changing waveform chart to waveform graph.

Thank you very much

0 Kudos
Message 8 of 12
(3,469 Views)

Thanks for resolving memory problem.

There is another problem. I can not click stop button to stop program during waiting for triggering. I have to press "abort excution" on top.

Please see how to avoid it. thanks

0 Kudos
Message 9 of 12
(3,462 Views)

Hi detech,

 

In LabVIEW, the loop stop condition is always the last thing checked in each iteration of the loop. All the stop control is doing is preventing another iteration of the loop from happening. So, the stop control in the VI won't have any effect until all of the VIs in the loop, including DAQmx Read, have finished executing for the current iteration.

 

The DAQmx Read VI won't return until all of the requested samples have been acquired, or the timeout has expired. The "stop" control does not do anything to stop the DAQmx Read from waiting for one of these conditions to happen.

 

The abort button calls into DAQmx in a different thread, and cases the task to abort immediately, i.e. end the wait for data or the timeout. You can do this programatically with the DAQmx Control Task VI with the action input set to "abort".

 

You can also try setting a shorter timeout, so the read will return more quickly when your trigger condition is not satisified.

 

William Earle
National Instruments R & D | Staff Software Engineer | DAQ Software

0 Kudos
Message 10 of 12
(3,450 Views)