Efficient PLC programming using finite state machine concept

A common types of automation systems are those that execute control actions in a sequence, and the programmer task is to make code that will execute those sequences in a correct order considering appropriate conditions. Sometimes the controlled system doesn't have too many states (steps) and any technique used to solve the automation task will work, but for some more complex sequences, combinational logic is not the most efficient approach. Programming sequences that contain many states with combinational logic methods will inevitably produce code that has poor readability, and also has many bugs. To debug such code simple monitoring of the logic while it is executed often will not be enough because logic errors last only for a short period (race conditions) which makes them hard to catch by monitoring. Thus some sort of tracing (graphic representation) of variables is required to locate the problem, this all together is time-consuming. Another frequent problem that arises with combinational logic solutions is that change in the order of fulfillment of external conditions causes unexpected behavior of the control system. Also very often errors in combinational logic are caused by some condition that is not important for the current state of the controlled system, but there was a mistake in the code which is supposed to ignore that condition in that particular state. So in combinational logic, it is necessary to write code for what system should do, and also to write code for what system should not do. All this opens more space for mistakes, and also requires more time for programming and debugging.

A more efficient way to code sequential control logic is to use a finite state machine (FSM) concept. Although it is not one size fits all solution, this concept in many cases can be a very good method for solving programming challenges in the field of industrial automation. This concept is already supported in PLC programming environments in the form of SFC (sequential function chart) programming languages, but with structured text comes more flexibility and wider platform support.

The definition from Wikipedia says that a finite state machine is an abstract machine that can be in exactly one of a finite number of states at any given time. The finite state machine can change from one state to another based on some conditions, that change is called transition, and those conditions are called transition conditions. There are also other resources about FSM theory, but a concrete example might be a better way to understanding how this concept can be used in PLC programming.

The backbone for implementing the FSM concept in ST (structured text) language is a CASE statement which allows coding finite state machine in an easy and readable way. The CASE statement variable is used as a state pointer that determines the state in which the finite state machine is. Every FSM state must contain at least a code for FSM transition, and optionally code used to execute actions specific to that state.

Here is an example of a finite state machine implemented in structured text:

This is an example of a typical finite state machine that can be applied in industrial automation, it is possible to start, pause, or abort FSM execution.

When the example code is first executed #State variable has value 0, and thus finite state machine is in state 0. In this state there is only the code that checks if #Start variable is set to true, meaning that there is no code for executing any other actions in this state besides transition. When #Start variable becomes true (ie. set by a user) then #State variable is assigned value 10, meaning that FSM transitions to state 10.

Code that belongs to state 10 will be executed one PLC cycle after the value of 10 is assigned to state pointer variable #State. In this state, #Actuator1 is set to true if start command is still present (#Start is true) and if #Condition1 is false. When #Condition1 becomes true then #Actuator1 is reset and FSM transitions to state 20 because value 20 gets assigned to the #State variable. In case that start command becomes inactive before #Condition1 becomes true then #Actuator1 will be reset to false, and FSM will stay in state 10, this can be considered as a pause for sequence. Of course this applies only if #Condition1 can't get satisfied if #Actuator1 is reset. The system will get in pause if #Start variable is reset due to #Error or if a user resets variable (ie. from HMI). If #Abort variable becomes true #Actuator1 will be reset and FSM will transition back to state 0, waiting for the next start.

In a state 20 #Actuator2 is set if start command is still present and if #Condition2 is not true. Variable #Condition2 is redundant because if FSM transitions to state 20 while #Condition2 is true then #Actuator2 would be set but immediately after it would be reset prior to FSM transition since #Condition2 also fulfills transition condition. But the purpose here is to give an idea that in one state actuators can be controlled based on multiple conditions. From this state, FSM can transition to state 10 if #Condition2 is true or to state 0 if #Abort is set to true.

State pointer variable #State determines a block of code that is executed. Only block of the code that belongs to the state identified by the current value of the #State variable is executed, all other code inside the CASE statement is ignored. In this way control logic is separated without additional effort, meaning there is no need for additional code to ignore conditions that are not important for the current state of the controlled system.

Finite state machine from the example has 3 different states that are identified by values: 0, 10, 20. State 0 is mandatory because when the program is run for the first time value of state pointer variable #State will be zero. In order to execute any code inside the CASE statement, there must be a corresponding code for every possible value of the state pointer variable. Because the value of zero is not in control of the programmer state 0 should always be defined. It is also possible to define initial value for the #State variable and thus avoid state 0 but this opens space for mistakes and it is bad practice. It is common practice to unconditionally transition FSM from state 0 and implement control logic code in other states. Other state identifiers are arbitrary, but good practice is to have them incremented towards the end of the CASE statement for better readability and easier navigation during debugging. It is a good idea to have increments step larger than 1 for example 0, 10, 20, 30, and so on in case that something has to be added afterward. In case that #State variable is assigned value that doesn't have corresponding code inside the CASE statement then FSM will get stuck until the state pointer variable is assigned appropriate value manually by the programmer. If this happens, there will be no PLC cycle timeout because the CASE statement is not a loop. Also if there are multiple states with the same state identifier inside the CASE statement only the code that belongs to the uppermost state will be executed.

During debugging if there is some problem first thing to start with is to figure out the current value of the state pointer variable and thus FSM state. From that, it is easy to track down where is the problem and correct it. Even if a problem appears in some previous state it is easy to follow FSM transitions backward and figure out the origin of a problem.

Tips and tricks to improve FSM code:

• Don't assign value to the state pointer variable outside of the CASE statement, this will cause unpredictable behavior and make debugging difficult. A good way to impact FSM execution is by using variables like #Start or #Abort as it is done in the example above.
• Double-check variables that are assigned a value in one state, and left to be reassigned in some of the following states, particularly if there are states that are not always executed in the same order.
• Implement actuator handling logic (actuator driver) outside of the CASE statement, or even better in separate program organization unit. This will make FSM logic reusable and independent from the actuator type.
• After a power cycle to the PLC finite state machine will continue execution from the state in which it was prior to the power cycle if the state pointer variable is retained.
• FSM concept is a very good way to go when writing drivers, and communication protocols. Since systems that drivers are made for usually require some initialization procedure (ie. assignment of parameters for communication port) after PLC power cycle some sort of reinitialization of state pointer variable should be implemented.
• If there are calculations or actions that need to be executed only once before or after some more complex control action, they should be placed in a separate state.
• For the sake of clarity, the last code in every state should be code that handles FSM transition, and code that is to execute control actions for that state should be put before as it is the case in the example.
• State pointer variable value can be used to indicate the current state of the controlled system on the HMI device and it is the starting point for the debugging process.

If you like this article feel free to share it with who it might be interesting or useful. If you have some suggestions, further questions, or feedback feel free to leave them in comments or in the inbox.