Other events interfere with abort for state machine started by an event

[davey31415]

In the attached VI there is a state machine that is triggered by a boolean “start” change event.  There is also a boolean “stop” that stop the state machine, a numeric “voltage” that has an event handler and a boolean “exit” that has an event handler.

The stop button works as expected unless if the voltage value is changed before the stop button is pressed.  I was thinking this might be because there is an event for the voltage value change but there is also an event for the exit button value change and the problem does not occur if the exit button is pressed before stop.

If anyone could explain the reason I am only running into the problem with the voltage value change and/or how to properly implement the stop/abort function I would appreciate it!

Thanks,

Dave (LabVIEW 7.1)

[AnalogKid2DigitalMan]

Dave:

Your vi did not attach.

[tbob]

You forgot to attach the vi.  Some people will set up an exit event like this.  Put Exit button on front panel.  Create event case for Exit value change.  Put exit button's block diagram icon inside event case and wire it to loop stop sign.  What can happen is that the exit button is pressed while some other event is taking place.  The exit event gets put in the event queue.  Now the exit button has been read, and if set to a latch condition, the button value returns to False because it has just been read.  By the time the exit event takes place, the button is false and the loop does not stop.

To alleviate the problem, don't wire the boolean button to the loop stop sign, instead wire a True constant.

[davey31415]

Ah whoops, here is the VI.

I thought the event queue might be causing the problem but it seemed like the exit button wasn't having the same effect as the voltage value change.  I must be missing something!

Message Edited by davey31415 on 11-27-2006 03:09 PM

[johnsold]

Dave,

What you have might be better handled by a Producer/Consumer architecture. The loop inside the Start: Mouse Up case runs for many seconds before any other case can execute. That loop (and anything which takes longer to execute than the user takes to get the next control) should be in an independent parallel loop. Pass the Start, Stop,and Exit commands to the other loop via queues. The data can be returned via another queue.

Lynn

[davey31415]

Thanks Lynn, I'll give that architecture a try for the first time.

Thanks tbob too, I have changed my exit event as you suggested; good to know the boolean can reset before the event finishes!

[davey31415]

Well that certainly solves the problem I was having!  The case in a while in a case in a while reminds me of the 10-level deep if statements I used to end up when starting C programming.  I guess the inner case/while are required for the state machine and the outer while is required for the Producer / Consumer.  I always find myself thinking in terms of "if/then" statements and the case/comparison took the place of that. 

Regardless, problem solved.  If anyone has tips on how to make it (attached) look better, please post them!

Lynn, I wasn't quite sure about your instructions on passing the exit and stop commands through the queue.  I went with the idea of keeping the long-running loop separate.  I know I still have a bit more to work out such as use of exit button while state machine is running, and the stop button only works in between state machine iterations.

Message Edited by davey31415 on 11-27-2006 07:04 PM

[davey31415]

I feel like I'm close with this one.  If it was working I feel like I am using a ton of resources to do something very simple though.  Other than that, it doesn't work!  For some reason the queue doesn't seem to be filling up at all- I can press stop again and again but the ControlStop queue # waiting to be removed does not budge from zero.  Any ideas why that is?

[tbob]

The best way to troubleshoot this problem is to turn highlite execution on.  That way you can see the data flowing.  You can see what happens when you press the stop button.  I can't do it here because I don't have your subvi's.  Another approach is to remove the subvi's and put fake data in its place just to troubleshoot the architecture.  Then when is looks good, put back the subvi's.

[johnsold]

I can't run your VI because of missing controls and subVIs, so I need to guess. Are you in the inner loop when you say the ControlStop queue is not filling? Only when the sampling loop is running will you see that indicator update.

You really only need one queue and one loop in the lower state machine. Add states for Idle, Init, Start, Stop, and Exit to the state enum type def. Use the enum as the data type for the queue. Start the loop in the idle state and stay there until a Start, Stop or Exit command is received from the UI loop. Put a 100 ms timeout on the Dequeue function. This eliminates the need for the 100 ms Wait but allows for immediate response to a Stop command. Put the Sampled Data array on a shift register and you can get rid of the Value property nodes, which tend to be very slow. In the Sample Inrush In case replace the 5000 ms wait with a call to a Wait state. Set the End of Wait time (current tick count plus desired wait time in milliseconds) in a shift register. In the Wait state compare the current tick count to the shift register value. This allows the Stop command to interrupt the wait.

Sorry for being a bit long-winded. I don't ahve time right now to fire up LV 7.1 to modify your VI.

Lynn