Hello, I am seeing some mighty peculiar behavior and I hope someone can help. I am using the standard producer-consumer loop, queued state machine, event-driven architecture. The producer loop contains the event structure...the consumer loop contains the functionality. The two chat with each other via a queue, a notifier, and some user events. In my consumer loop, I have several states -- Initialize, Get Data, Driver On, Current Change, All Drivers Off, Error, and Stop. The consumer loop spends most of its time in the Get Data state. The Get Data state contains a while loop which collects data from my sensors. It also contains a Get Notifier Status VI, and one or two other odds and ends (mostly processing -- this isn't a high-speed acquisition). The Get Data loop will stop under 3 conditions: if the interlock circuit indicates the interlock has been opened; if an event fires, thus sending a "True" value to the notifier; or if an error occurs. My code determines which one of these things has occurred and takes the appropriate action. If the interlock opens, the code generates a user event which will queue the Error state. If an error occurs, again the code generates a user event which queues the error state. If an event occurs, the code exits the state, and whichever event fired (Driver On, Current Change, etc.) is queued. (The notifier value is also set back to "False" previous to exiting the Get Data state, so that the loop won't terminate immediately the next time I enter it.) In that case, the consumer loop enters the appropriate state for executing the action indicated by the event (i.e. if the Driver On event fires, the consumer loop enters the Driver On state and executes that code...turns the driver on). After the action has been executed, the consumer loop generates a user event which queues the Get Data state, and the consumer loop re-enters that state and again loops until something happens to stop the loop. This works perfectly under all conditions except one. As it happens, my engineers have decided that they might possibly want to shut down all of the drivers while the current is in the middle of ramping. The current ramping is done inside a subroutine. I use my notifier to abort the current ramp and exit the subroutine if either the All Drivers Off button, or the Stop button, is pressed. My main VI also monitors the notifier, so it knows that the notifier is returning a "True"...i.e. an event has fired. It takes the same action as above...that is, exits the state it's in and queues the next state (which is always either Stop or All Drivers Off). If the next state is Stop, the code performs the shutdown actions and terminates. If it's All Drivers Off, the code turns all the drivers off, then generates a user event which queues up the Get Data state. This also works perfectly. HOWEVER. After this sequence of events has occured, I see some strange behavior the next time I try to fire an event. I have a probe on the notifier inside the Get Data loop, and I have a probe on the element output of the Dequeue Element VI in my consumer loop, so I can see when the states change. What I see is, the output of the Get Notifier Status flashes "True", then quickly flashes back to "False". The output of the Dequeue Element VI doesn't change, and the code does not exit the "Get Data" loop. If I then fire another event, the notifier again goes "True", stays that way until the code sets it back to "False", and both events show up in the queue, in the correct order. Both execute. So clearly the first event got into the queue, but for some reason didn't get dequeued promptly at the other end. My feeling is that this is because the Get Data loop did not register the "True" value of the notifier...something set it back to "False" before it could be read...thus the loop just kept looping along happily, with no idea that it was supposed to have stopped. Firing another event causes the notifier to be "True" long enough for the loop to notice, so it quits and then the next event can be queued up and executed...and so on. Interestingly, the NEXT event I fire under these conditions also exhibits this behavior -- that is, the notifier flashes "True", then sets itself back to "False" before the loop has registered it. And then the event after that one causes them both to fire, and on and on. I cannot find where that notifier is being reset, and for pete's sake I've been over it with a fine-toothed comb. And why in the world does it only do this under a single condition? None of this happens unless I've used the All Drivers Off button to interrupt a current ramp in the subroutine. If I let the current ramp complete, and then press the All Drivers Off button, the code does not show this behavior. Nor does it show this behavior under any other circumstances. Help? Thanks, d

LabVIEW

peculiar behavior from event-driven queued state machine

Author

I did put a probe on the notifier in the subroutine. That's how I know that it's not being registered. It does register in the relevant case in the main VI. Go figure.

The bottom loop in the subroutine has to stop when the upper loop stops. The upper loop will stop if either the current finishes ramping, an error occurs, or it receives a notifier from the main VI. The upper loop writes to an additional notifier when it stops. The bottom loop receives that notification and terminates. So there are actually two notifiers in the upper loop...it's receiving one and writing another. It seemed preferable to having local variables all over the place, as the same notifier can easily be used in the different execution cases and local variables tend to get messy in state machines.

Now that I think about it a bit further, I suppose I could put the continuous DAQ in a separate loop and perhaps use a queue or something to pass the relevant values into the subroutine for the necessary value checks. At the moment a resource competition won't exist because those tasks are used only in the Get Data loop and in the subroutine, and the subroutine is only called from the Drivers On and Set Current cases in the main VI. If the main VI is in one of those cases, then by definition it can't be in the Get Data loop. But I do see and acknowledge your point.

Thanks again,