PowerFlex 700S Stopping Intermittently

[ControlsGuyy]

Hello,

I am having an issue with a PowerFlex 700S. This drive controls a travel motor for an overhead hoist. It is periodically not starting after stopping at a programmed point and sometimes stops while traveling to the next station. It does not give any faults or alarms. It is controlled remotely from a CompactLogix through a wireless router to an N-Tron unmanaged switch to the 20-COMM-E adapter. There are some limited manual controls, but the normal operation is a start, stop and speeds all sent from the controller. We have the DI6 set to enable and that does not seem to ever be lost. When this happens the only thing that I can find is the start inhibit parameter shows a bit 8 set high which is a start request present. I can see the PLC has already sent the start signal. I can put the machine in manual mode then cycle back to auto and the drive takes off. The only thing I can see changing while doing this is the start command is dropped and then sent again. I have changed the comm adapter as originally I had thought this was an issue with comms, but now I am skeptical as I have it set to fault and stop if a comms loss is detected. I am also able to connect to this drive and others on the same hoist through the wireless comms, so I feel better about the comms path. What causes this start inhibit bit 8 to become active? Does this seem to be a communication issue or a potentially a bad drive?

 

[Ken Roach]

Welcome to the PLCTalk forum community !

I'm not in love with the wireless architecture, but I'm not willing to blame it entirely for the malfunctions. Any system using wireless should have some diagnostics built into it to watch for normal and abnormal numbers of lost packets and retries.

>The only thing I can see changing while doing this is the start command is dropped and then sent again

That part of your narrative is making me suspicious of a common issue with ControlLogix, VFD control logic, and asynchronous I/O over a network.

Check your logic to see exactly when it sets the STOP bit false. If your logic tries to emulate "two wire" control by setting STOP true whenever START is false, then you could be falling victim to a timing issue with asynchronous I/O.

Imagine your system is just purring along with the drive idle and the STOP bit remaining True. Then a command or event happens that causes the logic to set the START bit true.

And then, immediately after START is set True in the relay ladder logic routine but before the STOP bit is set false, the I/O connection RPI timer expires.

The current state of the Output data assembly with both START and STOP set to True is copied out of the Controller-scope tag database to be carried over Ethernet and WiFi and Ethernet again to the drive.

A-B drives have always required the STOP command to be false at the time that the START command undergoes a false-to-true transition to start the drive. If STOP and START are both true when the output data assembly arrives at the drive, it doesn't matter that STOP goes false in the next I/O update: at the time of the START bit's false-to-true transition, STOP was still true and that prevented the drive from starting.

This wasn't a problem with PLC-5's or SLC-500's with RIO. But it's a problem with any A-B drive with ControlNet or EtherNet/IP.

The more often your drive starts and stops, the more often this situation will occur. It's mystifying because there's no error detected: the drive just "misses the start command".

The standard way to prevent this from happening is to condition your STOP bit control so that it is set True only until the drive reports that it has actually stopped. That way it will be verified to have stopped the drive, but it will be false the next time the START but goes from false to true, no matter when during the PLC logic routine the I/O connection RPI times out.

It's possible there's also something going on in the RF environment, but I'd at least check the logic for the STOP bit first.

And again, welcome to the PLCTalk forum community !

 

[ControlsGuyy]

Thank you very much for the help!

I have made some edits to the code, and it has improved greatly. It does still happen periodically, but I feel as though we are now looking at a problem with communication over the wireless. The antenna actually broke off and now we have a temporary solution in place with which makes sense as we have an excessive number of retries on the wireless packets.

Thank you again, Ken Roach!