Multiple same states in a state machine

[jyang72211]

 Hi all,

This is a follow up on a post at the wrong location.  I have attached one state in my state machine.  That state appears maybe 3 more times in the state machine, so maybe I should make it into a subvi instead, but I was thinking since there are not too many low level nodes and leaving the code in that state out of a subvi seems to be more clear, I thought maybe leaving the code out is better.  Not sure which way to go, please feel free to give me suggestion.

Yik

[Davidek]

Hi Yik

If I understand you correctly you have the same state duplicated four times in the same state machine? Is there some special circumstance to why you've done it this way? The whole point of the state machine is to allow you to set the execution order at runtime depending on what is happening in the code. So you shouldn't need to have a state 4 times in the code, just call the same state multiple times when appropriate.

I also noticed that your next state output tunnel uses a default value in on or more states (the output tunnel in the image is half-filled). This could be because you are still building your code, but it is really recommended that you specify a next state for every state.

Hope this helps! Best Regards

David

NISW

[jyang72211]

Hi David,

Some of the states are exactly the same, but I separate them out, becasue I want to show the sequence of test flow more clear on the state machine.  Not sure is that appropriate or not.

For some states, they are not exactly the same, but there are some minor differences in the states.

Yik

[Mark_Yedinak]

If the state is the exactly the same I would not recommend copying it. If you need to make a change to the code you now have multiple places to make the update. Also, rather than making it clearer what is happening I think it leads to more confusion since someone looking at the code will spend time trying to figure out why there are multiple instances of the same state. If you want to document the flow (actually the state transitions) then simply document them and keep that document up to date. That documentation would most likely be easier to read and see what the system is doing then reverse engineering the code.

[RGreg]

I think David and Mark are right: just call the same state multiple times.  If there are minor differences between the states, then I'd explore storing those minor differences.  Maybe you could encode the differences as a cluster that is passed through the state machine in a shift register?  

Or maybe store the differences in a subVI that returns slightly different results depending on what command you pass into it.  Of course, that command choice would need to be chosen in a previous state, which gets back to using a shift register...