Can AI write PLC code? Yes, it can draft IEC 61131-3 logic that compiles and behaves as described, but only reliably when something checks the output before an engineer sees it. A model on its own produces plausible code with subtle defects. A model inside a loop of compile, static analysis and repair produces drafts worth reviewing. Neither replaces testing or engineering judgement.
The research agrees. The LLM4PLC study found that general models such as GPT-4 struggled to produce valid PLC programs alone, and that adding grammar checks, compilers and verification in a loop raised the generation success rate from 47% to 72%. The verification, not the model, did most of the work.
Why AI-generated PLC code goes wrong
Models learned to program mostly from general software, which runs top to bottom once. A PLC scans forever: it reads inputs into an image, solves the program in order, then writes outputs. Generated code that ignores this gets edges, latches and restarts wrong.
The classic example is the motor seal-in. Asked for a start/stop circuit, a model will often write the holding branch with only the motor's own contact and forget the stop condition in series. The motor latches on and the stop button does nothing. It looks right on screen and it is a defect, which is exactly the failure the LADX Chat page singles out.
How the generate, compile, check and repair loop works
- Generate. The model drafts the logic from a description, given the project's existing tags so it does not invent new ones.
- Compile. The draft goes through a real IEC 61131-3 compiler. If it does not build, it is rejected.
- Static analysis. A checker looks for problems a compiler accepts: uninitialised variables, unreachable code, unused variables, recursion.
- Schema check. The program structure is validated against the PLCopen XML schema, so the file is well formed, not just the syntax.
- Repair. Any failure goes back to the model with the tool's own error messages attached, and it tries again.
- Show. Only a draft that passes every stage is shown to the engineer.
The open tools inside the loop
matiec, the IEC 61131-3 compiler
matiec is an open-source compiler for IEC 61131-3. Its iec2c translator turns Structured Text, Instruction List and Sequential Function Chart into equivalent ANSI C. In a validation loop it acts as the first gate: types must match, every variable must be declared and every statement must parse.
iec-checker, the static analyser
iec-checker reads Structured Text and PLCopen XML and runs 26 checks from the PLCopen software construction guidelines, for example that variables are initialised before use and that program units never call themselves. It also finds unreachable code and unused variables. These are the bugs a compiler lets through and a reviewer misses at four in the afternoon.
PLCopen XML and IEC 61131-10
PLCopen XML began as the PLCopen TC6 exchange format and was published by the IEC as IEC 61131-10 in April 2019. It can carry a whole project in all five IEC 61131-3 languages, including the graphical layout of ladder and function block diagrams. Holding logic in this form is what lets one program be written out to several vendors' formats.
What is an AI Code Generator? LLM Coding, Productivity, & Risk
IBM Technology
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeWhat the loop proves, and what it does not
| Check | Catches | Cannot catch |
|---|---|---|
| Compiler (matiec) | Syntax, type and declaration errors | Wrong logic that is valid code |
| Static analysis (iec-checker) | Uninitialised variables, dead code, recursion, guideline breaches | Whether the sequence matches the machine |
| Schema (PLCopen XML) | Malformed structure | Behaviour of any kind |
| Simulation (scan-accurate) | Sequence, timing and edge faults against forced inputs | Wiring faults, wrong devices, real process dynamics |
| Engineer review and FAT | Fitness for the process and the hazard | Nothing is caught without test cases |
A compiler proves code is valid, not that it is correct. After the loop, run the draft in a scan-accurate simulator with normal, fault and restart cases. LADX Monitor does this on the same engine as the editor, and saves the run as a record you can attach to a factory acceptance test. Then an engineer who understands the process reviews it, and it goes through FAT and SAT like any other code.
A worked example: conveyor with a guard interlock
Ask for 'a conveyor that starts on a start button, stops on a normally closed stop button and only runs while the guard is closed'. A typical unchecked draft has three problems: the seal-in branch bypasses the stop button, the guard contact is placed only on the start branch so opening the guard does not stop a running conveyor, and the run lamp is driven from a tag that does not exist in the project.
In a validation loop the undeclared tag fails compilation and is fixed in the repair pass. The other two compile perfectly, so only a test finds them: force the stop input while running and the output stays on; open the guard while running and nothing happens. That is why simulation sits after the compiler, never instead of it.
Does the model matter?
Less than you would think. With validation in the loop, a small free model is usually good enough, because a failed attempt costs a retry rather than an engineer's time. A larger model reduces the number of retries. What matters more is the context it receives: the tag list, the target platform and a precise description, which is why a written functional specification pays off twice.
Next step
Try the loop yourself in the LADX browser editor, read the LADX product brief, or see how the group's industrial AI practice supports controls teams. If you want the code written for you, send us the scope.
