The short answer
IEC 61131-3
IEC 61131-3 is the international standard for programmable controller programming languages. It defines five languages: ladder diagram, function block diagram, structured text, instruction list, and sequential function chart, plus a common model of data types, variables, and program organization units (programs, function blocks, and functions) that all five share. Most modern controllers implement the standard to some degree, but conformance is partial and dialects differ, so a program does not move between vendors without work.
Key points
- Five languages, one data model. Mix them within a project; pick each by the job.
- Program organization units: programs, function blocks with state, and functions without.
- Typed variables with declared scope replace raw addresses.
- Conformance is partial on nearly every platform, and dialects differ. Portability is a goal, not a fact.
- The standard is why a function block written well once can be reused across a plant.
What the standard covers
IEC 61131 is a family of standards for programmable controllers, and part 3 is the one programmers meet. First published in 1993 and revised since, it standardized what had been a different language on every controller: the syntax and semantics of the programming languages, the data types a program can declare, how variables are scoped and how they persist, and how a program is organized into reusable units. Its purpose was to let a programmer trained on one platform read another, and to let well-built code be reused.
What it does not cover is the hardware, the I/O addressing conventions, the communication protocols, or the engineering software. Those remain vendor territory, which is why two conformant controllers can still feel very different to work on.
The five languages
| Language | Form | Best for | Weak at |
|---|---|---|---|
| Ladder Diagram (LD) | Graphical; rungs of contacts and coils resembling relay logic | Discrete interlocks, motor control, anything an electrician will troubleshoot online | Arithmetic, string handling, loops, and anything with more than a few branches |
| Function Block Diagram (FBD) | Graphical; blocks with inputs and outputs wired together | Analog signal processing, PID loops, and data flow that reads left to right | Sequences and conditional branching |
| Structured Text (ST) | Text; a Pascal-like language with IF, CASE, FOR, and assignments | Calculations, data manipulation, algorithms, state machines, anything with loops | Online troubleshooting by people who do not read code; discrete logic that is clearer as rungs |
| Sequential Function Chart (SFC) | Graphical; steps and transitions | Batch and startup sequences with clearly defined states | Continuous control; sequences with many parallel branches become hard to follow |
| Instruction List (IL) | Text; an assembler-like list of instructions | Very small controllers and legacy code | Readability. Deprecated in the third edition of the standard |
A project mixes them. A typical water plant program has ladder for the motor and valve control, function blocks or structured text for the analog processing and PID, structured text for the calculations and the more involved logic, and SFC where a real sequence exists. Choosing one language for everything, in either direction, makes some part of the program harder to read than it needs to be.
The common elements
- Data types
- BOOL, INT and DINT, REAL and LREAL, TIME, STRING, and the rest, with defined sizes and behavior. Derived types let a programmer declare a structure, an array, or an enumeration, so a pump can be one variable with all its members rather than forty separate tags.
- Variables
- Declared with a type and a scope: local to a unit, global to the project, or mapped to an input or output. The standard includes attributes for retentive variables that survive a power cycle and constants that cannot be written.
- Programs
- The top-level units, assigned to tasks and executed by the scheduler. A program owns its variables and calls function blocks and functions.
- Function blocks
- Units with internal state: a timer, a PID controller, a pump control block. Each instance keeps its own data, so one block definition serves every pump in the plant. Function blocks are the standard mechanism for reuse.
- Functions
- Units without state that return a value from their inputs, like a scaling function or a square root. Same inputs, same output, every time.
- Tasks
- Execution containers with a cycle time or a trigger, to which programs are assigned. The standard defines periodic and event tasks and priorities among them.
What conformance means
The standard defines a conformance model in which a vendor declares which features are implemented. Nearly every platform implements a subset and adds extensions, and the same feature can differ in detail: how a retentive variable is declared, what a timer instruction is called, how an array is indexed. A program written in structured text on one platform is much easier to move to another than a ladder program was in 1990, but it still needs editing, and the I/O mapping and communication configuration are rewritten from scratch.
Some platforms that predate the standard wrap it around an older model. Others were designed to it. A useful test is whether the platform lets you write a function block with a structured input, instantiate it a hundred times, and pass the structures around; that capability is what the standard was for, and it is where the differences between platforms show.
Why it matters for a utility
A utility rarely chooses a controller for its language conformance. The standard matters for a practical reason: a program written in the style the standard encourages, with typed variables, function blocks for each equipment type, and a program organization someone else can follow, costs less to maintain for twenty years than one written as thousands of rungs on raw addresses. The standard gives that style a vocabulary and a set of tools. Whether the integrator uses them is a specification question, and worth asking.
Frequently asked questions
- Which language should I learn first?
- Ladder, because it is what the installed base is written in and what most troubleshooting is done in. Structured text second, because it is where the calculations and the more capable logic live, and it transfers between platforms most easily. The other three are learned when a project needs them.
- Is ladder logic obsolete?
- No. It remains the best language for discrete control that maintenance staff troubleshoot online, because the state of every contact is visible in place. It is a poor language for arithmetic and data handling, and programs that force those into ladder are the ones that give it a bad name.
- Can I move a program from one vendor to another?
- Not without rewriting. Structured text and the logic structure move with editing; the I/O configuration, communications, and vendor-specific instructions are rebuilt. The PLCopen XML format helps with some tools, but the honest expectation is a re-implementation informed by the original.
- Does the standard say anything about how to structure a program?
- It provides the mechanisms, not the rules. Program organization, naming, and the discipline of one function block per equipment type are site standards, and the PLCopen guidelines are a good source for them.
Related topics
- Ladder Logic FundamentalsRungs, contacts, coils, and the relay conventions the language inherited — plus the patterns you will meet in almost every industrial program.
- Structured TextThe text language of IEC 61131-3: syntax, control structures, how it fits alongside ladder, the conventions that keep it readable for the next person, and the mistakes that make structured text a liability in a plant that troubleshoots online.
- Function Block DiagramThe graphical data-flow language of IEC 61131-3: how blocks, pins, and wires work, execution order, where FBD beats ladder and structured text, building reusable equipment blocks, and the habits that keep a diagram readable.
- Tasks and Execution PriorityHow a controller schedules its work: the continuous task, periodic tasks at a fixed rate, event tasks triggered by something happening, how priority preempts, and where each kind of logic belongs.
- Controller Memory and AddressingHow a controller organizes its data: data tables and tags, the input and output images, the elementary data types and what they hold, and the naming discipline that keeps a program readable years later.
- State Machines in PLC ProgramsWriting sequences as explicit states instead of tangled interlock chains: what a state is, how transitions are written, the pattern in structured text and in ladder, publishing the state to the HMI, and the failure handling every state machine needs.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.