Zone 5 is stopped, PE5 is clear, Zone[5].Expecting is 0, and there is a 600 mm carton standing 30 mm short of the beam that no zone on the line is driving. Zone 4 behind it has a carton on its eye, Owns clear, its hold timer done, and every permissive it needs to release – and it will, into the back of the carton zone 5 cannot see. That is the whole fault. Two zones with a working zone ownership handshake between them have ended up with different opinions about one box, and the box is in the 900 mm between the eyes where neither of them can check.
The handshake did not fail. It half-completed, and half is the same as none.
Everything below is on the twelve-zone line from the singulation article, which is where the Owns and Expecting bits come from: a 5069-L320ER CompactLogix, polarised retroreflective 42EF eyes 150 mm back from each discharge into a 5069-IB16, a PowerFlex 525 per zone, 1.5 m pitch, 0.280 m/s, zone logic in a 50 ms periodic task. A zone runs while it owns a carton in transit or is expecting one; a handover completes when the downstream eye makes. The ways that goes wrong, and the one change that removes most of them, are what follows.
The stuck case, read online
Before anything is reset, read the bits. They name the fault.
The call is always the same – “zone 5 has stopped with nothing on it” – and it covers at least six different states, which is why the first move is to go online and read Zone[4].Owns, Zone[5].Expecting, PE4 and PE5 together. Owns set and Expecting set with both eyes clear is a carton the logic released and never saw arrive: it is under the frame, wedged at the transfer, or somebody lifted it off in the blind length, and the transfer timer will say so at 8 s. Owns set with Expecting clear and PE4 blocked is a handover that somebody’s reset cleared from one end only, and zone 4 will hold that carton until the controller is power-cycled. Every bit clear with a carton visibly short of PE5 is the flicker, described next, and it is the dangerous one, because zone 5 reads Ready. Reading four bits takes a minute and it is the difference between fixing the fault and resetting it so it can happen again on the next shift.
Neither zone is wrong about its own eye. They disagree about the carton between the eyes, and the release rule only ever asks about eyes.
The flicker: a handover that completed on one scan
A carton rocks on the transfer, the beam makes for 50 ms, and the handover is done.
Tall cartons rock as their nose drops off zone 4’s last roller onto zone 5’s first, and on this line the nose of a 600 mm carton at 0.280 m/s reaches PE5 5.36 s after it broke PE4. About a quarter of a second before that, a rocking carton’s top corner can tip through the beam and out again, and a 42EF is a 1 ms sensor into a card with a 1 ms filter, so a 50 ms task sees PE5 made for exactly one pass. The handover rule in the singulation article completes on PE5 AND Owns[4]
Owns[4] and Expecting[5] clear, the hold timer on zone 4 starts, and the carton rocks back out of the beam with 30 mm still to travel. Now RunReq[5] is false, because zone 5 neither owns nor expects, and zone 4 has stopped driving because it no longer owns; the carton stands 30 mm short of PE5 on rollers nobody is turning. Zone 5 reads clear and not expecting – Ready – and 850 ms later zone 4’s hold expires and it releases the next carton, which arrives at 0.280 m/s and shoves the standing one onto PE5, at which point zone 5 is occupied by two cartons with one record and the sorter three zones later gets them as a pair. The whole thing was one scan, and nothing in it was a sensor fault.The fix is to qualify the arrival. The beam has to stay made for 100 ms, two task passes, before the handover completes: at 0.280 m/s that is 28 mm of travel, which a carton that has actually arrived does without noticing and a rocking corner never does. The input card’s own filter is not the place for it – 5069-UM004 lets the 5069-IB16 filter run to 50 ms in each direction, but a transition is valid only if the input holds for the whole filter time in both directions, so a 50 ms filter delays every beam clear on the line by 50 ms as well and takes 14 mm off every setback for no reason. A TON on the rung, Arrive[4], preset 100, enabled by PE5 while the boundary is in transit, costs nothing and touches nothing else.
One state per boundary. Owns and Expecting are read out of it every scan, so there is no scan in which zone 4 and zone 5 can hold different opinions.
The zone ownership handshake as one state per boundary, not two bits in two zones
Three of the six stuck cases are the same fault: two writers for one handover.
Owns[4] and Expecting[5] describe one thing, a carton in transit across one boundary, and the moment they are two tags they can be written separately – by the release rung, by the arrival rung, by the jam reset, by the E-stop recovery, by an HMI button somebody added in year two – and any writer that touches one without the other leaves the pair disagreeing. The version that cannot disagree stores one value per boundary, Xfer[4].State: 0 idle, 1 in transit, 2 arrived, 3 lost. Owns[4] is then State = 1, Expecting[5] is the same comparison, both derived every scan and written by nobody, and every event that used to set or clear a bit becomes a transition on the one tag. The release one-shot moves 0 to 1. Arrive[4].DN moves 1 to 2, and the hold timer moves 2 back to 0. The transfer timer moves 1 to 3, and 3 leaves only two ways, both below.
(* ConveyorTask, 50 ms - boundary 4/5, one state, derived bits *)
Zone[4].Owns := Xfer[4].State = 1;
Zone[5].Expecting := Xfer[4].State = 1;
Arrive[4].PRE := 100;
Arrive[4].TimerEnable := PE5 AND (Xfer[4].State = 1);
TONR(Arrive[4]);
IF NOT PE5 THEN Arrive[4].Reset := 1; END_IF; (* a rock clears it before DN *)
IF Xfer[4].State = 1 AND Arrive[4].DN THEN
Xfer[4].State := 2; (* arrived, in one place *)
Xfer[4].XferTmr.Reset := 1;
END_IF;
IF Xfer[4].State = 1 AND Xfer[4].XferTmr.DN THEN
Xfer[4].State := 3; (* lost: alarm, keep driving nothing *)
END_IF;
(* the recovery run: a person pressed Recover, both zones drive again for one transit *)
IF Recover_Run AND Xfer[4].State = 3 THEN
Xfer[4].State := 1;
Xfer[4].XferTmr.ACC := 0;
END_IF;
(* the confirmed clear: only with both eyes clear, only from LOST *)
IF Confirm_Clear[4] AND NOT PE4 AND NOT PE5 AND Xfer[4].State = 3 THEN
Xfer[4].State := 0;
END_IF;
That block is the whole handshake and it is the only place Xfer[4].State is written. The HMI reset that used to clear Expecting[5] now has nothing to clear; it can request Recover_Run or Confirm_Clear, and both are gated on a state, so a button held down or pressed twice does nothing the second time.
Two bits in two zones is a discipline. One state per boundary is a data structure.
The recovery run, which is what restarts the conveyor
A lost carton is a carton the logic could not see. It is not, usually, a carton that is gone.
The transfer timer expires at 8 s – 1.5 m at 0.280 m/s is 5.4 s, times 1.5 – and on this line the carton it alarms on is nearly always still between the eyes: it stopped 30 mm short during a rock, or it was standing in the blind length when the E-stop dropped and the reset routine rebuilt the zones from their eyes and forgot it. The tracking article has the same problem on a belt and answers it with an encoder; on independent zones the answer is to drive. Recover_Run puts the boundary back into transit: both zones run, the transfer timer starts again from zero, and one of two things happens within 8 s. The carton reaches PE5, holds it for 100 ms, and the handover completes exactly as it would have on a good day – no state was invented, the logic just finished what it started. Or the timer expires a second time, and now the alarm is honest: two transits of driving and no beam, so the carton is not between the eyes, and the person at the line uses Confirm_Clear, which only takes with both eyes clear and only from the lost state, because clearing a boundary with a carton on an eye is how the next disagreement starts.
Run first. Clear second, and only after the run found nothing.
What the recovery run must not do is rebuild state from the eyes. The reset in the singulation article – walk the array, set Occupied from PE, clear every Owns and Expecting – is the right thing after a jam that a person has cleared by hand, because at that point what is on the eyes is the truth. It is the wrong thing after an E-stop, because 520-UM001 is clear that Safe Torque Off on its own is a coast-to-stop, so every carton in transit coasted to wherever friction put it, and a rebuild from the eyes declares every one of them in a blind length to be nobody’s. On a full line that can be four cartons. Keep the boundary states through an E-stop – they are ordinary tags and they survive – and let the recovery run finish the transits that were interrupted. The transfer timers need one rung for this: gate XferTmr.TimerEnable on Line_Running as well as the state, or the 8 s expires during the stop and every interrupted transit restarts as lost.
Worked from the line’s geometry. The top trace is the fault; the bottom trace is the same carton with Arrive[4] in the rung, one tenth of a second later and nothing else different.
The two that are not the handshake’s fault
Two of the six stuck states come from somewhere else and look identical.
A release one-shot that fires on the first scan after a mode change: Owns[4] sets with no carton released, and 8 s later the boundary is lost. 1756-RM018 says the ONS storage bit is set true at prescan precisely to prevent an invalid trigger on the first scan, so a release written with an ONS does not do this; a release written as ReleaseReq AND NOT Release_Last with Release_Last left at zero through the mode change does, on every zone whose request happens to be true, at the same moment. The other is the transfer timer running through the E-stop, above. Both show up as lost boundaries with the carton still sitting where it was, and both are found by trending Xfer[4].State across the event that preceded the call rather than reading the bits after it.
The same call on the radio for all six. The bits tell them apart, and three of them disappear when the boundary has one state.
The thing everyone checks first
The eye.
A carton standing short of PE5 with the zone stopped sends the electrician to the eye, and the eye is aligned, the LED is steady, the spare makes no difference, because the eye was never asked the question it got blamed for. It saw the corner of a rocking carton for 50 ms and reported it, which is its job; the rung that turned 50 ms into a completed handover is the fault. Then the drive gets blamed, because zone 5’s PowerFlex 525 shows no run command and that looks like a drive that will not start – it is a drive that was not asked. Trend PE5, Xfer[4].State and RunReq[5] at the task period and the one-scan make is right there, on the day it happens, and it will usually be a product code with a tall carton and a light load, on the transfer with the biggest roller gap.
The eye told the truth for 50 ms. The rung believed it for 850.
Next step
Count Recover_Run presses per boundary per shift and put the count on the same screen as the jam counts from the jam timer article, because a boundary that needs recovering twice a shift has a mechanical reason – a roller gap, a height step at the transfer, a product that rocks – and the recovery run is hiding it. Then look at the boundary states after the next E-stop before anyone presses anything: if every interrupted transit shows lost the moment the line resets, the transfer timers are still running through the stop. The other half of what a stop does to a zone – the drive that needs a new start edge, and the twelve zones that all want to accelerate at once – is a restart problem rather than a handshake problem, and the photo-eye setback decides how far a coasting carton overshoots before the handshake ever sees it.