Sequential equipment that has to move through distinct phases, such as a unit that idles, purges, starts, runs, and shuts down, is a nightmare to control with a sprawl of ad-hoc interlock rungs that all fight over the same outputs. The disciplined answer is a state machine: a single variable that holds which phase the equipment is currently in, and a block of logic that says exactly what to do in each phase and when to move to the next. This pattern turns a tangle of conditional rungs into a clean, readable sequence that a person can follow and a tester can verify one state at a time.
State machine in PLC programming in one line: A state machine in PLC programming is a structured way to control a sequence using a single state variable, often an integer step number, and a block of logic with one branch per state, whether a rung per state in ladder or a case per state in structured text. Each state defines what the equipment does while it is active and the conditions that move it to the next state. It replaces scattered ad-hoc interlock rungs with an ordered, readable, testable sequence.
The core of the pattern is a single variable that answers the question of where the sequence is right now. It is usually an integer, sometimes called the step number or state number, and at any moment it holds exactly one value representing the current phase. Because the whole sequence is summed up in one number, an operator or engineer can tell at a glance what the machine is doing, and the logic never has to infer the phase from a combination of scattered flags. The state variable is the single source of truth for the sequence.
Around that variable is a block of logic organized by state. In structured text this is naturally a case statement that selects the code for the current state; in ladder it is a set of rungs each gated by an equals comparison on the state number, so only the rungs for the active state do anything. Whichever form it takes, the effect is the same: exactly one section of code is live at a time, and it is the section that belongs to the current phase. Everything the machine should do in that phase lives in that one place, which is what makes the sequence readable.
This is a deliberate contrast to the ad-hoc alternative, where dozens of independent rungs each carry their own set of conditions and all quietly influence the same outputs. In that style there is no single place that says what phase the machine is in, so behavior emerges from the interaction of many rungs and becomes very hard to reason about or change safely. The state-machine discipline gathers all of that scattered intent into one variable and one organized block, which is why it scales to complex sequences that ad-hoc logic cannot handle cleanly.
Each state has three things worth distinguishing. First, there are the actions performed while the state is active, the steady behavior of that phase, such as holding a purge valve open throughout a purge state. Second, there are entry actions, done once as the state is entered, such as starting a timer or opening a valve at the beginning of the phase. Third, there are exit actions, done once as the state is left. Separating one-time entry and exit actions from continuous in-state actions keeps the logic clean and avoids commands being needlessly re-issued every scan.
The other half of each state is its transitions: the conditions that decide when to leave and where to go next. A transition changes the state variable from the current value to a new one, and the rest of the logic follows automatically because a different branch becomes active on the next scan. A state may have several possible transitions, for example a normal path forward when the phase completes successfully and an abnormal path to a shutdown state if a fault appears. Each transition is guarded by a clearly written condition, so the reasons the sequence moves are explicit rather than implied.
What this structure buys you is testability. Because only one state is active at a time and its actions and transitions are gathered in one place, you can test the sequence state by state: force the machine into a given state, confirm it does the right thing, satisfy a transition condition, and confirm it moves to the correct next state. There is no hidden interaction to trip over, because the machine can only ever be in one state and the transitions out of it are enumerated. This is a large part of why safety and process reviewers strongly favor state machines for anything sequential.
A well or a compressor startup maps naturally onto a state machine. The states might be IDLE while the unit is at rest, PURGE while gas is cleared before ignition or start, START while the unit is brought up and its permissives are proven, RUN during normal steady operation, and SHUTDOWN while it is brought down in an orderly way. The state variable holds one of these at a time, and each state has its own actions and its own transitions: IDLE moves to PURGE on a start command with permissives met, PURGE moves to START when the purge timer or purge-complete condition is satisfied, and so on.
The abnormal paths are just as much a part of the design as the normal flow. From almost any state, a trip condition transitions the machine directly to SHUTDOWN, which then performs the safe-state actions and eventually returns to IDLE. Because the shutdown path is written as an explicit set of transitions rather than as scattered trip rungs bolted onto every phase, it is easy to confirm that every operating state has a defined and safe way out when something goes wrong. The sequence has a shape you can trace, including all the ways it can be interrupted.
This structure is a gift for SCADA and remote operations, because the single state variable is exactly the thing a remote operator most wants to see. A dashboard that displays the current state, IDLE, PURGE, START, RUN, or SHUTDOWN, tells a supervisor hundreds of miles away precisely what the unit is doing at a glance, without decoding a mess of individual flags. Logging the sequence of states over time gives a clean history of every startup and shutdown, and stalled sequences become obvious because the state simply is not advancing. The discipline that makes the logic readable to an engineer also makes it legible to a remote monitoring system.
Because sequential equipment controlled by scattered ad-hoc rungs quickly becomes impossible to reason about, since no single place tells you what phase the machine is in and many rungs quietly influence the same outputs. A state machine gathers all of that into one state variable and one organized block with a branch per phase, so only one section of logic is active at a time. That makes the sequence readable, changeable, and testable state by state.
Entry actions run once at the moment a state is entered, such as starting a timer or opening a valve to begin the phase, while in-state actions run continuously the whole time the state is active, such as holding that valve open. Exit actions run once as the state is left. Separating one-time entry and exit actions from continuous in-state actions keeps commands from being needlessly re-issued every scan and makes the logic cleaner.
Each state has one or more transitions, which are conditions that, when true, change the state variable to a new value. On the next scan a different branch of the logic becomes active because it is gated by the new state number, so the machine follows automatically. A state can have multiple transitions, such as a normal path forward when the phase completes and a path to a shutdown state if a fault appears.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.