The E-stop is reset, the safety relay is closed, every one of the twelve PowerFlex 525s on the accumulation line has S1 and S2 at 24 V again and F059 cleared from its display, and nothing moves. No fault on any drive, no alarm on the HMI, twelve zones with a carton on every eye and the palletiser asking for product. Then somebody presses the line start a second time, all twelve drives go into their P041 ramp in the same scan, the feeder draws 30 A against a 25 A thermal setting for half a second, and now there is a fault – on the breaker. A full-line conveyor restart is the hardest thing this line ever has to do, and it comes right after the one event that leaves every zone in the worst possible state.
Nothing moves because no drive got a start edge. Everything moves because they all got it at once.
Everything below is on the twelve-zone line from the zone logic article, with the ownership handshake from the singulation article: a 5069-L320ER CompactLogix, a PowerFlex 525 per zone commanded over EtherNet/IP with P046 [Start Source 1] at 5 “EtherNet/IP”, STO on every drive from one safety relay, 0.75 kW zone motors that draw 1.4 A running loaded and sit at 2.5 A in current limit through a 0.5 s ramp, 1.5 m pitch, 0.280 m/s, logic in a 50 ms task.
What the E-stop left behind
Coasting cartons, faulted drives, and a run request that never went false.
520-UM001 is specific about the first one: Safe Torque Off on its own is a coast-to-stop, with a reaction time of 100 ms maximum from the safety input to the gate control being disabled. There is no P042 ramp under an E-stop, the belt slows on friction alone, and on this line a carton in transit coasted 40 to 110 mm past its eye depending on the load on the zone. So a full line after an E-stop is not twelve cartons neatly on twelve eyes; it is ten of those and two standing past the beam in the blind length between zones, which is the handshake article’s case and is handled there. The second is the drives: with t105 [Safety Open En] at its default of 0 “FaultEnable”, every drive whose safety inputs dropped shows F059 Safety Open, and 520-UM001 describes it as both safety inputs not enabled, so twelve drives are faulted and stay faulted after the safety relay closes, because the fault is an event and the relay closing is not a fault clear. The third is the quiet one. Zone[i].RunReq in the zone logic already carries NOT Line_EStop_Active, so every run request dropped when the E-stop hit and rose again when it was reset – and if it rose in the same scan the drives were still faulted, the leading edge on the Start bit arrived at a drive that could not take it.
Three states, and only one of them shows on a screen.
The conveyor restart edge, and why the line does nothing
P046’s description in 520-UM001 carries one note that decides this section: the drive must receive a leading edge from the start input to start after a stop input, a loss of power or a fault condition, unless t064 [2-Wire Mode] is set to level-sense. Over EtherNet/IP the start input is Logic Command bit 1, and 520COM-UM001 adds that a Not Stop condition – bit 0 at 0 – has to be present before a 1 on Start starts the drive. The zone logic writes Drv[i].O.Start := Zone[i].RunReq and Drv[i].O.Stop := NOT Zone[i].RunReq, which is correct, and gives the drive its edge every time RunReq
RunReq rise in the same scan as the safety reset and the Start bit’s edge lands 20 ms before the Clear Fault bit’s edge is even sent, the drive clears its fault and sits there with Start at 1 and Stop at 0 and no edge, and the line does nothing with nothing on any screen to say why.(* RestartTask, 50 ms - the order of things after a safety reset *)
Safety_OK_OS := Safety_OK AND NOT Safety_OK_Last;
Safety_OK_Last := Safety_OK;
ClrPulse.PRE := 200;
ClrPulse.TimerEnable := Safety_OK;
TONR(ClrPulse);
IF Safety_OK_OS THEN ClrPulse.Reset := 1; END_IF;
FOR i := 1 TO 12 DO
Drv[i].O.ClearFault := ClrPulse.TT; (* 0 -> 1 -> 0, 200 ms *)
Drv_OK[i] := Drv[i].I.Ready AND NOT Drv[i].I.Faulted AND ClrPulse.DN;
END_FOR;
(* staged enable, discharge end first, 300 ms apart *)
Stage_Tmr.PRE := 300;
Stage_Tmr.TimerEnable := Line_Running AND Stage_Step < 12;
TONR(Stage_Tmr);
IF Stage_Tmr.DN THEN
Stage_Step := Stage_Step + 1;
Zone_Enabled[13 - Stage_Step] := 1;
Stage_Tmr.Reset := 1;
END_IF;
IF NOT Line_Running THEN
Stage_Step := 0;
FOR i := 1 TO 12 DO Zone_Enabled[i] := 0; END_FOR;
END_IF;
(* the run request, with the drive's own opinion in it *)
FOR i := 1 TO 12 DO
Zone[i].RunReq := Line_Running AND Zone_Enabled[i] AND Drv_OK[i]
AND NOT Line_EStop_Active AND NOT Zone[i].Jam
AND (Zone[i].Owns OR Zone[i].Expecting);
Drv[i].O.Start := Zone[i].RunReq;
Drv[i].O.Stop := NOT Zone[i].RunReq;
END_FOR;
Drv_OK[i] is the permissive that was missing. It reads the drive’s own status words rather than assuming the fault cleared, and it waits for the pulse to finish so that a drive that clears its fault 40 ms into the pulse does not get a run request while the Clear Fault bit is still high. One trap sits in the Ready bit: A574 [RdyBit Mode Cfg] on FRN 3 and later has a Standard and an Enhanced mode, and in Enhanced the Ready bit goes low when a stop is commanded through comms, with the Stop bit at 1 – so a permissive that waits for Ready before it drops Stop waits forever on a drive set to Enhanced. Drv_OK here gates the run request, and the Stop bit is written from the run request, so on an Enhanced drive Ready goes low the moment Stop is asserted and comes back when it is released. Trend Drv[1].I.Ready through one restart and the mode is obvious.
The order is the logic. Fault clear, then drive ready, then the run request, whose rising edge is the start edge 520-UM001 asks for.
Two things not to do. A541 [Auto Rstrt Tries] with A542 [Auto Rstrt Delay] would clear the F059 and restart the drive without the controller, and 520-UM001 puts an attention block on it about injury and equipment damage, for the obvious reason that a conveyor restarting itself after an E-stop is a conveyor restarting itself after an E-stop. And A543 [Start At PowerUp] answers a different question, a drive that lost mains, which STO does not cause: the mains stay on through an E-stop on this line, which is also why there is no precharge inrush and no F004 to worry about on the restart, only the acceleration current below.
The safety relay closes. The drive clears. The zone asks. In that order, with proof between each.
Twelve ramps in one scan
Every zone that is allowed to run wants its current limit for half a second.
A loaded zone motor on this line draws 1.4 A running. Through the P041 ramp it draws what A484 [Current Limit 1] allows, which 520-UM001 defaults to 1.1 times drive rated amps in normal duty and 1.5 in heavy duty, and on these 2.3 A drives set for heavy duty that is 2.5 A once the load is on the belt. Twelve zones started in one scan is twelve motors at 2.5 A for 0.5 s, 30 A on a feeder that carries 16.8 A with everything running and has its thermal element at 25 A; it holds for the first restart of the day, and on the third restart of a bad shift, with the element warm, it does not. The mechanical side is worse than the electrical. A full zone has 1.5 m of loaded belt to accelerate, and a drive that cannot get it to speed inside the current limit stretches the ramp and eventually reports F006 Motor Stalled, whose listed action in 520-UM001 is to increase the accel time or reduce the load so the output current stays under A484; a drive that gets it there but runs hot doing it gets F064 Drive Overload, with the same advice. Twelve zones pulling twelve full belts at once, each one pushing its carton into the next zone’s carton because the next zone is also still in its ramp, is how a zero-pressure line becomes a pressure line for half a second on every restart.
The stagger fixes both and costs 3.3 s. Stage_Tmr enables one zone every 300 ms starting from zone 12, so a downstream belt is always moving before the one feeding it is enabled – the line pulls apart instead of pushing together – and with a 0.5 s ramp at most two drives are ramping at any moment: 19.0 A peak instead of 30. The 300 ms is 0.5 s of ramp divided by the two-at-once you are willing to allow, and on a line with a longer P041 it gets longer. The 3.3 s is nothing, because on a normal restart of a full line the release wave in the next section is slower than the stagger anyway; the stagger only sets the pace in slug mode, when every zone has somewhere to go.
Two drives in a ramp at once, never twelve. That is the whole stagger.
Worked from the article’s motor numbers, not a clamp-meter trace. The stagger keeps the peak under the breaker with the same drives, the same ramp and the same load.
The wave, and why the infeed looks stuck for 24 seconds
On a full line with single release, only zone 12 can move when the line starts.
Every other zone is occupied and the zone below it is occupied, so nothing upstream has a release permissive until zone 12’s carton has cleared PE12 – 2.14 s for a 600 mm carton at 0.280 m/s, plus the detection chain – and zone 11 can release into it. Then zone 10 waits for PE11 to clear. The release wave runs upstream at one zone per 2.2 s, and zone 1 first moves 24 s after Line_Running went true, which is exactly right and looks exactly like a stuck line to the person at the infeed with a full pallet jack. That person presses stop, or presses start again, or calls maintenance, and the wave starts over. Put the wave on the HMI: a “line draining” state that shows the release front moving up the zones, or at least a countdown from the number of full zones times 2.2 s, and the calls stop.
Twenty-four seconds of a full line working correctly. Label it or somebody will reset it.
Slug release is the other option and it is the fast one: every zone runs together, the line empties at 2.14 s a carton instead of 6.2, and the singulation article has the arithmetic. It is only an option when the palletiser will take product at that rate, because a slug released into a downstream that stops halfway through is twelve cartons leaning on the one at the front, and after an E-stop the palletiser is usually the machine whose own restart takes longest. Ask the palletiser’s ready bit, not the operator.
Zone 12 at once, zone 1 at 24 s. The two red cartons coasted past their eyes when STO dropped and are put back into transit by the recovery run before the wave starts.
The two cartons that coasted
The restart must not rebuild the zones from the eyes.
Zones 4 and 9 had cartons in transit when the E-stop hit; they coasted 110 and 90 mm past PE4 and PE9 and are now standing in the blind length, seen by no eye. Xfer[4].State and Xfer[9].State are still 1, in transit, because they are ordinary tags and an E-stop does not touch them, and the right restart drives zones 4, 5, 9 and 10 through one transit timeout and lets the handshakes complete on PE5 and PE10 making, which is Recover_Run from the handshake article, run automatically on Line_Running for every boundary still in transit. The wrong restart is the reset routine that sets Occupied from PE and clears every ownership bit, which after a jam clear is right and after an E-stop declares both cartons nobody’s – and then zone 3 releases into the back of the one in zone 4’s blind length the moment the wave reaches it. The transfer timers need gating on Line_Running for the same reason: 8 s expires during any E-stop longer than a coffee, and a boundary that went lost during the stop restarts as an alarm instead of as a transit.
Rebuild from the eyes after a jam clear. Never after an E-stop.
Every step has a bit that proves it, and the last row is the one to put on the HMI. Times are this line’s; measure yours with a trend on the same bits.
The thing everyone checks first
The drives.
A line that does nothing after a reset gets the drives blamed, because the drives are the things with a display, and the display says nothing – which is the point. F059 was there and it is gone. The electrician cycles power on one drive, the drive comes up, still nothing, and now the network gets blamed. Go online and look at Drv[5].O.Start and Drv[5].I.Ready together: Start at 1, Stop at 0, Ready at 1 and no motion is a drive that never saw the edge, and a RunReq that was true through the whole reset is why. The second thing blamed is the safety relay, when the sequence is right and one zone still will not start – check t105 on that drive, because a spare set to 1 “FaultDisable” does not show F059 at all and behaves differently on the Ready bit, which the F059 article covers, and the reset button itself, which has to be a rising edge and not a level for reasons in safety reset: rising edge, not level.
Start at 1 and no motion is not a faulted drive. It is a drive that was never asked properly.
Next step
Trend Safety_OK, Drv[12].O.ClearFault, Drv[12].I.Faulted, Drv[12].I.Ready, Zone[12].RunReq and Drv[12].I.Active at the task period through one E-stop and reset, and read the order off the trend: the run request must rise after Faulted drops and after Ready is up, with a visible gap, or the edge is landing early. Then put a clamp meter on the feeder for one full-line restart and compare it with the 30 A the arithmetic predicts for your motors; if the measured peak is near the breaker’s thermal setting the stagger is not optional. The other half of the same event, what the coasting carton did to the eye it passed, is the setback question in photo-eye placement on an accumulation zone, and the command word the run request is written into is in driving a PowerFlex 525 from ControlLogix.