Transitioning a legacy program from Stacked Sequence Structure - alternatives?

[VPI001]

I am maintaining a legacy instrument control program (in LV 2011, but it was written long before that) which is essentially several nested stacked sequence structures. Each execution loop, the program reads data from external sources as well as several Boolean controls, performs a large number of checks, and finally updates the status of a bunch of external relays. 

For this application it's very important that these tasks always be executed, and always in this specific order, so despite the general disdain for stacked/flat sequence structures around here I think this is their intended use case. If I were to simply put all the code left-to-right, not in any structure, the program would be one screen high and 100 screens wide.

However, this architecture makes it very difficult to constantly monitor for events such as the pressing of a button. I'd like to be able to do/check certain things programatically more than once per program loop. I'm not very well-versed in LabView, what alternatives to a stacked sequence should I be looking at? A state machine would be overkill because there's never a need to decide which state to advance to.

[crossrulz]

Button presses in generally should be monitored with the Event Structure.  Hard to say any more other than you might have been coded into a corner.

As far as getting rid of the SSS, I would go to a state machine.  Options that come to mind are using queue to hold your sequence of states or use the JKI State Machine.  I prefer going this route since it enables being able to reuse steps instead of duplicating code.  You just load all of your steps into the queue at the beginning of the sequence and let the Dequeue pull the states off the FIFO.  This also allows for much better error handling.

[RavensFan]

A state machine is not overkill.  Just because you don't need to decide on the next state, doesn't mean you can't use it.  The state diagram would just look like a straight line.

What do you want to do more than once per program loop?  How does it fit within whatever else is going on in a specific frame of the stacked sequence now?  With a state machine, you can always have the state go back to the current state to check on an input or control again, then use some code to decide when it should advance on to the next state.

[aputman]

I would venture to say that a state machine is almost never overkill.  You may not need to decide at runtime which step is next but you can define the static execution order at design time.  Throw in an IDLE state to check the event structure for UI events, break up your routine into meaningful portions, use shift registers to pass the data to the next state and you have a working architecture that fits on one screen.  If the test routine is long running and you want to check for button presses during the routine, you need to occasionally call the IDLE state throughout the routine to allow the event structure to process events. 

You might want to check out the JKI State Machine.  It allows you to define a Macro, which is a series of states that are called consecutively and in the order that you define.  Very much worth your effort to learn how to use it. 

[Ben]

---

@VPI001 wrote:

I am maintaining a legacy instrument control program (in LV 2011, but it was written long before that) which is essentially several nested stacked sequence structures. Each execution loop, the program reads data from external sources as well as several Boolean controls, performs a large number of checks, and finally updates the status of a bunch of external relays. 

For this application it's very important that these tasks always be executed, and always in this specific order, so despite the general disdain for stacked/flat sequence structures around here I think this is their intended use case. If I were to simply put all the code left-to-right, not in any structure, the program would be one screen high and 100 screens wide.

However, this architecture makes it very difficult to constantly monitor for events such as the pressing of a button. I'd like to be able to do/check certain things programatically more than once per program loop. I'm not very well-versed in LabView, what alternatives to a stacked sequence should I be looking at? A state machine would be overkill because there's never a need to decide which state to advance to.

---

Those last two statements by you that I have highlighted are one reason a state machine is the pattern you are after in your quest. If it had been implemented as a state machine it would have been trivial to add checks and branches.

"the best time plant a tree is seven years ago. The second best time is today." (provided it is the growing season)

Similarly for converting the SSS to a state machine. Fix it now before it gets any worse!

Now how to proceed...

Do not fall into the temptation of converting every frame to state. Instead, review the code and break into down into ... say three states. They could be "set-up" , "Do something", "Close" or others as you choose. Create a SM that does those lmited number of states.

In each state determine what data structures are sued and touched in each state. Data that is only touched in one state can be handled locally to that state. Data touched in multiple states can be passed via a cluster, Action Engine etc. As you find the data structures ask yourself "Is this something the User  has to see?". I fthe answer is "no" then do not use FP controls, locals, etc for those data structures, put them the cluster you will be passing from stat to state.

Ben

[VPI001]

There are multiple events I'd want to catch as near instantaneously as possible, despite the program loop taking about half a second - for example, there are some booleans that should never be true so long as another boolean is false, or if one boolean is set to false, several other booleans should immediately set to false. 

Also, data is logged on an onscreen plot, and currently the plot can only record one data point per program loop - I would like to be able to record them much faster.

Currently there's just a single sequence in the stack that handles all of these in "if/then style" once per loop.

[VPI001]

I'm unclear on what specifically are the advantages of using a linear state machine rather than a sequence structure - they seem functionally identical to me. Is the difference to do with whether or not the entire thing is wrapped up in a While loop?

I'm envisioning essentially transferring the code in each state to it's own case - how would this improve my options?

[Ben]

Re: State Machine vs QSM (structure vs chaos)

Spoiler

The term "State Machine" is short for "Finite State Machine" see here.

QSM - Queued State Machine is a misnomer and is or closely resembles a "Pushdown Automaton" see here.

Comparing the diagram in the Wikipedia links I provided above it can be seen that the "Finite-State-Machine has a fixed number of transitions while the "Pushdown Automaton" does not ( can be queued at front end or back end)  and therefore does not have a finite set of possible transitions and as a result can not be documented in a closed form.

 It only takes one undisciplined developer changing a "QSM" to introduce chaos into the application.

Trouble shooting a QSM can be a nightmare since the order in which states are executed can change depending on timing and other factors. One only has to be responsible for X-shooting a bad QSM to learn why QSM can be a very bad dream.

A Queued Message Handler does not enqueue itself and is therefore safe.

Ben

[VPI001]

Thanks for the informative reply. 

Unfortunately just about every single variable tracked by the program needs to be on the front panel. Currently the program does some very minor initialization, then enters the stacked sequence which proceeds in 3 basic phases as outlined in my OP: 

1. External data is collected (and displayed on the FP).

2. Various values are checked against various setpoints. If a setpoint is exceeded, the appropriate booleans are changed. The order these checks are resolved is important and fixed (and each and every setpoint and boolean must be a control on the FP).

2.5. This "step" is my bad workaround frame where a bunch of conditional case structures check some booleans and do things if they have been changed - things like change *other* booleans or object properties.

3. Finally the booleans are all written to a set of external relays with some fieldpoint modules.

This big collection of external values, setpoints, and booleans is sitting on the front panel and I don't think any of them could be handled locally. The problems with this are of course that if the user hits a button,nothing can happen until step 2.5 is reached - and if I swap the boolean after step 2 then it's not checked until step 2 of the next loop!

With all that in mind, does a state machine solve these problems, and is there a better way to handle it than, as you say, "converting every frame to a state?"

Thanks again for your assistance as I'm not a LabVIEW expert nor can I justify the man-hours to truly become one.

[Ben]

Yes.

Ben