Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Does the NI 6115 automatically fill the FIFO before transferring to system memory?

I am using 10 PXI 6115's to acquire large #'s of samples at 10 MHz on each channel (for a total of 40 channels). I have found some references in the Knowledge Base that seem to indicate that I must set the "Allocate Device Memory" option in AI Config in order to make this work (because of system bus bandwidth limitations).

However, when I use AI Config with this option, the acquisition returns no data (and no errors). If I leave it on the default (allocate host memory), the acquisition seems to work fine. Certainly the boards must be filling up the onboard FIFO before transferring to system memory; there's no way the PCI bus could support this bandwidth.

My question is this: does
the 6115 automatically fill the FIFO before sending data to system memory? Do all NI boards work this way? If so, what is the point of the "allocate device memory" option (which doesn't appear to work)?

Also, is there a good reference somewhere that explains how the NI boards use the FIFO's under the standard Labview AI VI's? For example, if I set the "allocate device memory option", what effect does the "buffer size" input have? Is that the system buffer size or the device buffer size? Also, if I set that option, why can I not get pre-trigger scans?

Thanks in advance,

RGA
0 Kudos
Message 1 of 5
(3,312 Views)
RGA,
This is functionality that National Instruments has recently added for the NI 6115. Please Email me at jace.curtis@ni.com. I would be interested in talking more about your application if you have time and helping you with any issues you might be having.
0 Kudos
Message 2 of 5
(3,312 Views)
Acquiring into device memory is a new feature of the NI 61XX devices added to NI-DAQ 6.9.3 for finite acquisitions only. See the following Knowledge Base:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/9c419710b6071a6d86256bd600624b83?OpenDocument

As to your particular questions...
In both "allocate host memory" and "allocate device memory" modes, as the device is acquiring data into its onboard FIFO, it is transferring this data over the PCI bus into the PC buffer allocated by AI Config.vi. It does not wait for the entire FIFO to fill up before its starts transferring data to the PC buffer. When allocating host memory in a finite acquisition, it must transfer all of the data acquired into the onboard FIFO into the PC buffer (and thus
the buffer must be large enough to store all of it at once). AI Read.vi then reads data out of the PC buffer into LabVIEW memory. When allocating device memory for finite acquisitions, it transfers enough data from the FIFO to fill up the PC buffer and stores the remaining data in the FIFO. When AI Read is called, it starts reading data from the PC buffer into LabVIEW memory. As data is read out of the PC buffer, a transfer of the next segment of data from the FIFO to PC buffer is initiated. Thus your PC buffer never has to hold all of your data at one time.

Acquiring into device memory is only supported with finite acquisitions because restrictions with buffer management prevent the guarantee that all of the correct data will fit onto the device in continuous acquisitions. Since pre-trigger acquisitions are continuous until the trigger occurs, pre-triggering is not supported when using this mode.

I am attaching an example that demonstrates how to acquire data into device
memory with an NI 6115. Hopefully this helps clear up any confusion.

Nicole
Message 3 of 5
(3,312 Views)
Nicole,

Thanks for the reply - I have a much better understanding of how the buffering process works. I am still unclear, however, on a couple of things.

If I use the "allocate device memory" option, am I to understand that the board does not acquire data into the FIFO until it receives a trigger? Doesn't the board use the FIFO as a circular buffer that continually acquires data until a trigger condition is met, then it collects the requisite number of post-trigger scans and stops updating?

Something still doesn't add up because I can capture data (with pre-trigger scans) across all 40 channels at 10 MHz without using the "allocate device memory" option - that bandwidth can't possibly be going across the PCI bus, so it must be using the device memor
y as a circular buffer. If the acquisition works this way with pre-trigger scans, under what conditions would I want to allocate device memory and limit myself to only post-trigger scans?

Thanks again,

RGA
0 Kudos
Message 4 of 5
(3,312 Views)
Hello,

The onboard memory acts like a FIFO and not a circular buffer. It's really the PC buffer that acts like a circular buffer, continually streaming in data from the hardware FIFO until a trigger condition is met and collecting the specified number of pre and post trigger scans. Therefore, when using a stop trigger to acquire pre-trigger scans, you must allocate host memory to implement the circular buffer needed for this functionality. When using a start trigger, which only gives you post-trigger scans, the device does not even start acquiring data until the trigger is met.

In your situation where you are able to acquire across all 40 channels at 10MHz without having to use device memory, how long are you doing this for? When allocating host memory, the data is accumulated into the device memory while it's waiting for the resources to be transferred across the PCI bus. As long as it does not fill the entire buffer and start over-writing data that has not yet been transferred to PC memory, no errors will occur and the situation you described should be possible. If all of the data you are acquiring fits onto the onboard memory, then you will not run into this buffer overflow situation and there is more leeway in how quickly all of the data must be transferred to the PC buffer, similar to using the device memory allocation mode.

So why would you want to use device memory allocation as opposed to host memory allocation? When you allocate host memory for finite acquisitions, the PC buffer you configure has to be large enough to hold all of the data. The size of the buffer that you can allocate depends on how much memory Windows and your particular system allows you to page lock. If you want to acquire 30MSamples of data, Windows will not let you page lock a 30MSample buffer. Previously, the only option was to implement a continuous acquisition, which has throughput limitations.

The ability to acquire into device memory was implemented for high channel count, fast, finite acquisitions. This allows you to create a small PC buffer to store the first segment of data, while storing the remainder of the data in the onboard memory of the device. You can then transfer the remainder of the data into PC memory in smaller segments at a time after the acquisition has completed, eliminating PCI bandwidth issues. But one of the limitations is that you cannot acquire pre-trigger scans in this mode.

Nicole
0 Kudos
Message 5 of 5
(3,312 Views)