PowerFlex 700S Stopping Intermittently

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?
 
Look again at your circuit.By the way is it a hoist like UP and DOWN movement or just like an overhead crane long travel (FWD/REV) movement issue?
Does it have to reduce/increase speed when it reaches a certain point ?
 
Look again at your circuit.By the way is it a hoist like UP and DOWN movement or just like an overhead crane long travel (FWD/REV) movement issue?
Does it have to reduce/increase speed when it reaches a certain point ?
This drive controls the FWD/REV travel motion. A different drive is controlling the lift motion.

When the hoist gets within range of the tank it is to stop above, it will reduce the speed down to 25% until it meets the position. It is accurate on its stopping location.
 
Here there must a digital input (either a mechanical limit switch or proximity switch) at certain point that will will disable your speed from >25% of your output frequency.
So look at two things:
1.Circuit wiring,check connections integrity.
2.Parameters at Input/Output (because the limit proximity switch might not be closing to enable low speed (here I am using 4 x frame 10 to run 4X250kW motors on a short conveyor belt of 2.3km at load of 2000t) but look at Local I/O St status and the other parameter is minimum speed that the limit switch will input at,if you are set @ 0Hz you will definitely.

Apparently you 20-COMM-E is ok.
 
I wonder if there was any update or resolution to this issue from the original author?

That would be nice to know if they found the source of the intermittent problem.

My first thought, when network communication seems to send signals randomly, is to check the routing of the network cables and see if interference might be causing the errors. One switched bit in a VFD command word could be causing erroneous behavior. Are you using shielded cables for the 20-COMM-E <-> switch and the switch is grounded? Sounds like other devices on that switch are working as expected?
 
I wonder if there was any update or resolution to this issue from the original author?

That would be nice to know if they found the source of the intermittent problem.

My first thought, when network communication seems to send signals randomly, is to check the routing of the network cables and see if interference might be causing the errors. One switched bit in a VFD command word could be causing erroneous behavior. Are you using shielded cables for the 20-COMM-E <-> switch and the switch is grounded? Sounds like other devices on that switch are working as expected?
Yes, the other devices were all working as expected. The patch cord from the adaptor to the switch was not shielded but during the diagnostic processes, I did change these just to eliminate the possibility. It did not seem to affect the outcome. The work around I have come up with is to add a time delay from the moment the stop signal is lost to when the start signal is being given to the drive. I believe, due to the nature of the wireless communications, we were receiving the start signal before the stop was lifted. This has been running with these changes since the beginning of last month and we have had no issues thus far.
 
Top