Large language models can discuss ladder logic convincingly and still get the rung wrong. What it actually takes for AI to read Studio 5000, CODESYS, and the rest of a plant's control logic correctly.
Controls Engineers ask us this question more than any other, usually with a fair amount of skepticism behind it. The short answer is yes, but not the way most people first try it. Pasting an exported routine into a chatbot produces something that reads well and cannot be trusted on a live machine. Getting to answers you can act on takes a different architecture, and it is worth being precise about why.
Why the Obvious Approach Fails
A modern language model has seen plenty of IEC 61131-3 text in training. It knows what an XIC instruction does, it can explain a seal-in circuit, and it will happily walk through a rung you paste into it. Three problems show up the moment you try to use that for real work.
First, the code it needs is not text. A Studio 5000 project is a proprietary format wrapping tags, routines, UDTs, AOIs, and cross-references. A CODESYS project is its own structure. By the time someone has flattened a project into something a chatbot can ingest, the structure that gives the logic its meaning is gone. An output coil matters because of every place its tag is examined, and that lives in the cross-reference, not the rung.
Second, context. A production PLC program is routinely thousands of rungs across dozens of routines, referencing tags defined elsewhere, driven by HMI writes and interlocks from other controllers. No context window holds an operation, and sampling fragments of it produces answers built on fragments.
Third, and this is the disqualifying one: a probabilistic model asked about rung 47 will sometimes describe a rung that does not exist. It will do so fluently. On a machine that can injure someone or scrap a shift of product, an answer that is usually right is not a capability, it is a liability.
The failure mode is not that the model knows nothing about ladder logic. It is that it cannot tell you which of its statements are load-bearing.
What Reading Actually Requires
The conclusion we reached building Nexus is that the reading has to be deterministic and the reasoning can sit on top of it. In practice that means a parser, not a prompt. The project file is parsed into a complete, exact representation: every rung, every tag, every instruction, every cross-reference. Questions about the logic are answered against that representation, and every claim is cited to the specific rung it came from. The same question gets the same answer every time, and the answer can be checked by opening the project at the cited location.
The language model still matters. It is what turns "show me why this valve will not open" into a traversal of interlocks, and turns the result into plain language. But it is reasoning over ground truth it cannot invent, which is a different thing from generating plausible text about code it half remembers.
This division of labor has a pleasant property: the system gets better as models improve, without the correctness of the reading ever depending on them.
The Vendor Problem
Any real plant is a mix. Rockwell on the older lines, a CODESYS-based machine from a European OEM, Ignition or another SCADA layer above it, and documentation scattered around all of it. An approach that only reads one vendor's format answers questions about one corner of the operation.
We handle Studio 5000, Ignition, and the CODESYS family directly, and a PLCopen parser covers the export format used by more than 500 OEM brands. The design rule is that a vendor is a module, not a rewrite. The early connectors this engine was built on are open source under MIT on GitHub, public and auditable, because we do not think industrial engineers should be asked to trust a black box. They are no longer actively maintained, but they show exactly how the reading works.
The Evidence
Claims about reading code should be checkable, so here is what we have measured on real production data rather than synthetic demos:
- 509 real PLC project files from operating plants, parsed with zero parser errors.
- 137 of 137 AI-written program documents graded rung-accurate by three independent Controls Engineers.
Rung-accurate is the standard that matters. Not "a reasonable summary," but every statement about the logic traceable to the rung that makes it true.
What Still Belongs to People
Reading is not judging. A system that can trace every interlock on a valve still does not know that maintenance has a bypass jumper on the third one, or that the right call is to hold the batch. Our position, and the way Nexus ships, is that the system handles recall and correlation across more logic than any person can hold in their head, and the consequential judgment stays with the engineer looking at the machine.
So, can AI read PLC code? Yes, if the reading is deterministic, cited, and cross-vendor, and if nobody pretends the model's fluency is the same thing as its correctness. That is the version we built, and it is running on real floors today.