The way the DAQ buffer works in continuous mode with DAQmx

[mcduff]

---

@BertMcMahan wrote:

---

@mcduff wrote:

One last tip for continuous acquisition if you are also using the built in logging. Make the number of acquired points for each event an even multiple of the disk sector size. This greatly improves efficiency. I have used the same functions as you in LabVIEW instead of C and for high speed acquisition multiple channels 10MSa/s; having an even multiple of the disk sector size made all the difference.

---

Here's a link on determining your sector size:

https://www.computerhope.com/issues/ch002288.htm

---

Can't access your link, not sure if it is a work related issue but why not use a native function?

EDIT: Forget the OP was using C. Now the link makes sense. Sorry.

[vygr0]

Any idea what that corresponds to in DAQmx? Does DAQmx have a C function for that? Thanks

[mcduff]

---

@vygr0 wrote:

Any idea what that corresponds to in DAQmx? Does DAQmx have a C function for that? Thanks

---

What I posted is a LabVIEW function, SORRY, there should be a native function in a standard C library to get the disk information. Typically the sector size is 512 bytes or a multiple of it.

[vygr0]

---

@Kevin_Price wrote:

2. However, the driver is also smart.  It not only keeps track of where it left off pushing new data into this circular buffer, it also keeps track of where your app left off pulling data out of the buffer with calls to the DAQmx Read function.  If your app is "keeping up", the driver will be free to push new data into the buffer because it'll only be overwriting old values you already pulled out.

---

Hey so does DAQmxReadAnalogF64() always read N number of samples from the "head" of the buffer? You explained that when it's the DAQ card placing newly collected samples into the buffer, the buffer is a circle so it wouldn't have a "head". Is it the same "circle" mechanism when the user read samples from the buffer with DAQmxReadAnalogF64()? From your answer I think buffer acts like a circle also when DAQmxReadAnalogF64 reads samples from it but I wanted to make sure. Thank you!

[vygr0]

---

@Kevin_Price wrote:

4. DAQmx is good at controlling timing without a lot of CPU waste.  If you sit in a tight loop doing nothing but requesting 1/10 sec worth of data per iteration, that loop will be paced by DAQmx waiting for the next 1/10 sec of data that it needs to return back to you.

    Reading 1/10 sec worth of data at a time is a good rule of thumb and starting point for a wide range of acquisition tasks.

---

Another question I have is about this. In my application I probably will need to read much more frequently, around 1/100 sec worth of data. What would be your opinion on calling DAQmxReadAnalogF64() that often? Thanks.

[mcduff]

---

@vygr0 wrote:

---

@Kevin_Price wrote:

4. DAQmx is good at controlling timing without a lot of CPU waste.  If you sit in a tight loop doing nothing but requesting 1/10 sec worth of data per iteration, that loop will be paced by DAQmx waiting for the next 1/10 sec of data that it needs to return back to you.

    Reading 1/10 sec worth of data at a time is a good rule of thumb and starting point for a wide range of acquisition tasks.

---

Another question I have is about this. In my application I probably will need to read much more frequently, around 1/100 sec worth of data. What would be your opinion on calling DAQmxReadAnalogF64() that often? Thanks.

---

There is overhead with each read call. I have also found that ~100 ms of data for each event works best. If your sampling rate is small enough frequent calls may not be a problem, for a large sampling rate that it becomes problematic.

[vygr0]

---

@mcduff wrote:

There is overhead with each read call. I have also found that ~100 ms of data for each event works best. If your sampling rate is small enough frequent calls may not be a problem, for a large sampling rate that it becomes problematic.

---

Thanks! I guess at this point I will need to try with my specific hardware and see the performance myself.

[Kevin_Price]

Hey so does DAQmxReadAnalogF64() always read N number of samples from the "head" of the buffer? You explained that when it's the DAQ card placing newly collected samples into the buffer, the buffer is a circle so it wouldn't have a "head". Is it the same "circle" mechanism when the user read samples from the buffer with DAQmxReadAnalogF64()? From your answer I think buffer acts like a circle also when DAQmxReadAnalogF64 reads samples from it but I wanted to make sure. Thank you!

---

Yes, DAQmx tracks both app-side reads and driver-side writes with the same kind of circular mechanism.  As you iterate over successive calls to DAQmx Read, you'll be retrieving a lossless sequence of samples, no duplicates, no gaps.

Note that while DAQmx's read pointer and write pointer are *distinct*, they are not entirely *independent*.  They pay attention to one another. 

    If your combo of read position and # samples to read would want to overtake and pass the write position, DAQmx will wait for enough new samples to come in to advance the write pointer and allow the read to complete. 

    Analogously, if new samples are arriving from the board but would overtake and pass the read position, DAQmx throws a fatal task error, preventing the overwrite that would make you lose some samples and give you others out of order.

-Kevin P

[Kevin_Price]

---

Another question I have is about this. In my application I probably will need to read much more frequently, around 1/100 sec worth of data. What would be your opinion on calling DAQmxReadAnalogF64() that often? Thanks.

---

I would start a friendly argument with you and have you try to convince me that you had a good reason to try to perform reads 100 times a second.

Such apps *do* exist, but in my experience on these forums and in real life, they aren't all that common.

-Kevin P