IEC 61131-3: The Five PLC Programming Languages

Short answer

Part 3 of the IEC 61131 standard defines the programming languages for programmable controllers. There are five: two graphical (logic; LD, ladder diagram, and FBD, function block diagram), two textual (ST, structured text, and IL, instruction list), and one for organizing sequences (SFC, sequential function chart). The standard is paid; this guide describes the languages in its own words, without reproducing the text. To test a program without a physical PLC, using OpenPLC and other simulators, see free PLC simulation and tools.

The five languages in one table

How each language thinks

Ladder. The program reads like a ladder: two rails on the left and right, and between them rungs with contacts (conditions) and coils (results). A contact in series with another acts as AND; contacts in parallel act as OR. It is the common language between whoever programs and whoever maintains, because it mirrors the relay control schematic. It is developed in the series guide on ladder: contacts, coils, and seal-in.

Function block diagram. Each block (timer, comparator, controller, scaling) has inputs on the left and outputs on the right; the programmer joins them with lines. It comes naturally to anyone from instrumentation, because the diagram resembles a loop diagram.

Structured text. A high-level language with assignments, conditionals (IF, CASE), and loops. When logic has to operate on data, walk through a table, or implement a formula, text is shorter and clearer than any graphic.

Instruction list. One instruction per line, with an implicit accumulator. It is compact and very close to the machine. The third edition of the standard left it deprecated; it shows up in old programs that must be maintained.

Sequential function chart. It does not describe how an output is calculated, but what stage the machine is in and which condition takes it to the next one. Each step contains actions written in one of the other languages. Its origin is the French GRAFCET; the GRAFCET and SFC guide covers it separately.

Program organization: program organization units

The standard does not only define languages, it also defines a way to structure the project. The pieces are:

• Program: the main unit the controller runs in a task.
• Function block: a unit with its own memory; each use creates an instance with its internal data (a timer is the classic example).
• Function: a unit without memory; for the same inputs it always returns the same result.
• Global and local variables, with declared data types.
• Tasks and resources: decide when and at what priority each program runs.

This separation lets you write a function block once for a motor and reuse it for every motor in the plant. It is the basis of what is explained in PLC programming best practices.

How to choose a language by type of problem

Illustrative example: the 15 kW motor in three languages

Assumed data: 15 kW, 400 V motor, with a start pushbutton, a stop pushbutton, and the thermal overload relay contact.

• In ladder, the start contact and the coil’s own contact in parallel, in series with the stop and the overload, form the classic start-stop seal-in.
• In structured text, the same logic is written as an assignment: the output is true if there is a start or it was already active, and there is neither a stop nor an overload trip.
• In function blocks, a stop-dominant latch block receives the start and the stop condition.

All three versions do the same thing. Which is better depends on who will maintain it: ladder in a plant where electrical staff do the maintenance; in a system with many identical motors, a function block in structured text instantiated for each motor.

What each brand brings and what it does not

The standard fixes the languages, but each manufacturer offers its own environment, with its own extensions, instruction names, and limitations. Some environments use proprietary names (for example, SCL for structured text at one manufacturer, or languages with no exact equivalent elsewhere). That is why a program does not move from one brand to another without work; the guide on PLC brand equivalences lists the names that correspond to each other. The PLCopen organization publishes supporting documents and defines an XML exchange format that some environments support for moving programs between tools.

Reuse and maintenance: what the standard makes easier

Beyond the languages, Part 3 of the standard brings a project discipline that pays off after years in service:

• Declared data types. The compiler warns when incompatible types are mixed, which prevents silent errors.
• Explicit interfaces. A function block shows its inputs and outputs; nobody needs to read its internals to use it.
• Separation between logic and signal assignment. The logic works with named variables, and the mapping to physical addresses is done separately, in the hardware configuration.
• Libraries. Proven blocks are grouped and reused across projects.

A maintenance team that receives a plant programmed with this structure can work on one motor without walking through the whole program. A program written without it forces you to trace every signal by hand. So when specifying a control system, require four things by contract: use of the standard, the accepted languages, delivery of the source code, and documentation of the variables.

Common mistakes

• Choosing the language out of habit rather than for the problem. Long calculations in ladder, or simple interlocks in text without need.
• Mixing languages without criteria. A readable project assigns languages by layer: SFC for the sequence, ladder for interlocks, text for calculations.
• Not using function blocks. Copying and pasting the logic of each motor instead of creating a reusable block.
• Assuming everything converts. An automatic conversion between languages can produce code that is correct and unreadable.
• Using instruction list in new projects.
• Assuming a language implies different performance. Execution time depends on the compiler and the hardware, not on the language used to draw it.

Checklist

• The manual confirms which languages the controller model supports.
• Each layer of the program has a defined and documented language.
• The staff who will maintain the plant can read the chosen language.
• Repeated logic lives in reusable function blocks.
• Variables are declared with a type and a meaningful name.
• There is no instruction list in new code.
• The project has a backup in the tool’s native format.

Frequently asked technical questions

• Is there a faster language? Not by itself; the compiler converts all of them to machine code.
• Can ladder and text be mixed in the same task? Yes, as separate units of the same project, within what the manufacturer’s environment allows.
• What is PLCopen? An association that promotes use of the standard and publishes guides and an exchange format.
• Does the standard cover communication between PLCs? Part 3 covers programming; networks and protocols are handled separately, as in Modbus RTU and TCP.

How we help

Defining the program structure, the languages per layer, and the project conventions keeps a control system from becoming impossible to maintain. At Tiza Group we do the control engineering and related studies, then test and commission the system. See engineering design and studies and testing and commissioning, or write to us through contact.

Related guides

• Interlocking: mechanical and electrical
• What is a PLC: architecture and scan cycle
• Ladder in PLCs: contacts, coils, and seal-in
• PLCs in Substations: Uses, IEC 61131-3 and Testing
• PLC with IEC 61850: Modicon M580, S7-1500, ControlLogix
• Intelligent MCC: CENTERLINE 2100, SIVACON S8, MNS, Okken
• Substation SCADA and HMI: What They Do and How Control Works

References

• IEC 61131-3, programming languages for programmable controllers (paid standard).
• PLCopen, introductory material on IEC 61131-3.
• OpenPLC, project documentation on the five supported languages.

Frequently asked questions