Large language models can discuss ladder logic convincingly and still get the rung wrong. What it actually takes for AI to read Studio 5000, TIA Portal, 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, add-on instructions, and cross-references. A TIA Portal project is a different proprietary format with its own conventions, and a CODESYS project is its own structure again. By the time someone has flattened any of them into something a chatbot can ingest, the structure that gives the logic its meaning is gone.
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. The exports we work against run to 69, 112, and 168 megabytes for a single controller. 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 are answered against that representation, every claim is cited to the rung it came from, and the answer can be checked by opening the project at the cited location.
Four properties of that reading do the actual work, and each one has a field session behind it.
The cross-reference is where meaning lives. An output coil matters because of every place its tag is examined. An engineer looking for the signal that permits an upstream conveyor to feed got his answer partly from the rung that writes it, and mostly from a cross-reference showing exactly one reference to that tag in the entire project. Written here, read nowhere else. That is what a hardwired discrete output to another controller looks like from inside the logic, and it is not visible in the rung. The same operation, run in the other direction, is what proved a proposed change safe: before a decommissioned lane was taken out of service, an untruncated cross-reference on both governing bits showed no motor outside the lane is commanded by either one. Both are written up: a cross-controller feed permit and decommissioned in the host, still running on the floor.
Reading has to reach inside the instruction bodies. Most of what a site wants to know is not in the routine anyone opens first. An engineer asked how a conveyor's OEE state is calculated and pasted the structured text he was reading, and it was the wrong layer. That routine only calls three OEM add-on instructions, among 148 in the export. The state machine, the precedence chain, and the rule that separates blocked from faulted all live inside those bodies. The rule turned out to be a single alarm-code threshold that nothing on the screen expresses. See reading an OEE state machine out of a vendor instruction body.
Not-found has to be a real answer. An operator once handed us four tag names copied off a supervisory screen. None of them existed in the controller. A system willing to produce a plausible-sounding answer about tags that do not exist would have burned the session; returning not-found with close matches is what led to the real objects behind the screen aliases. In the same session, a raw text search over the export matched the string FLT inside an encoded data block and briefly suggested those names existed after all. A text search does not know the difference between logic and a base64 blob. Structured lookups do. That is four faults on the screen, one in the controller.
Reading code is not reading state. This one catches experienced people. A controller export carries the project file's last stored offline values, not what the controller holds at the moment of export. On one investigation, values read live at 2:57 PM disagreed with an export pulled at 3:14 PM in a way that was physically impossible, because release counters only go up. An analyst trusting that column would have gone off to fix a ratio setting that was never wrong. Any honest system has to know which artifact an answer came from and say so.
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. It is reasoning over ground truth it cannot invent, which is a different thing from generating plausible text about code it half remembers. That split 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 Siemens cell dropped in by an integrator, 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 and RSLogix 5000, Siemens TIA Portal and STEP 7, Ignition, and the CODESYS family directly, and a PLCopen parser covers the export format used by more than 500 OEM brands. That list is deliberate on both ends: the current IDEs and the legacy ones still running most of the plants we walk into. 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. Those foundational connectors are no longer actively maintained, and the tooling built today stays in-house, but they still 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.
- 4,386 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. The method is in generating PLC documentation with AI.
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 Reading Still Cannot Do
Reading is not judging, and it is not omniscient either. Comprehension stops at the boundary of what is in the corpus. In the OEE session, the service that computes the availability percentages could be named from a comment inside an instruction and not read, because it sits above the controller. In a ghost fault investigation the export could prove a jam block was declared and never driven, and could not prove the zone was physically dead, which are two different claims. Roughly half the operator-facing abbreviations on one line had no confirmed expansion for that site, and the correct behavior was to flag them and tell the reader to ask a site expert rather than invent plausible ones.
And 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. The way Nexus ships, 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. That boundary is one of our four research directions, not an afterthought.
So, can AI read PLC code? Yes, if the reading is deterministic, cited, and cross vendor, if the system knows which artifact each answer came from, 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.