PLC-LadderHow PLC-Ladder turns plain English into IEC 61131-3 logic you can trust: the AI drafts, a strict compiler validates, and nothing ships until you approve it.
"AI generates. The compiler validates. The human approves."
That sentence is the whole architecture of PLC-Ladder, and this post explains why each of the three parts exists — and why removing any one of them would make the other two dangerous. If you've been skeptical of AI writing control logic, good: that skepticism is the design brief we built against.
Why generation alone is not a product
Ask any language model for ladder logic and it will produce something that looks plausible. Looking plausible is the problem. A requirement like "stop the conveyor when the part reaches the sensor" hides at least four decisions: which edge of the sensor signal? What happens if Stop is pressed during the dwell? What happens after E-Stop is released? What state does everything take on power-up? An AI that silently picks answers to those questions hasn't saved you work — it has buried decisions you'll excavate during commissioning, which is the most expensive dig site in automation. Most commissioning rework starts as an assumption nobody wrote down.
So in PLC-Ladder, the AI's job is deliberately narrow: it drafts IEC 61131-3 Structured Text, and it writes down every assumption it made, as a list you read — "Added EStop — not in your request." "Assumed 3 s dwell." "Sensor treated as a rising edge." The draft is a proposal. The assumptions list is the real deliverable: it is the conversation your team would otherwise have at FAT, moved to the day the requirement was typed.
What the compiler actually refuses
The second stage is a deterministic compiler that accepts a strict subset of IEC 61131-3 and rejects everything else with a line number. Timers (TON/TOF), counters (CTU/CTD), edge detection (R_TRIG/F_TRIG), SR/RS latches and SET/RESET coils, comparators, integer and real arithmetic, user function blocks, located variables, initial values, RETAIN — that subset compiles. FOR and WHILE loops, arrays, CASE, strings, SFC do not: the compiler refuses them, with a reason, on purpose. A small language you can fully check beats a big one you can only mostly check.
The important rule sits between the stages: nothing the compiler rejected is ever shown to you as a program. A draft that fails gets repaired and re-checked — up to four rounds — and a draft that can't be repaired is withheld, not prettied up. The AI proposes; the compiler disposes. You never review code that doesn't compile, which means your review time goes where machines can't help: is this the right logic, not is this valid logic.
Why the human stays in charge
What you see at the end is a review card: the program rendered as ladder and function block diagrams, a before/after diff if you're changing existing logic, and the assumptions list. Nothing is saved until you click Approve. This isn't ceremony. The compiler proves the program is well-formed; it cannot know that your plant's stop philosophy requires reset-dominant latches, or that the "3 s dwell" assumption is wrong for the heavy variant of the part. Those are engineering judgments, and the product is built so they are made by an engineer, visibly, every time.
Approval is also where the requirements start working for you. Each requirement becomes a scenario test — a table of time, inputs and expected outputs — that re-runs on every change, and a later draft that breaks one is held back. A true story from a bottle-filling exam program shows why this matters: the counter could never count, because of scan order — the logic read a value before the rung that wrote it. The program looked right on the page and compiled cleanly. A requirement test ("after three bottles, the batch output goes on") catches it in seconds, because tests execute the scan cycle instead of admiring the diagram.
From approved draft to your HMI
Once approved, the logic runs in the browser's scan-cycle simulator — run, step, force inputs, watch timers accumulate, power-cycle to check your RETAIN variables. One click exposes the running simulation as an OPC UA endpoint with per-session credentials, so Ignition, FactoryTalk View, WinCC or UaExpert can drive the same compiled logic from the screens your operators will use. Inputs can be forced from the HMI; outputs are read-only. It is always a simulation, never a live PLC — that boundary is by design, and it's also why the two-hand start exercise or a Stop-during-dwell scenario can be tested as aggressively as you like.
When you're done, verified Structured Text exports today. Vendor formats — Rockwell L5X, Siemens, CODESYS, PLCopen XML — are built but locked until each is validated round-trip in the vendor's own tool; until that evidence exists we say "in validation," not "supported." (Rockwell .L5X import, as a what-converted-and-why audit, is in private beta.) And the standing rule under all of it: a qualified engineer approves and validates the logic for the actual equipment. The product drafts and checks; it does not sign.
The honest comparison
Vendor copilots exist — Siemens and Rockwell are both building AI into their suites — and they're locked to one vendor's stack, with verification living in separate tools. Browser simulators exist, and they simulate whatever you bring but don't generate or check it. The gap PLC-Ladder occupies is the AND: generation and compiler-checking in one loop, vendor-neutral. Whether that's the right trade for your work is exactly the kind of judgment the product leaves to you.
Here's the concrete way to find out: take the requirement from your last FAT rework — the one that turned out to hide a decision — paste it into plcladder.com, and read the assumptions list before you look at the rungs. If the assumption that bit you is on that list, you've just moved that argument from the plant floor to a browser tab.