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 sixteen read-only reads overturned the premise of the question.
Four tag names copied off a supervisory screen, pasted in with one sentence: why are all of these faulted?
No controller named, no program, no routine. Four names, and none of them existed in the controller.
That is a normal starting point rather than a bad one. Supervisory screens are built on aliases someone mapped years earlier, and the name on the tile is usually not the name in the logic. The method worth watching here is what happens next: reconcile the names against the real objects before answering anything, then let the running controller settle the question, including when it contradicts the person standing in front of the machine.
Reconciling four screen names that do not exist in the controller
Looking up each of the four names returned not found, with close matches, rather than a plausible sounding answer about tags that were never there. That refusal is what made the rest of the session possible. An engine that guesses at this point produces a fluent paragraph about four objects that do not exist, and the operator has no way to tell.
The close matches led to the real objects: the jam blocks for those roller zones, instances of the OEM jam-reset instruction. Each one came back cited to where it is declared and where it is called, three call sites for the first of them, spread across the OEE program, rung 26 of a lights and horns routine, and rung 5 of a bypass routine.
So the screen's fault names are aliases onto the zone fault word. There is no tag with that spelling in the controller, and the operator was never going to find one by searching.
Being wrong, and being corrected by the operator
The first hypothesis was a jam or a gateway cluster. Four zones going red together on shared infrastructure is a reasonable read. It was also wrong.
The operator pushed back with two facts from the floor: the jam latch is clear, and the screen flashes the way it does for a motor fault.
Those two facts only contradict each other if the tile and the latch are driven by the same bit. Tracing rung 1 of the jam-reset instruction settled that:
MDR_JAM_RESET, rung 1
[ ZONE[0..3].FAULT.JAM ] OTE(JAM_LAT)The latch mirrors exactly one bit. Every other fault the zone can raise leaves it off.
What the zone fault word actually carries
Walking the type chain from the gateway node data down through the card node and its parameters to the fault word exposed the rest of it. Thirty bits, of which the jam bit is one member among many.
| Group | Bits carried in the word | Effect on the jam latch |
|---|---|---|
| Motor | MTR_OVR_CUR, STALL_ERR, MTR_CON_ERR, MTR_OVR_TEMP | None. Tile goes red, latch stays clear |
| Power and comms | CAN_FLT, CAN_INIT_ERR, OVER_48V, UNDER_48V, BRD_OVR_TEMP, TRK_ERR, FRM_EE_ERR | None. Tile goes red, latch stays clear |
| Jam | JAM | The only bit that drives it |
That is the whole reconciliation. A motor fault sets a different bit in the same word the tile is aliased to, the screen goes red, and the jam latch never moves. The operator's two facts stopped contradicting each other, and the question narrowed to which of the four cards actually had a bit set right now.
The sweep: sixteen fault structures, read-only
Answering that needs the running controller. The offline export says where to read. It cannot say what is true at 10:40 on a Thursday.
The connection was read-only, to a controller with its keyswitch in REMOTE RUN, and the sweep ran in three passes.
- 01Read the node input on each of the four jam blocks, to find where the cards sit on the roller gateway. Nodes 4, 5 and 6 for the first three, node 10 for the fourth.
- 02Read all four jam latches. All false, good quality. Not a jam, now confirmed live rather than inferred from a rung.
- 03Read the fault word for all four zones of all four cards. Sixteen structures, every one returning good quality.
One active bit in the entire set.
| Screen tile | Gateway node | Zone structures read | Active fault bits |
|---|---|---|---|
| Zone A, card 1 | 4 | 4 | None |
| Zone A, card 2 | 5 | 4 | None |
| Zone A, card 3 | 6 | 4 | None |
| Zone B, card 1 | 10 | 4 | MTR_CON_ERR, zones 1 and 2 |
Three of the four tiles the operator was looking at have no fault bit set anywhere in the controller, on any zone of the card. The fourth has a motor connection error on two of its four zones, which is a physical thing to chase at the roller motor cable and connector.
"All four are faulted" was not true. It took sixteen cited reads at good quality to say so, which is the only acceptable way to contradict the person standing in front of the machine. Every interaction was a read. No writes, no forces, no edits, on a controller in RUN, which is the same read-only path used to scope a decommissioned lane down to two enable bits.
What each read ruled out
The value of the session is not the one bit at the end. It is that each step closed off a branch, and the branches were closed in an order that never required trusting the tool's judgment over the evidence.
| Observation | What it ruled out | What it left |
|---|---|---|
| Four screen names not found, close matches returned | The names being controller tags at all | Supervisory aliases onto the zone fault word |
| Jam latch driven by the jam bit alone, rung 1 | The tile and the latch being one signal | A non-jam bit in the same word |
| All four jam latches false, live | A jam, and with it the shared gateway theory | The motor, power and comms bits |
| Fault word clean on three cards across every zone, good quality | Those three tiles reflecting controller state | A mismatch above the controller |
| Motor connection error on two zones of the fourth card | A purely supervisory explanation for that tile | A physical fault at the motor cable |
Two problems, cleanly separated
The operator finished with one physical fault to fix and one supervisory problem to clear: three tiles showing red that the controller flatly contradicts.
We reported the mismatch and stopped there. The visualization project was not loaded, so the binding from alias to member is inferred from the logic rather than proven, and three candidate causes stay open. They have different owners and different tests.
| Candidate cause | What would confirm it | Where it lives |
|---|---|---|
| An alarm raised in the supervisory layer that never cleared | Alarm history showing a raise with no matching clear | Alarm server |
| Stale or bad data quality on the alias | The item's quality flag, read at the server rather than at the tile | Data bridge |
| The alias bound to the wrong member of the fault word | The configured address compared against the zone fault word | Graphics configuration |
Those are the same three layers a ghost fault on another conveyor had to be cleared out of one at a time, and the reason the fix there needed a window rather than a delete. Naming the mismatch is useful. Guessing which of the three it is would not have been.
The shape recurs. A screen that blames the wrong party is the same failure that let a palletizer report waiting on its host for five hours while the controller was the side rejecting the work. In both cases the controller held the answer in a tag and nothing surfaced it.
Minutes against an estimated shift
The session itself ran in minutes. The comparison people want is against the same triage done by hand, and we do not have a measured one. Nobody ran a control, and there is no stopwatch on the manual path.
The basis for the estimate is the work it replaces. An engineer starts from four names that return nothing in a tag search, has to find that they are aliases, has to locate the gateway and four node numbers, and then has to open each card's fault structure in an online editor and read four zones apiece, sixteen in all, on a line that is down while they do it. We estimate that as a shift of chasing, and we call it an estimate rather than a result.
Where both sides were actually measured, it was a different question on a different controller: a cross-controller feed permit traced in twenty seconds against eight minutes by hand. That one is a timing. This one is a judgment.
The trap worth publishing
Early discovery reached for a raw text search over the export file instead of the structured lookups. It matched the literal string FLTS inside an encoded data block and briefly suggested the screen tags existed after all. They did not.
The export is 69 MB and carries source protected routines whose bodies are stored encoded. A text search matches inside them and reports a hit with no idea whether it found logic or a base64 blob. The structured lookups skip encoded data entirely, which is the difference between a false positive that costs ten minutes and a clean not-found with suggestions.
It stays in the file because it produced the only wrong answer of the session, and because it is the first failure mode a general purpose tool pointed at a large export falls into.