A better and efficient alternate to Queued State Machine

[MogaRaghu]

I am just attaching a very simple QSM. This is just a Proof of concept to change the User interface language based on a selection.  Actually in real time machine controls i have been using the QSM architecture for sequential logic.  Just  create a TypeDef for the Enumerated Queue states and code.  Its working but at times the number of discrete states runs into hundreds and it gets difficult maintaining.

Just thinking aloud if there is any better method in LV to handle Sequential Logic ? There are times when you keep doing the same thing that you miss an opportunity to migrate to new methods !!

[Yamaeda]

Queueing up new items in the consumer can lead to some issues, but that's not the main thing here.

If you're always doing the same things, there's no reason to separate them into different cases, just make 1 sub-vi or a state machine in 1 case.

Also, what happens if the producer queues up an action while this is running? Instead of 1,2,3,4,5 it might be 1,2,3,8,4,9,5,10, what'll happen then?

/Y

[crossrulz]

Some advice:

1. Do not name your queue.  Have the queue named can lead to another loop accidentally using the same queue name and then things get really weird (who will dequeue what, etc).  By leaving it unnamed, the only way to access that queue is with the reference.

2. The queue is good for adding many items to your sequence at once.  Each case should not be adding to the queue unless they need something additional done.  With your example, you could have case 0 enqueue {1,2,3,4,0} and then your other cases do not need to do anything to the queue.  And when 0 comes back around, since I made sure it was put at the end of the queue, it can enqueue the full sequence in again.  If you want to keep have each case decide where to go next, then just use a simple shift register instead of the queue since it is doing nothing but adding complication.

[Ben]

---

@MogaRaghu wrote:

I am just attaching a very simple QSM. This is just a Proof of concept to change the User interface language based on a selection.  Actually in real time machine controls i have been using the QSM architecture for sequential logic.  Just  create a TypeDef for the Enumerated Queue states and code.  Its working but at times the number of discrete states runs into hundreds and it gets difficult maintaining.

Just thinking aloud if there is any better method in LV to handle Sequential Logic ? There are times when you keep doing the same thing that you miss an opportunity to migrate to new methods !!

---

THAT is exactly the reason I rail against the QSM every chance I get!

Sure it is simple to start and a good developer can guard against problems, but let just one novice take over not knowing the dangers and an avalanche of problems occurs.

1) Look at a QMH which process requests but does not feed itself like the Worm-Oroboros known at the QSM.

2) as mentioned above, use sub-VIs instead of "states" in the QSM. If you are tempted to queue up three states in a row in a QSM, just call three sub-VIs.

3) Use multiple QMH if there is more than one thing happening. Do not mix multiple functional areas into a single QMH. Create unique QMHs or whatever for each area of functionality.

I will spare you the rest of my usual rants about QSMs and close by saying...

Once you start think seperate loops and the interaction between those loops, your code will be easier to maintain and understand.

Slay the dragon now and you will be better off because you did.

Ben

[Ben]

AS a possible help I offer the documents I included in this post many years ago.

Those were application developed back in LV 5 and 6 but the ideas still stand as valid today. Please review those docs and read the comments etc to get another idea how to design applications.

Thank you,

Ben

[MogaRaghu]

@Ben

I tried reading the link you gave and found some good arguments on Commenst for LV code - the pros and cons of it. 

But honestly yet to get a good tutorial on QMH. Shall look up the KB over the week end.

You being so against the QSM, i guess its OK for someone to use the Queue per say to pass variables between different VIs. Its a long time since i totally moved away from Local variables ( only use to avoid very wires at times ) and Global variables.  Have so far not tried Shared Variables since all my applications never ever needed a network topology - maybe i can use them to pass data between VIs on the same machine ? Again to start reading - this is never ending man !! . 

[Bob_Schor]

I think that "Before there were Global Variables, there were Functional Global Variables (FGV) a.k.a. VI Globals (VIG)".  In case your hair isn't sufficiently gray, these are simply VIs with a While Loop with True wired to the Stop Indicator, a Case Structure with a Get/Set Boolean input, a "Data" Input and Output, and a Shift Register holding the latest "Set" value.  Another way to think of it is an Action Engine with only two Actions, Get and Set, or a "simple Memory function".  What I like about it is (a) it has Error In/Error Out, so it obeys Data Flow, (b) it is more compact than most Globals, (c) I can design its Icon to make it "more recognizable", and (d) as long as I am judicious about how/where/why I call the Set function, I should be able to avoid Race conditions.  I'm sure there are other plusses and minuses that I'm overlooking ...

Bob Schor

[MarcDub]

One comment I feel relevant here about QMH is that you should try to break down your application into sub-processes, each sub-process being a QSM, even for the UI. Each sub-process has typically only a few states. The issue becomes communication between the sub-processes. Once you start thinking this way, it is the first step towards Actor Framework and other multi-processes framework.

[MogaRaghu]

---

@Bob_Schor wrote:

I think that "Before there were Global Variables, there were Functional Global Variables (FGV) a.k.a. VI Globals (VIG)".  In case your hair isn't sufficiently gray, these are simply VIs with a While Loop with True wired to the Stop Indicator, a Case Structure with a Get/Set Boolean input, a "Data" Input and Output, and a Shift Register holding the latest "Set" value.  Another way to think of it is an Action Engine with only two Actions, Get and Set, or a "simple Memory function".  What I like about it is (a) it has Error In/Error Out, so it obeys Data Flow, (b) it is more compact than most Globals, (c) I can design its Icon to make it "more recognizable", and (d) as long as I am judicious about how/where/why I call the Set function, I should be able to avoid Race conditions.  I'm sure there are other plusses and minuses that I'm overlooking ...

Bob Schor

---

Oh thanks for pointing out.. I love FGVs !! ( Sure I am going to be hit on the head shortly for this love ) But frankly I have been using them as my only means to pass data between different VIs and to date there has been  no issues. Want a new one ?No problem - just create another instance of it changing the name and maybe the icon. So good !! See the attached sample ....

[Bob_Schor]

---

@MogaRaghu wrote:

---

See the attached sample ....

---

You do realize, don't you, that we can only see the Front Panel, as it is Password-Protect ...  Why bother attaching an example we cannot examine?

Bob Schor