DAQmx Error -50352: How can I determine the maximum allowed buffer size?

[luke_q]

I am using a PCI 6259 board with the DAQmx library (v9.0.2) and I get error "-50352: Memory cannot be allocated" whenever I try to make my recording too long. Here are some limits I have found:

   1 AI channel, 1Msample/sec: 7.71 sec max

   1 AO channel, 1Msample/sec: 7.71 sec max

   1 AI channel, 500ksample/sec: 15.4 sec max

   2 AI channel, 500ksample/sec: 7.71 sec max

   1 AI, 1 AO channel, 1Msample/sec: 5.6 sec max

So in most cases, I cannot acquire more than 7.71 Msamples in a single task, whether it is AI or AO. When mixing AI and AO tasks, that limit seems to decrease. This will occur with a freshly started application, so I do not think this is a task clearing issue. 

Is this a hardware limit with the device? (And if so, how can I determine this limit?)

My impression was that the device uses DMA to transfer samples to system memory, of which there is plenty--I can easily allocate over 400MB of contiguous memory in the same application.

[Esteban_B]

Hi Luke,

I did some research and I found a couple of articles related to the error -50352. I was able to find a couple of articles related to this error code:

Resolving DAQmx Error -50352 "Memory Cannot Be Allocated"

DMA FIFO host side buffer failing to allocate memory with error -52000 or -50352

Please try to follow the instructions in these articles and let us know if you were able to solve th...

Regards,

[Brad_K · Accepted solution]

Hi Luke,

How much RAM does your system have installed?

What OS are you using? If it's a 32-bit OS, are you using /3GB or increaseuserva? Those settings have a tradeoff: they reduce the size of the kernel virtual address space. This increases the likelihood that DAQmx will succeed at allocating the memory but fail at mapping it into the kernel virtual address space.

Does your system have any devices with extremely large memory mapped I/O ranges, such as a video card with a large amount of onboard memory? On a 32-bit OS, this can reduce the size of the kernel virtual address space by a significant amount.

Brad

[luke_q]

Thanks Brad, you are absolutely correct--I am using 32-bit Windows with 4GB ram and using the /3GB switch. Disabling /3GB has fixed my problem; I didn't consider that DMA writes into kernel memory instead of user memory.

[Brad_K]

Hi Luke,

Memory for DMA doesn't necessarily have to be mapped into the kernel address space, but the M Series driver is designed to do it that way.

Is removing /3GB going to cause problems for any of your applications? I don't know if moving to 64-bit Windows is an option, but it would increase both the user and kernel address space limits, even for 32-bit apps (as long as they have the /LARGEADDRESSAWARE flag set in the PE header).

Brad

[luke_q]

It'll take some more testing to determine if removing the /3GB flag will cause problems. My impression is that 32-bit windows limits single processes to around 1.5GB RAM anyway, so probably this won't affect us much. 

We are currently working on getting 64-bit Windows working, but this is held up until all our third-party libraries and device drivers make the transition.

Interesting tip on the /LARGEADDRESSAWARE flag, I'll look into that (but again, we'll most likely need third-party libraries and drivers to provide that before we can).

Thanks, this is very helpful information.