Friday afternoon the managed switch in the MCC died. Six PowerFlex 525s on the accumulation line, all on EtherNet/IP off a CompactLogix 5380. Five of them dropped out and stopped, the way they should. Number four kept going at its last speed for a good minute. Operator hit stop on the PanelView and nothing happened. He hit the e-stop and it coasted down.
Switch is swapped, everything talks again, line's running. I went online and compared the logic first, and drive four is the same AOI as the other five, same rungs, and the HMI stop button writes the same tag on all six.
So is the HMI at fault here, or the program? Same code on six drives and one of them behaves different. Is there something in the drive itself that decides what it does when the comms go, rather than anything in my code?
Two things. A stop button on a screen is not a safety function, so the e-stop doing the stopping is the system working, not failing. Separate that from the real question.
The real question is why five drives faulted and one held. Same code, same network, different result, so look at the drive, not the PLC. Do all six have the same comm fault action set?
Not sure what you mean by fault action, that's not a parameter I've been in. All six came from the same integrator, same commissioning sheet.
C143, EN Comm Flt Action. It's what the drive does when the EtherNet/IP connection drops. Default is Fault, which is what your five did. The other options are Stop, Zero Data, Hold Last, Send Flt Cfg. If someone set drive four to Hold Last, then when the switch died it kept its last run command and its last speed reference and carried on, exactly like you saw.
Read C143 off the keypad on all six. Takes five minutes.
Five of them read 0. Drive four reads 3, which on the keypad shows as hold last. Nobody here admits to changing it.
I do remember that drive dropping off the network every few weeks last summer, maybe more often than that. Nuisance trips, line stopped each time. Then it stopped happening.
Then that's the story. Somebody got tired of the nuisance trips and set C143 to hold last so the drive would ride through the dropouts, instead of finding the bad cable. Which hid the network problem and gave you a conveyor that ignores the whole plant when the network's gone.
Set it back to 0. Then find the cable or port that was dropping last summer, it's still there. Lock the drive out before you're in the terminal cover reseating anything.
The comm loss options and what each one does is in this one: https://plctr.com/utilizing-plc-for-motor-control-and-drive-systems/
Set C143 back to 0 on drive four. Tested it by pulling the cable at the switch, drive faulted on net loss straight away and stopped. Put the same test on the other five for good measure.
Somebody had put C143 on hold last, and my money is on last summer to stop the nuisance trips. Back to fault on drive four, and the network gets sorted properly this time instead of papered over.
Cable to drive four tests fine on the tester. Replaced it anyway. Still don't know why it was dropping last year, could be the old switch was already on its way out.
Thanks vinnie86, and gary for the point about the e-stop, that went in the incident report.
Retitled so the C143 part shows up in search. Marking solved.