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 against an offline export. 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.

The method on display is not "find the tag." It is the check that runs before the change: what else reads this bit, and what stops if I clear it. Act one produced the right lever in one search. The part worth the session was proving which lever the engineer should not pull.

What the engineer asked, and what they did not supply

The first message named one example lane and one symptom. Find the bit keeping this lane in a running and available state, these lines are off, we need to disable OEE for them. Then the four real targets. Then, on challenge, the question that reshaped the answer.

No tag names, no routine names, no logic. The engine was given four lane labels and a controller.

The corpus was a single offline export of that whole controller, 168 MB, taken close to four months before the session. There was no live connection in act one, and that was stated to the engineer before any recommendation, because it bounds what the answer can cover. Structure was current. Bit values were not.

Finding the per-lane switch in a 168 MB export

A logic search on the one lane the engineer named returned that lane's block in the OEE routine, written in structured text. Every lane in the routine turned out to be 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

One block gives the shape. Two broader searches generalized it, one across every _Status.inRunning assignment and one across every per-lane enable, and a scoped search on the zone family pinned the four targets: four gates at lines 21970, 22041, 22112 and 22183 of the OEE routine, each wrapping its own lane, all four driving inRunning from the same zone bit. The example lane the engineer opened with sat at line 22936 on the identical pattern.

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, and it has no effect at all on conveyor motion.

The second finding explains the symptom. 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. The zone was still enabled to run, so as far as the metric was concerned, so were four lanes that were switched off at the floor. A companion study on a different controller hit the same class of thing from the other direction: an OEE state machine where "running" means the zone is permitted to run, and an empty belt scores exactly the same as a full one.

What else reads this bit?

The engineer pushed back with the question that turns a config edit into a safety-relevant change. Does that zone bit only cover these four destackers, or will dropping it shut off more of the area?

The cross-reference returned fifteen references, untruncated:

Ten of the fifteen are live control logic, spread across rungs 2 through 34 of the merge routine. Forcing that bit off stops the entire merge zone, drive included. That is an order of magnitude more than four destackers.

The fifth OEE lane is the quieter half of the answer. A lane outside the request rides the same enable, so the shortcut would also have pulled a fifth line out of the metric with nobody looking for it. Cross-references are the only way that shows up. Nobody finds a fifth consumer by reading the routine they were already reading.

So the recommendation was explicit. Do not touch the zone bit. 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 four lanes dropped out of OEE, with no effect on the zone or the adjacent lines. The engine wrote nothing, at any point in either act. It is read-only by design, and the change belonged to the engineer to make and to own. That division is the whole shape of how the system ships.

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 opened a read-only connection to the running controller and worked through it live.

The structural trace came first. The zone enable is an output of the zone's start and stop instruction, latched at rung 10 of the instruction body once the auto-hold start timer completes. The actual trigger sits at the call site, rung 8: the start comes from the area start pushbutton and the local cabinet start pushbutton, held up by a start permissive that ANDs the area's ok-to-run bit, two safety device bits, a not-in-energy-management condition, and gateway health.

That trace answers a question the engineer had not asked yet. A stop pressed at the local station will not stick on its own, because the area-wide start pushbutton is one of the two things that re-arms this zone.

Fourteen live reads, and what each one settled

The first five rows kill the natural first hypothesis, that the change did not stick or something re-sealed the enable behind the engineer's back. It stuck.

The comm rows kill the natural second hypothesis, and they matter more than they look. "A comm fault is holding the cards in their last commanded state" is exactly the kind of explanation that sounds right, gets accepted, and sends someone to check network hardware for an hour. It was disproved rather than assumed. The controller can reach the cards. It is telling them to stop.

Why a bigger enable would not have helped

The engineer's next instinct was to drop an area or system enable instead. Traced out, every enable above the zone resolves into the same command chain, and that chain was already at zero. Dropping a higher enable only reasserts a stop that is already being sent. It cannot reach the rollers by a different route.

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

One path does issue a distinct command to the cards. The energy management sleep, at rung 2 of the energy management routine, is gated on every zone photo eye being clear and the cabinet being on. Live, the photo-eye clear bit read false because product was sitting on the line, and the sleep timer sat at zero. Sleep cannot arm while the zone is occupied, which is the correct design and also the reason the zone would not quiet itself.

That left two effective levers, both physical. Clear the product so the zone sleeps itself, or remove power from the roller segment under lockout. The engine diagnosed. The engineer decided.

What travels to other sites

Two patterns here are not local to this floor.

An OEE running signal wired to a zone enable rather than to product movement will over-report availability on every lane it feeds, permanently, and it will do it silently because the number never looks broken. It looks like a line that is up more than you thought.

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. An operator watching belts move after a confirmed disable will reasonably conclude the disable failed, and will reasonably escalate to a larger enable, which is the wrong direction on a production line.

Two smaller method notes came out of the same session. An early attempt to read the export directly by byte offset landed in a configuration data blob rather than in source, so every citation in this study came from the structured logic index instead. And names on a screen are not always tags: four of the unit names the engineer supplied came back as not found, because they are sub-conveyors under a card rather than standalone unit objects, and instruction-internal operands would not resolve by bare name either, only fully qualified. Both would cost a manual investigation real time, and the second one can end in a confident wrong conclusion about what exists.

Why act two is the more useful half

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

Act two is the part offline analysis could not reach. Two intuitive hypotheses, that the change did not stick and that a bigger enable will catch it, both felt right and were both wrong. Fourteen 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 running line while product sits on it.