Understanding state-full programming methods

A straightforward approach that enforces discipline with preparation, planning, and documenting.


When considering the solution to a programming task, there is generally no shortage of approaches. These typically range from the mundane to the extremely complicated. There is one approach to consider when solving a problem and that is through the use of a state machine.

The basis of a state machine is in fundamental theory of computation. The specific construct is a deterministic finite acceptor. We won't get into the arcane mathematics, but a basic understanding is in order. The basic elements are:

1. An understanding of the starting point or condition
2. What all of the intermediary steps / states are
3. What the conditions are to transition to the next step / state, and
4. What constitutes the end point(s).

What should be apparent from this is that the problem has to be considered fully and outlined before any work can be done. This is one of the key points of this type of programming in that it enforces preparation, planning, and documenting. The development process is as simple as following the four elements outlined above.

There are some key elements to keep in mind:

In a state machine there can be any number of states; as many as required to complete the task. This characteristic alone necessitates the use of integer-based states; the best analog is a recipe, such as baking a cake.

The machine can only be in one state at a time. As in following a recipe, you typically perform one step after another. You never hear of baking the cake at the same time as adding the ingredients.

Each state can transition to any other state, providing the transition is clearly defined. This is the real power of the construct: loops and jumps can be performed as well as single steps. As in baking a cake, add one egg, mix well, add a second egg, mix well, and add a third egg, mix for 60 seconds. Some steps are repeatable until a different transition is encountered.

Once the endpoint has been reached, the only viable next state is to start over at the beginning.

While automation programming is not quite the same thing as baking a cake, the basic concepts apply. Consider the control of a set of pumps used to pump down a sump:


1. At Low Level, turn on Pump #1
2. At Mid Level and Pump #1 On, turn On Pump #2
3. At Hi Level and Pump #2 On, Turn On Pump #3
4. At Mid level and Pump #3 On, Turn Off Pump #3
5. At Low Level and Pump #2 On, Turn Off Pump #2
6. At Low-Low Level and Pump #1 On, Turn Off Pump #1


The solution of this problem starts out with clearly defining the states and what are the conditions that will cause them to change. The basic states for the sump example are contained in Table 1.

The solution of this problem starts out with clearly defining the states and what are the conditions that will cause them to change. The basic states for the sump example are contained in Table 1.

Once the states have been defined, the next step is to work out the criteria that cause the states to change. The transition criteria are contained in Table 2.

Once the states have been defined, the next step is to work out the criteria that cause the states to change. The transition criteria are contained in Table 2.

It should be clear that each state has specific criteria, or inputs, that cause the machine to change or advance. In fact, using the initial criteria, we don’t even have to concern ourselves with whether or not the pumps are running – at this point we don’t really care; that is taken for granted by the state machine.

At this point we are almost ready to begin programming the state machine. However, before we do that we have to plan for some registers and flags that we’ll need. Some of these are required because of the way that a typical automation controller runs its program, from the top down.

The first register is CURRENT_STATE. This is exactly what it says, where the machine is currently. The next register is NEXT_STATE. This is the state that we want to transition to. Finally, there is a flag called NEW_STATE, this is a bit used to signal that we have moved into a new state. This is not strictly required for our example, but it is extremely helpful with larger machines.

The following is a ladder logic representation of the above example. I’ve over-simplified some things, such as the levels and there isn’t any code to check for valid numbers, but that’s not required for the example.

The following is a ladder logic representation of the above example.

The following is a ladder logic representation of the above example. This example covers all of the basics: initial state, intermediate states, and transitions. I’m sure that you may have noticed that there isn’t an end state. For this specific example it wasn’t required. That is one of the advantages of a state machine; you don’t necessarily have to have an end.

While this example covers a very basic system, nothing inherent in the construct limits it to this use. The example is also limited in that it doesn’t illustrate the actual connection between the states and the field devices it controls but that should be easily addressed. This concept can, and has, been expanded all the way to recipe handling with hundreds of states. The only limitation that it has is the imagination of the programmer.

This post was written by Jeff Monforton. Jeff is a senior engineer at MAVERICK Technologies, a leading system integrator providing industrial automation, strategic manufacturing, and enterprise integration services in the manufacturing and process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, and business process optimization. The company provides a full range of automation and controls services – ranging from manufacturing plant energy efficiency to data historians and continuous improvement solutions. Additionally MAVERICK offers industrial and technical staffing services, placing on-site automation, instrumentation and controls engineers.

DAVID , KY, UNITED STATES, 07/02/13 10:44 AM:

I have used State machines successfully since the seventies. My PLC programming standard is called bit-shifting, where each bit in a matrix represents a state of the machine or process. This method utilizes all off the advantages you noted in your article but is much less verbose since it uses bits that can be directly accessed with a NO or NC contact.
Feel free to contact me if you would like to discuss more.
DENNIS , AZ, United States, 07/10/13 04:03 PM:

IEC 61131-3 Sequential function chart(SFC) is designed from the ground up to think in terms of states. I still find it amazing that USA integrators still prefer to do everything in ladder logic, when there are clearly better standardized choices.
DAVID , OR, UNITED STATES, 07/10/13 04:04 PM:

Bit shifting is great, but much more difficult for a rookie maintenance electrician to follow. I try to write code for the lowest skill level person who will have to work with it later.
Anonymous , 07/10/13 11:41 PM:

Siempre en las aplicaciones que desarrollo aplico conceptos de estados, y funcionan adecuadamente, como SFC, y contador de eventos
Tom , , 08/03/13 12:51 AM:

No electrician should be allowed anywhere near a PLC and the code should be as condensed and opaque as possible.
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Intelligent, efficient PLC programming: Cost-saving programming languages are available now; Automation system upgrades; Help from the cloud; Improving flow control; System integration tips
Smarter machines require smarter systems; Fixing PID, part 3; Process safety; Hardware and software integration; Legalities: Integrated lean project delivery
Choosing controllers: PLCs, PACs, IPCs, DCS? What's best for your application?; Wireless trends; Design, integration; Manufacturing Day; Product Exclusive
PLCs, robots, and the quest for a single controller; how OEE is key to automation solutions.
This article collection contains several articles on improving the use of PID.
Learn how Industry 4.0 adds supply chain efficiency, optimizes pricing, improves quality, and more.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Special report: U.S. natural gas; LNG transport technologies evolve to meet market demand; Understanding new methane regulations; Predictive maintenance for gas pipeline compressors
Cyber security cost-efficient for industrial control systems; Extracting full value from operational data; Managing cyber security risks
Drilling for Big Data: Managing the flow of information; Big data drilldown series: Challenge and opportunity; OT to IT: Creating a circle of improvement; Industry loses best workers, again