Consult the Modify the Simple State Machine LabVIEW Template tutorial for how to get started with.
Determining Your Needs
Before you customize the template, ask yourself the following questions:
- What states does the application consist of?The answer to this question determines the states you add.
- For each state, what should the next state be?The answer to this question determines the value of theNext Stateenum that each state sends to the shift register on the While Loop.
A single state can conditionally transfer to multiple states. An example is the Wait for Event state in the template, which transitions to a state based on user input.
- What kind of data will each state need access to?The answer to this question determines what data types you add to Data.ctl.
- What are some errors that could occur, and how should the application respond to these errors?The answers to these questions determine the amount of error handling you need.
Transition Code Examples
There are different methods to determine which state to transition to next, discussed below.
Note that while the examples images show the “Init” state, these transition possibilities could apply to any state.
One-to-one: If you always transition from State A to State B, there is no need to program any logic, just output the name of the next case (Case B) of to the shift register.
Figure 3a: Only One Possible Transition State
One-to-two: If you could transition from State A to State B or State C, you can use a Select function to assess the status of an indicator. You should assess something that determines which State you want to move to. For example, in Figure 3b we see that the user input of the Stop Button determines whether we move from the Power Up state or proceed to Shut Down.
Figure 3b: Two Possible Transition States
One-to-multiple using Arrays: If you have multiple states that you could transition to, you could use a Boolean area associated with an enum constant to program the transition. For example, in Figure 3c, some code is conducted where the outcome of the code determines the transition, the output of which is an array of Booleans. The Boolean array correlates with an Enum constant which contains a list of possible states that could be transitioned to. Using the Index Array function, the index of the first “True” Boolean in the Boolean array is output. Then, using the Array Subset function, you can pull out the appropriate from the Enum constant it correlates with.
Figure 3c
Tip: Recall that arrays are 0-indexed and Enums are 1-indexed. To correlate the Boolean Array with the Enum constant, use the Increment function to correct that offset.
One-to-multiple using While Loop: Another option if you have multiple possible transition states is to use a while loop inside of a case. The code inside of the while loop will continue until a Boolean status is set to true, triggering the stop button. This will effectively allow code to run until a triggering event occurs.
Figure 3d demonstrates an “Init” state using an inner loop and case structure to transition to the next state. The inner case structure contains one diagram for each transition that leaves the current state. Each of the cases in the inner case structure has two outputs – a Boolean value, which specifies whether or not the transition should be taken, and an enumerated constant, which specifies the state to which the transition goes. By using the loop index as an input to the case structure, this code effectively runs through each transition case one by one, until it finds a diagram with a “True” Boolean output. After the “True” Boolean output is found, the case outputs the new state to which the transition goes. Though this method may appear slightly more complicated than the previous methods, it does offer the ability to add names to transitions by “casting” the output of the loop index to an enumerated type. This benefit allows you to add “automatic documentation” to your transition code.
Figure 3d
Other Programming Considerations
Code Redundancy
Problem: The hardest part of creating a State Machine is to differentiate between possible states in the state diagram. For example, in the co*ke Machine state diagram (Fig.4), we could have had 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50 cent states rather than having a “wait for response” state that goes from one state to another depending on which type of coin is dropped. That would create 11 different states with the exact same case diagram. Redundant code can create a big problem in a larger application.
Solution: If different states have the same case diagram, try to combine them into one state. For example, the “wait for response” state is created to avoid code redundancy.
Enum use
Problem: Enums are widely used as case selectors in State Machines. If the user attempts to add or delete a state from this enum, the remaining connected wires to the copies of this enum will break. This is one of the most common obstacles when implementing State Machines with enums.
Solution: Two possible solutions to this problem are:
1. If all the enums are copied from the changed enum, the breaks will disappear.
2. Create a new control with the enum, and select “typedef” from the submenu. By selecting typedef, all of the enum copies will be automatically updated if user adds or removes a state.
