Most AI troubleshooting tools were designed for a demo, not a down line. What fault diagnosis actually requires, where AI genuinely helps, and the failure modes that only show up against a real controller.
A line is down, the fault on the HMI says almost nothing, and the person who knew this machine's habits retired in March. That is the situation AI troubleshooting tools claim to help with, and some of that claim holds up while some of it does not. We have spent the last few years finding out which is which by running our system, Nexus, against real production controllers. Here is where the line actually sits, with the field sessions that put it there.
What Troubleshooting Actually Is
Strip away the tooling and PLC troubleshooting is a search problem under time pressure. The symptom is visible: a stalled conveyor, a valve that will not open, an alarm that keeps returning. The cause is buried somewhere in thousands of rungs, the live tag values, the interlock chain from an upstream machine, a change someone made two years ago, or a sensor drifting out of spec.
What the skilled engineer is doing is recall and correlation. Which rung drives this output, what else examines that tag, what changed, what does this pattern usually mean on this machine. The work is mostly bounded. In one session an engineer knew only that a 24 V output told an upstream conveyor it was safe to feed, and did not know the tag, the routine, or the conditions. The answer was fully determined by the export in front of him: one output instruction, four permissives inside the drive instruction body, and a cross-reference proving nothing else in the project reads that tag. He had been searching for eight or nine minutes by hand and had not finished. Traced, it came back in about twenty seconds with a rung reference on every claim. That session is written up in full as a cross-controller feed permit traced in 20 seconds.
The harder shape is the fault that never announces itself. A robotic palletizing cell sat stopped for over five hours reading "waiting on a host assignment" while the host was healthy and dispatching work the controller silently rejected. Not one bit was set in any of the cell's five alarm words, because the message was a plain output coil rather than a fault. There was nothing to search for. There was only a chain to follow, and it ran through the export, the live values, and one physical observation on the floor. The write-up is two stacked root causes behind a five-hour palletizer stop.
Where AI Genuinely Helps
The wins are narrower than the marketing and more useful than the skepticism expects.
| Capability | What it looks like on a floor |
|---|---|
| Tracing | Walking backward from a misbehaving output through every condition that gates it, across routines, instruction bodies, and controller boundaries, in seconds rather than an afternoon of cross-referencing |
| Correlation | Reading supervisory data and control logic as one picture instead of three windows and one person's short-term memory |
| Recall | Surfacing the machine manual, the OEM drawings, and the last three work orders on this asset at 2 a.m. with a line down |
| Explanation | Answering "why did this trip" in plain language, cited to the rung, so a newer technician can act without ten years of tribal knowledge |
Tracing is the one people underestimate. When an engineer wanted four destacker lanes pulled out of an OEE metric, finding the per-lane switch took a single search. The part that mattered was the untruncated cross-reference proving the other candidate bit commands ten units across the whole merge zone, which turned "flip this bit" into "do not flip this bit, here is the list." That is in OEE was counting four lanes that were switched off.
Notice what is not in the table. The system does not decide whether to restart the line, and it does not override an interlock.
The useful question is not "can AI fix my machine." It is "can it put the cause in front of a person fast enough to matter, with evidence attached."
The Failure Modes a Demo Never Shows
This is the section a skeptical Controls Engineer should read first, because these are the ways a plausible tool produces a confident wrong answer against real plant data.
Text search does not know what it is reading. In one session, early discovery ran a raw string search over a controller export and matched FLT inside an encoded data block, which briefly suggested the supervisory screen's tag names existed in the controller. They did not. A false positive like that costs ten minutes if you catch it and the rest of the session if you do not. Structured lookups ignore encoded data and return a clean not-found with close matches instead, which is what made the rest of that investigation possible. See four faults on the screen, one in the controller.
An offline export does not contain live state. A controller export carries the project file's last stored offline values, not what the controller holds right now. On a merge investigation we read live values at 2:57 PM and pulled an export at 3:14 PM, and the export's release counters were smaller than the live ones taken seventeen minutes earlier. Counters only go up. Every conclusion an analyst would draw from that column was wrong, and each one was wrong in a plausible direction: a ratio reading 3:1 when the controller was set to 4:1, an override reading active when it was inactive. The full comparison is in eliminating the code on a merge releasing in slugs.
The screen and the controller disagree more often than anyone admits. An operator listed four faulted zones off a supervisory screen. Sixteen cited live reads found one active fault bit in the entire set. Three of those tiles were red against a controller that flatly contradicted them. Contradicting the person standing at the machine is only defensible with receipts, which is the whole argument for citations.
A tool that reasons over the wrong artifact fails in exactly these three ways, and none of them appear in a demo environment where the export is fresh, the tags are clean, and the screen agrees with the logic.
The Constraints a Real Plant Imposes
Answers must be exact and reproducible. A probabilistic guess about which rung caused a trip is worse than no answer, because chasing a hallucinated cause costs real downtime. Nexus is built as a deterministic engine: the logic is parsed completely, every answer is cited to the rung, and the same question returns the same answer. We validated the reading on 4,386 real PLC project files with zero parser errors, because the whole approach collapses if the reading is approximate. The longer argument is in can AI read PLC code.
It has to run where the plant runs. Defense, utilities, and pharma will not ship control logic to someone's cloud, and plenty of floors have no route out anyway. There is a smaller version of this problem that shows up constantly: a site wanting a starvation alert whose number lived in a cloud analytics stack nobody could get API access to. Every term in that formula turned out to be a controller tag or a known constant, so it was rebuilt on premise from eighteen tags. That is reproducing a cloud starvation metric locally. On premise and air gap capable is the default shape for the same reason.
It has to read what is actually installed. Real plants are cross vendor. Studio 5000 next to a CODESYS machine under an Ignition SCADA layer is a normal Tuesday, and the logic that matters is often sealed inside OEM add-on instructions rather than the routine anyone opens first. A tool that reads one vendor's format diagnoses one fraction of your downtime.
Where the System Stops
Our research position is that the division of labor should be explicit: the system handles recall and correlation, people keep the consequential judgment. That is not a disclaimer, it is the shipping behavior. Across the field sessions above, the engine held read-only connections and wrote zero tags. A human disabled the two zone enable bits that took a decommissioned lane out of service. A site Controls Engineer, not the engine, wrote the palletizer counts back to empty. Diagnosis you can verify travels further than action you have to trust, and it is what dividing the work between people and AI actually looks like in practice.
What to Ask Any Vendor
The questions that separate substance from demo are short. Can it cite the rung, not just name a plausible cause? Is the answer reproducible? Does it know the difference between an offline export and a live read, and will it tell you which one it used? Does it run on premise? What was it validated on, and was that real production data or a synthetic benchmark? Who graded the output, and would they sign their name to it?
For our part, the program documentation Nexus writes was graded rung-accurate on 137 of 137 documents by three independent Controls Engineers, and we publish that number because it is the kind we would demand from anyone else. The method behind it is in generating PLC documentation with AI, and the wider question of what a system should be trusted to do sits in our research on operational intelligence.
AI does not replace the engineer standing at the panel. Done properly, it hands that engineer in seconds the picture that used to take the shift to assemble. That difference shows up in downtime, which is the only benchmark a plant actually cares about.