Two PowerFlex 525s with 42.50 Hz on both keypads were running the takeaway at 0.500 m/s and the palletiser infeed it hands over to at 0.462 m/s, and every carton that crossed the transfer between them arrived 7.6% closer to the one in front than it had left. A 1219 mm carton that left the takeaway 210 mm behind its neighbour reached the palletiser 101 mm behind it, the 300 mm totes that left at 210 mm were touching, and the transfer eye 0.6 m past the nose-over was staying blocked for four and five seconds at a time on product that should have cleared it in 2.4. Nobody had changed anything. Conveyor speed matching had never been asked of the two drives: they had been given the same frequency, not the same belt speed.
The fix is a reference for the second drive derived from the first one’s measured speed, with a small lead on it, and a trim from the transfer eye that only ever moves it a quarter of a hertz at a time.
Everything below is the end of the takeaway from the carton counting article: a 5069-L320ER CompactLogix, a PowerFlex 525 on the takeaway and another on the 6 m palletiser infeed, both commanded over EtherNet/IP, a 42EF eye PE_X 0.6 m past the transfer, products of 300, 600 and 1219 mm, and the takeaway at 0.500 m/s measured with a chalk mark. The drive facts are from 520-UM001; the G120 notes at the end are from its list manual and operating instructions, for the line where the infeed came with the palletiser and a SINAMICS on it.
Why product bunches without conveyor speed matching
A transfer between two belts changes the pitch of everything that crosses it by the ratio of the two speeds, and nothing else about it matters.
Two cartons cross the transfer a fixed time apart, because that is what the upstream belt delivered, and on the downstream belt that time becomes a distance at the downstream speed. The nose-to-nose pitch on the second belt is the pitch on the first multiplied by v2 over v1, and the gap is that pitch minus the carton. At 0.462 over 0.500 a 1429 mm pitch becomes 1320, and 1320 minus 1219 is 101 mm. At the same ratio a 510 mm pitch for the totes becomes 471, minus 300 is 171 mm, which sounds fine until the next transfer onto the palletiser’s own belt takes another 7.6% and the one after that closes it to nothing. Each transfer that runs slow compounds the last, and the place the cartons finally touch is two sections away from the one that caused it.
The nose-over is where it shows. A carton bridging the transfer has its nose on the slow belt and its tail still driven by the fast one, so for the length of the carton the tail is pushing the nose into whatever is ahead; a carton with 101 mm to spare skews as its tail catches up, and a tote with none is shoved into the tote in front and turns. The transfer eye then sees two totes as one long blockage, which is the four and five seconds, and the count downstream drops by one for every pair.
Two totes as one blockage, and the count downstream drops by one.
The gap is the pitch times the ratio, minus the product. A slower second belt eats it.
Same hertz, two speeds. The carton on the nose-over is being pushed by its own tail, and the gap behind it has already been spent.
Hertz is a drive number, not a belt number
The two drives read 42.50 Hz because somebody matched them by the keypad, which is the most natural thing to do and the wrong one.
The frequency sets the motor speed. The belt speed is the motor speed through a gearbox ratio, a drive roller diameter and a belt thickness, and the palletiser infeed came from a different builder with a different gearbox. Measured loaded with a chalk mark over 3.00 m, the takeaway does 0.500 m/s at 42.50 Hz, which is 85.0 Hz per metre per second, and the infeed does 0.462 m/s at the same reference, which is 92.0 Hz per metre per second. Those two constants are the whole calibration, and once they are written on the drives the arithmetic is one line: for the infeed to run at the takeaway’s speed it needs 42.50 times 92.0 over 85.0, which is 46.00 Hz, a reference of 4600 in the 0.01 Hz units the PowerFlex 525 takes over EtherNet/IP.
Measure loaded, because the number changes. P039 [Torque Perf Mode] defaults to SVC on this drive, and the manual says the drive applies slip based on the motor nameplate data it was given, P036 [Motor NP RPM] being what it uses to calculate the rated slip, with d375 [Slip Hz Meter] showing how much it is adding at any moment. Leave P036 at its 1750 rpm default on a motor whose plate says 1720 and the drive compensates for less slip than the motor has, so a loaded belt runs a little slower than an empty one and the chalk mark on an empty belt lies by that amount. Enter the plate value on both drives before measuring either belt.
Nameplate rpm first, then the chalk mark, then the constant.
Two chalk marks, two constants, one multiplication. Then the keypads can read what they like.
The ratio reference, and the lead on it
The infeed’s reference is computed from the takeaway’s, every scan, so that the two belts stay matched whoever changes the takeaway.
(* ConveyorTask, 50 ms - infeed follows the takeaway *)
K_TA := 85.0; (* Hz per m/s, takeaway, chalk mark 2026-03 *)
K_IN := 92.0; (* Hz per m/s, palletiser infeed, chalk mark 2026-03 *)
Lead := 1.02; (* infeed 2% faster than the takeaway, never slower *)
Ref_IN_Base := DINT_TO_REAL(FreqRef_TA) * (K_IN / K_TA) * Lead; (* 4250 -> 4692 *)
Ref_IN := REAL_TO_DINT(Ref_IN_Base) + Trim_IN; (* trim in 0.01 Hz, bounded below *)
Ref_IN := LIMIT(REAL_TO_DINT(Ref_IN_Base), Ref_IN, 5200); (* floor is the ratio, ceiling is the palletiser *)
Drv_IN.O.FreqCommand := Ref_IN;
The 2% lead is deliberate and small. A transfer that runs exactly matched keeps the gaps it is given and gives nothing back; one that runs slightly fast opens each gap by 2% of the pitch, 29 mm on the 1429 mm pitch, which is enough that the tote never touches the tote ahead when the takeaway reference wobbles, and not enough to change the count or spread the product visibly. The floor of the trim is the computed ratio itself, because the infeed must never be allowed to run slower than the takeaway for any reason the logic can control, and the ceiling of 5200 is what the palletiser will accept product at, measured, not what the drive can do. The gapping article does the same multiplication for a different purpose. There the ratio is large on purpose, 1.832, to manufacture a gap proportional to the product length. Here it is 1.02 to preserve the gaps that already exist. The arithmetic is identical and the intent is opposite, which is why the two belong on different pages.
Never slower. The floor of the trim is the ratio, and the trim can only add to it.
Rung 60 is the design. Rungs 61 to 63 are the trim, and the limit on rung 64 is what stops the trim from becoming the design.
The trim from the transfer eye
PE_X sits 0.6 m past the nose-over, far enough that the longest carton is fully on the infeed belt before its nose reaches the beam, and it measures one thing: how long each block lasts.
A carton on its own blocks the eye for its length over the belt speed, 2.39 s for the 1219 mm carton at 0.510 m/s, 0.59 s for the tote. Two products touching block it for the sum of their lengths and never clear between them, and that is the signal. A TONR runs while PE_X
Touch_Cnt and used once to add 25 to Trim_IN, a quarter of a hertz. The counter is the evidence and the trim is the reaction, and the counter matters more: three touching events in an hour is a product with a slick base lagging the infeed belt; thirty is a belt whose speed has changed, and the trim will have found it long before anybody reads the counter. The other direction is gentler. If the clear time at PE_X, measured with a second TONR while the eye is clear, comes out more than 10% longer than the clear time at the takeaway’s last eye for twenty products running, the infeed has drifted fast and 25 comes off, down to the floor. That comparison needs the upstream gap time, which the tracking article’s boundary eye PE_T4 already measures, and it is in the same task.TON(Blk_X, PE_X AND Belt_IN_Run); (* preset 3000 ms *)
IF Blk_X.DN AND NOT Blk_X_Last THEN (* two products touching *)
Touch_Cnt.CountUp();
IF Trim_IN < 600 THEN Trim_IN := Trim_IN + 25; END_IF;
END_IF;
Blk_X_Last := Blk_X.DN;
IF Batch20.DN THEN (* every twenty products *)
IF Gap_X_Avg > Gap_T4_Avg * 1.10 AND Trim_IN > 0 THEN
Trim_IN := Trim_IN - 25;
END_IF;
Batch20.Reset();
END_IF;
Twenty-five hundredths of a hertz on a 92.0 Hz per metre per second belt is 2.7 mm per second, which is a change nobody can see and the pitch arithmetic can. The trim’s range, 0 to 600, is six hertz, and if it ever sits at 600 the ratio constant is wrong and the chalk mark is due again.
The trim covers drift. It does not find the ratio, and it is bounded so that it cannot.
Ramps, and why matched times are the wrong thing to match
Every line start bunches product at the transfer if the two belts do not reach speed together, and matching P041 [Accel Time 1] on the two drives does not make them.
P041 is defined in 520-UM001 as the time from 0 Hz to P044 [Maximum Freq], so the drive accelerates at P044 over P041 hertz per second whatever the reference is. Two drives with P044 at 60 Hz and P041 at 3.0 s both ramp at 20 Hz per second, and 20 Hz per second on the takeaway is 0.235 metres per second per second while on the infeed it is 0.217. The takeaway reaches 0.500 m/s in 2.13 s; the infeed reaches its matched 0.510 in 2.35 s, and for a fifth of a second on every start the takeaway is delivering faster than the infeed carries away. It is small, and it is the reason the first two cartons after a start were always the touching pair. Match the acceleration in metres per second per second, which means P041 on the infeed at 3.0 times 85.0 over 92.0, 2.77 s, and P042 [Decel Time 1] the same way; the staged restart article has the version of this problem for a fully loaded line.
Match the acceleration in metres per second per second, not the seconds.
If the infeed has to hold a belt speed to better than the slip compensation can manage, a loaded 6 m belt with product density that varies from empty to solid, the encoder option is the drive’s answer: A535 [Motor Fdbk Type] with a 25-ENC-1 card, and the manual’s own description is that the drive then uses the encoder to determine the actual output frequency and adjust it to match the command, with A538 and A539 as the loop gains, giving increased speed accuracy compared to open-loop slip compensation and no bandwidth improvement. For a palletiser infeed it is not worth the card. For a section that feeds a scanner or a print-and-apply it can be.
The same numbers on a G120
Where the infeed came with its machine and a SINAMICS G120 on it, the vocabulary changes and the arithmetic does not.
The setpoint is a speed, scaled to p2000 rather than written in hundredths of a hertz, and the chalk mark constant is metres per second per unit of that. Slip compensation is a parameter, p1335, expressed as a percentage of the rated slip the drive calculates in r0330 from the rated speed in p0311; the list manual gives it a factory setting of 0%, which is off, and 100% as fully compensated, and notes that Standard Drive Control sets it to 100% by default. A G120 left in U/f control, p1300 at 0, with p1335 at zero and the wrong p0311 has the same loaded-belt error as the PowerFlex with P036 at its default, for the same reason. The ramp times p1120 and p1121 are referenced to the maximum speed p1082 exactly as P041 is to P044, so the same acceleration match applies. And on the CU240E-2 PN the operating instructions list EtherNet/IP among the fieldbuses, with p8980 selecting the ODVA AC/DC drive profile and p8982 setting the speed scaling, which is what lets the same CompactLogix hold both references without a gateway; the profile that arrives on the Rockwell side is a generic module, not an add-on profile, and it wants its own commissioning day.
Different words, the same two constants, the same loaded chalk mark.
The G120 on a Siemens controller is the other half of that story.
Worked from the article’s numbers, not a stock plot. The events stop when the infeed leads; the trim moves once, when the takeaway reference is nudged down.
The thing everyone checks first
The keypads.
Both drives say 42.50 Hz, so the belts match, so the problem must be the product, or the transfer plate, or the eye, and the afternoon goes on the transfer plate. Put a chalk mark on each belt and a stopwatch on the mark before touching the plate. If the two speeds differ by more than a percent, nothing downstream of the drives is the cause, and the number that fixes it is the ratio of the two chalk-mark results, which no keypad can show. The second thing people try is a hold timer at the transfer, releasing product only when the eye is clear; it moves the queue a section upstream and slows the line by the hold, and it never changes the fact that the second belt carries away less than the first delivers.
A timer cannot fix a rate. Only a speed can.
Next step
Chalk-mark both belts, loaded, with the nameplate rpm entered on both drives, and write each one’s hertz per metre per second on the drive and on the line sheet. Compute the second reference from the first, add 2%, and write it as a multiplication in the task rather than as a number in the drive. Put Touch_Cnt on the HMI next to the count and watch it for a shift; if it stays at zero the ratio is right, and if the trim is climbing the belt has changed. Then look at how the zones upstream release product into the takeaway, because a transfer that holds its gaps only preserves what it is given, and the gaps it is given are decided three sections back.