Transfer rate of high-speed sample acquisition from DAC to PC.

[MR.AC]

I am using a PCI 6321 to run a scanning microscopy setup and would appreciate some advice on a technical issue with timing the DAC for acquisition (output).

I need to acquire 40,000 samples from 3 Analog Input channels at a sample rate of 5 kHz. I understand that the DAC can only hold ~4000 samples in the buffer at a time, so they need to be transferred to the computer to empty the buffer before I accumulate more data points. So, my plan is to have the DAC continuously recording samples and then transfer the whole set of data points every 4000 samples. My concerns here is that I don't know how long it takes the DAC to transfer the data to the computer. Would it take longer than the 200 microseconds I have in between data points to transfer the data and then get prepared for the next set of 4000 samples? Or would I be able to continuously run and not miss any samples? Is this the same speed as uploading points onto the card to use for the AO channels? I am using an external clock for the data acquisition.

[santo_13]

This is called streaming, and in terms of DAQ, you need to continuously read in chunks of 100ms of the sample (rule of thumb). The good thing is that DAQ implements DMA, thereby it can directly write to computer memory locations.

In general, streaming 3 AI channels at 5kHz is not a challenging task at all. Please share your code to ensure you're following the best practices.

[MR.AC]

Hello Santhosh,

Thank you for your response. Would this vi be able to read every sample at 5kHz?

[santo_13]

Your implementation cannot keep up as you're reading 1 sample at a time which is too slow.

If you just need to collect the data, FlexLogger will make your life easy as it is configuration based data acquisition.

[ft_06]

Look at https://forums.ni.com/t5/Multifunction-DAQ/Buffer-size-limitations-in-finite-acquisition-best-way-to...

It is explaining the real-time constraints in a streaming case with examples in python and VI,. where you process data live through callbacks.

As mentioned by santo_13, if you just need the samples, there are better ways.

For example, I process measurements live to display them on a screen. And I also use APIs to acquire data and post-process later, thus I don't need callbacks in that case

[MR.AC]

Hello Santosh and ft,

The Daqmx maxes out at 1000 samples with this program. Is this the buffer limit?

Alex

[santo_13]

---

@MR.AC wrote:

Hello Santosh and ft,

The Daqmx maxes out at 1000 samples with this program. Is this the buffer limit?

Alex

---

It is not a limit, but rather, you left some inputs to the DAQmx Timing VI unwired, letting it go with the default values of 1000 finite samples.

Now, all that you need to do is change Finite Samples to Continuous Samples and the 1000 wouldn't matter and DAQmx will automatically size the buffer based on the number of samples you wire to DAQmx Read.

 

[ft_06]

Hello,

I can't really help for Labview but the concepts are the same between Labview, C API and python API. As various people highlighted, the principles are (I just summarize, I let you draw the decision tree 😉 😞

- use finite acquisition if you just want samples at the end and no live post-processing, there is some wire to change the number of samples. 1000 samples may be a generic default config for all devices or what the onboard buffer size allows you before having to dump on host (generally onboard buffer is like 2K, 4K, ... so same order of magnitude then 1000 samples)

- if you want huge number of samples, framework may disagree allocating too big host buffer then you switch to CONTINUOUS mode and you stop it when time has elapsed. In finite or continuous cases, framework can take care of the copies between onboard buffer and host buffer and storage on disk

- you don't have high-rate acquisition so you can let framework decide the buffer size on your host. If you have specific load constraints on your host (for example I display data live), you can tune it, there should be some input_buffer_size property somewhere in Labview