PXI 6259 memory full while acquiring data at 1MHz for few seconds

[hyin]

Hello everybody,

I'm a newbie using Labview 8.6 with PXI 6259 on chassis 1031.

I tried to acquire some acoustic emission signal with 1MHz sampling rate, but it gives the message of 'labview memory full' after 2 -3 seconds.

Is this due to the limitation of the device?

Does it have anything to do with the DMA?

I read that there are 6 DMA channels in PXI 6259, but I do not know how to locate the channel and configure it.

Any clues?

Thank you very much.

Regards,

HY

[Dennis_Knutson]

What else is your code doing? Do you get an error when you run one of the examples? Please attach an image of the block diagram or the actual VI.

[hyin]

Hi Dennis,

No error while running.

I set my sampling rate as 1MHz, and number of samples as 100 kHz and append the signal every loop so that I can get a longer signal.

However, after running few seconds and I pressed the stop button to stop the VI, the message 'Not enough memory' appeared.

Previously, I didn't include the 'append' vi in my block diagram, and the longest data the vi can measure is 2s. When I tried to acquire 3s of data, it gives the message of 'memory full' too. That's why I include the append vi and check whether I can acquired the data at a longer time frame.

Attached is the block diagram of my vi.

Thanks. 

[Ezags1]

When the append waveforms vi is front panel is opened you will notice that the waveforms are unbundled and that it is using a build array to concatenate the waveforms together. By using the shift register and the append waveforms vi, you are continuously growing the memory by putting new items in the array. With the high sample rate its going to run out of memory fast like you are seeing.

You could take a look at the producer/consumer architecture which would run two parallel loops. Here is a NI whitepaper that describes it.https://www.ni.com/en/support/documentation/supplemental/21/producer-consumer-architecture-in-labvie...

By using this pattern, you could run your data acquistion at the same time as file recording and insteading of putting a bunch of data in a shift register, it would be wrote to a file instead.

[johnsold]

Try preallocating memory for the data. The way you are doing things now LV or the OS must reallocate memory for the data as the array grows. The data in arrays must occupy contiguous memory locations so it is not too surprising that you get memory errors at the time scale you describe.

Determine the maximum duration of your run. From that determine the maximum array size. Double precision numerics occupy 8 bytes per value so you will require 8 MB per second. To run for 1 minute will require an array of 60 million samples or 480 MB. Does your system have that much memory available in one contiguous block?  If it does, use Initialize Array outside the loop to create an array of that size and wire it to the shift register. Inside the loop use the array form of the DAQmx Read and Replace Array Subset to put the newly acquired data into the pre-allocated array.

How is the Write to Measurement File VI configured? Writing to a text file will require at least twice as much memory because it will have a string copy as well as the numeric data in memory. Do you have 1.5-2 GB available? Writing to binary may not require a copy but I have not checked the internal workings of Write to Measurement File VI to determine whether it makes a copy or not.

More realistically, you should look at the Producer/Consumer architecture as recommended by Ezags1. Write data to the file about once per second in the consumer loop. Or use the TDMS file VIs which are optimized for high speed data acquisition. Either way you avoid trying to accumulate hundreds of MB in memory.

Writing 100000 points to a graph is useless because your graph likely only has ~1000 pixel width. Thus, LV needs to reduce the data to ~1000 points to plot. You can let LV do it, but it should be in the Consumer loop to avoid slowing the data acquisition. Or you can do your own data reduction, again in the consumer loop.

Lynn