LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

problem with flush queue

I have a fairly straight forwared producer/consumer event driven app based on the template.  I am using enums for the queue and a case statement inside the consumer loop.

 

I have several buttons tied into the event structure to start and terminate actions.  The first thing I do is to stuff the queue with an enum that directs execution to a state that reads a micro and displays the result.  At the end of that state, I push it's enum back into queue, thus starting off this state to loop indefinately as a monitor.

 

I then can press a button that pushes the next function to be performed onto the queue (charging).  It executes and then pushes its enum state back on the queue (looping) until it finishes (reaches a particular voltage) at which time is simply does not push its state on the queue and quits running.  Because of the queue, the monitor loop and the charge loop run one after the other and when charge quits, the monitor keeps running.

 

Up to this point, all is fine.

 

If I want to manually terminate the charge process, I have a key in the event structure that pushes a terminate state onto the queue.  Within the terminate state, it does several things but before it leaves, it flushes the queue and then pushes the monitor state back on the queue.  Flushing the queue of only the charge state would be nice and would stop that from cycling, but there is no function to do that.  Since there will only be two states in the queue, monitor and charge, I should be able to flush the queue and then push the monitor state back on the queue.  The flush and push queue vi's are one after the other with their error pins forcing sequential execution.   The problem is that I do not always get the monitor state to show up in the queue and the program effectively stops.   Do I need to wait some finite time or check some variable to make sure the flush operation has completed before pushing?  I can add weights or run in trace mode and it seems to fix it, but that is not acceptable.

 

Has anyone else seen this type of problem.  I have seen it before.  I'm running LV2010.0.1 on XP Professional

0 Kudos
Message 1 of 3
(2,375 Views)

Any chance you can post the code or a stripped down version exhibiting this problem?

=====================
LabVIEW 2012


0 Kudos
Message 2 of 3
(2,366 Views)

I didn't realize that if there is a code on the error chain entering the queue vi's, they don't execute.  I handle all my own errors in the state machine so I ended up having to encapsulate the queue vi's and break the error chain to get it to work.

0 Kudos
Message 3 of 3
(2,357 Views)