Getting Error -200279: Unable to Keep Up with Acquisition in DAQmx

[PaulOfElora]

OK, guys, one more question for the DAQ fire hose I'm drinking from.  I'm trying to run my little cDAQ 9205 AI card in a 9174 chassis just as fast as I can.  I'm trying to achieve the absolute minimum *latency* of the analog voltage input measurement.  When I crank up the sample rate to the 9205 maximum of 250kS/s, I soon get a -200279 error.  As you can see, I'm doing extremely little to slow down the PC.  I can upsize the DAQ buffer, but of course that just prolongs the agony - it just takes longer to croak.  I *think* I understand that the default transfer mechanism is DMA (because it seems to be supported for my hardware, although I'm not positive on that.  Since I'm not really *doing anything* with the data (other than occasionally displaying it), I wouldn't think I'd really need to set up a buffer in the software.  What's wrong with my thought process? Thanks for any insight, paul

[GerdW]

Hi paulo,

do you think it's a good idea to read samples one-by-one while setting the task to a sample rate of 250kHz?

---

@PaulOfElora wrote:

As you can see, I'm doing extremely little to slow down the PC.

You do your best to slow down the DAQmx driver by requesting just one sample per DAQmxRead call!

Calling DAQmxRead adds some overhead, more or less constant independently from requested sample number. So you add that overhead to each and every sample! Usually its recommended to read samples worth of 0.1s (yielding a loop rate of 10Hz) so you would add that overhead just 10 times per second, compared to your 250k times per second…

[mcduff]

Look in the Example Finder for Continuous acquisition, 250kSa/s should be no problem, but as @GerdW said, you cannot acquire them one-by-one.

mcduff

[Kevin_Price]

In addition to what GerdW already mentioned:

- nope, not DMA.  Your 9174 chassis connects over USB, where your best case scenario for latency is simply always gonna be worse than what you could get with a desktop PCIe board (or PXIe).

- The fact that you get a buffer overflow error while reading 1 sample at a time means that you have another source of *HIDDEN* latency.   The calls to DAQmx Read will be trying to return a continuous lossless stream of samples.  When you read 1 sample at a time and iterate slower than the hw sample rate, the 1 sample you read will be growing increasingly outdated.

- For the most part, increasing your sample rate isn't going to help you with latency.  In fact, you might be better off with a software-timed on-demand task if you just want to poll for 1 sample as fast as possible.

- However, if you stick with a hw-timed and buffered continuous sampling task (as you have now), this might be a good use case for explicitly wiring a -1 to the # samples to read.  You could add a msec Wait timer in the loop that would pretty much define your maximum latency.  Each call to DAQmx Read will return whatever # of samples are in the buffer, helping to prevent overflow.  The oldest one will have been sampled just after your last loop iteration and have the most latency.  The newest one will have the least latency, subject to limitations of the USB bus.

-Kevin P

[Bob_Schor]

Why can't people learn to attach VIs, rather than pictures (even if they are Snippets)?  I could not get the Snippet to expand into code, not sure why (except it's LabVIEW 2019) ...

Change the Timing VI to specify 1000 samples per channel, make your DAQmx Read be 1 Channel, N Samples, wire 1000 into the DAQmx Read's # Samples/Channel, choose your output format (1D Array of Dbl or Waveform), and you'll be off!  

I know you say you are trying to achieve the minimum latency of the analog input measurement, but you are trying to have your cake and eat it, too.  What do you plan to do with a quarter of a million points a second?  As you can see, it takes a little time to make decisions.

Why don't you try doing the experiment from the other direction?  Start with, say, 100 samples/second, taken one at a time, and do something meaningful with each value.  Now go up to 1000 samples/sec, then 10K, then 100K, then see where things break down.

Bob Schor

[PaulOfElora]

Ok, it's starting to sink in.  Actually, the poor thing did pretty well keeping up at about 150kS/s, but I'm beginning to realize what all has to happen just to get 1 sample.  I guess the USB transfer adds some delay, too.

I like Bob's approach of sneaking up on it from slow to fast, will try in the morning.

Bert, I did try the idea of using the same task for both 'repetitive' 20-sample reads, and the Start Trigger functions.  Didn't work - the read wouldn't wait for the trigger.  I'm surprised that DAQmx would let me create 2 different tasks using the same card, and not throw the resource error until I actually tried to do a read.  Doesn't matter.

I do have 1 question though. Looking at articles like at:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAraSAG&l=en-US

They talk about the circular "PC Buffer".  Is that the "DAQmx driver's" memory?  So the fact that I'm shoving data into a functional global or a queue has nothing to do the "PC Buffer, right?

Again, thanks so much for the help and tutoring, guy's! Many more adventures ahead...

[Bob_Schor]

---

@PaulOfElora wrote:

They talk about the circular "PC Buffer".  Is that the "DAQmx driver's" memory?  So the fact that I'm shoving data into a functional global or a queue has nothing to do the "PC Buffer, right?

---

I believe you are correct, that they mean the memory in the driver where data are transferred from the hardware, and then DAQmx delivers it to you as "Data Out".  You do not want to "shove it into a functional Global", but a Queue (or Stream Channel) isn't a bad idea ...

Bob Schor

[PaulOfElora]

Thanks, Bob.  Uhhh, well, I *was* gonna shove the data into an FGV - I'm incorporating averaging of samples into the FGV to use with the Integral part of my PID-ish loop control.  But I'm open to suggestion/education.  Looking at channel wire stuff, I do see an intriguing nugget about "Accumulator Tags" - maybe I could use that as an averaging function?!?!

I did try & save the vi's as LV16 for you, but when I do that I get weird, slightly scary stuff happening like trying to save my entire library out to a new folder, spooks me a bit.  Guess I need to prove to myself that that's not screwing my working, LV19 library.  Guess my stuff is all going to change anyway today, sigh...

[crossrulz]

---

@Bob_Schor wrote:

Change the Timing VI to specify 1000 samples per channel, make your DAQmx Read be 1 Channel, N Samples, wire 1000 into the DAQmx Read's # Samples/Channel, choose your output format (1D Array of Dbl or Waveform), and you'll be off!

---

Generally, you are best off leaving the Samples Per Channel on the DAQmx Timing VI unwired when using the Continuous Samples.  You are just limiting your buffer if you wire something up there.  As far as the number of samples to read inside the loop, I tend to keep with the 100ms worth of data per read.  So in this case, I would try to read 25k samples per iteration.

[crossrulz]

---

@PaulOfElora wrote:

I'm incorporating averaging of samples into the FGV to use with the Integral part of my PID-ish loop control.  But I'm open to suggestion/education.  Looking at channel wire stuff, I do see an intriguing nugget about "Accumulator Tags" - maybe I could use that as an averaging function?!?!

---

What kind of averaging are you doing?  Do you want a moving average?  An average over X number of samples?  How fast is your control loop?