PLC Programming Languages: The 5 IEC 61131-3 Languages Explained
If you're starting PLC programming, the first question is which language to learn. The IEC 61131-3 standard defines five languages in its 2013 edition, and in practice most programs are written in Structured Text (ST) or Ladder Diagram (LD).
This guide explains all five, compares them honestly, and helps you pick the right one to start with. It also covers a question that comes up right after: why use a PLC at all when a $10 microcontroller can read inputs and drive outputs?
What Is IEC 61131-3?
IEC 61131-3 is the international standard (IEC 61131 Part 3) that defines programming languages for programmable logic controllers. Its editions date from 1993, 2003, 2013 and 2025. Editions 1 to 3 define five languages; the 2025 edition no longer includes IL. Siemens, Rockwell, Beckhoff, B&R, Omron, Mitsubishi and many CODESYS-based controllers support at least some of these languages, often with vendor-specific dialects and extensions.
The standard matters because it means your ST code is largely portable. A well-written Structured Text program follows the same core syntax whether you're using CODESYS, TwinCAT, or a vendor tool such as TIA Portal (which calls its dialect SCL, with documented differences from the standard). Expect to rework I/O addressing and vendor libraries when you move a program.
The 5 Languages at a Glance
1. Structured Text (ST)
ST is a high-level, text-based language with syntax similar to Pascal. If you've written any programming language before (Python, JavaScript, C, Java), ST will feel familiar within minutes. It supports:
- Conditional logic:
IF...THEN...ELSIF...ELSE...END_IF,CASE...OF - Loops:
FOR...DO,WHILE...DO,REPEAT...UNTIL - Functions and function blocks: reusable, parameterized logic units
- Strong typing:
BOOL,INT,REAL,TIME,STRING, arrays, structs - Expression-based:
result := (a + b) * c / 2.0;
Why people pick ST: Software engineers entering industrial automation find it natural. It's version-control friendly (plain text), and it handles complex logic that ladder can't express cleanly.
2. Ladder Diagram (LD)
LD is the oldest PLC language, tracing back to relay logic and the first Modicon programmable controller (the 084, designed in 1968 and first delivered in 1969). It represents logic as relay circuits: horizontal "rungs" with contacts (inputs) on the left and coils (outputs) on the right. Electricians can read it because it looks like an electrical schematic.
- Strengths: intuitive for boolean logic, visual tracing of signal flow, universally understood by maintenance electricians
- Weaknesses: awkward for math, loops, data processing, and complex state machines. A short calculation that fits in a few lines of ST can take many rungs.
LD remains very widely used, not because it's the best for every task, but because maintenance teams know how to read it. If your code will be maintained by electricians on the factory floor, ladder is the pragmatic choice.
3. Function Block Diagram (FBD)
FBD represents logic as a data-flow graph: boxes connected by lines. Each box is a function (AND, OR, ADD, PID controller) and lines show how data flows between them. Popular in process industries (chemical, oil & gas, water treatment) where engineers think in terms of signal flow and control loops.
- Strengths: intuitive for signal processing and closed-loop control (PID blocks), good for process engineers
- Weaknesses: large programs become spaghetti diagrams, harder to version control than text, not all vendors support it equally
4. Sequential Function Chart (SFC)
SFC is a state machine language: a flowchart of steps and transitions. Each step executes actions, and transitions define when to move to the next step. It's the clearest way to express sequential processes: "do step A, wait for condition X, then do step B."
- Strengths: the clearest language for batch processes, assembly sequences, and any state-based logic. Easier to read than a state machine coded in ST.
- Weaknesses: not suited for continuous control, limited vendor support compared to ST and LD, and the graphical editors vary significantly between platforms.
5. Instruction List (IL), Deprecated
IL is an assembly-like language: one instruction per line, accumulator-based operations. It was included in the original 1993 standard for compatibility with older PLCs. It was marked deprecated in edition 3 (2013), and the 2025 fourth edition no longer includes it, although individual vendors can still offer it in their tools. It is rarely written in new projects; you mainly meet it when maintaining legacy programs.
Which Language Should You Learn First?
Here's why ST is the better starting point for most people in 2026:
- ST is more expressive. Anything you can draw in ladder you can write in ST. The reverse is not true: complex math, string processing, and data manipulation are painful in ladder.
- ST is portable. IEC 61131-3 ST is supported by CODESYS, TwinCAT, and most other IEC-based platforms, and TIA Portal's SCL is a related dialect with documented differences. Graphical editors differ more between vendors, so ladder programs usually need more rework when moved.
- ST is version-control friendly. Plain text means git diff, merge, review. Graphical programs are stored as project or XML files whose diffs are much harder to read.
Learn ladder when you need to: for maintenance, for communicating with electricians, or when working in environments where ladder is the standard. But start with ST. For a side-by-side comparison of the two plus the SCADA angle, see Ladder Logic vs Structured Text.
Can You Mix Languages?
Yes. The IEC 61131-3 standard explicitly supports mixed-language projects. A common pattern: use SFC for the overall sequence orchestration, ST for the complex calculations, and LD for the simple I/O mapping. Each POU (Program Organization Unit) can use a different language. This is how professional PLC projects are structured.
PLC vs Microcontroller: Why Use a PLC at All?
Every engineer who discovers Arduino asks it: why pay for a PLC when a microcontroller (Arduino, ESP32, STM32) costs a fraction as much and also reads inputs, runs logic, and drives outputs? On a bench they do the same job. The difference is what happens in a factory, and it is also why PLCs have their own standardized languages.
What a PLC Gives You
- Predictable scan cycle. A PLC reads inputs, executes the program, writes outputs, and repeats, with a configured cycle time and a watchdog that flags overruns. A loop on a microcontroller runs when the processor gets to it, so adding WiFi or serial logging changes the timing.
- Industrial I/O. Opto-isolated 24 V inputs connect to field sensors directly. Outputs are built for inductive loads such as contactors and solenoids. Wiring a 24 V sensor straight to a 5 V microcontroller pin can destroy it, so you need level shifting, isolation, and flyback protection that someone has to design and test.
- A standard way to maintain the code. This is where the IEC 61131-3 languages above matter in practice. When the original developer leaves, an electrician can open a ladder program on a standard platform. A custom C++ firmware has no such common ground.
- Fail-safe behavior. Watchdogs, defined output states on fault, and vendor documentation are part of the product.
Where a Microcontroller Is the Right Call
- Prototypes and proofs of concept before committing to PLC hardware.
- Non-critical data logging and sensor gateways, for example an ESP32 reading sensors and publishing over Modbus or MQTT.
- Custom displays and educational projects.
- Controlled environments where a failure costs little and you have the expertise to maintain the hardware.
Why Hobbyist Builds Fail in Factories
The pattern is familiar: a custom Arduino controller works on the bench, then misbehaves in the plant. The usual causes:
- Electrical noise from VFDs, motors, and welders resets or crashes unshielded boards.
- Voltage spikes from inductive kickback destroy inputs that lack isolation.
- Vibration loosens friction-fit header connections, producing intermittent faults.
- Heat inside a summer cabinet exceeds a commercial-grade part's rating.
- No fail-safe design: no watchdog, undefined outputs after a crash.
- No maintainability: no documentation, no standard programming model, one person who knows how it works.
The two are often combined: a PLC handles control and safety while a microcontroller acts as an edge device or custom touch interface, talking to it over Modbus or MQTT. And you can prototype on a microcontroller, then reimplement the proven design on a PLC for production. For anything installed in a production facility, treat the microcontroller as a gateway or prototype, not the controller.
Reading Data Out of a PLC
Whatever language you program in, the PLC's registers end up being read by something else. Modbus Poll lets you read and write Modbus registers on a Mac to verify what your controller actually exposes, and Voltrus SCADA turns those tags into dashboards and alarms.
Explore Modbus Poll