Ladder logic vs structured text vs function block

IEC 61131-3 language choice is the part of the controls job that decides whether the next engineer who opens the project file shouts at the screen or quietly gets on with the work. The standard defines five languages — Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, Sequential Function Chart — and most modern PLC platforms support at least three of them. The choice between them is rarely about what is technically possible (any of them can implement a start-stop with debounce) and almost always about who reads the code, what the maintenance team is fluent in, and which shape of logic each language draws cleanly. This tutorial walks the same simple sequence — start a motor with a three-second debounce — through all five languages and gives the criteria for picking among them.

Why this matters on real plants

Most controls engineers in SA come up through one platform — Allen-Bradley or Siemens, mostly — and one language, which is usually Ladder. They write Ladder fluently, they read Ladder fluently, and the maintenance teams they work with read Ladder during a 02:00 callout because Ladder looks like the relay diagrams the older fitters were trained on. The trap is that "fluent in Ladder" gets generalised to "Ladder is the right choice for everything", and projects end up with 400-rung sub-routines that implement what should have been a 30-line Structured Text loop. The fault is not Ladder; the fault is using Ladder for a job that Ladder draws badly.

The cost of a wrong language choice is paid in review hours, not in runtime errors. A clean Structured Text routine that handles a moving-average filter in 12 lines becomes 80 rungs of Ladder with a counter, an array index, and a pile of MOV instructions that only the original author can read. Six months later when the filter needs tweaking, the new engineer reads the 80 rungs at 4 rungs per minute, asks three colleagues what the array index pattern is doing, and rewrites the whole thing rather than modify it — a 6 hour task that should have been 30 minutes. The wrong language choice triples or quadruples the maintenance cost on the affected piece of logic. Multiply by the dozens of such choices in a typical project file and the cost is substantial.

The third reason it matters more in SA than in textbook examples: the team mix. SA plants commonly have an in-house controls team that is Ladder-fluent, an outsourced systems integrator that prefers Structured Text or FBD on new projects (because they bill by feature delivery and ST writes faster), and a vendor support engineer who flies in once a year and reads whatever shape the platform's debugger draws best. A project file that mixes Ladder, ST, and FBD without a separation rule — say, ST for the algorithm-heavy function blocks and Ladder for the IO and interlock layer — confuses every reader and pleases none. Picking the right language per piece of logic, and committing to a separation rule that the team agrees on, is what makes the file readable across the three audiences.

The mental model

Each of the five IEC 61131-3 languages draws one shape of logic cleanly and the others poorly. Ladder Diagram (LD) draws Boolean discrete logic — the AND-of-ORs combinations of inputs and timers and bits that sit between field signals and motor outputs. It is unbeatable for interlock chains, start-stop seal-in circuits, permissive logic, and anything where the question is "is this output allowed to be on right now". It draws math poorly: anything past four arithmetic operators in a single rung becomes unreadable, and any indexed-array operation becomes a tangle.

Function Block Diagram (FBD) draws dataflow — signal-conditioning chains, scaling, filtering, PID loops, calculation pipelines where named blocks pass data left-to-right and side branches are uncommon. FBD wins for analog signal processing and for libraries of reusable function blocks where the connections between block instances tell the story. It draws Boolean logic acceptably (each block is a logic gate) but no better than Ladder, and it draws sequential logic — anything with state transitions — badly.

Structured Text (ST) draws math, loops, and conditional branching cleanly. Anything that involves arrays, FOR loops, recursive structures, string manipulation, or arithmetic past four operators is shorter and clearer in ST than in any other IEC language. ST also draws complex conditional logic — IF...ELSIF chains with three or more clauses — far more readably than the equivalent Ladder. It draws Boolean discrete logic acceptably but verbosely; for a simple seal-in circuit, ST takes more lines than the equivalent Ladder rung.

Sequential Function Chart (SFC) draws sequential processes — batch sequences, recipe-driven steps, state machines where the system progresses through a series of states with explicit transitions. Each step is a box, each transition is a labelled gate, each parallel branch is a fork-and-join. SFC is unbeatable for batch and sequence logic; it draws continuous logic poorly because the step-and-transition model does not fit dataflow.

Instruction List (IL) is the assembly-language-style mnemonic form. It is in the IEC standard but has been deprecated in IEC 61131-3 Edition 3 (2013), and the major vendors are removing tooling support. New development should not use IL; legacy systems that already use IL should be maintained in IL only as long as no other change is being made to the routine, then migrated to ST on the next significant edit.

The mental rule is to pick the language by the shape of the logic, not by the engineer's preference. Boolean discrete logic to Ladder. Dataflow to FBD. Math and loops to ST. Sequential processes to SFC. Legacy maintenance only to IL. And — critical — never mix two languages in a single function block or routine without a separation rule that the team has agreed on, because each language has its own debugger view and mixing them in one routine multiplies the cognitive load on every reader.

Worked example

Open the simulator. Drop a CompactLogix CPU on the rack with a DI16 input module and a DO16 output module. Wire start pushbutton on DI16 channel 0, stop pushbutton on DI16 channel 1, motor contactor on DO16 channel 0, and run-feedback (auxiliary contact) on DI16 channel 2. The simulator's editor lets you implement the same routine in any IEC language and switch between them. The sequence to implement: when start is pressed, debounce for three seconds (motor must not energise on a contact bounce shorter than 3 s), then energise the motor and seal in until stop is pressed.

Here is the same sequence in all five languages.

(* === Ladder Diagram (LD) — what most teams read fluently === *)
(* Rung 1: debounce timer *)
| START_PB    STOP_PB    DEBOUNCE_TON.Q  MOTOR_RUN |
|----| |--------|/|---------|/|------------( )---- |
(* Plus a TON instruction with 3000 ms preset, EN tied to START_PB *)
(* Rung 2: motor seal-in *)
| MOTOR_RUN   STOP_PB                       MOTOR  |
|----| |--------|/|----+-----------------( )------ |
| MOTOR                |                            |
|----| |---------------+                            |
(* 4 rungs total including the TON. ~12 visual elements. *)

(* === Function Block Diagram (FBD) === *)
(*   START_PB ---+-- AND ---+-- TON(3s) ---+-- AND ---+-- OR ----+-- MOTOR *)
(*   STOP_PB ---NOT-+-------+--------------+----------+----------+         *)
(*   MOTOR ---------- (feedback to OR for seal-in) ----+                   *)
(* Same logic. ~6 named blocks, 9 connection lines. Reads as dataflow. *)

(* === Structured Text (ST) === *)
DEBOUNCE_TON(IN := START_PB AND NOT STOP_PB,
             PT := T#3s);
MOTOR := (MOTOR OR DEBOUNCE_TON.Q) AND NOT STOP_PB;
(* 2 statements, 4 lines. Most compact form. *)

(* === Sequential Function Chart (SFC) === *)
(*  Step IDLE                                                                *)
(*    -- transition: START_PB AND NOT STOP_PB                                *)
(*  Step DEBOUNCING (action: start 3s timer)                                 *)
(*    -- transition: TIMER_DONE                                              *)
(*  Step RUNNING (action: MOTOR := TRUE)                                     *)
(*    -- transition: STOP_PB                                                 *)
(*  back to IDLE                                                             *)
(* 3 steps, 3 transitions. Reads as a state machine. Heavier scaffold        *)
(* than necessary for this size of problem, but exactly right at scale.      *)

(* === Instruction List (IL) — legacy only === *)
LD    START_PB
ANDN  STOP_PB
ST    DEBOUNCE_TON.IN
CAL   DEBOUNCE_TON(PT := T#3s)
LD    MOTOR
OR    DEBOUNCE_TON.Q
ANDN  STOP_PB
ST    MOTOR
(* 8 lines. Compact but unreadable to most modern engineers. *)
(* Deprecated in IEC 61131-3 Edition 3. Do not use in new code. *)

Now the readability comparison. The Ladder version is the longest in line count (12 visual elements across 4 rungs) but the most universally readable on a SA plant — every fitter, technician, and engineer over 30 reads Ladder fluently. The ST version is the shortest (2 statements, 4 lines) and reads cleanly to anyone with any programming background, but reads worse than Ladder to a fitter without programming experience. The FBD version is the most "drawn" — its dataflow shape is intuitive at a glance and stays intuitive as the logic scales up to 20 or 30 blocks. The SFC version is overkill for this size of problem (the scaffold of step-and-transition adds visual weight that the simple seal-in does not need) but becomes the right choice the moment the sequence has more than three states. The IL version is compact but reads like assembly to anyone who has not used IL before, which by 2026 is most working engineers.

The recommendation by logic shape, with a SA-team default in parentheses: Boolean discrete logic — Ladder (default). Analog dataflow and signal processing — FBD (with ST as a second choice for the math-heavy parts). Math, arrays, and loops — ST. Batch sequences and state machines with more than three states — SFC. Instruction List — never in new code; maintain existing IL only as long as no significant edit is needed, then migrate to ST. The default for a SA plant where the maintenance team is Ladder-fluent and the systems integrator wants to use ST: Ladder for the IO and interlock layer (everything that touches the field), ST for the algorithm-heavy function blocks (filters, PIDs, batch logic), with a clean separation rule that no routine mixes Ladder and ST in the same block.

Common mistakes

• Using ST when the team is Ladder-fluent. A systems integrator delivers a project file with the entire interlock layer in ST because ST writes faster on the integrator's billable hours. The in-house team that has to maintain it after handover reads ST at half the speed of Ladder, the maintenance review time triples, and the next callout where a fitter needs to walk an interlock chain at 02:00 turns into a phone call to the integrator at premium rates. Always match the language to the maintenance team's fluency, not to the development team's preference. If the team is Ladder-fluent, use Ladder for anything the maintenance team will need to read.

• Using LD for math past four operators. A 4-rung calculation that takes a 4-20 mA input, scales it to engineering units, applies a moving-average filter over 16 samples, and converts to a percentage becomes 30 rungs of Ladder with three counters, an array index, and a tangle of MOV instructions. The same logic in 8 lines of ST is readable in 30 seconds. Ladder is the wrong language for arithmetic past about four operators. Switch to ST or FBD for math-heavy logic.

• Using IL anywhere in new development. Instruction List is deprecated in IEC 61131-3 Edition 3 (2013), the major vendors are removing tooling support over the 2024-2028 window, and most engineers under 35 cannot read IL without a manual. Legacy IL routines that work and do not need editing can stay; the moment a routine needs significant change, migrate it to ST. Never write new IL.

• Mixing two languages in a single function block without a separation rule. A function block with both Ladder rungs and ST sections forces every reader to switch between two debugger views to follow the logic, and forces every editor to learn both languages on every change. The cognitive cost is high. The rule the team agrees on can be "Ladder routines are routines containing only Ladder; ST routines contain only ST; calls between routines pass clean inputs and outputs". Function blocks that need both should be split into two cooperating function blocks.

• Choosing SFC for a logic that does not have explicit states. SFC is built for sequential processes — batch recipes, calibration sequences, washdown cycles. Logic that is essentially continuous (a PID loop, a permissive interlock chain, a level-control routine that runs every scan) draws badly in SFC because the implicit "every-scan" execution does not fit the step-and-transition model. Use SFC only when the system genuinely has explicit states with explicit transitions between them.

• Forgetting that the platform may not support all five languages. The IEC 61131-3 standard defines all five, but vendors implement subsets. Some smaller platforms support only Ladder and ST. Some support Ladder, FBD, and ST but not SFC or IL. Always confirm what languages are licensed and supported on the actual platform the project will run on, not what the standard allows. A project file that uses SFC on a platform that only supports Ladder and ST will fail to download.

How to practise this in the simulator

The simulator's editor lets you implement the same routine in any of the five IEC languages and switch between them in real time, with the runtime behaviour identical across all five. Open the start-stop-motor scenario, implement it first in Ladder (the default), then duplicate the routine and re-write it in ST, then in FBD, then in SFC. Run each version against the same simulated pushbuttons and watch the motor behaviour match across all four. Then try a math-heavy task — a 16-sample moving-average filter — in Ladder and in ST. The difference in readability and edit cost becomes obvious in 15 minutes. Then try a four-state batch sequence — fill, mix, drain, clean — in SFC and in Ladder. The SFC version reads cleanly; the Ladder version becomes a tangle. The simulator gives you the same logic in different languages without the cost of building four different real plants.

Vendor reference

The cross-vendor reference for the standard itself is the Wikipedia: IEC 61131-3 article, which summarises the five languages, their syntax models, and the deprecation status of IL in Edition 3. The iec.ch standards page hosts the canonical IEC 61131-3 document for purchase, currently at Edition 3 (2013) with a draft Edition 4 in technical-committee review as of 2025-2026. Vendor implementations vary — the Studio 5000 environment from Rockwell supports Ladder, ST, FBD, and SFC with full debugger support across all four, and the TIA Portal environment from Siemens supports the same four with the additional GRAPH language for sequential logic that overlaps SFC. The CODESYS runtime that ships on many smaller platforms (including some Schneider, WAGO, and Beckhoff PLCs) supports all five languages including IL, though IL is being phased out of the CODESYS roadmap as well.

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. Our completion certificates are course-level only — they describe what you covered, not an NQF Level X qualification. The CCST cert from ISA is the portable industry credential we recommend; we are not an ISA cert delivery partner either, but our cert packs are CCST-aligned. Picking the right IEC language for a piece of logic is a judgment skill that builds with reps on real and simulated projects — the simulator gives you all five languages on the same controller without ordering five different platforms.