A pusher divert with its trigger eye 1.20 m upstream and a 2780 ms delay in the program was diverting 97% of the 600 mm cartons and 61% of the 300 mm totes, and every tote it missed was hit on its back corner and spun onto the takeaway sideways. The 2780 ms was right for the carton. It was 300 ms late for the tote, because a delay counted from the nose breaking the beam has half the product’s own length in it, and the tote’s half-length had never been put in. Divert timing comes right when three numbers are right: the lead distance from the trigger eye to the paddle centre, the actuator delay from the output going true to the paddle actually touching product, and the half-length of the product being diverted. Time from the eye is a stand-in for belt position, and it stops being a good one the moment the belt speed or the product mix changes. Track position instead, and put the decision for each carton in a queue at the eye. Everything below is the takeaway after the merge in the priority rule article: a 5069-L320ER CompactLogix, a polarised retroreflective 42EF as the trigger eye into a 5069-IB16, a pneumatic pusher with a 400 mm paddle driven from a 5069-OB16, the takeaway at 0.500 m/s with an incremental encoder on the tail pulley, and the divert logic in a 20 ms periodic task.
Three numbers, and only one of them is on the drawing.
The three numbers behind divert timing, and where each comes from
The lead distance is on the drawing, and it is the only one of the three numbers that is.
From the beam of PE_D to the centreline of the paddle is 1.20 m, measured with a tape after the sensor bracket was tightened. At 0.500 m/s the carton nose takes 2.40 s to travel it – but the paddle has to land on the carton’s centre, not its nose, so the distance that matters is the lead plus half the product: 1.50 m for a 600 mm carton, 3.00 s; 1.35 m for a 300 mm tote, 2.70 s. That 300 ms difference is the whole of the tote problem, and it is the number a single fixed delay cannot carry. The actuator delay is not on any drawing and has to be measured. On this pusher the valve is a 24 V DC solenoid on a 5/2 spool, the cylinder is 300 mm stroke at 6 bar, and a reed switch on the extend end of the cylinder shows the paddle reaching the belt 180 ms after the output goes true, with 20 ms of spread across fifty operations. Put the output bit and the reed switch in one trend at the task period and read it off – the number is different on every pusher, it lengthens as the air supply sags on a Friday afternoon, and it is the reason a divert that was set up in the morning starts clipping corners by the end of the shift.
The paddle is 400 mm wide and the carton 600, so the paddle can land anywhere within 100 mm of the carton’s centre and still push it square. At 0.500 m/s that is a window 400 ms wide, and 300 ms of it is eaten by treating a tote like a carton.
Then the detection and output path, which is small and worth knowing anyway. The 42EF retroreflective is rated at 1 ms in 42EF-TD001, the 5069-IB16 default input filter is 1 ms per 5069-UM004, the task is 20 ms and the output connection RPI is 20 ms, so the worst case from the beam breaking to the output module switching is about 42 ms; on the 50 ms task the zone logic uses it would be 72 ms, and the divert has its own faster task for exactly that reason. The valve’s own pull-in is inside the 180 ms already, because the reed switch was measured from the output bit. So the fire point for a 600 mm carton is 3.00 s minus 0.18 s minus 0.04 s: 2.78 s after the nose breaks the beam, which as a belt position is 1.39 m of travel. For the tote it is 2.70 minus the same 0.22: 2.48 s, and a program with one number in it cannot fire at both. The 2780 ms in the program had been found at commissioning by watching cartons, which is a fair way to find it and the reason it was right for cartons and for nothing else. On a tote the paddle lands at 2.96 s with the tote’s centre already 150 mm past it, and a 400 mm paddle landing 150 mm behind the centre of a 300 mm tote touches only its back 50 mm. That is the corner hit, and it is not a sensor.
Fire early by the actuator delay and the path, so the paddle lands when the centre is opposite it. The window for a 600 mm carton is 2.80 to 3.20 s; the paddle lands at 2.96.
Why time from the eye is the wrong variable
Because the belt does not always run at 0.500 m/s, and the program does not know when it is not. A takeaway drive on a PowerFlex 525 with a speed reference from a potentiometer, or from an HMI setpoint that maintenance nudges when the palletiser is slow, moves the fire point without touching the program. At 0.450 m/s the 600 mm carton’s centre reaches the paddle at 3.33 s, the paddle fires at 2.78 s and lands at 2.96, 150 mm early, and the carton is hit on its front quarter and spins. The forty-one misses in the hour after a belt change in the figure below are that, and every one of them was logged as a sensor fault. An encoder on the tail pulley turns the question from when into where: fire when the belt has moved 1.39 m since the nose broke the beam, and the speed drops out of the arithmetic altogether. The encoder on a high-speed counter input is the hardware side; on this line it is 500 pulses per revolution on a 160 mm pulley, 1.0 mm per pulse near enough, read as a DINT that the divert logic differences.
Speed comes out of the arithmetic and product length goes into it. Those are the two changes.
The queue: more than one carton between the eye and the paddle
With 1.20 m of lead and cartons arriving nose to tail at 1.07 m pitch off the merge, there are two cartons between PE_D
PE_D – the scanner has already read it, the sort logic knows whether it goes to the reject lane – and that decision has to travel with the carton, not sit in a bit that the next carton overwrites 2.1 s later. So the eye loads a queue: on the rising edge of PE_D, an FFL puts the belt position at which this carton’s centre will be opposite the paddle into Divert_Q, and a carton that is not being diverted puts nothing in. The fire rung compares the current belt position against the head of the queue, fires when the belt is 120 mm short of it – the 180 ms actuator plus the 42 ms path at 0.500 m/s is 111 mm, rounded up – holds the output for the dwell, and an FFU takes the entry off when the dwell ends. The FIFO instruction pair does the bookkeeping; what matters is that every carton carries its own fire position, computed from its own measured length at the moment it was seen.(* DivertTask, 20 ms periodic. Belt_mm is the encoder count in mm, free-running. *)
IF PE_D AND NOT PE_D_Last THEN (* nose breaks the beam *)
IF Sort_Reject THEN
FirePos := Belt_mm + 1200 + (Track[1].Len_mm / 2); (* lead + half the product *)
FFL(FirePos, Divert_Q[0], Divert_Q_Ctl, 8, 0);
END_IF;
END_IF;
PE_D_Last := PE_D;
(* fire early by the actuator delay and the path: 222 ms at 0.5 m/s = 111 mm, rounded up *)
Fire := NOT Divert_Q_Ctl.EM AND (Belt_mm >= Divert_Q[0] - 120);
Dwell.PRE := 400;
Dwell.TimerEnable := Divert_Out;
TONR(Dwell);
IF Fire AND NOT Divert_Out THEN
Divert_Out := 1; Dwell.Reset := 1;
END_IF;
IF Dwell.DN THEN
Divert_Out := 0;
FFU(Divert_Q[0], Done_Pos, Divert_Q_Ctl, 8, 0);
END_IF;
The queue is what lets two cartons be in flight at once. The GEQ fires on position, so the belt speed is not in the rung.
The queue length of 8 is a limit, not a target, and Divert_Q_Ctl.DN going true is an alarm.
The dwell, and the carton behind
The paddle has to stay out long enough to push the carton clear, and go home before the next one arrives. Four hundred milliseconds of dwell was found by trend rather than arithmetic: at 300 ms a 600 mm carton was left with its tail on the takeaway edge, at 400 it was clear on every one of fifty tries, and 500 clipped the nose of the following carton twice in the same fifty. Retract is another 200 ms on this cylinder, so from the output going true the paddle is back home 180 plus 400 plus 200 – 780 ms – later, and in that time the belt moves 390 mm. The next carton’s nose must not reach the paddle inside that, which sets the minimum pitch between diverted cartons at 390 mm plus the paddle’s 400 mm width plus the tolerance: call it 900 mm nose to nose, and the merge upstream delivers 1070 mm at its tightest. That is a margin of one carton length in six, which is why the takeaway runs at 0.500 m/s and not the 0.280 of the feeds – the gap the speed step opens at the merge is the gap the divert needs here.
Slow the takeaway and the dwell has to shrink with it, or the paddle catches the carton behind.
What it did over a shift
Same line, consecutive days, counted at the reject-lane confirm eye against the sort decision. The tote row is the length term; the belt-change row is the speed term.
The five remaining misses were all in the same ten minutes and coincided with a compressor changeover, which is the actuator delay term moving, and the trend of the reed switch against the output showed it at 260 ms during that window. That one is not a program problem.
A pressure regulator, not a rung, and the reed switch trend is what proved it.
The thing everyone checks first
The eye, and then the valve.
A divert that misses sends people to PE_D, and the eye gets cleaned, realigned and replaced, and it changes nothing because the eye was never late – it is a 1 ms device. The second thing they check is the valve, which is closer, and a valve that has slowed from 180 to 260 ms will show up in the reed-switch trend before anyone strips it. What almost nobody checks is the length of the product that was missed against the length the delay was set for, and that is the first question to ask: is it always the short one, or always the long one? If it is, the delay has the wrong product in it. If it is everything, and it started on a particular day, somebody changed the belt speed.
Ask which product it misses, and since when, before touching anything on the machine.
Next step
Put a confirm eye in the reject lane and count diverts against decisions per product code, because a divert that is 97% right looks fine on the HMI and is losing 36 cartons a shift. Then trend Belt_mm against a stopwatch for a minute to prove the encoder scaling, and trend the reed switch against Divert_Out for a shift to get the actuator delay you actually have rather than the one in the commissioning notes. Once both are known the fire offset is arithmetic, and the only thing left to decide is how the divert tells the zone logic upstream to hold when the reject lane is full – which is a permissive on the merge’s token, not on the divert.
Count the misses first, then measure the two delays, then change the offset.