Add states to an existing state machine (SM) or create a SM within an SM?

[TolkienWASP]

I'm familiar with a variety of standard SM labview implementaitons. Currently I'm developing an event driven SM. One of the state executions involves a flat sequence. Unfortunately the operations are sensitive, and if an error is encountered anywhere within this sequence, I need the ability to abort the program from that point in the sequence. To do this it seems best to turn this flat sequence into a SM.

My position now is such that I am unsure whether to add these new states to the original SM, or create a new SM within the original SM. The latter seems to make the most logical sense, as these substates don't seem to justify the distinction of states from the perspective of the original SM, however I'm not sure if this is a necessary approach. 

I'd apprecaite any advice, thansk!

[altenbach]

I would use the former instead of the latter.

[BowenM · Accepted solution]

What altenbach said.  

To expand a little bit, the “inside” state machine is going to need the ability to pass its state between loop iterations. This is going to be another shift register that is only used in one state. The "inside" state machine will also need the ability to send new states to the "outside" machine (otherwise the "outside" state machine would never exit the current state).  

With this in mind, it makes sense to just add the extra states to your main state machine. It saves you a shift register and needless complexity.

Edit:  It's late. I made my ramblings (slightly) more coherent

[mikeporter]

You never want to have an embedded state machine. So you are left with two.options:

1. Incorporate the new states into the existing machine.
2. Create the new functionality as a new process that runs in parallel with the existing software.

Option 1 sounds more promising at this point.

Mike...

[Bob_Schor]

---

@mikeporter wrote:
You never want to have an embedded state machine. So you are left with two.options:

---

Can you explain why you said this?

I'm a great believer in "encapsulation" (or "lots of sub-VIs").  I can visualize a State Machine that looks like the following:

• Initialize
• Do Task 1, return Value 1
• Do Task 2, return Value 2
• Based on Value 1 and Value 2, go back to Do Task 1 or do Clean Exit
• Cleanly Exit

I would tend to write Task 1 and Task 2 as sub-VIs to emphasize that they are isolated individual tasks that (from the standpoint of this State Machine) are isolated except for their Return Value.  If I now think about what Task 1 and Task 2 entail, why can't I envision them as State Machines, operating within their own "realm of influence"?  And wouldn't this qualify as an "embedded State Machine"?

I do agree that you need to carefully consider the concept of a "State", and how State Transitions work.  But I see no reason, a priori, that within a State (here considered as a body of code that runs to its conclusion using the usual Principles of Data Flow) one couldn't use any "encapsulated" design that fits the job.

Bob (Always Happy to Learn) Schor

[mikeporter]

I define an embedded state machine as one state machine that is built inside one state of another state machine.

Your example is actually a good one. Yes, you should write the tasks as subVIs and those subVIs should have whatever structure is right for them. But that is not what the OP was talking about.

Mike...