My error I assumed this was named a queued state machine, it is a queued state machine with user input.
So you're saying this is a abomination or it's okay?
EDIT : So to be clear at first I had only a 'Queue state machine' that I'm trying to change to a 'Queued state machine with user input'.
Read the comments below the example you linked.
In a very limited application you can get away with that but it does not scale well and if you do not know that changes "need to be done delicately", the beast can go wild on you. I have seen those growing to use 90 or more states because someone just added states as time went on.
But for what little I know of what you are doing I suspect a "QMH" is better and if you separate the ideas of your "Mode of Operation" from the states of the QMH, it may be easier to avoid conflating states with modes.
My error I assumed this was named a queued state machine, it is a queued state machine with user input.
So you're saying this is a abomination or it's okay?
Having multiple loops that can affect the state queue is where I call it an abomination. Some ideas:
1. Put the Event Structure in your "Idle" state and react to the user as necessary by enqueuing states.
2. Use a Dequeue element for another queue in your "Idle" state and allow the GUI loop to send messages as necessary. The QSM can then react as it sees fit based on whatever other state information it has.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
After reading the OP's response, use a FGV with error in and error out
Actually, it sounds more like I did not properly understand the setup the OP has. QSM is a single loop, which means it should be fine storing it in that loop. But the OP's last post points to them actually using a QMH.
Patrem1, Please post your VI so we can understand what your current situation is.
IN the deepest darkest corners of the LabVIEW wild there exist an abominable beast that is part QSM part QMH.
That critter get feed from an event handling loop or will on occasion eat its own tail. It actions are chaotic and there is no way to predict it next move or tell where is or has come from.
Beware the Beast!
Ben
Ben! I'm amazed that you remember that post! That "Beast" functions exceedingly well when it has a "zookeeper" (That is, don't ever let anyone feed the animals)
So lets expose a definition of "Event Driven Queued Message Handler" EDQMH
This is a twist on an Event Driven P-C pattern where the following rules apply:
No state nor event can enqueue more than 1 element
Event cases must enqueue opposite end
State cases may enqueue but never enqueue opposite end
If State cases flush the queue and do not enqueue the user must be notified that something smarter than the code needs to make a decision.
Timeout events are prohibited
An event driven queued message handler it useful when:
the user interrupts MUST take precedence
The state machine has an intentional need for user input (non-autonomic)
No one not versed in the construct will ever touch the code
In that analogy there are only two things of importance.
The recipe for executing a finite goal
Users! Damn them! or "Events that may make us change the path we will take"
The down side is that once you let the thing out of its cage- Ben is exactly correct, some "Developer" isn't going to follow the rules and there is no safety net for that fool.
