UI control of State Machine

[Hamm]

I'm working with a traditional state machine that stores the current state in an OO cluster and reads it in the next iteration (no shift registers). 

I have another VI that handles the User Interface, it's a loop with an event structure. 

I need to transition the state machine according to the events of the UI.

In the past, I have simply wrote a new state to class variable when the desired event occurs.  This "works", but has proven unreliable because at times I find that the state machine will rewrite the variable after the User Interface VI tries to change it.

I've tried boolean flags indicating certain UI events, but it seems to be slower.  I've also tried writing event refnums to variables, this is about the same speed and probably a gratuitous waste of memory.

How do you do it?

[Allen_W.]

I am not sure of the relationship between your class and your state machine, but have you considered a queue driven state machine? This is very versatile because can feed the queue based on user events or programmatic actions.

Allen

[mikeporter]

A good solution is to make the whole thing event driven. Put your state machine in the Timeout event and have the usual events for managing the rest of the interface. As long as nobody pushes a button, the state machine merrily chugs along, doing its thing; but is a GUI event occurs, the event is handled and then state machine continues - or not depending on what the action was that the operator took.

Mike...

[TCPlomp]

Or the other way around, put the event structure inside one state 'idle' or something. In that way you can control your State Machine from the Events that happened in the Event Structure.

Ton

[Ben]

Mike wrote;

A good solution is to make the whole thing event driven. Put your state machine in the Timeout event and have the usual events for managing the rest of the interface. As long as nobody pushes a button, the state machine merrily chugs along, doing its thing; but is a GUI event occurs, the event is handled and then state machine continues - or not depending on what the action was that the operator took.

The State Diagram Editors "use as sub-VI" mode is included to fill this use case nicely unless the UI actions must "lock" the UI until it the events execute and the state machine can not tolerate this.

In that case I tend to put all of the UI stuff in the event structure and run the state machine in parallel interconnected via command a response queues.

Ben