LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

QSM, queue based on current state

Solved!
Go to solution

@Patrem1 wrote:

I would need to do some formating before posting my Vi and I'm using fonctions from the 'Vision and motion'. 

But my current situation is like this example :

https://forums.ni.com/t5/Example-Program-Drafts/Queued-State-Machine-with-User-Input/ta-p/3497450 

 

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.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 11 of 14
(699 Views)
Solution
Accepted by Patrem1

@Patrem1 wrote:

But my current situation is like this example :

https://forums.ni.com/t5/Example-Program-Drafts/Queued-State-Machine-with-User-Input/ta-p/3497450 

 

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.


GCentral
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
0 Kudos
Message 12 of 14
(695 Views)

Hi, 

 

Thank you for your answers, I understand the potential problems with this. 

I think I will try crossrulz ideas. As my application is simple and I would prefer not having to learn QMH right now with the time I have. 

0 Kudos
Message 13 of 14
(687 Views)

@Ben wrote:

@crossrulz wrote:

...

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.

 

Spoiler

 

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
  • The code is incredibly well documented

lets examine the beast in a Trip to Grandmas house  

In that analogy there are only two things of importance.  

  1. The recipe for executing a finite goal
  2. 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.


"Should be" isn't "Is" -Jay
Message 14 of 14
(658 Views)