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.
We connected to the running controller read-only and worked against its full 69 MB export at the same time. The offline structure tells you where to read. The live values tell you what is true.
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:
AREA_44 / MC_Bypass, rung 1
XIC(ZONE_1B_STSP.A_EN) XIO(BYPASS_1_DRIVE.FAULT_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. 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 bypass stretch and its roller zones all key off one zone enable, and the two takeaway belts key off a second one in a neighboring area. Two bits, both reading live as true.
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 divert enable false, set in the sorter interface routine. 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.
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 start-stop instruction, latched once the auto-hold timer completes, and the start comes from the area-wide start pushbutton. Every area start re-seals the zone. The lane would come back on the next start of the shift, and nobody would connect the two events.
Blast radius, which is the part the engineer pushed on
The challenge was fair: this is a large control area, not just this lane. Are you certain?
The cross-reference on both zone tags returned every reference, untruncated, and no motor outside the lane is commanded by either bit. Neither bit gates another zone.
That left one physical coupling. A shared merge conveyor sits at the end of the lane, and the lane does a metered release onto it. Chasing that conveyor to its owner showed it belongs to the adjacent zone, not this one, and 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.
The recommendation, least invasive to most
- 01Operator zone stop on both zones. Instant and reversible, but re-seals on the next area start.
- 02Disable the two zone enable bits. Durable, reversible, surgical. This is the path taken.
- 03An online edit adding a maintained decommission interlock that breaks the start permissive for both zones. Permanent and change-controlled.
- 04Module inhibit or lockout. Most invasive, and it produces red comms faults rather than the grey state that was asked for, with a real risk of faulting neighbors that share the roller gateway and network master.
Option two keeps all I/O, gateways, and safety live, so nothing propagates outward. The engineer disabled both bits and reported back: every listed unit turned solid grey, exactly the requested state.
Which step actually mattered
Naming the two bits took one search and a cross-reference. The step that decided whether the change happened was the second one: answering "are you sure this will not hit other lines" with an untruncated reference list rather than reassurance. That is the answer an engineer can check in their own editor before touching a running area, and it is the one they should refuse to accept without citations.
What it did not close
The engine is read-only by design here. It diagnosed, it recommended, and a human made the change. That is the correct boundary for a running plant, and it does mean the loop closes on the engineer rather than the tool.
Two smaller edges. Live reads of instruction-internal operands came back unusable, because they were addressed by their bare names inside the instruction rather than through their instance path, so part of the live annotation degraded to undetermined even though the offline structure carried the explanation. And the mapping from unit enable at zero to solid grey on the screen is the standard convention, confirmed by the outcome, but the actual color rule lives in the visualization project, which the engine could not read. It said so rather than asserting it.