Home › Guides › PLC Programming Languages

PLC Programming Languages Explained

A newcomer opening a PLC project for the first time often gets a surprise: the same controller can be programmed in several completely different-looking languages. One screen shows rungs that look like relay diagrams, another shows boxes wired together like an instrument loop, a third shows lines of text that look like Pascal, and a fourth shows a flowchart of steps and transitions. They are not competing products. They are the languages of IEC 61131-3, the international standard for PLC programming, and a good engineer picks the language that fits each job rather than forcing every job into one language. This guide explains all five languages, what each one is good at, and how to choose between them. It builds on our PLC basics and ladder logic guide, so if the scan cycle and the seal-in circuit are new to you, start there.

IEC 61131-3: one standard, five languages

Before IEC 61131-3, every PLC manufacturer had its own programming method, and moving a program from one brand to another meant rewriting it. The standard, first published in the 1990s and revised since, defined a common set of languages, data types and program organisation units so that the concepts — if not the exact files — transfer between platforms. The five languages are ladder diagram (LD), function block diagram (FBD), structured text (ST), sequential function chart (SFC) and instruction list (IL). The third edition of the standard deprecated instruction list, but you will still meet it in older plants, so it is covered briefly at the end.

The standard also defines how programs are organised, and this matters as much as the languages themselves. A program is built from program organisation units: functions, which compute an output from inputs and hold no memory between calls; function blocks, which hold internal state (a timer or a PID controller is a function block); and programs, the top-level units that the PLC runs. Data types are standardised too — BOOL for on/off, INT and REAL for numbers, TIME for durations, STRING for text — so a temperature that arrives as a REAL in one language is a REAL in all of them. Variables can be given meaningful names, called tags, instead of raw memory addresses, which is what makes a modern program readable by the next engineer who has to maintain it.

Ladder diagram (LD): the language of discrete control

Ladder diagram is the graphical language that mimics relay logic: two vertical power rails with horizontal rungs, contacts on the left expressing conditions, coils on the right expressing outputs. It is the most widely used PLC language in the world, and for good reason. Electricians and maintenance technicians can read it without learning a new notation, and on a live plant you can watch contacts change state rung by rung as the process runs, which makes fault-finding fast and intuitive.

Ladder excels at discrete, Boolean logic: interlocks, permissives, motor start/stop stations, valve sequencing driven by limit switches, alarm logic. Its weakness appears when the logic becomes heavily mathematical or data-driven. A complex calculation spread across dozens of rungs with intermediate coils is hard to read and harder to verify, and ladder has no natural way to express loops or arrays. Rule of thumb: if the logic can be said as "if these contacts are true, energise that output", ladder is the right tool. If it needs a paragraph of arithmetic, reach for structured text instead.

Function block diagram (FBD): signal flow you can see

Function block diagram is also graphical, but instead of rungs it shows blocks connected by signal lines, like an instrument loop diagram. Each block performs one job — an AND gate, a timer, a PID controller, a scaling function, an averaging block — and signals flow from block outputs to block inputs. Engineers with an instrumentation background often find FBD the most natural language of all, because a control loop drawn in FBD looks like the loop it controls.

FBD shines for continuous and analogue control: PID loops, signal conditioning, scaling 4–20 mA inputs to engineering units, averaging and filtering, and building reusable control strategies from standard blocks. Its weakness is the same as its strength: when a diagram grows to hundreds of blocks with lines crossing everywhere, it becomes a wiring diagram that is hard to follow, and discrete interlock logic expressed as AND/OR blocks is less readable than the same logic as ladder rungs. FBD and ladder are often used side by side in one project — ladder for the interlocks, function blocks for the analogue loops — and that combination is one of the most common patterns in real plants.

Structured text (ST): text for calculations and data

Structured text is a high-level textual language in the Pascal family, written as statements rather than drawn as diagrams. A few lines of structured text can express what would take a full screen of ladder: IF statements, CASE selections, FOR loops, mathematical formulas, string handling and array operations. It is the language of choice for calculations, data manipulation, recipe handling, batch sequencing logic expressed as state machines, and any algorithm that would be awkward as rungs or blocks.

Its weakness is visibility. You cannot watch a structured text program execute the way you can watch ladder rungs change state; debugging means tracing values in a watch table or adding diagnostic outputs, which is slower on a live plant. It also demands more programming discipline: a poorly written loop can overrun a scan, and a variable used before it is initialised can produce a fault that is hard to trace. The practical rule is to keep structured text blocks small and well-commented, give them clear inputs and outputs, and reserve them for the jobs where text genuinely beats graphics — calculations, conversions, data handling and complex decisions — rather than rewriting an entire plant in text.

Sequential function chart (SFC): sequences drawn as steps

Sequential function chart is the language of sequences, and it looks like a flowchart: a series of steps, each containing actions, connected by transitions, which are the conditions that move the process from one step to the next. A batch reactor that fills, heats, mixes, holds, drains and cleans is a natural SFC program: each phase is a step, each step's actions run its equipment, and each transition checks the condition — level reached, temperature reached, timer elapsed — that advances the sequence.

SFC's great advantage is that the sequence itself is visible. An operator or engineer can see at a glance which step is active, what it is doing, and what condition it is waiting for, which makes both operation and fault-finding far easier than tracing the same sequence through interlocked ladder rungs. Its weakness is that it is a poor language for anything that is not a sequence: continuous control inside a step still belongs in ladder, function blocks or structured text, and SFC programs that try to do everything become tangled. The standard pattern is SFC for the sequence skeleton, with the detailed actions in each step written in the language that suits them.

Instruction list (IL): the legacy language

Instruction list is a low-level textual language, one simple instruction per line — load a value, AND it with another, store the result — similar in spirit to assembly language. It was compact and fast on early PLCs with limited memory, and you will still find it in programs written decades ago that are still running. The third edition of IEC 61131-3 deprecated it, new projects should not use it, and most modern platforms no longer offer it for new code. If you inherit an IL program, the practical approach is to understand what it does and, when the plant allows a planned change, rewrite it in ladder or structured text rather than extending it.

Choosing the right language for each job

The choice is rarely one language for a whole project. A well-structured project mixes them deliberately: ladder for discrete interlocks and motor control, function blocks for analogue loops and signal conditioning, structured text for calculations and data handling, and sequential function chart for batch or start-up/shutdown sequences. When choosing, ask four questions. Who will maintain this code at 3 a.m.? If the answer is a plant electrician, ladder wins for that block. What does the logic look like? Boolean conditions suit ladder, signal flow suits function blocks, maths suits structured text, sequences suit SFC. How will it be tested? Code that can be watched live is debugged faster than code that can only be traced. And what does the site standard say? Many plants mandate a house style, and consistency across a site beats personal preference every time.

Two habits separate good PLC programmers from clever ones. First, name variables by what they mean, not by where they live: "Feed_Pump_Running" beats "M104.2" in every review and every fault-finding session. Second, keep each block small and single-purpose, with a comment explaining why it exists, not just what it does. A program written this way survives staff changes, midnight callouts and plant expansions. For the surrounding topics — how the controller talks to the field, and how operators see it all — see our guides to industrial networks and protocols, HMI design and SIL and safety instrumented systems. And remember the boundary that matters most: safety-critical shutdown logic belongs in a dedicated safety system designed for that role, not in a standard PLC program, whatever language it is written in.

Frequently asked questions

← Back to all guides · PLC basics · HMI design · Industrial networks · SIL & safety systems