Convert sequence to state machine option

[falkpl]

Anyone that refactors code from another programmer has probably received some code that has too many sequence structures.  Often I convert these to a simple state machine.  With scripting this could be easily converted to a state machine for loop.  A default enum type def could be created to do a state machine sequence 1 -> 2 -> 3 -> 4 ->5 -> ...last sequence in structure.  All sequence locals could be replaced with either a local or a shift register (that will bypass all other cases where it is not used). 

Why would I want this?

Sequences are over used and it is well documented that state machine architecture can provide many benefits over the static and simple sequence.  Many programmers are un aware of these benefits and don't understand data flow so use sequences  to force execution order.  Sometimes sequences are convenient early in the prototyping only to find the known shortfalls of this programming paradigm.  When this happend dont worry, just right click on the sequence structure and click convert to state machine.  This could make refactoring code easier, at least in my mind (but is late on friday and I am ready for the weekend which could cloud my thought process).

[Jim_Kring]

I like it!  This sounds like a job for LabVIEW Scripting and would make a great plugin for the JKI Right-Click Framework 🙂

[falkpl]

My attempts on scripting were not that great.  In theory it is not all that difficult, each sequence translates 1:1 to a sequential state machine, the next state is just the sequence index (i would auto create a typdef enum with the index values to make it a standard state machine).  All sequence locals would be replaced with a shift register (this is a little trickey because all other states would require a wire through connector). I dont see any major technical difficulties but would prefer it be added instead of writing my own script.  Is scripting supported yet, I have recieved mixed answers on this topic.

[onrb]

I've been using a state machine (SM) to simplify design of my system. I've tried using the string based and queue based structures and reverted to a simple case structure using enum control. After doing this I found there is some benefit to a queue based structure in that some states can then be reused in multiple state sequences. However, predictability of the queue based state-machine was reduced. Given this I now think it would be best to have two state machines available, a simple non-queue SM and a queue based SM. I have not worked enough with a queue based SM to provide guidance on a final structure to be incorporated into the NI structure menu. However, I think the non-queue based SM is simple enough it is clear on how to define the requirements for the structure:

1. SM is available in standard NI menu for structures. Frame of structure is similar to while structure, maybe with case structure cross hatched pattern (key is that frame is same width as while structure).

2. Fundemental function of structure is a case structure surrounded by a while loop.

3. State control is through an enum type.

    Reserved enum values: 0 - NoRequest, 1 - Stop,  2 - Error, 3 - Initialize (user adds beyond 3)

    State controls are reserved (Probably another object on the menu)

    State control consists of an enum "State" and an enum "StateRequest" (May be valuable to add "PreviousState" as well)

[onrb]

I've been using a state machine (SM) to simplify design of my system. I've tried using the string based (JKI) and queue based structures and reverted to a simple case structure using enum control. After doing this I found there is some benefit to a queue based structure in that some states can then be reused in multiple state sequences.

However, predictability of the queue based state-machine was reduced. Given this, I now think it would be best to have two state machines available, a simple non-queue SM and a queue based SM. I have not worked enough with a queue based SM to provide guidance on a final structure to be incorporated into the NI structure menu.

However, I think the non-queue based SM is simple enough it is clear on how to define the requirements for the structure:

1. SM is available in standard NI menu for structures. Frame of structure is similar to while structure, maybe with case structure cross hatched pattern (key is that frame is same width as while structure).

2. Fundemental function of structure is a case structure surrounded by a while loop.

3. State control is through an enum type.

    Reserved enum values: 0 - NoRequest, 1 - Stop,  2 - Error, 3 - Initialize (user adds beyond 3)

         NoRequest, and Stop states are not visible to the user in the state machine. (Handled internally)

    State controls are reserved (Probably another object on the menu)

    State control consists of an enum "State" and an enum "StateRequest" (May be valuable to add "PreviousState" as well). Looking forwards, maybe an argument could be passed

4. The SM has the following inputs: Variable cluster, state control reference, and error input. The SM has the following outputs: Variable cluster, and error output.

5. The error input and output are shift register indexed and automatically wired through on creation of a state (Wire can be deleted by user and rewired).

    The error shift register is optional. Probably right-click on the boarder and select "State machine Error shift register". Appearence will need to be slightly different than the standard green error cluster since it would be linked to the SM operation.

6. The cluster input and output variables are accesable through a slider on the left and right sides (similar to the event structure). In addition to the cluster variables being selectable, also the "State", "StateRequest", "PreviousState", and "Argument" could be selectable on the left side.

7. The next state would be selectable in a box embedded in the (lower center or lower right of the frame). This would be similar to selecting the case in a case structure as in the top of the frame which selects the current state.

      To allow for logic to define the next state, "NextState" would be selectable on the right side slider(similar to left side slider for variables).

8. Upon an error event after execution of a state, the state is forced to state "Error".

9. "StateRequest" is defaulted to "NoRequest". If "StateRequest" does not equal "NoRequest" then the next state executed will be "StateRequest" unless there is an error. Error has precidence.

10. "StateRequest" and "Argument"(optional) can be set with an icon outside of the state machine.

11. Both Case structures and sequences should be convertable to the state machine structure. (and the reverse)

The advantage of introducing this structure is significant simplification and cleanup of the VI.

    - No passthrough of a variable cluster (area savings)

    - Simplified access to variables in the cluster (no unbundling and bundleing).

    - No state machine controller to handle external Exiting, state requests and error events.

After users have their hand at such a structure and provide feedback, it would be obvious what minor modifications would be required to extend the state machine to a queued state machine (the focus would be on queuing control).

I'm happy to be a beta tester if someone at NI would like to initiate coding up a state machine.

If useful, I could edit up an image of the structure and also attach an example SM with while/case structure. Let me know if there is interest from NI developers.

The key is KISS.

[onrb]

Here is a concept example

[onrb]

Here is a concept example of the SM implementation in the UI. As can be seen the extention from a simple SM to a queued SM is likely a selection of the "SM" box feeding the structure.