Giving PLC software a common structure

IEC 61131-3 defines the syntax, semantics and common software structures of programming languages used in programmable controllers. It concerns not only how a logic expression is written, but also how variables, program units and programs associated with tasks are organized. It provides a shared foundation for developing understandable, structured control software across automation environments.

The standard is not a particular manufacturer's PLC software or a universal project file that can be downloaded directly to every controller. The language standard, development environment, runtime system and target hardware must be assessed separately.

Where are ST, LD and FBD useful?

Structured Text, ST: A textual language for conditions, calculations, loops and data processing. It can provide a clear representation for scaling, recipe calculations or processing arrays. When using Structured Text, consider data types, loop limits and the execution time required within the task.

Ladder Diagram, LD: Represents logic using graphical elements resembling contacts and coils. Digital permissives, operating conditions and interlocks can be convenient for maintenance personnel to follow. A contact symbol in Ladder Diagram is a software condition; the physical contact type and the logical value received by the PLC must also be assessed.

Function Block Diagram, FBD: Organizes functions and the flow of data between them through graphical connections. Comparisons, timers and control blocks can be represented as a network. FBD is a programming language, whereas an FB, or function block, is a program organization unit. These are different concepts.

How should SFC and IL be distinguished?

SFC, Sequential Function Chart, divides a process into steps, transition conditions and actions. A washing process, for example, can be organized into filling, washing and draining, with explicit completion and transition conditions. Appropriate programming elements implement the actions within the SFC structure.

IL, Instruction List, is an instruction-based approach found in older applications. It is absent from the programming-language list in the scope of the 2025 edition. Some software may nevertheless continue supporting it for legacy maintenance. When modernizing a machine programmed in Instruction List, verify timing, memory use and actual operating behaviour alongside any instruction conversion.

What are programs, functions and function blocks?

A POU, Program Organization Unit, is a fundamental unit for organizing software. A PROGRAM executes a section of the application; a FUNCTION produces a calculation or processing result from supplied values; a FUNCTION_BLOCK is instantiated and has its own data and state. Two separate instances of the same function block provide two separate operating states.

For example, timers controlling delayed operation of two conveyors should use separate instances. Sharing one instance's state between independent processes can produce unexpected results. A function block retaining state between calls does not mean that all its data survives a power failure. Check RETAIN/PERSISTENT support, the memory hardware and restart behaviour separately.

Data types and I/O mapping

BOOL for logical values, INT and DINT for integers, REAL for floating-point calculations and TIME for durations are basic examples. Arrays, structures and defined data types support more organized data models. Overflow, signed and unsigned values, type conversions and initialization all matter in real applications.

Symbolic variables must be mapped to physical input and output modules for the target system. Identical variable names in two projects do not establish identical terminals or data addresses. The 2025 edition also includes UTF-8 strings and associated functions; verify the implementation supported by the selected editor and runtime.

Task periods, priorities and real-time behaviour

The task arrangement determines how often and at what priority a program executes. Supported cyclic or event-triggered operation depends on the target platform. Different application functions may be assigned to different tasks, and consistency of shared data must be considered. Unnecessarily lengthy calculations inside a loop can affect other operations' timing.

Example: Ordinary input-reading logic executing every 10 ms cannot be assumed to detect every 1 ms pulse. Input hardware with pulse-capture capability, an interrupt arrangement or a high-speed counter may be needed. Successful compilation does not prove that timing requirements have been met.

Why does moving code to another PLC require additional work?

Common language structures help engineers reuse knowledge and some software units. However, vendor libraries, hardware addresses, task arrangements, supported features and project formats can differ. PLCopen XML and IEC 61131-10 provide a framework for exchanging project elements, but the imported project's behaviour on the new target still requires verification.

The implementation of IEC 61131-3 in CODESYS must likewise be assessed with the selected version and target device. An editor opening a Ladder program does not establish support for every language, edition or manufacturer's library. Fully automatic conversion between languages must not be assumed for every program either.

What do the parts of IEC 61131 actually cover?

Part 1 addresses general information and the controller system's principal characteristics. Part 2 covers equipment requirements and tests. Part 3 defines programming languages and common software elements. Hardware testing and programming-language rules are different scopes.

IEC TR 61131-4 provides user guidelines that help with PLC selection and specification. IEC 61131-5 addresses controller communication aspects and services. Part 4 should not be described simply as “programming examples,” or Part 5 as “operating characteristics.”

IEC 61131-6 concerns functional safety PLCs and their associated peripherals, while IEC 61131-7 concerns fuzzy control programming. Part 6 is not a general fieldbus protocol, and Part 7 does not cover general hardware specifications.

IEC TR 61131-8 provides guidelines for applying and implementing programming languages. IEC 61131-9 covers the SDCI sensor/actuator interface commonly known as IO-Link, and IEC 61131-10 covers the PLCopen XML exchange format. The series is therefore not limited to seven parts.

Communication, distributed control and safety boundaries

IEC 61131-3 includes software features that facilitate communication; it should not be treated as a single document defining every wiring and protocol requirement for a particular network. IEC 61499 is a separate family addressing a function-block architecture for distributed control. IEC 60947 concerns low-voltage switchgear and controlgear.

Using IEC 61131-3 software does not automatically make a system a safety PLC. Safety functions require suitable hardware, a software development process, verification and the relevant application requirements to be assessed together. IEC 61508 and the series' functional safety part help explain this distinction.

Related PLC programming topics

Explore PLC programming languages for language selection, the PLC CPU for execution hardware, PLC programming software for development environments, PLC debugging for commissioning work and differences between PLC brands and models for portability considerations.

Field devices and control applications

Related topics include sensors and NO/NC contacts for understanding input signals, encoders for motion feedback, PID control for regulating a continuously varying quantity and Modbus communication for exchanging data with devices. Language selection should be assessed alongside the electrical and timing characteristics of the connected equipment.

Continue through the programming guide

Visit PLC programming for application approaches and IEC standards for PLCs for the wider standards framework.