PLC Programming Languages: The IEC 61131-3 Guide (Ladder, FBD, SFC, ST, IL)

Why a standard for PLC languages exists

Before the IEC 61131-3 standard (published in 1993), every PLC manufacturer had its own programming language, often incompatible even between different product lines from the same manufacturer. A program written for one controller couldn't move to another without a full rewrite, and training a new programmer meant training them on a specific brand rather than a discipline. The standard fixed this by defining five standardized programming languages, sharing common syntax, data types and an execution model, now implemented by virtually every programmable controller development environment on the market, from Codesys to TIA Portal.

A language being standardized doesn't mean they're all interchangeable. The point of the standard isn't for a programmer to pick one and use it for everything, but for each task in a project to be solved with whichever language best fits its nature. That's the central idea of this article.

The five languages of IEC 61131-3

The standard groups the languages into two families: graphical, which represent logic as a diagram, and textual, which represent it as written code. The table below summarizes the five options and their most common use on the plant floor:

Ladder Diagram (LD): the universal language

Ladder is by far the most widely used language in industry, and its shape reflects its origin: it represents logic as a diagram of contacts and coils mimicking the electromechanical relay schematics it replaced back in the 1970s. That heritage is exactly its strength: any maintenance electrician, with no programming background, can follow an interlock's logic by reading the diagram the same way they'd read an electrical schematic.

That's why it remains the default language for combinational logic and safety interlocks: motor start/stop, run permissives, interlocks between equipment. Where Ladder starts to fall short is with decimal math, array handling, or algorithms with several nested conditions — the diagram becomes hard to read well before its text equivalent would.

Function Block Diagram (FBD): programming with blocks

FBD represents the program as a network of function blocks connected by signal lines, in a way that closely resembles how an instrumentation diagram is drawn. Each block encapsulates a function (a timer, a PID, a scaling function, a counter), and signals flow from block to block without needing to explicitly declare intermediate variables for every connection.

It's the natural language for continuous control and process regulation: temperature or pressure PID loops, control cascades, processing of analog sensor signals. The graphical representation makes the signal flow across the loop obvious in a way that would feel forced in Ladder and less intuitive to review in text on a maintenance screen.

Sequential Function Chart (SFC): staged process control

SFC doesn't describe combinational logic but sequences: a series of steps connected by transitions, where each step activates a set of actions and moving to the next step depends on a condition being met. It's essentially a state machine drawn out visually.

It fits naturally with batch processes (dosing, mixing, recipe-driven processes), startup and shutdown sequences of complex installations, and generally any process an operator would naturally describe as "first this, then that, and if this happens, skip to that other step." The advantage over trying to program the same thing in Ladder is that the diagram itself documents the sequence: seeing which stage the process is in at any given moment is as simple as checking which step is active.

Structured Text (ST): the high-level textual language

Structured Text is the standard's most capable textual language, with Pascal-derived syntax: FOR/WHILE loops, IF/CASE conditionals, complex math operations, and handling of arrays and data structures. It's the language to reach for when the logic is algorithmic rather than electrical: non-linear scaling calculations, recipe management with dozens of parameters, communication with protocols that require manipulating byte buffers, or any reusable function worth encapsulating in a well-tested function block.

In modern projects built on Codesys, ST has gained significant ground because it allows engineers to write reusable, documented, testable libraries with the same discipline as conventional software development — something purely graphical programming makes difficult past a certain level of complexity.

Instruction List (IL): the language the standard retired

IL is a low-level textual language, close to assembly, that operates on a single accumulator register. It was common in earlier generations of PLCs for its efficiency and low memory footprint, but the third edition of IEC 61131-3 (2013) removed it due to its poor readability and maintainability compared with ST. Today it only shows up in legacy projects that haven't yet been migrated, like the ones we cover in our S7-300 to S7-1500 migration guide; for new development, there's no reason to choose it.

How to choose the right language for each task

The right question isn't "which language should I use for this project?" but "which language should I use for this part of the project?" A well-structured PLC program mixes languages according to the nature of each functional block:

• Interlocks and safety → Ladder, for its readability by electrical maintenance staff.
• Control loops and analog signals → FBD, for its visual correspondence with the process control diagram.
• Startup, shutdown and batch sequences → SFC, because the diagram itself documents which stage the process is in.
• Calculations, recipes, communications and reusable libraries → Structured Text, for its power and its ability to encapsulate complex logic in tested blocks.

This mix isn't a rare exception — it's standard practice in any control system of real scale, where most function blocks in a well-designed library tend to be written in ST, while the machine's overall orchestration is handled in SFC or Ladder depending on the case.

The role of the programming environment in the choice

Not every environment supports all five languages with the same depth. Codesys, as a reference implementation of the standard, offers all five languages natively and lets you freely mix them within the same project, including calling a function block written in ST from a step in an SFC. Environments like Siemens TIA Portal also implement all five, though with their own nuances per product line, as we discuss in our Siemens vs Beckhoff comparison. Knowing these differences avoids surprises when migrating a program between platforms or porting libraries from one project to another.

AI-assisted programming doesn't change this logic, it speeds it up

Code-generation tools are starting to propose complete function blocks from a natural-language description, as we cover in our article on artificial intelligence in PLC programming. What doesn't change is the underlying criterion: generated code still has to respect which language suits which kind of logic, and it still needs review from an engineer who understands why an interlock belongs in Ladder while a recipe calculation belongs in ST.

How we work with PLC languages at Bluemation

At Bluemation we don't start from a preferred language — we start from the task that needs solving: we define which parts of the program go in Ladder, FBD, SFC or ST before writing a single line, document that decision, and maintain our own tested, reusable function block libraries across projects. That discipline is what keeps a program maintainable by another engineer, or by the client themselves, years after commissioning.

If you have an automation project and want PLC programming that's documented, maintainable, and uses the right language in every part of the code, check out our PLC programming service or get in touch with us. We'll walk you through how we'd approach your project, no strings attached.