Switch in the filler panel on our bottling line packed in on nights. Everything hanging off it dropped, which is fair enough, except the PF525 on the capper carried on turning at whatever speed it had at the time. It ran for the best part of two minutes with the CompactLogix showing the module faulted and no comms at all, and the lad on shift ended up hitting the e-stop.
I've been through the logic and the stop rung is fine, it's the same routine as the other four 525s in the panel and those four stopped the way you'd want. Compared the parameters against the commissioning sheet from 2022 too, though I'm not sure I'd spot it if something was out of place.
On the TIA side you'd expect the device to go to its substitute values and be done. What does a 525 actually decide to do when its connection goes away, and where is that decision made?
Which switch is it, make and model, and is it managed? And did the drive log anything at all in its fault queue, or is the queue empty?
Unmanaged 8 port thing that came with the machine, no diagnostics on it to speak of. It's been replaced with a Stratix 2000 now.
Drive fault queue is empty for that event, nothing logged. The Logix controller logged the I/O module fault on all five drives at the same second, so the network drop itself is not in doubt. Worth saying the panel has been dropping the odd connection for a couple of years and there was a spell in 2024 where it was going weekly.
What's the RPI on those drive connections, and is the timeout multiplier still on the default?
If the RPI is slack enough the connection could be sitting there not-yet-timed-out for a lot longer than you'd think, and until it times out the drive has a perfectly valid last command to hold. That's not a fault, that's the connection still being open as far as the drive is concerned.
RPI is 20ms on all five, multiplier untouched, so we're talking 80ms before it gives up. Two minutes is not that.
And the other four faulted off the same switch at the same instant with the same RPI, so whatever it is, it's in the capper drive and not in the timing. Properly stuck on this one.
C143, EN Comm Flt Actn. That's the parameter that decides it and it lives in the drive, not in your program.
Default is Fault, which is what your other four did. The rest of the list is Stop, Zero Data, Hold Last and Send Flt Cfg. Somebody set the capper drive to Hold Last, and Hold Last means exactly what happened, it keeps the last run command and the last speed reference and spins until something else stops it. Read C143 off the keypad on all five and you'll see four the same and one odd.
Given you said the panel was dropping weekly in 2024, I reckon someone changed it then to stop the nuisance trips. Comm loss behaviour on EtherNet/IP generally, someone did a decent write up on it: https://plctr.com/utilizing-ethernet-ip-in-plc-communication/
That's it. Four drives read Fault on C143 and the capper read Hold Last. Set it back to Fault off the keypad, pulled the patch lead with the line empty to prove it, and the drive faulted and coasted the way the others do.
Maintenance manager found a note in the machine file from March 2024, the contractor who was here for the weekly dropouts wrote down that he had stopped the capper faulting and nothing else. Nobody ever went back to it because the dropouts got better on their own. Which they clearly didn't, they just got less frequent, so the switch was dying slowly for two years. Thanks petek, scott_m and boris_h, that's a nasty one off the list.
Unmanaged switch on a filler. There's the real fault.