A sortation lane had been retired in the warehouse host and pieces of it were still energized: some units faulted, some waiting, some running. The engineer wanted all of it showing not-enabled, least invasive option first, with cited evidence that it would not reach the rest of a large control area.
The lane had been decommissioned weeks earlier in the operations platform. The belts did not know that. The engineer wanted every unit showing solid grey, not faulted and not waiting, and wanted to be sure it would not take neighbors with it.
Finding the bit that turns something off is the easy half of a change like this. The half that decides whether the change actually happens is proving what else that bit touches, on a running area, before anyone flips it. This is a record of the second half.
What the session started with
The inputs were a controller path and a list of units. No tag names, no logic, no drawings, no prior session.
We registered a read-only connection to the running controller, which was in remote run, and worked against its 69 MB full-controller export at the same time. The offline structure tells you where to read. The live values tell you what is true. Neither one on its own answers the question the engineer was actually asking, which is not "how could this be enabled" but "what is enabled right now, and why."
One data-hygiene note, because it cost a few minutes and would cost an unattended tool much more. A sibling export sat in the same folder labelled as the unprotected copy of the same controller. It was 3.8 MB, the exact size of an unrelated safety controller's file, and almost certainly a bad copy. We worked from the full export instead. Any system that reads whatever export it finds nearby will confidently answer from the wrong one.
The whole lane reduces to two bits
Every unit on the lane uses the same standard conveyor instruction, and its enable comes out of the zone start-stop block:
Bypass conveyor routine, rung 1
XIC(ZONE_1B_STSP.A_EN) XIO(BYPASS_1_DRIVE.DS_FLT_LAT) OTE(BYPASS_1.UNIT_EN)Unit enable equals zone enable and no latched drive fault. There is no per-unit in-service configuration bit anywhere in the logic, which is worth stating plainly, because a per-unit switch is the first thing an engineer goes looking for. The grey "not enabled" state the engineer wanted is exactly this unit enable at zero with nothing latched.
Following that pattern across the lane: the four conveyors in the bypass stretch and the motorized roller zones behind them all key off one zone enable. The two takeaway belts key off a second one, in a neighboring area program, at rungs 57 and 58 of its conveyor routine. Two bits, both reading live as true.
Every claim of the form "only this lane uses this bit" came from a complete, untruncated cross-reference rather than a sampled one. That distinction is the whole basis of the recommendation that follows.
Why the host decommission did nothing
The operations platform action had worked. It just did not do what everyone assumed.
Live reads showed the host's lane enable latch false and the corresponding divert enable in the sorter status array false, both set in the sorter interface routine at rung 17. That bit gates routing. It tells the sorter to stop sending product to the lane. It has no relationship to the conveyor motors, which is why the sorter obediently stopped diverting while the belts kept running underneath it.
This is a layering problem and it is common. Routing enable and motor enable are different systems that sound like the same sentence in a meeting. A view that separated the two would have pre-empted the entire question.
Why a manual stop would not have stuck
The obvious workaround, walk over and press stop, fails quietly here.
Tracing the zone enable showed it is an output of the standard start-stop instruction, latched inside that instruction once the auto-hold timer completes and the start bit arrives, and the start bit comes from the plant-wide area start pushbutton. That path is cited at rung 13 in one area program and rung 33 in the other. Every area start re-seals both zones. The lane would come back at the next start of the shift, and nobody would connect the two events.
What the live reads returned
| Live read | Value | What it settled |
|---|---|---|
| Bypass zone enable | true | The lane's roller stretch is enabled right now, not coasting on stale state |
| Takeaway zone enable | true | The takeaway belts answer to a second bit in a neighboring area |
| Three bypass conveyor unit enables | true | Those units were running or waiting, not faulted |
| Both takeaway belt unit enables, command and drive status | false | Two of the units were already down, which is why the lane looked mixed |
| Host lane enable latch | false | The host decommission did land |
| Lane divert enable in the sorter status array | false | And it landed on routing only |
The mixed picture the engineer described, some units faulted, some disabled, some running, some waiting on downstream, stops being a mystery once both layers are on the table. The routing layer had been switched off weeks earlier. The motor layer had never been touched.
Does either bit reach anything outside the lane?
The challenge from the engineer was fair and it is the right challenge: this is a large control area, not just this lane. Are you certain?
The cross-reference on both zone tags returned every reference, untruncated. No motor outside the lane is commanded by either bit, and neither bit gates another zone. That settles containment at the command level.
It does not settle containment at the flow level, and those are different claims. One physical coupling remained: a shared merge conveyor at the end of the lane, onto which the lane does a metered release, cited at rung 8 of the bypass routine. Chasing that conveyor to its owner found it instantiated in the adjacent zone's inbound routine at rung 14, taking the adjacent zone's enable as its run permission. The lane feeds into it as a tributary. Stopping the lane cannot starve or back up the lines it merges with. It only stops contributing to them.
That is the difference between "the command is contained" and "the flow is contained." The second one is what the engineer actually needed, and it only surfaced because they pushed.
The options, least invasive to most
| Option | What it does | Reversibility | Verdict |
|---|---|---|---|
| Operator zone stop on both zones | Drops both zones from the panel | Immediate | Instant and reversible, but re-seals on the next area start |
| Disable the two zone enable bits | Holds both zones not-enabled in software | Immediate | Durable, reversible, surgical. The path taken |
| Online edit adding a maintained decommission interlock breaking the start permissive on both zones | Removes the start path entirely | By further edit | Permanent and change-controlled. More than this situation called for |
| Module inhibit or lockout | Cuts the cards off | Physical | Produces red comms faults, not the grey state that was asked for, and risks faulting neighbors that share the roller gateway and the network master |
Option two keeps all I/O, gateways, and safety live, so nothing propagates outward. That is the property that makes a software enable the surgical choice here and makes the module-level options the wrong tool for a cosmetic-sounding request. The same reasoning appears in the OEE lanes that were already switched off, where the cross-reference talked an engineer out of the bigger bit rather than into it.
Where each claim is written
| Claim | Citation |
|---|---|
| Unit enable is zone enable and no latched drive fault | Bypass conveyor routine, rung 1 |
| The two takeaway belts key off the second zone enable | Takeaway conveyor routine, rungs 57 and 58 |
| Each zone re-seals its enable on every area start | Bypass area start/stop rung 13, takeaway area start/stop rung 33 |
| The host decommission cleared the divert enable only | Sorter interface routine, rung 17 |
| The lane does a metered release onto the shared merge conveyor | Bypass conveyor routine, rung 8 |
| That merge conveyor belongs to the adjacent zone | Adjacent zone inbound routine, rung 14 |
Six citations, each checkable by the engineer in their own editor in under a minute. That is the point of citing rungs rather than summarizing them, and it is what the deterministic engine behind Nexus exists to produce.
What closed it
The engineer disabled both zone enable bits and reported back: every listed unit turned solid grey, exactly the requested state. The diagnosis held end to end on a running production controller, with zero writes from the engine.
Naming the two bits took one search and a cross-reference. The step that decided whether the change happened was the blast radius answer, and specifically the merge ownership trace. "Are you sure this will not hit other lines" answered with an untruncated reference list is a different kind of answer than the same question answered with reassurance. An engineer can verify the first one before touching a running area, and should refuse to accept anything less.