Plain English to PLC Code: How Natural Language Becomes Verified Ladder and FBD Logic

Every PLC program starts life as plain English. "Start the pump when the tank is low, stop it when it's high, and never run it if the inlet valve is closed" — that sentence, or one like it, is what the process engineer hands over, and turning it into rungs and blocks by hand is most of what PLC programming is. So the obvious question: can the translation itself be automated — can plain English become ladder logic and function block diagrams directly? The answer in 2026 is yes, with one enormous caveat that this post is really about: generated control code is worthless until it is verified, because natural language is ambiguous in exactly the places where control logic must not be.

From Plain English to PLC Code: What the Pipeline Actually Looks Like

A serious English-to-logic pipeline has four stages, and it's worth understanding them even if you never automate anything, because they mirror what a good programmer does in their head:

1. Intent extraction. The sentence above contains three requirements: a start condition (TankLow), a stop condition (TankHigh), and a permissive (InletOpen). It also contains an implied structure — start/stop with two distinct levels means a latch with hysteresis, not a simple AND of conditions. Recognizing that "start when low, stop when high" is a seal-in (or an SR block), not Pump := TankLow, is the difference between a translator and a toy.

2. Formal representation. The intent becomes IEC 61131-3 code — typically Structured Text first, because text is the easiest target for generation:

PROGRAM TankControl
VAR
    TankLow, TankHigh, InletOpen, Pump : BOOL;
END_VAR

Pump := (TankLow OR Pump) AND NOT TankHigh AND InletOpen;
END_PROGRAM

3. Cross-compilation to graphical languages. Because ladder, FBD and ST are three notations for one logic (the founding idea of IEC 61131-3), the ST can be compiled mechanically into rungs and networks — the seal-in becomes the parallel branch, the permissive becomes a series contact, exactly as described in Structured Text to Ladder Logic Converter: How Conversion Actually Works. This stage is deterministic; the uncertainty all lives in stages 1 and 4.

4. Verification. The generated logic is executed against test scenarios and checked against the stated requirements. This is the stage most "AI generates code" demos skip, and it is the only stage that makes the output usable on a machine.

Why Verification Is Not Optional: The Ambiguity Problem

Read the original sentence again: "never run it if the inlet valve is closed." Now answer: if the pump is running and the inlet valve closes, should the pump stop immediately, or finish some cycle? If the valve reopens, should the pump resume on its own, or wait for a fresh start condition? The English doesn't say. A human programmer would (should) ask; a naive generator will silently pick one reading, and the plant will discover which one during commissioning — the most expensive possible moment to find out.

This is the general shape of the problem. Natural language specs are systematically ambiguous about:

• Latching vs. following — "stop when X" rarely says whether the stop is momentary or holds.
• Auto-restart after a fault or permissive loss — almost never stated, always safety-relevant.
• Edge vs. level — "when the button is pressed" could mean either, and they behave very differently across scans.
• Priority — when start and stop are true together, who wins? (SR vs. RS is exactly this choice.)
• Timing words — "briefly", "after a while", "immediately" have no T# value.

So a trustworthy pipeline doesn't just generate — it does two more things. It surfaces its interpretations as explicit, reviewable decisions ("I treated the inlet permissive as non-latching: pump auto-resumes when the valve reopens — change?"). And it proves the behaviour by execution: run the generated logic in a simulator, drive the inputs through the scenarios that matter (valve closes mid-run; both levels true; power-up state), and show the engineer the resulting waveforms rather than asking for trust. Verification by execution also catches the generator's plain mistakes — a mis-mapped variable, an inverted contact — the same way it catches a human's.

What This Looks Like in Practice

This whole pipeline is what our PLC code generator implements: you type the control description in plain English, it produces ST, ladder and FBD views of the same logic in the browser simulator, lists the interpretation decisions it made, and lets you toggle the inputs — or inject a whole test sequence — to watch the behaviour before any of it goes near a real controller. The tank example above generates in seconds; the valuable part is the thirty seconds afterward, closing the inlet valve mid-run and seeing which reading of the spec you got.

Used this way, generation doesn't replace the PLC programmer — it moves their effort from typing rungs to reviewing intent, which is where the effort always belonged. The engineer's job becomes the four questions in the ambiguity list, asked before the logic exists rather than debugged after.

Honest Limits

Plain-English generation today is genuinely good at discrete logic in the size range most machine control lives in: interlocks, sequences, timers, counters, alarms — the material of Ladder Logic for Beginners through to multi-step CASE sequences. It is not the tool for servo motion profiles, safety-rated functions (those belong in certified safety logic with formal review, full stop), or continuous control loops that need tuning against real process dynamics. And no generated program, however verified in simulation, skips commissioning checks against the physical machine — simulation verifies the logic, not the wiring, the sensor calibration, or the mechanical reality.

The right mental model: plain English in, draft logic plus explicit assumptions plus executable evidence out — and an engineer in the loop who reads all three. How that verification step catches genuinely dangerous behaviour before it reaches the plant floor is a big enough subject to deserve its own post: Catching Unsafe PLC Logic Before Commissioning.