PLC Programming: Which Language for Which Industrial Process

When commissioning an automated system, the discussion about the PLC almost always revolves around the brand and model: Siemens or Rockwell, S7-1500 or ControlLogix. Rarely does anyone ask what programming language the code will be written in and why.

It’s a question that seems technical—one you’d ask a programmer. In reality, it’s a design decision with consequences that last as long as the system itself: ten, twenty years. The wrong programming language doesn’t cause errors during testing. It causes them when the original programmer is no longer around, when the machine stops at midnight, and someone has to figure out what’s going on by reading code they don’t recognize.

The IEC 61131-3 standard defines five programming languages for programmable logic controllers. They are not interchangeable. Each one models a specific type of industrial logic—and each process has a temporal and causal structure that is best suited to one of them.

This article explains how to approach this decision, starting with the process rather than the language.

A programmable logic controller (commonly referred to as a PLC) is the “brain” of an industrial automation system. It receives signals from sensors, executes control logic, and sends commands to actuators. It does this in continuous cycles, often in the order of milliseconds.

But you don’t program the PLC itself; you program the PLC using a language. And that choice remains in the code throughout the system’s entire life cycle.

The problem is that in Italy, PLC programming is still treated as a specialized skill reserved for a select few trusted technicians. When those technicians change companies, retire, or are simply unavailable, the system becomes a mystery. No one knows anymore what that block of instructions does, why that variable is named that way, or what happens when that bit goes to 1.

This isn’t a documentation issue ; it’s a language issue. Code written in the wrong language for a given process is difficult to read, even for those familiar with it. Code written with the project in mind is almost self-explanatory because the program’s structure mirrors the structure of the process.

The IEC 61131-3 standard, published by the International Electrotechnical Commission and updated in its third edition in 2013, standardized five languages precisely for this reason: because different processes have different logics, and each logic has a language that is best suited to represent it.

The IEC 61131-3 standard defines four text-based and graphical languages, plus one coordination language:

All major development environments support these languages: Siemens TIA Portal (S7-1200, S7-1500), Rockwell Studio 5000 (ControlLogix, CompactLogix), Schneider EcoStruxure Machine Expert (Modicon). The choice of language is independent of the choice of PLC manufacturer.

A copper or aluminum wire drawing line follows a defined sequence: loading the wire rod, tensioning the wire, passing it through the die, cooling, and winding it onto the coil. Each stage has precise input conditions (Is the wire taut? Is the die at the correct temperature? Is the coil ready?) and equally well-defined output conditions.

This is the perfect structure for a Sequential Function Chart. The program mirrors the process: each SFC step corresponds to an operational phase, and each transition corresponds to a verifiable physical condition. Reading the code is equivalent to reading the process flowchart.

In the case of a multi-wire line, where multiple wires are drawn in parallel on concentric rings, state management becomes more complex but remains sequential: each wire has its own SFC, and a coordinating SFC manages the dependencies. This would be difficult to implement in Ladder in a readable way: sequential logic in LD requires status bits, timers, and interlocking conditions that, beyond a certain level of complexity, become impossible to follow without additional documentation.

Experience with wire drawing systems (such as projects involving roughing machines and processing lines in the metals industry) shows that unscheduled maintenance often requires pausing and resuming specific phases of the cycle. The SFC allows this natively: you can pause a step, handle the exception, and resume from the exact point.

A plastic extruder has a completely different design. The process is continuous: the screw rotates, the material is melted and pushed through the die. The critical variables are the temperature in each barrel zone, material pressure, extrusion speed, and conveyor belt speed.

These variables are continuous, not binary. There are no “on” and “off” states: there is a setpoint of 230°C, a measured temperature of 228°C, and a deviation that the PID controller must correct. The ladder diagram is not the right place to write this logic: while it is possible to implement a PID in a ladder diagram, the graphical representation using contacts is designed for Boolean logic, not for continuous control.

The Function Block Diagram is the natural language for this type of process. A PID block, with its inputs (setpoint, measured value, parameters) and outputs (control signal to the heater), is immediately understandable even to those who did not write the code. The blocks are connected to one another just as signals are connected in P&IDs: the flow is visible.

Structured Text comes into play for managing recipes, as well as temperature, speed, and pressure settings for different materials (PE, PP, PA, PVC). A recipe is a data structure, and data structures are best managed in a text-based language using arrays, loops, and structured memory access.

The combination of FBD for continuous control and ST for data management is the de facto standard in mid-range and high-end plastic extrusion systems.

Packaging machines operate in a batch mode: they perform fast, repetitive cycles. A vertical packaging machine completes dozens of cycles per minute, each consisting of just a few steps (opening the pouch, filling, sealing, cutting, and ejecting). The logic is relatively simple, and the cycle speed is high.

In this context, the ladder diagram works well and continues to work well for maintenance technicians who are familiar with electrical engineering but not with object-oriented programming. The Ladder Diagram mirrors the logic of old relay schematics: it is easy to read without any computer science background, and it is directly related to the hardware and electrical systems.

However, integrated robotics adds a level of complexity that Ladder struggles to handle. Coordination between axes, kinematic calculations, trajectory management, and interfacing with industrial robots (Fanuc, KUKA, ABB via dedicated protocols) require Structured Text: FOR loops to iterate over arrays of positions, mathematical functions for coordinate transformations, and exception handling with explicit control structures.

In projects that combine packaging machines and robotic cells—which are becoming increasingly common in the food, pharmaceutical, and logistics sectors—the most effective choice is a hybrid approach: LD for the mechanical logic of the machine, and ST for coordination with the robots and management of product recipes.

The safety of a system is governed by different rules. The IEC 62061 and EN ISO 13849 standards define the safety integrity levels (SIL) and performance levels (PL) required for safety functions based on a risk analysis.

Safety PLCs (F-PLCs, Fail-safe PLCs) such as the Siemens S7-1500F with TIA Portal Safety, Allen-Bradley GuardLogix with Studio 5000 Logix Designer, or Pilz PSS 4000 manage safety logic in separate, certified environments. The safety code is written in languages approved by certification bodies (TÜV, Bureau Veritas), which in most cases are a limited subset of LD or FBD that is not fully ST-compliant.

The reason is clear: the safety logic must be verifiable, auditable, and easy to inspect. Structured Text that is full of nested loops and complex functions is not easily verifiable, and the certifier knows this. Ladder logic, however limited, has an inherent readability that makes it suitable for safety reviews.

This means that in a system where standard logic and safety logic coexist, the programmer often has to work in two different environments and two different languages, even when technically it would be possible to do everything in just one.

The choice of programming language does not occur in a vacuum. The PLC is not an isolated system: it communicates with sensors, actuators, drives, HMIs, and other systems via the fieldbus, which is the plant’s industrial communication network.

The fieldbus has a greater influence on the choice of PLC (and vice versa) than one might think. The main protocols in use are:

The choice of fieldbus determines which devices can be connected, with what latency, and with what level of diagnostics. A wire drawing system with Siemens drives and an S7-1500 PLC will operate in a Profinet ecosystem; a system with Beckhoff servo axes and complex motion control will use EtherCAT, and the programmer will almost certainly write code in ST using TwinCAT.

Unfortunately, we often find ourselves performing maintenance on systems that have problems we could never have imagined at the outset. This is where the difference between a junior programmer and a company with years of experience becomes clear. Our experience in design allows us to see the process and the project in its entirety—and even beyond, anticipating the possible variables that may arise over time.

A system programmed in Ladder with 3,000 rungs isn’t a system that malfunctions. It works, passes testing, and goes into production. The problem arises twelve months later, when a sensor sends an unexpected signal and no one can figure out in time where to look in the code.

Or five years later, when the company decides to add a step to the process and the original programmer—the one who knew how the logic was structured—can no longer be reached.

The IEC 61131-3 standard is not a list of equivalent options. It is a set of different tools for different tasks. Using the right tool not only improves the result but also reduces the time required for any future work on the system.

In complex industrial automation projects, the cost of software is often underestimated compared to that of hardware. But it is the software that determines how easily the system can be maintained, adapted, and improved over time. That is where a large part of the TCO—the total cost of ownership—of a production line comes into play.