What Is a Sequential Function Chart?

Back to Blog

How a Sequential Function Chart Works

An SFC is built from two core elements: steps and transitions. A step represents a stage of the process and holds the actions active during it. A transition is the condition that must be true to move from one step to the next. Control flows down the chart, dwelling in each step until its transition fires, then advancing. SFC also supports branches - divergences for choosing between alternative paths and parallel branches for running steps simultaneously.

Importantly, SFC usually does not do the detailed work itself. The actions inside each step are typically written in one of the other IEC 61131-3 languages - ladder, function block diagram, or structured text. SFC provides the skeleton of the sequence; the other languages fill in what each step actually does. This separation makes complex sequences far easier to design, read, and troubleshoot.

Where SFC Fits Best

SFC is ideal for any process that is inherently sequential: equipment start-up and shutdown routines, batch recipes, cleaning cycles, and multi-stage operations where order matters. When you can describe a process as "first do A, then wait for B, then do C," SFC captures that structure directly, and operators and engineers can see exactly which step the process is in at any moment.

In oil and gas, sequential logic appears in compressor start-up sequences, well start-up and shut-in routines, and automated proving cycles. Because the current step is visible, SFC also makes troubleshooting intuitive - a stalled sequence points immediately to the transition that failed to satisfy. A SCADA platform reads the step status and process values as tags, letting operators watch a sequence progress remotely; Merobix reads such tags over Modbus, OPC UA, and other protocols without altering the underlying logic.

Action Qualifiers: What Runs, and for How Long

Each action attached to a step carries a qualifier that controls its lifetime, and this is where SFC bites people who have only skimmed the language. IEC 61131-3 defines a set of qualifiers: N runs the action while the step is active, P pulses it once, D delays its start, L limits how long it runs, and the stored pair S and R set an action running and keep it running after the step deactivates, until some other step explicitly resets it. Non-stored actions clean up after themselves; stored actions do not.

The stored qualifiers are powerful for things that must persist across steps - keep the vent open through the whole sequence - and they are also the leading cause of the classic surprise where an output stays on after the sequence has moved on or aborted. Two habits prevent most of it: prefer non-stored actions unless persistence is genuinely required, and for every S there must be a documented R that lives in a step the chart is guaranteed to reach, including the abort and shutdown paths. An S whose reset only exists on the happy path is a latent defect waiting for the first abnormal exit.

A Worked Symbolic Example: Fill, Transfer, Settle

Take a simple transfer sequence written symbolically. Step 1, Fill: the inlet valve output is active with an N qualifier. Its transition is level at or above the high setpoint L_H. Step 2, Transfer: the pump runs, again non-stored. Its transition is level at or below the low setpoint L_L. Step 3, Settle: everything is off and a D-qualified action starts a settling timer; the transition is the timer's done bit T_done, after which the chart loops back to Fill or drops to an idle step depending on a run-request flag.

Written this way, the chart is its own documentation. An operator asking why nothing is happening gets a precise answer from the active step: if the chart sits in Fill, the level has not reached L_H, and the question becomes why - a stuck valve, a failed level measurement, or a genuinely slow fill. Compare that with the same sequence buried in interlocked rungs, where working out which condition the logic is waiting on takes real archaeology. The chart structure is doing diagnostic work that a purely parallel program makes you do by hand.

Restart Behavior and Parallel Branch Pitfalls

Two design decisions deserve explicit answers before a chart goes into service. First, restart: after a power cycle or a controller stop, does the sequence resume from the step it was in, or restart from the initial step? Resuming mid-sequence assumes the physical process also held still, which is rarely true; restarting from the top assumes the process can safely be re-run from the beginning. The right choice depends on the equipment, and for anything with safety implications it belongs to the site's procedures and qualified personnel, not to whatever default the programming tool happened to ship with.

Second, parallel branches: a simultaneous divergence runs several legs at once, and the joining transition cannot fire until every leg has reached its final step. A single leg that stalls - often on a transition nobody thought hard about because that leg always finished first in testing - freezes the whole chart at the join with no obviously failed step highlighted. When a chart hangs at a join, walk each parallel leg separately. The transitions themselves are ordinary boolean logic written in ladder logic or structured text, so the usual online-monitoring techniques apply once you know which leg to look at.

Frequently Asked Questions