What Is IEC 61131-3?

Back to Blog

The Five IEC 61131-3 Languages

The standard defines five languages, and engineers pick whichever suits the task. Ladder Diagram (LD) resembles relay wiring and is the default for discrete logic. Function Block Diagram (FBD) wires reusable blocks together and suits signal processing and analog control. Structured Text (ST) is a high-level, Pascal-like text language for complex algorithms and math. Sequential Function Chart (SFC) organizes a process into ordered steps and transitions. Instruction List (IL) is a low-level assembly-like language, now largely deprecated.

Crucially, these languages can be mixed within a single project. A batch sequence might be laid out in SFC, with each step calling function blocks defined in FBD and a tricky calculation written in ST. The standard also defines common data types, variables, and program organization units, so the structure of a program is portable in principle even when vendor implementations differ in detail.

Why IEC 61131-3 Matters

The practical payoff is skills and portability. A controls engineer who knows structured text or function blocks can move between compliant platforms without relearning fundamentals, and code concepts transfer even when the exact toolchain changes. It also enables better software practices - reusable function blocks, structured programs, and cleaner logic - than the flat ladder programs of earlier eras.

In oil and gas, most PLCs used at skids, compressor packages, and metering stations are IEC 61131-3 compliant, which is why an engineer will describe a control scheme as "ladder" or "structured text" and expect to be understood. Whatever language runs inside, a SCADA platform reads the resulting tags over the PLC's protocol - Merobix polls Allen-Bradley, Siemens, and Modbus PLCs regardless of the IEC 61131-3 language their logic was written in.

Programs, Function Blocks, and Functions

Beneath the five languages, the standard defines a common software architecture built from program organization units, or POUs. A function is stateless: give it the same inputs and it always returns the same result, like a scaling calculation. A function block has memory: each instance keeps its own internal state between calls, which is why timers, counters, and PID controllers are function blocks - two timer instances run independently even though they share one definition. Programs sit at the top, composing functions and function blocks into the logic for a unit, and tasks schedule when each program executes.

The standard also fixes the data model. Elementary types such as BOOL, INT, REAL, and TIME behave the same across compliant platforms, and engineers build structured types and arrays on top of them. Variables are declared with explicit scope - local to a POU, global, or bound to physical I/O - which is a large part of why a well-organized IEC 61131-3 project stays readable in a way old free-form controller logic rarely did.

Matching the Language to the Task

Because all five languages compile into the same runtime model, the choice is really about who will read the code and what shape the problem has. A rough field guide:

Task	Usual best fit
Discrete interlocks and permissives	Ladder Diagram
Analog signal paths and PID strategies	Function Block Diagram
Math, data handling, protocol parsing	Structured Text
Batch steps and startup sequences	Sequential Function Chart

The social factor is real: maintenance electricians troubleshoot ladder logic with live power-flow highlighting on a running controller, so interlocks that a technician must diagnose in the middle of the night often stay in ladder even when a developer would prefer text. Meanwhile structured text wins for anything with loops, arrays, or arithmetic, where the ladder equivalent would sprawl across dozens of rungs.

How Portable Is IEC 61131-3 Code Really?

The honest answer: concepts port perfectly, source ports partially, projects port poorly. Structured text logic and function block designs usually move between platforms with modest editing, and the PLCopen XML exchange format gives tools a common way to import and export POUs. What does not move is everything around the logic - hardware configuration, I/O addressing, communication setup, and vendor library blocks, which every platform handles its own way.

Teams that care about portability write for it deliberately: keep platform-specific calls in a thin layer at the edges of the program, prefer standard function blocks over proprietary ones, and document the logic in the standard's vocabulary so a future migration is a translation rather than a redesign. That discipline pays off even within a single platform, because whoever migrates the controller a decade from now inherits logic they can actually follow.

Later editions of the standard added object-oriented extensions - classes, methods, and interfaces layered onto function blocks - and larger libraries increasingly use them. Support varies between platforms, so treat those features the same way as a vendor library: powerful inside one toolchain, a rewrite risk when moving across toolchains. The safest core for portable logic remains plain structured text and standard function blocks.

Frequently Asked Questions