An operator listed four faulted conveyor zones off a supervisory screen and asked why they were all down. The tag names did not exist in the controller, the first hypothesis was wrong, and the live read overturned the premise of the question.
The question arrived as four tag names copied off a screen and one sentence: why are all of these faulted? None of those four names existed in the controller.
That is a normal starting point. Supervisory screens are built on aliases that were mapped years earlier by someone else, and the name on the tile is often not the name in the logic.
Reconciling names without guessing
Looking up the four names returned not found, with close matches, rather than a plausible-sounding answer about tags that do not exist. That refusal is what made the rest of the session possible.
The close matches led to the real objects: the jam blocks for those roller zones, instances of the OEM jam-reset instruction, cited to the routines that call them. The screen's fault names are aliases pointing at the zone fault word, not at any tag with that spelling.
Being wrong, and being corrected by evidence
The first hypothesis was a jam or gateway cluster. Four zones going red together on shared infrastructure is a reasonable read.
The operator pushed back with two facts: the jam latch is clear, and the screen flashes like a motor fault.
Tracing the jam-reset instruction settled it. Rung 1 drives the jam latch from exactly one source, the jam bit of the zone fault word:
MDR_JAM_RESET, rung 1
[ ZONE[0..3].FAULT.JAM ] OTE(JAM_LAT)Walking the type chain from the gateway node data down to the fault word exposed the full picture: a thirty-bit word carrying motor bits (over-current, stall, connection error, over-temperature), power and comms bits (bus fault, bus init error, over and under voltage, board over-temperature, tracking error), and one jam bit.
So a motor fault sets a different bit in the same word and leaves the jam latch off. The screen can be red while the jam latch is clear, and the two facts stop contradicting each other.
The live read, and the premise falling over
Connected read-only to the running controller. Found the four zones' node numbers, confirmed all four jam latches false, then read the fault word for all four zones of all four cards. Sixteen structures, all returning good quality.
One active bit in the entire set.
| Screen tile | Node | Live fault bits |
|---|---|---|
| Zone A, card 1 | 4 | none |
| Zone A, card 2 | 5 | none |
| Zone A, card 3 | 6 | none |
| Zone B, card 1 | 10 | Motor connection error, zones 1 and 2 |
Three of the four tiles the operator was looking at have no fault bits set anywhere in the controller. The fourth has a real motor connection error to chase physically, at the roller motor cable and connector.
"All four are faulted" was not true. It took sixteen cited reads at good quality to say that, which is the only acceptable way to contradict the person who is standing in front of the machine.
Two problems, cleanly separated
The operator ended with one physical fault to fix and one supervisory-layer problem to clear: three tiles showing red that the controller flatly contradicts. Either a latched alarm that never cleared, stale data quality, or a binding pointing at the wrong member.
We reported the mismatch and did not assert its cause, because the visualization project was not loaded and the binding could not be proven from the controller side. Naming the mismatch is useful. Guessing at its root cause would not have been.
The trap worth publishing
Early discovery used a raw text search over the export file, which matched the string FLT inside an encoded data block and briefly suggested the screen tags existed after all. They did not. A raw text search over a controller export does not know the difference between logic and a base64 blob.
The structured lookups ignore encoded data, and using them from the start is the difference between a false positive that costs ten minutes and a clean not-found with suggestions. We keep this one in the file because it is exactly the failure mode a general-purpose tool pointed at a large export falls into.
What it did not close
The supervisory side stayed a black box. Without that project loaded, the alias-to-member binding is inferred from the logic rather than proven, and closing out the three stale tiles needs it.
Zone indexing cost an extra round trip. The screen counts zones from one and the controller array counts from zero, and the first live read covered only the first zone, which found the real fault but could not yet prove the other three cards were clean on the other zones. The full sweep did.