Two cartons released 1.1 seconds apart from line A and line B arrive at a 30 degree merge at the same moment, because line A’s release eye is 1.3 m from the junction and line B’s is 1.7 m, and 0.4 m at 0.28 m/s is 1.4 seconds. The rung that let that happen was two release rungs, one per line, each looking at the same merge eye and each finding it clear in the same scan. Nothing about either rung was wrong on its own. Merging two conveyor lines needs one token. A single arbiter rung decides which line may release, holds the token until the released carton has proved it is past the junction, and only then looks again. The priority rule is the part of that arbiter that says who wins when both lines are asking, and it only matters when both lines are asking – which on this junction is most of the shift, because the merge is slower than the two packing cells feeding it put together.
One token. One winner per scan. One proof that the junction is clear.
Everything below is worked on the twelve-zone line from the zone logic article, with a second line joining it: a 5069-L320ER CompactLogix, polarised retroreflective 42EF eyes, PowerFlex 525 zone drives, logic in a 50 ms periodic task, both feeding lines at 0.280 m/s and the takeaway past the junction at 0.500 m/s.
Merging two conveyor lines: what the junction looks like, and where the eyes are
Three eyes do the whole job.
PE_A is the release eye on the last zone of line A, 1.3 m before the junction. PE_B is the release eye on the last zone of line B, 1.7 m along the merge from the junction – longer, because a 30 degree merge conveyor has to be long enough for the carton to be running straight by the time it joins. PE_M is the merge eye on the takeaway, and its position is the one number in this article that has to be chosen rather than measured: it sits 0.9 m past the junction so that the nose of any product up to 900 mm long breaking that beam is proof the tail is clear of the junction. Run a 1200 mm product through this merge and PE_M has to move, or the token has to wait for the beam to clear rather than make. The transit times then fall straight out of the distances. From PE_A to the junction is 1.3 m at 0.280 m/s, 4.6 s, then 0.9 m on the takeaway at 0.500 m/s, 1.8 s: 6.4 s from grant to PE_M making. From PE_B it is 1.7 m at 0.280 m/s plus the same 1.8 s: 7.9 s. Add the ramp on the releasing zone’s drive – P041 Accel Time 1 on a PowerFlex 525 runs from 0 Hz to P044 Maximum Freq, so a zone at 60 Hz with P041 at 0.50 s costs a quarter second of travel on every release – and the detection chain, a 1 ms eye, a 1 ms input filter and a 50 ms task, which is nothing next to the rest. Measure them with a stopwatch anyway, from the release bit going true to PE_M making, twenty times each, and use the longest.
The distances set the transit times: 6.4 s from a line A release to PE_M making, 7.9 s from line B. Those two numbers are the merge’s cycle time and they are what the arbiter is holding the token for.
Two measured speeds and three distances are the whole input to the arbiter.
One arbiter, not two release rungs
The double release happens in one scan and it cannot be fixed with a timer.
Rung A says release A when Req_A and PE_M is clear. Rung B says release B when Req_B and PE_M is clear. Both are evaluated in the same scan, both read the same input image, both see the beam clear, both release, and 6.4 and 7.9 seconds later two cartons meet at the junction with the takeaway trying to carry both. Putting a gap timer after each release only spaces out consecutive releases from the same rung; it does nothing about two rungs firing in the same 50 ms. What fixes it is a token that only one rung can take, and a rung order that makes the second rung see the first rung’s decision in the same scan.
Two rungs, one input image, one scan, two cartons at the junction.
(* MergeTask, 50 ms periodic - one token for the junction *)
Req_A := Zone_A[12].Occupied AND NOT Zone_A[12].Owns AND Zone_A[12].HoldTmr.DN;
Req_B := Zone_B[8].Occupied AND NOT Zone_B[8].Owns AND Zone_B[8].HoldTmr.DN;
(* the token: free only while nothing is in transit to PE_M *)
Merge_Idle := NOT Merge_Busy;
(* one winner per scan - B is only evaluated against A's result *)
Grant_A := Req_A AND Merge_Idle AND NOT (Req_B AND B_Starved);
Grant_B := Req_B AND Merge_Idle AND (NOT Req_A OR B_Starved) AND NOT Grant_A;
IF Grant_A OR Grant_B THEN
Merge_Busy := 1;
XferTmr.PRE := 12000; (* 7.9 s worst transit x 1.5 *)
XferTmr.ACC := 0;
END_IF;
XferTmr.TimerEnable := Merge_Busy;
TONR(XferTmr);
(* the proof: the nose makes PE_M, and only that clears the token *)
IF PE_M AND Merge_Busy THEN
Merge_Busy := 0;
END_IF;
IF XferTmr.DN THEN
Merge_Lost := 1; (* alarm; a person looks, the token stays taken *)
END_IF;
Three things in that block are deliberate. Grant_B carries AND NOT Grant_A even though the priority terms already make the two mutually exclusive on paper, because the day somebody edits the priority expression that one term is what keeps the junction safe. Merge_Busy is cleared by PE_M making and by nothing else – not by a timer, not by the releasing zone’s eye clearing – because the beam is the only evidence that the carton is past the junction. And the lost-product timer alarms rather than freeing the token, for the reason worked through in the singulation handshake: a carton the logic cannot account for is under the frame or wedged at the merge, and releasing the other line into it makes two problems out of one.
The beam is the proof that the junction is clear. Nothing else is.
The same arbiter as ladder. Rung 21’s XIO Grant_A is the one-winner-per-scan term; rung 22 is the starvation counter, reset on every B grant.
Who goes first, and why it is a question about accumulation
Priority does not make either line faster. It decides which line backs up.
Under capacity the arbiter almost never has both requests at once, and the token goes to whichever line asked, so the rule is idle. This junction is not under capacity: the A cell packs 6 cartons a minute and the B cell 4, measured over a shift, and the merge cycle – the token held for 6.4 s per A carton and 7.9 s per B carton – gives 9.4 a minute if only A ran, 7.6 if only B ran, and about 8.9 for the mixed traffic. Ten in against 8.9 out means one line is accumulating for most of the shift, and the priority rule is the decision about which one. Give A fixed priority and B’s zones fill back to the B cell’s discharge, the cell’s outfeed eye blocks, and the B packer stops; that is a real cost with a real number, the B cell’s rate, and it is the argument for the rule and not a fairness principle.
Ten cartons a minute arriving at a junction that passes 8.9. The rule decides whose zones fill.
So the rule is written from the machines, not from a preference. On this line the A cell is the one whose outfeed has three zones of accumulation and the B cell has one, so A gets priority, and B gets a guarantee: it will not wait more than three consecutive A grants. That guarantee is a counter, B_Wait, incremented once per A grant while Req_B is true and reset on every B grant, with B_Starved its done bit at a preset of 3. Three A grants is 19.2 s at this junction’s transit times, and B’s single accumulation zone holds a carton for that long without the B cell’s outfeed eye blocking. The number is the B cell’s tolerance to waiting, expressed in A cycles, and it is different on every merge. Alternation – strict A, B, A, B – is the other rule people reach for, and it is the right one when the two cells have equal accumulation and equal rates. It is the wrong one here, because it holds A to B’s rate when B has product and A has three zones of buffer that alternation never uses. Write it as the starvation counter with a preset of 1 and you have alternation anyway, which is the point of writing the rule as a counter: the preset is the policy, and the policy is one number an engineer can change at 2 am without touching the rungs.
Set the preset from the side line’s accumulation, not from a sense of fairness.
Top: fixed priority, and B never sees the token while A has product. Bottom: the same demand with the limit at 3; B waits 19.2 s at most and A still takes three grants in every four.
The token and the gap are different things
A carton past the junction is not a carton with a gap behind it.
The token guarantees that the next carton, from either line, cannot reach the junction before this one has left it. It says nothing about the spacing on the takeaway, which is set by how long the arbiter waits after PE_M makes before it considers the merge idle again. On this line that is zero, because the takeaway runs at 0.500 m/s against 0.280 m/s on the feeds, and the speed step alone opens a gap of 79% of the carton length – 470 mm behind a 600 mm carton that left the feed nose to tail with the one in front – as each one accelerates onto it. A takeaway at the same speed as the feeds would need a hold after PE_M makes, and that hold comes off the merge capacity: 0.5 s of hold on every grant takes the mixed capacity from 8.9 to 8.3 a minute, which is a number to put in front of whoever asked for the gap.
Hold time comes off capacity, every time, and somebody has to sign for it.
What it does after a stop
Every stop leaves a carton somewhere between a release eye and PE_M, and the arbiter has to remember it. Merge_Busy and XferTmr are retentive by nature in Logix, and they must stay that way: on a restart the token is still taken, the transit timer carries on from where it was, and the carton that was 0.3 m short of the junction when the E-stop dropped gets to finish before either line is released behind it. The one thing to add is a reset that rebuilds state from the eyes after a jam clear, the same walk-the-array reset the zone logic already does, and it must not clear Merge_Busy unless PE_M is clear and a person has confirmed the merge section is empty. A reset that frees the token because the transit timer expired during the stop is a reset that releases the other line into a carton nobody moved.
Retentive on purpose, and written on the drawing as such.
The thing everyone checks first
The merge eye.
A collision at the junction sends people to PE_M first, because it is the sensor that was supposed to prevent it, and the eye gets realigned and swapped and it changes nothing. The eye was telling the truth: it was clear when both rungs asked. The proof is in the trend – put Grant_A, Grant_B and PE_M in one trend at the task period and the two grants going true in the same 50 ms sample is the whole diagnosis, and it will show up on the day the B line first has product at the same time as A, which on a new line is often weeks after commissioning. Then check the transit timer preset against the measured transit, because an arbiter whose lost-product timer is shorter than the real B transit will alarm on every B release and somebody will have lengthened it to five minutes, at which point a carton genuinely lost at the merge holds the token for five minutes and the line stops with nothing on the screen.
The eye was right the whole time. The rungs were not.
Next step
Put B_Wait.ACC on the HMI next to the merge, and trend it with both request bits for a shift. If it never reaches the preset, the junction is under capacity and the priority rule is not doing anything, which is fine; if it sits at the preset for minutes at a time, the merge is the bottleneck and the number to change is the transit distance or the takeaway speed, not the preset. Then decide what the arbiter does with a divert downstream, because a token that clears on PE_M making does not know whether the takeaway beyond it can accept the carton – a divert has its own transit arithmetic, lead distance and actuator delay, and the jam timer on the merge zone has to be gated on Merge_Busy, not on the eye, for the same reason a zone timer is gated on the run request.