Switching between dual state machines. BEST PRACTICE?

[Gearmiester]

OK so the question is simple but the application needs description.

Q- Inside an application I want to run two state machines but do not want to call them asynchronously. i don't want them to be pop up windows and have to close one subvi before opening another subvi. i want to be able to switch between state machine functionality seamlessly from the main user interface. Can this be done? 

I have both state machines as subvi, but I am dissecting them to usable code in the main program. What I am trying to accomplish is a cleaner interaction with two automated sequences in a specific mode of operation. The HMI is where the main program runs and talks to a cRIO via TCIP/IP Messaging. Buliding this system in LabVIEW 2017.

Here is a screen shot of one state machine set up in the main program. The control to switch state machines is disabled in all modes except the mode it needs to run in. And it defaults (radio button) to the primary state machine but is inactive until the enable button is pressed. I believe that I can work out how to pass latest values from one state machine to the other, this is more a question about will this work in the way i believe it will.

[altenbach]

A state machine is typically implemented in the toplevel, but you seems to be talking about subVIs.

I see serious architectural problems even in the code you are showing, with interactive loops inside events structures, for example. This just does not look right, but it would help to see more than just the surface.

[Gearmiester]

Thanks for the reply altenbach. It is OK that you are concerned about the code shown in the screenshot. That was the purpose of this question. the rest of the code does not have this kind of interaction inside the event loop (it's all fire and forget user input to do something out the cRIO, or asynchronous calls to modal subVI's) I was hoping that something like what was shown would be possible without having to call subVI's for the different state machines. Also while the two state machines do operate the same output and physical machine, they cannot be incorporated into one state machine smoothly or i would just do that and asyncro call the one state machine as a subVI user interface over the main program. unfortunately I can't get you into seeing the program on public forums or without an NDA. Do you have any other suggestions to accomplish what I am trying to without having to call multiple subVI's and slowing down the transition process?

[kevanA]

The idea of having two state machines controlling one thing defeats the obvious purpose of a state machine. Can you explain in english why these need to be separate. Without knowing more, I would suggest that you combine them both into one state machine. The key might be in the transitions: what are valid states while you have value X of the selector and what are valid states while Y is selected? The power of the state machine is that some of the states may be valid for both selections. Why limit yourself? The ideal mapping should be one state machine to one set of physical stuff. Think about how you decide on your state transitions. One machine also eliminates the problem of passing data, its all there and can be used or not as needed.

Kevan

[Gearmiester · Accepted solution]

Just a quick post to kill this thread. This was a best practice question about programming something I was attempting to do differently than normal. I was not sure if the application was going to be something feasible or not, so i took a screen and asked a question. The question was answered and verified my problematic thinking with the design and pointed me in the direction that i was figuring I would have to go anyway; combining the two state machines into one and still doing an asynchronous call. Back to the drawing board as it were. Thanks for the replies and input.