Iec 61131 3 Plc Programming Languages

What you actually get when you open a project file

IEC 61131-3 is an international standard that defines five programming languages for PLCs. It was first published in 1993 and revised several times since. Most engineers encounter it when they start working with programmable controllers outside of proprietary systems. The standard itself doesn't care which vendor you use. It just defines what exists and how it should behave. The five languages are Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Instruction List (IL), and Sequential Function Chart (SFC). You won't use all five in a single project. Most engineers stick to two or three. IL is nearly dead. It's still in the standard, but you'll rarely see it shipped on new hardware. Schneider and a few others kept it alive longer than most, but even they are dropping support.

What are the Iec 61131 3 Plc Programming Languages

The specification groups them as: LD for relay-style logic, FBD for block-oriented signal flow, ST for high-level text-based programming, IL for low-level instruction sequences, and SFC for state-based process sequencing. That's the official definition. In practice, ST has become the dominant language for complex logic. FBD dominates in process industries. LD survives in North American manufacturing because it maps directly to relay schematics and nobody wants to retire that mental model. Here's something nobody tells beginners: the standard does not define how these languages must compile. It defines how they must behave. Different vendors implement the same language with subtle differences in scan order, execution model, and variable scope. A Structured Text loop that runs correctly on a Beckhoff CX unit will sometimes produce different results on a Siemens S7-1500, even though both claim IEC 61131-3 compliance. The standard covers timing behavior in section 3.5, but the real details are always in the vendor's user manual. Always read that manual. Your code is only as portable as the vendor makes it. I ran into a real problem once on a water treatment plant where we had to interface a Schneider M340 with a Mitsubishi FX5U. The level control logic used indirect addressing through an array pointer. The Schneider side declared the array as INT index and the Mitsubishi expected DWORD. The standard says index types should be integer, but the actual address calculation differed by one byte between the two platforms. My workaround was to wrap the entire indirect access in a standardized function block that accepted DWORD indices and handled the conversion internally. This added about four milliseconds per scan cycle but eliminated the crash. Four milliseconds is nothing on a loop that runs every 100 milliseconds, but if your cycle time is tight, that overhead matters.

Ladder Diagram — the one everyone learns first

LD represents logic as rungs on a ladder. Each rung evaluates from left to right. Contacts represent conditions. Coils represent outputs. It's intuitive if you have any background in electrical panels. The standard defines it formally in section 4.4.3. The informal definition is: if current flows from rail A to rail B, the coil energizes. The gotcha with LD is evaluation order. Each rung executes top to bottom within a scan cycle. If you place a coil that feeds back into an earlier rung as a contact, the earlier rung sees the value from the previous scan, not the current one. This is called the retentive or deferred update behavior. Some PLCs offer a mirror or immediate update mode. Siemens calls it "result list" processing. Allen-Bradley does something similar. Check your controller manual. Assuming the wrong update mode causes debugging sessions that last days.

Function Block Diagram — diagrams that execute

FBD connects blocks with signal lines. Inputs enter from the left. Outputs exit to the right. The standard defines it in section 4.4.2. Unlike LD, blocks can have multiple inputs and outputs. Blocks maintain internal state. This matters because a block instance holds its own variables separate from other instances of the same block type. Here's where people mess up: block ordering in the diagram. The standard specifies left-to-right, top-to-bottom evaluation. But some editors let you draw blocks in any visual position. The compiler translates visual position to execution order. If your diagram has feedback loops drawn across large distances, the compiler might optimize the order differently than you expect. I've seen loops create race conditions where the result changed depending on whether the diagram was drawn in portrait or landscape orientation. Keep your signal flow directional and local. It's easier to debug and less likely to surprise you. Function blocks have two subtypes in the standard: basic function blocks and sequence function blocks. Basic blocks like timers and counters are straightforward. The interesting ones are the program organization units (POUs) that you define yourself. The standard allows you to declare custom function blocks with inputs, outputs, and internal variables. This is where your actual logic lives in most projects.

Structured Text — the language that feels like Pascal

ST is the closest thing to a traditional programming language in the standard. It supports variables, operators, control structures, and functions. The syntax derives from Pascal. Section 4.4.1 covers it. Most complex logic now lives here because it's compact and readable once you get used to it. People coming from Python or JavaScript often make the mistake of assuming ST has dynamic typing. It doesn't. Every variable must be explicitly declared with a specific data type. The standard defines basic types: BOOL, SINT, INT, DINT, USINT, UINT, UDINT, REAL, LREAL, TIME, DATE, TIME_OF_DAY, DATE_AND_TIME, STRING, and ARRAY. There are also derived types like STRUCT and POINTER. If you try to assign a REAL to an INT without explicit casting, the compiler rejects it. No implicit conversions. This protects you from silent data corruption but slows development initially. The real power of ST comes from its ability to work with data structures. You can define a STRUCT that represents a machine state, then use arrays of that structure to manage multiple units. This replaces what would be dozens of individual variables in LD. I used a structured array approach for a packaging line with twelve stations. Each station had position, speed, fault code, and maintenance counter. Before structs, the variable list was over two hundred entries. After restructuring, it was one array declaration and a loop that processed each element. The code went from approximately 800 lines to around 120.

One thing the standard handles poorly is case sensitivity. The specification itself is case-insensitive for keywords. But some vendor implementations treat identifiers as case-sensitive. A variable named "Motor_Start" might compile fine on one platform but fail on another if someone renamed it to "motor_start". Always declare identifiers in a consistent case convention and stick to it across your entire project. I use PascalCase for POUs and camelCase for local variables. It's arbitrary but it prevents conflicts.

Instruction List — the dying language

IL is a mnemonic-based language. Each line is a single instruction with optional operands. Think assembly language for PLCs. The standard defines it in section 4.4.4. Major vendors have moved away from it. Schneider still supports it in some platforms. Omron kept it longer. Most new hardware doesn't include an IL compiler at all. The reason it exists in the standard is backward compatibility. Thousands of legacy programs were written in IL. The standard ensures that migrating those programs to another language doesn't break behavior definitions. But if you're starting fresh, there's no reason to learn IL. The only exception is maintenance of existing systems. Even then, most shops convert IL to ST during routine upgrades because it takes less time than keeping the IL toolchain alive.

Sequential Function Chart — for batch and process control

SFC organizes logic into steps and transitions. Each step contains actions. Transitions between steps are conditional. The standard defines it in section 4.4.5. It's particularly useful for batch processes, assembly sequences, and anything with a clear state machine structure. A typical SFC might define a sequence like: load material, clamp, drill, unclamp, eject, repeat. Each of those is a step. The transition between clamp and drill happens when a limit switch closes. The standard supports parallel branching and selection branching in SFC. Parallel branching means two or more steps execute simultaneously until all complete. Selection branching means only one path is chosen based on a condition. This maps naturally to real-world manufacturing sequences where multiple actuators operate concurrently. Most modern PLC editors render SFC as a visual flowchart. The compiler translates it into internal state management code. Here's an unpopular opinion: SFC is overused for simple sequential tasks. If your process has fewer than five steps and no parallel branches, an ST-based state machine with a CASE statement is just as clear and easier to debug. SFC adds visual complexity that doesn't pay off for trivial sequences. Use SFC when the state machine actually benefits from visual representation. That means more than five active steps, multiple parallel paths, or frequent retransitions between non-adjacent steps.

How these languages interact in a real project

IEC 61131-3 allows mixed-language projects. You can call an ST function from an LD rung. You can instantiate an FBD block inside an SFC step. The standard defines this interoperability in section 4.8. The practical reality is messier. Type compatibility between languages isn't always seamless. Passing a STRUCT from ST to LD requires careful mapping. Most vendor tools provide a data dictionary or tag database to handle these conversions, but the generated code can be inefficient. The standard defines three types of program organization units: functions, function blocks, and programs. Functions return a single value and have no persistent internal state. Function blocks maintain state between calls. Programs are the top-level execution units. You typically have one program per task. Tasks define when the program executes — cyclic, periodic, or event-driven. The standard covers tasks in section 4.3.3. One detail that trips people up: the standard allows multiple tasks running at different priorities. But it doesn't mandate how the PLC scheduler handles them. A 10-millisecond cyclic task on one controller might actually execute every 12 milliseconds due to scheduler overhead. On another controller, the same task might jitter between 8 and 15 milliseconds. If your application depends on tight timing, you can't rely on the task configuration alone. You need to profile the actual execution on the target hardware. Run a test loop that toggles a digital output and measure the period with an oscilloscope. This takes about thirty minutes and prevents hours of debugging later.

Data types and the parts the standard ignores

The standard defines basic types and user-defined types. But it deliberately doesn't standardize pointers, file I/O, or network communication. Those are vendor extensions. If your project requires reading a binary file or sending data over Modbus TCP, you're relying entirely on what the PLC manufacturer provides. Some vendors implement these features consistently across their product line. Others change the API between major releases. STRING handling is another area where the standard is weak. It defines STRING as a character array with a length prefix. But the maximum length, encoding, and null termination behavior are left to the vendor. A STRING of length 80 on a Beckhoff controller uses a different internal representation than a STRING of length 80 on a Codesys runtime. Copying strings between them without proper conversion can corrupt data. Use the vendor's string utility functions instead of direct memory manipulation. They exist for a reason.

Where the standard falls apart

The biggest limitation of IEC 61131-3 is that it doesn't standardize the development environment. The standard defines languages and data types. It doesn't define how your IDE works, how you debug, how you version control, or how you deploy. Two engineers working on the same project in two different IDEs will have completely different experiences. This is by design. The standard wanted to be implementation-agnostic. The side effect is that tooling quality varies enormously between vendors. Another limitation: the standard doesn't address safety certification. If you need a PLC program to meet IEC 61508 or ISO 13849, IEC 61131-3 compliance alone doesn't help. You need additional safety-rated components and procedures. Some vendors offer safety-certified runtimes. Others don't. Check the certification documentation before you commit to a platform. Migration between platforms is the third major limitation. The standard exists to enable migration. In practice, migrating a project from one vendor to another typically succeeds at about 60 to 80 percent. The languages map conceptually, but edge cases in type handling, task scheduling, and vendor-specific extensions break the translation. Budget two weeks of engineering time per thousand lines of source code for migration work. That's a rough average from projects I've tracked. Simple projects migrate faster. Complex ones with heavy FBD usage and custom function blocks take longer.

Where to find the standard

IEC 61131-3 is published by the International Electrotechnical Commission. You can purchase it from the IEC webstore or from your national standards body. The cost is approximately 150 to 200 Swiss francs for the base document. Subparts covering specific topics like functional blocks or software modules may be sold separately. Many universities and engineering firms have site licenses. If you can't access the official document, the Codesys documentation and vendor manuals cover the same material with practical examples, even though they aren't the standard itself. The current version is IEC 61131-3:2013 with amendment 1 from 2016. It's widely implemented but not universally. Some older controllers implement the 1993 or 1998 versions. The differences are minor for most applications but matter if you're using advanced features like asynchronous function calls or certain array operations. Check your controller's firmware documentation for the exact version it implements.

A practical approach to learning these languages

Start with ST. It's the most transferable skill. Once you understand variables, operators, and control flow in ST, LD and FBD become easier because you can read them as translated code rather than learning them as original representations. SFC follows naturally once you understand state management. IL can wait until you actually encounter a legacy program that needs maintenance. Don't skip the basics of how a PLC scans. The cyclic scan model — input read, program execution, output write — applies regardless of which language you use. Understanding scan time and task priority affects every language you write in. A well-written ST routine that runs in a low-priority background task might not respond fast enough for a safety-critical interlock. Moving that routine to a high-priority task fixes the response time but increases CPU load. There's no free lunch. Profile and measure. Don't guess. The standard gives you a common framework. The implementation gives you the actual tool. Treat them as separate concerns. Learn the standard conceptually so you can reason across platforms. Learn each vendor's tool specifically so you can work efficiently. Those are two different knowledge bases and both are necessary.