LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 200294

Solved!
Go to solution
Highlighted

Hello.

 

I am generating Error 200294. I have read through posts related to this error and incorporated solutions that I think apply to my code. I want to execute an unlimited number of triangle pulses, with varying amplitudes based on the level selected. When I look at the output on the oscilloscope, the correct output signal is generated each time I execute a level and I am able to output a signal more than once. However, when I quit the program, I still get the error. I used a probe to look at the data going into the Write function and there is data available each time I execute the task. 

 

I would appreciate any suggestions to eliminate this error and clean up my code.

 

Thank you.

0 Kudos
Message 1 of 3
(289 Views)
Highlighted
Solution
Accepted by topic author Miller37

Might the error have been -200294?  That little "minus" sign is pretty important ...

 

I'm guessing the problem is the way you stop your Consumer Queue (the lower loop).  I know that numerous NI examples show Releasing the Queue to cause an Error in the Consumer, but this is really a stupid way to stop the loop, particularly if you are not handling the Error properly.  Consider your code.  You Release the Queue.  This causes an Error in the Dequeue (as its Queue doesn't exist).  It does something (who knows what?) and puts something (possibly an empty Array) on its (orange) output wire, which goes to the DAQmx D/A Write that is expecting N samples, and gets (possibly) 0.  Oops, maybe this causes Error -200294.

 

Here's the Simple Fix -- use a single Error Line in the Consumer.  Put the Dequeue on the same Error line as the DAQmx Write ("jog" the DAQmx Task Wire around the Dequeue function).  Now place a Case Statement around the remaining code (the DAQmx stuff) and wire the Error line to the Case Selector.  See the nice green border?  Go to the "Error" (red border) case and place a "Clear Error" on the Error Line.  Leave the Stop terminal outside the Case structure, but wire a "True" from the Error case to the Stop terminal.

 

Now when an Error occurs because you (foolishly) closed the Queue, your Consumer loop will "see" it and respond by clearing the Error (inside the Error Case) and stopping the loop.  As a bonus, any code you run on this Error line after the loop exits will also see the "No Error" condition!

 

A Better Way is to use a "Sentinel" to let the Producer tell the Consumer to Exit.  When you are sending Arrays in a Queue, the most obvious Sentinel is to send an Empty Array when the Producer Queue ends.  The Producer Queue has exited, so it won't be putting anything else on the Queue, but leaves the Queue alone (because how does it know if the Consumer has had a chance to read the last entry?).  In the Consumer, you use a similar construction as what I described above -- you Dequeue, and put the rest of the code in the loop inside a Case Statement.  But since you are now using a Sentinel, what you do is examine the item you just dequeued and ask "Is this the Sentinel?" (in this case, was that an Empty Array?].  If so, you do the "Exit the Consumer" case where you don't do anything with the Queue contents (there weren't any in this case), but bring out a True to stop the Consumer, leaving the other Case to process the data.  Now, when the Consumer exits, it is definitely "safe" to Release the Queue, as both Producer and Consumer have exited without errors.

 

Bob Schor

Message 2 of 3
(253 Views)
Highlighted

It took me a little while to figure out what I *think* you're trying to do.  A big part of my confusion was driven by the fact that you configured your AO task for continuous sampling with regeneration explicitly disallowed.  But then the rest of the code seems structured to want to regularly software trigger a brief burst of finite samples.

 

So I made only a very few small mods to the code so that it would stay generally recognizable for you.   Mainly, I changed over to Finite Sampling mode so that the series of DAQmx calls in your consumer loop can make sense.  Once in Finite Sampling mode, a couple of the DAQmx property nodes weren't useful any more, so I got rid of them.  And I did just a wee bit of wire tidying in the process of figuring out the code in the first place.  I think that's about it, and I suspect things will work more like you want now.

 

 

-Kevin P

0 Kudos
Message 3 of 3
(241 Views)