Need clarification on buffers for DAQmx.

[Redeemed]

I am running DAQmx in continuous mode and am curious if I have to created my own double buffer or if LabVIEW takes care of this for me by simply declaring the collection mode as continuous.

[Christian Mergl]

Hey,

With an continous acquisition the "number of samples" declares the buffer size. If you don't set the number of samples the driver sets the size regarding your sample rate.

Christian

[Neil_S.]

Christian is correct, NI-DAQmx automatically assigns the buffer for you.  Unlike Traditional NI-DAQ Legacy that required managing your own double buffer, NI-DAQmx manages this for you.  It is one of the many incredible features of NI-DAQmx that makes life that much easier.  In addition, the NI-DAQmx uses a more flexible circular buffer in place of a less dynamic double buffer.  For more information on how NI-DAQmx creates the buffer refer to the NI-DAQmx Help file that is installed with NI-DAQmx.  This section is particularly helpful:

How Is Buffer Size Determined?

Input Tasks

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. For example, if you specify samples per channel of 1,000 samples and your application uses two channels, the buffer size would be 2,000 samples. Thus, the buffer is exactly big enough to hold all the samples you want to acquire.

If the acquisition is continuous (sample mode on the Timing function/VI set to Continuous Samples), NI-DAQmx allocates a buffer equal in size to the value of the samples per channel attribute/property, unless that value is less than the value listed in the following table. If the value of the samples per channel attribute/property is less than the value in the table, NI-DAQmx uses the value in the table.

Sample Rate	Buffer Size
no rate specified	10 kS
0–100 S/s	1 kS
100–10,000 S/s	10 kS
10,000–1,000,000 S/s	100 kS
>1,000,000 S/s	1 MS

You can override the default buffer size by calling the Input Buffer Config function/VI.

NI-DAQmx does not create a buffer when the sample mode on the Timing function/VI is set to hardware-timed single point.

Note  Using very large buffers may result in diminished system performance due to excessive reading and writing between memory and the hard disk. Reducing the size of the buffer or adding more memory to the system can reduce the severity of these problems.

Output Tasks

For generations, the amount of data you write before starting a generation determines the size of the buffer. The first call to a Multiple Samples version of the Write function/VI creates a buffer and determines its size.

You also can use the Output Buffer Config function/VI to create an output buffer. If you use this function/VI, you must use it before writing any data.

The samples per channel attribute/property on the Timing function/VI does not determine the buffer size for output. Instead it is the total number of samples to generate. If n is your buffer size, setting samples per channel to 3×n generates the data in the buffer exactly three times. To generate the data exactly once, set samples per channel to n.

NI-DAQmx does not create a buffer when the sample mode on the Timing function/VI is set to hardware-timed single point.

Regards,

Neil S.

Message Edited by Neil S. on 10-19-2007 08:21 AM

[Redeemed]

I don't want to beat a dead horse, but I just want to clarify:

Collecting in Continuous Mode, Analog 2D DBL NChan NSamp...
1. initialize buffer size in DAQmxTiming.Samples/Channel >= 2*DAQmxRead.NumSamples/Channel
2. You don't have to keep track of where you are in the buffer, because DAQmxRead is already taking care of that behind the scene.

Is this correct?

Also, is there a way to get the location of where you are in the buffer using DAQmx?

Thanks!

[Christian Mergl]

Hey,

As Neil allready wrote DAQmx is allocating the buffer....and LabVIEW does the rest.

When configuring a Task for continous acquisition the data will be written directly to your RAM via DMA. So the number of samples is the size of this buffer in your RAM. Then the DAQmx Read.vi takes the data from this buffer to your application memory. This memory will be allocated from the LV memory manager.

There are also other ways to set the buffer with the advanced DAQmx functions, and then only call the read VI within a loop if the number of samples are available. Attached you will find a little example on this (build in LV 8.2.1)

Christian

Message Edited by Christian_M on 10-19-2007 09:51 AM

Message Edited by Christian_M on 10-19-2007 09:51 AM

[BrowningG]

Hello Redeemed,

To clarify your last post, the DAQmx timing VI handles the buffer acquisition.  By passing a value to the number of samples, you are attempting to specify the buffer size.  Depending on the sample rate, this value can be overwritten by the DAQmx driver.  The Chart that Neil provided above indicates the values that the driver will set. 

The DAQmx driver will automatically read the most recent samples from the buffer during a continuous acquisition.  The position will also be automatically updated. 

The DAQmx read property node includes all of the buffer control properties for DAQmx.  The property Current Read Postion indicates in samples per channel the current position in the buffer. 

[Kevin_Price]

Browning G wrote:

The DAQmx driver will automatically read the most recent samples from the buffer during a continuous acquisition.  The position will also be automatically updated.

Isn't the default behavior of the DAQmx driver to read the "earliest-acquired-but-not-yet-read" data from the buffer?  I'm pretty sure it is.  This supports the typical use -- repeated calls to DAQmx Read give you a lossless stream of data.  You only have to call it often enough that it won't fill up and need to start overwriting.

(I've actually had apps where I needed to get "most recent samples", but I had to deliberately program around the defaults.)

-Kevin P.

[BrowningG]

Hello Kevin,

Thanks for your reply.  I did misspeak in my earlier post. 

By default, the DAQmx read will read the "earliest-acquired-but-not-yet-read" data from the buffer.  Thank you for pointing this out.