DAQmxGetReadAvailSampPerChan capped at 1,000,000 using PCI6251?

[David_Lin]

I am using PCI6251 to do 3 channel finite number sampling as well as counter0 reading. The sample number per channel was set to be 1.5M with

DAQmxErrChk (DAQmxCfgSampClkTiming(task,"",srate,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,dataperchan));

where dataperchan is 1.5M and srate is set to be 150K, just for testing purpose.

However,  when I use

DAQmxErrChk(DAQmxGetReadAvailSampPerChan(task,rd));

to check how many samples are available, the number rd was capped at 1,000,000. I tested a few numbers and it seems any number less than 1M can be correctly returned while any one above 1M was capped.

Then I use the same program to test PCI6251 and no such error occured and correct number of sample available can always be returned.

Could anyone please explain how it could happen?

[David_Lin]

Sorry, made a mistake. The title should be DAQmxGetReadAvailSampPerChan capped at 1,000,000 using PCI6133? and the content is

I am using PCI6133 to do 3 channel finite number sampling as well as counter0 reading. The sample number per channel was set to be 1.5M with

DAQmxErrChk (DAQmxCfgSampClkTiming(task,"",srate,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,dataperchan));

where dataperchan is 1.5M and srate is set to be 150K, just for testing purpose.

However, when I use

DAQmxErrChk(DAQmxGetReadAvailSampPerChan(task,rd));

to check how many samples are available, the number rd was capped at 1,000,000. I tested a few numbers and it seems any number less than 1M can be correctly returned while any one above 1M was capped.

Then I use the same program to test PCI6251 and no such error occured and correct number of sample available can always be returned.

Could anyone please explain how it could happen?

[Mcdan]

David,

The difference between your PCI-6251 and your PCI-6133 is the amount of onboard memory.  The PCI-6133 has a fifo of 64 MB.  As a result, there are situations where DAQmx will use some of this FIFO space in lieu of allocating memory on the host PC.  By default the driver is limiting the buffer size on the host PC to 1 million samples for the 6133, and allowing the remainder of your data to accumulate into your device's FIFO.  This is meant to be friendly to your system's memory in cases where DAQmx can be certain that all data acquired can fit within the default 1 million sample buffer and the device's FIFO.

If you were to explicitly set your buffer size (call DAQmxSetBufInputBufSize) and pass it 1,500,000 you'll see the PCI-6133 and 6251 behave in the same manner.

Hope this helps,
Dan

[David_Lin]

Hi, Mcdan,

from what you explained, does it mean the sampled data is saved in both the FIFO and the PC memory? If yes, how to check if all samples are available? If not, to set buffer size seems to be the direct way to solve the problem.

BTW, where can I find this kind explanation from the documents instead of posting questions here? we may start to employ more different DAQ cards for different applications and I hope I can find some answers from the manuals or datasheet.

David

[David_Lin]

Also, from the NI-DAQmx help chm file, I found the explanation about buffering and it says "If your acquisition is finite (sample mode on the Timing function/VI set to Finite Samples), NI-DAQmx allocates a buffer equal in size to the value of the samples per channel attribute/property." Is this still applicable to PCI-6133 card?

[Mcdan]

David,

 The documentation you found is not accurate for S Series devices with large onboard FIFO's (greater than 32 MB).  These devices are the PCI-6115, PCI-6120, PCI-6122, PCI-6123, PCI-6132, PCI-6133, PXI-6115, PXI-6120, PXI-6122, PXI-6123, PXI-6132, and PXI-6133.  For these devices, DAQmx will default the buffer size to 1,000,000 samples if you are doing a finite acquisition with the total number of sample between 1,000,000 and (1,000,000 +FIFO Size).  As I'd mentioned in my previous post, you can override this default behavior by calling DAQmxSetBufInputBufSize.  I will look into getting the documentation updated to reflect this difference in behavior for the devices listed above.

Hope this helps,
Dan

[David_Lin]

The problem is solved. Thanks!