Error0r-200290 occured at DAQmx Wait Untill Done.vi

[GowthamRajegowda]

Hello Everyone hope you all doing well.

 We have created a Lab View  software for some application.This software uses PCI-6713 analog card which is used to generate the required signal and this generated signal is fed to UUT (Unit under test). In our software we have controls for amplitude, frequency, Noise and Distortion controls etc.. so user can generate signal by controlling above controls, in order avoid changing  the parameters each time before generation we have written a python code which takes the control of lab view and changes parameters by its self and generates the signal and python will create the corresponding csv file. We are calling the pythoncode.py through the same GUI i.e., in GUI pythoncode will run through System execu.vi land take the controls of the same GUI which is running.

This is executing properly continuous untill we stop the pythoncode execution through GUI, but the thing is sometimes it will get hang and pop up error as shown below

Error -200290 occurred at Property Node DAQmx Wait Utill Task Done.vi:1->Cont Write Dig Port-Int Clk.vi Possible reason(s): The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated. To avoid this error, you can do any of the following: 1. Increase the size of the background buffer by configuring the buffer. 2. Increase the number of samples you write each time you invoke a write operation. 3. Write samples more often. 4. Reduce the sample rate. 5. Change the data transfer mechanism from interrupts to DMA if your device supports DMA. 6. Reduce the number of applications your computer is executing concurrently

but this error is not coming every time its like random sometimes GUI will run 48hrs without any problem and sometimes it will popup error event after 5 or 6 hrs i am too worried about this to clear as soon as possible

NOTE: things in my GUI

Sampling Rate=100K Hz

Wait Until Done i have kept = -1

signal Duration is=2.2sec

Gap between Signal Generation= 8 sec

PC Info

Windows7 32 bit

4GB RAM

Please can anyone suggest me a idea to solve this

Thanks in advance

[Kevin_Price]

Code would help.  It's unclear why you find it necessary to share duties between LabVIEW and python and exactly which responsibility lies on which side.

That said, 100 kHz continuous for 24+ hours is a bit of a challenge.  DAQmx and your hardware can handle it, but long-running highish-bandwidth  data handling puts stress on any weak points in your application programming and can reveal unpredictable quirks in your operating environment.  (For example, many threads arise here when Windows puts USB ports into power-save mode after some hours of runtime.)

Some things in your description sound a little incompatible.

"Wait until Done" - typically only used for Finite Sampling tasks

"Cont Write Dig Port - Int Clk" - an example program for non-regenerative Continuous Sampling 

"signal Duration" and "Gap between..." - these parameters imply Finite Sampling

Error 200290 - this is a buffer underflow error, normally only seen in Continuous Sampling tasks

Post the code and someone will probably be able to help solve any issues on the app programming side.  It's too soon to entirely rule out the OS and environment, but the seeming confusion between Continuous/Finite tasks makes me suspect it's mostly an application programming issue.

-Kevin P

[GowthamRajegowda]

Hello Sir,

Thank you for your kind reply since it is a project code I couldn't post so here is the main code along with hardware write code

[Kevin_Price]

The hw write code looks ok EXCEPT that it's code for analog generation.  Your error seems to reference an example vi for digital output.  What's the DO generation code look like?

-Kevin P

[GowthamRajegowda]

Hello Sir,

We are not having the Digital Output we are reading Digital inputs

here I am attaching the play music vi in which the same error occurs sometime, we will play the music folder which has 10Hrs duration(i.e., 30 min duration of total 20 files)

[GowthamRajegowda]

here is the error image while playing music

[Kevin_Price]

1. Keeping your wiring more neat and tidy *really* is helpful to both yourself and others who need to understand your code.  As is, it's much more difficult to follow than it needs to be.

2. Your "producer" loop where you read from file has fixed 100 msec timing per iteration.  Perhaps that's too long and you're starving your "consumer" (AO) loop of data?

3. Your "consumer" loop has 2 separate Dequeues in series, each with a 2000 msec timeout.  Since your producer runs faster, this may not be the immediate problem, but it reveals a lack of clarity in thinking through the app.

4. Errors are being ignored in several places.

I think you should coordinate your loops a little differently instead of relying on fixed timing.  Basically, you should let your consumer inform your producer when it's ready to accept more data and let *that* drive your producer loop.  

   A simple way to do this is to set the queue up for a limited size.  Then add a short timeout to the enqueue in the producer loop.  If/when it times out, you know the queue is full, so you try again on the next iteration.  Eventually when you reach end of file and there's no more data to enqueue, send an intentional empty array as a "sentinel value" to let the consumer know there's no more real data coming.

This way, the producer loop will quickly fill the queue and then keep it full until you reach end of file.  The producer loop can then exit as the consumer loop "catches up", consuming and generating the data that's still in the queue buffer.  When the consumer dequeues an empty array (with no corresponding error or timeout), it's time for the consumer loop to quit.

Overall this app seems like a good candidate for using Channel Wires instead of the queue.  Channel Wires include a dedicated mechanism for the producer to indicate "I'm all done producing".  Search here and you'll find lots of info plus a lot of advocacy from Bob Schor.  

-Kevin P

[Kevin_Price]

One more thing I meant to mention.  A little further restructuring of the code (and a big enough queue buffer) would let you generate the AO continuously instead of having a short gap as you change to another file and reconfigure AO.

If the producer was more independent of the consumer (right now they aren't fully because they reside within the same outer loop), then when you finish with one file, you'd simply start reading and enqueueing from the next.

Dunno if this is desirable for your app, but it seemed like it *might* be.

-Kevin P

[GowthamRajegowda]

Hello Sir,

Please find the attached error Image which I was talking about

[GowthamRajegowda]

Hello Sir,

That solution which you have gave is for that Play Music vi, but similar error as I attached image previous one what about that..??