OEE Was Counting Four Lanes That Were Switched Off

This one has two acts, because the problem changed underneath it. Act one is a metric question answered offline. Act two is what happened when the goal shifted from hiding the lines to physically stopping them, and the engineer's obvious next move did not work.

Act one: find the right switch, then prove it is the right switch

Against a 168 MB full-controller export, the structure came back quickly. Every lane in the OEE routine is a self-contained block wrapped in a single gate:

IF DSTK_1_Enable THEN
    ... alarm build ...
    OEE_ALARM(...)
    DSTK_1_Status.inRunning := ZONE_1A_STSP.A_EN;
    DSTK_1_Status.inStopped := NOT DSTK_1_Status.inRunning;
    OEE_STATE(...)
END_IF

Two findings fell out of that block.

The per-lane enable is the intended switch. Clearing it stops the lane's alarm build, its running and stopped states, and its OEE manager calls from updating. It has no effect at all on conveyor motion.

The running signal is not a motion signal. inRunning reads the zone run-enable bit. Not a motor, not a photo eye, not throughput. All four target lanes read the same zone bit. That is precisely why lines that were physically off kept reporting available: the zone was still enabled to run, so as far as the metric was concerned, so were they.

The engineer then asked the right question, the one that makes this a safety-relevant change rather than a config edit: does that zone bit only cover these four destackers, or will dropping it shut off more of the area?

The full cross-reference returned fifteen references, untruncated:

So the answer was explicit: do not touch the zone bit. It governs the entire merge zone, and a fifth OEE lane rides on it. The four per-lane enables are the only lever that touches exactly the four requested lanes and nothing else.

The engineer cleared the four enables and reported back. The lanes dropped out of OEE, with no effect on the zone or the adjacent lines.

Act two: "I dropped the zone enable and the belts still run"

The metric was fixed and the real problem reasserted itself. Downstream was off, product was trapped, and the lines needed to physically stop. The engineer dropped the zone enable anyway, hit the blast radius they had been warned about, and the belts kept moving.

At that point we connected to the running controller, read-only, and worked through it live.

The disable held. The zone enable read false, the start bit false, the stop bit true, the start permissive false, and the auto-hold timer sitting at zero accumulated. Nothing was re-driving the enable. The change had taken.

The controller is commanding the whole zone off. Every unit enable in the zone read false. The merge drive read false on both its command and its running feedback. No jam latched.

The command path is healthy. The roller gateway fault bit and all three network master comm faults read false. This mattered, because "a comm fault is holding the cards in their last state" is the natural second guess, and it was disproved rather than assumed. The controller can reach the cards. It is telling them to stop.

So the motion is below the command layer. These are motorized roller cards running their own local photo-eye and accumulation logic. Every unit's charge-enable was still true. The cards were draining trapped product, which is what they are designed to do, independent of whether the controller has given the zone permission to run.

And energy management will not sleep them. The sleep instruction is the one path that issues a distinct command to the cards, and it is gated on all zone photo eyes being clear. Live, the photo-eye clear bit read false, because product was sitting on the line. Sleep mode was dormant with its timer at zero.

A bigger enable would not have helped. The engineer's next instinct was to drop an area or system enable instead. Tracing it out, every enable above the zone feeds the same command chain that was already at zero. Dropping a higher one only reasserts the stop that is already being sent. It cannot reach the rollers by a different route.

That left two effective levers, and both are physical: clear the product so the zone sleeps itself, or remove power to the roller segment under lockout. The engine diagnosed. The engineer decided.

Why act two is the more useful half

Act one is a good offline win. It found the lever, and more importantly it found the lever the engineer should not pull, with a complete cited cross-reference behind that judgment.

Act two is the part offline analysis could not have reached. Two intuitive hypotheses, that the change did not stick and that a bigger enable will catch it, both felt right and were both wrong. A handful of live reads disproved them and relocated the root cause to a layer below the controller. Without that, the next step is a sequence of progressively larger enables being dropped on a production line, which is exactly the wrong direction.

It also documents a conveyor pattern worth carrying to other sites: motorized roller zones run on local logic and drain product independent of the run enable. The zone and area enables remove permission, not motion. When downstream is off and product is trapped, the cards keep indexing until the line clears, sleep engages, or power is removed.

What it did not close

The card layer itself is below what either the export or the tag reads can see. We can prove the controller commands stop and the network path is healthy, and from that conclude the cards are running locally. That is a deduction from complete evidence, not a direct read of a card-level run bit, and it was presented that way.

Act one also ran with no live connection, against an export several months old. The structural recommendation was sound, but confirming the current state of those bits still needed the engineer at the panel. The live half of act two is what closed that loop.

One more, on the honest side: the OEE platform semantics were inferred. "Clearing this enable removes the lane from the metric" follows from the routine structure, and the outcome confirmed it, but how the lane renders on the dashboard lives in a layer above the controller that the engine could not see.