PLC programming languages are the set defined by the international standard IEC 61131-3: Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, and Sequential Function Chart. Three are graphical and two are textual, and most modern controllers let you mix several in one project, picking the right language for each part of the job.

The reason there are five, not one, is that a PLC does several very different kinds of work, and no single notation is best at all of them. Boolean interlocks read cleanly as ladder. Reusable device control reads cleanly as function blocks. Loops, math, and string handling read cleanly as text. This guide walks each language, shows the same logic written two ways, and gives a plain rule for choosing. For the hardware underneath, start with what a PLC is; this is the software side of that same machine.

What is IEC 61131-3?

It is the international standard that defines how PLCs are programmed. Published and maintained by the International Electrotechnical Commission, IEC 61131-3 is the third part of the broader IEC 61131 family, and it standardizes the programming languages, data types, and software model that controllers from different makers share. Before it, every vendor had its own dialect; the standard gave the industry a common vocabulary, so an engineer who knows Structured Text on one platform can read it on another.

One update worth knowing: the standard has evolved. Historically it defined five languages, and that is still how the industry talks and how nearly every installed controller behaves. The 2025 fourth edition of the standard deprecated Instruction List, treating it as a legacy language on its way out (IEC 61131-3). Plenty of controllers still ship IL support, so you will meet it in the field for years, but if you are learning today, spend your time on the other four.

The five IEC 61131-3 languages, graphical and textual One standard, five languages IEC 61131-3 the standard GRAPHICAL Ladder Diagram (LD) Function Block (FBD) Sequential Function Chart TEXTUAL Structured Text (ST) Instruction List (IL) deprecated in the 2025 edition Most controllers let you mix languages in one project, the right tool per task.
IEC 61131-3 defines five languages, three graphical, two textual, and controllers mix them freely.

What are the five languages, and what is each good at?

Each language earns its place on a different kind of logic.

LanguageTypeReads likeBest for
Ladder Diagram (LD)GraphicalRelay wiring diagramInterlocks, start/stop, permissives
Function Block (FBD)GraphicalSignal-flow schematicAnalog, PID loops, reusable devices
Structured Text (ST)TextualPascal-like codeMath, recipes, data handling, algorithms
Sequential Function Chart (SFC)GraphicalFlowchart of stepsBatch phases, sequences, state machines
Instruction List (IL)TextualAssembly codeLegacy compact logic (deprecated)

What does the same logic look like in two languages?

The clearest way to feel the difference is to write one simple rule, run a motor when Start is pressed and Stop is not, two ways. In ladder it is a rung of contacts and a coil. In Structured Text it is one line that reads almost like English. Neither is more correct; they suit different readers and different problems.

Same logic: Ladder Diagram versus Structured Text One rule, two languages LADDER DIAGRAM Start Stop M contacts → coil STRUCTURED TEXT IF Start AND NOT Stop THEN Motor := TRUE; Ladder reads like the wiring; Structured Text reads like a sentence. Pick the notation that fits the logic and the people who maintain it.
The same motor rule as a ladder rung and as one line of Structured Text, different readers, different strengths.

How does Sequential Function Chart organize a process?

SFC breaks a job into steps (things the machine is doing) and transitions (the conditions that move it to the next step). It is the natural fit for anything that runs as a sequence, a clean-in-place cycle, a batch recipe, a start-up routine, because the chart mirrors how an operator would describe the process out loud: fill, then heat, then hold, then drain. Inside each step, you drop in ladder, function blocks, or structured text to do the actual work.

A Sequential Function Chart of a simple batch Steps and transitions STEP 1 · IDLE STEP 2 · FILL STEP 3 · HEAT + HOLD STEP 4 · DRAIN start pressed level reached time & temp met empty → back to idle
An SFC reads like an operator describing the job: each step waits for a transition condition before the next begins.

How do you choose a language for a task?

You do not pick one language for the whole program; you pick per function. Here is the working rule of thumb most integrators use:

  1. Default interlocks and safety-adjacent logic to Ladder. If maintenance will troubleshoot it live at 3 a.m., ladder's readability wins. Start/stop, permissives, and simple discrete logic belong here.
  2. Use Function Block for analog and reusable devices. PID loops, signal scaling, and any “valve” or “motor” object you will instantiate many times read best as wired blocks and stay consistent everywhere they appear.
  3. Reach for Structured Text when logic gets mathematical. Calculations, recipe parameters, array and string handling, and complex decisions that would become an unreadable wall of rungs are far cleaner as a few lines of ST.
  4. Structure sequences with SFC. Batch phases, start-up and shutdown routines, and state machines get a clear backbone from SFC, with the other languages filling in each step.
  5. Leave Instruction List alone for new work. It is deprecated in the standard. Maintain it where it exists, but do not start new programs in it.
  6. Match the language to the people, not just the problem. The best notation is the one your team can maintain. A clever Structured Text routine no one else can read is a liability the day its author is on vacation.

Consistency matters more than cleverness. A plant where every line follows the same language conventions is a plant where any technician can walk up to any machine and troubleshoot it, which is the whole point of a standard in the first place.

Graphical or textual: which should you learn first?

If you are starting out, learn Ladder Diagram first and Structured Text second. Ladder is where you will spend most of your early troubleshooting time, because it dominates the discrete logic on real floors and because reading a rung teaches you how the scan actually evaluates logic. Once ladder feels natural, Structured Text is the language that pays off next: it is close enough to ordinary programming that the skill transfers, and it handles the math, data, and recipe logic that ladder makes painful.

Function Block and SFC are worth learning as soon as you meet a problem that calls for them, a process loop, a multi-phase sequence, rather than in the abstract. The trap to avoid is treating language choice as a matter of taste or resume-building. A program that mixes five notations because the author enjoyed each one is harder to maintain than a disciplined program that uses two languages well. The standard exists to make code portable and readable; the point is a plant where any technician can walk up to any machine and follow the logic, not a showcase of technique.

How does this connect to the rest of the plant?

Whatever language a program is written in, it is producing the same thing underneath: tag values that describe what the machine is doing. Those tags, running, faulted, at temperature, part count, are the raw material for everything above the control layer, from SCADA screens to machine monitoring and analytics. You do not have to change a line of ladder or structured text to read them; a gateway subscribes to the tags the program already exposes. That read-only tap is the least invasive way into the data most plants are sitting on, and the standard first move in any IIoT or smart factory effort. It is also where a layer like Harmony connects, reading from the controllers you already run, no rip-and-replace (see the platform).

By the numbers

The anchor fact: IEC 61131-3 is the international standard, maintained by the International Electrotechnical Commission, that defines the PLC programming languages the whole industry shares (IEC 61131-3; IEC). It defined five languages, Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, and Sequential Function Chart, and the 2025 fourth edition deprecated Instruction List, leaving four in active use while the installed base keeps running all five. When a controller vendor claims “IEC 61131-3 compliance,” this is the standard they mean.

Learn the four that matter, keep ladder for the logic maintenance will read, and let each function pick its own language. For the machine that runs this code, see what a PLC is and for how classic PLCs compare with the more PC-like controllers now on the market, read PLC vs PAC.