DAQ Fifo buffer transfer

[scalpas]

Hi,

I'm currently working on a program for continuous analog output and acquisition. This is new to me, so I'm still learning. From what I've read, the DAQmx Read.vi controls the transfer of samples from the PC buffer to Labview (for acquisition), and the PC buffer size is controlled by the DAQmx Timing.vi.

However, what controls the transfer of data from the DAQ board FIFO buffer to the PC buffer  ? What triggers the transfer ?

Thanks,

ps : I have a M series PCI-6221 card and Labview 8.0 

[Corby_B]

Hello scalpas,

Thanks for your post and questions about DMA.

You are correct in stating that the DAQmx timing.vi is used to control the buffer size. It also sets the buffer size in the computer memory that it uses based on the parameters set by the user. The transfer of data is triggered by the DAQmx read.vi. So in short the transfers are all handled by the DAQmx driver for you.   If you don't read and fill up your buffer then the data is not moving from this memory and will cause a memory overflow. The driver only reserves the amount of memory that you as the user specifies. Let me know if this clears up your questions/concerns about how DMA works using the DAQmx driver. 

DMA

Cheers!

Corby_B

http://www.ni.com/support 

[scalpas]

Yes, that clears things up. Thanks for you answer !

[Neil_S.]

I just wanted to add a few thoughts on this thread.  You are correct that a DAQmx Read triggers the transfer from your computer's RAM to LabVIEW.  However, the data being transferred from the board into memory is a bit more complicated and depends quite a bit on the hardware you are using, the timing configuration and other task parameters.

As Corby pointed out DMA (or direct memory access) is one way data is transferred from the board into memory.  Most PCI, PCI Express, PXI, and PXI Express boards transfer data in this way for most configurations.  This is done by configuring the board to handle data transfers into memory and the transfers occur independent of your program once the task is started (either by calling DAQmx Start or calling DAQmx Read with the autostart configuration).  The DAQmx Read doesn't directly trigger a transfer from the board unless you are doing an on-demand task.

Another way transfers are done with a PCI device is using interrupts.  In this configuration the board is configured to send an interrupt when it is ready to transfer data to the computer.  The NI-DAQmx driver then recieves the interrupt independent of your application and moves the data into the memory buffer.

In either case you can use an NI-DAQmx property node to set up when the board triggers the transfer.  For analog input tasks this is done with the AI Data Transfer Request Condition property:

The defaults for this property and they way NI-DAQmx transfers the data is fine for most applications, so you don't often need to worry about these details.  There are a few cases (including Buffer Overwrites as Corby pointed out) where it is useful to know a few guidelines.  A few guidelines I would give are:

1. If you do not read data from the buffer fast enough the buffer will be overwritten.  This can lead to errors when attempting to read data that is no longer available.
2. Larger read sizes can typically allow higher throughput (allow you to acquire more data per second).
3. Smaller read sizes decrease throughput but can decrease latency
4. If data cannot get across the bus fast enough the FIFO on the board can become overwritten and NI-DAQmx will throw an error.  You should make sure your task is using DMA, and that other devices are not hogging the bus.  Also you may be running into a limitation of the bus, especially if you have a lot of board all acquiring simultaneously.

I would recommend you take a look at a recent web cast I gave on some of these topics.  It is called:

Tips for Maximizing DAQ Throughput and Performance

Thanks for posting to the forums and good luck with your application.

Regards,

Neil S.

Multifunction DAQ

Product Support Engineer

National Instruments

Message Edited by Neil S. on 10-01-2008 11:49 AM