Daq reading error

[kps001]

Hi friends

I am getting this error while reading daata from cdaq 

kindly help me to solve this

   

[Ajskrim]

Hi kps001,

This means you are telling your DAQ card to acquire more samples than you are reading with your application.
You can find far better and detailed explanation here:

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

Hope this helps,

[GerdW · Accepted solution]

Hi kps,

simple rule:

Don't add additional wait functions when your DAQmx task (and the DAQmxRead) will be responsible for setting the loop iteration rate!

Do you really need to place 4 DAQmx tasks within one loop? 4 tasks with different sample rates???

Why are you using TimedWhileLoops in your VI, which is running on a plain Windows (I guess)?

Why do you use so many local variables?

Are you sure your AO tasks are defined before those PID loops try to set output values? That 1s wait before the loops might be sufficient, but are you really sure?

Why do you need to scale the PID output back to 4-20mA current values? Why don't you set the output range and PID gains as needed and have the PID itself do the scaling?

Why do you use DAQmxWrite in "N chan 1 sample" mode when your task only contains a single channel?

There is so much unclear in your VI. It's block diagram is far too big, please cleanup!

[Kevin_Price · Accepted solution]

Pay close attention to GerdW's reply.  The first thing he mentioned (getting rid of the call to "Wait until next msec multiple" in the Read state) is the key to your *immediate* problem with the DAQmx error.  But he also pointed out several additional things that are somewhere between likely and certain to cause you future problems.   Be sure to think about and work through those things too!

DAQmx key idea: with a task configured for 2000 samples per sec and a repeated call to DAQmx Read that requests 40 samples, DAQmx *itself* will do the necessary waiting of up to 20 msec until the next set of 40 samples is ready. 

   Having the redundant wait actually *hurts* you, because the minor timing variations that are inevitable with Windows means that you'll occasionally miss one of those 20 msec multiples and be stuck waiting an extra 20.  Each time that happens, you build up more backlog of samples in your task buffer until it eventually gets overfilled and you get the -200279 error.

-Kevin P