Transitioning a legacy program from Stacked Sequence Structure - alternatives?

[crossrulz]

Just to clarify Ben's reply:

---

VPI001 wrote:

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?"

---

Yes.

Every frame to its own state might be a little overkill.  You can combine similar tasks together.  But do keep error handling in mind.  You will want to catch errors as soon as quickly as possible.  So any "long" tasks should be on their own.

[RTSLVU]

---

@VPI001 wrote:

A state machine would be overkill because there's never a need to decide which state to advance to.

---

A state machine is NEVER overkill, in fact I use a state machine architecture in %99.999999 of my LabVIEW programs.

Even if you are right and none of the states will ever select a different next state than the state that follows, it is still easier read and debug the state machine.

Here's an example of a Queued State Machine that never changes the order of execution.

[Ben]

---

@VPI001 wrote:

Thanks for the informative reply. 

...

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

---

Go ahead and post the code for us to agonize over. The worst that can happen is people will tell you the predecessor do not serve you well. We may be able suggest something that will at least get you started.

Ben

[VPI001]

I can share the code in a bit if need be, but I worry that poring over its inadequacies won't be a good use of anyone's time. I think I am very close to working through this problem myself.

My goal is a program which responds as quickly as possible to setpoints being exceeded or buttons being pressed. Here is what I am thinking I can do:

I should use a state machine to handle the continuous cycle of [read values] > [check  setpoints] and back again. If a check fails, the program can branch to [do something] > [write values] and then back to [read values] > [check setpoints] and so on...

However I must also need an event structure that catches whenever the user presses a button. I think this is a matter of having the event structure within the state machine, at the end of the [check setpoints] state, so that it is executed once each time that state is executed. That way a button press can cause the state machine to branch to [do something else] > [write values] ...

I may not understand event structures well enough - will this work, or is putting the event structure inside the state machine a bad idea? My concern is that if multiple events happen at once, it won't handle them all before moving on to [write values] and a value might be written that wasn't validated.

[Mark_Yedinak]

---

@VPI001 wrote:

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?

---

A state machine and a stacked sequence structure are not functionally the same. Think of a SSS as a tunnel, once you enter you MUST traverse the entire tunnel before you can exit. If your car catches fire in the middle of the tunnel there is nowhere for you to go. You still have to go through the entire tunnel. An even better analogy is that your are a train going through the tunnel. You can't leave the tracks.

A state machine is more like a car driving down a highway. You always have options to vary your course. You can get off at any exit along your route. You can turn around and go back to repeat things. The important part is you ALWAyS have the option to alter the flow unlike the train which can never leave the tracks.

While your particular case may not require you to change your flow (at this point in time) you will always have the option. State machines also make it easier in the future to make changes to your code.

Now, as you admit you are not a LabVIEW expert. Given that, pay close attention to all of the experts posting here which are recommending that you use a state machine.

[Mark_Yedinak]

I personally would recommend that you have the event structure running in a separate parallel loop to your state machine. That way it can catch the user interaction immediately and provide feedback to the user that there request/action was received and is being processed. You can update the pertinent data via local variables which the state machine can read at the appropriate time. There are other ways to pass data between the loops as well.

You can have an event structure within your state machine but you do need to be mindful of it not blocking your execution. You will need to have a timeout case so that you will not wait indefinitely for an event. As suggested, take a look at the JKI state machine. It is a good place to start from.

[VPI001]

Thanks,

I wasn't aware parallel While loops were an option - That does seem like the best solution. 

[RTSLVU]

One more example: Don't be afraid to do something like this.

Notice the iteration counter drives the state machine, so all the states are executed in sequence. It's the same but better than a stacked sequence.

[RavensFan]

Be careful about those tunnels.  They are all marked to Use Default if Unwired.  If you forget to wire one across in one of your cases, you'll lose the data in the shift register.

[RTSLVU]

---

@RavensFan wrote:

Be careful about those tunnels.  They are all marked to Use Default if Unwired.  If you forget to wire one across in one of your cases, you'll lose the data in the shift register.

---

Good point, but I have already thought of that and made sure the shift registers were wired as needed. I admit I got lazy on this one. There are only four cases and used the "Used Default if Unwired" just so I would not have to wire across all the cases.