LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Daq reading error

Solved!
Go to solution

Hi friends

I am getting this error while reading daata from cdaq 

kindly help me to solve this

daqerror.jpg

dq.jpg

795e57e7-d1a7-4fcf-955b-84ebb133e260.jpg

   

0 Kudos
Message 1 of 4
(901 Views)

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,

_______________________________________________________________

-Patrik
CLA || CTA
If it helps - Kudo it, if it answers - Mark As Solution
0 Kudos
Message 2 of 4
(876 Views)
Solution
Accepted by topic author kps001

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 4
(863 Views)
Solution
Accepted by topic author kps001

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4
(842 Views)