ControlNet PowerFlex 40p comm issues

Hello all. Been reading for a long time, 1st real post. AB was unable to help me beyond "Yeah, that's old, we think you should upgrade..." which would be nice, but I'm just a maintenance man, so my job is to fix it.

We have 15 AB PF40p conveyor drives on a ControlNet chain. This was installed about 8 years ago, and has given us problems with several drives since install. This was converted from a contactor on/off set up, to drives. The main issue is comm loss. Either one or more drives will stay running after being commanded to stop, or one or more drives will stay off when commanded to start. The easy button is logging into the PLC5000, and resetting the CNet card, which gets us going 99 of 100 times. Occasionally, we will have to power off the drive entirely, and reset the comms to get the drive talking again.

I wont go into complete detail the things we've done to remedy this, as this post would be PAGES long, but the basics are as follows:

OHM tested all T-post junctions. Replaced the ones on the drives that most frequently give us issues. None tested out of range.

OHM tested the trunk line. no out of spec measurements.

REPLACED all of the trunk line. New high end connectors, top quality cable, a $400 crimper set, the works, all on the recommendation of AB, all their parts. ***This did help reduce comm loss and noise about 70%, but its still not as reliable as our newer ethernet drives.***

Replaced several drive mounted CNet COMM cards, on drives whos failure rate is higher.

Noise insulated the trunk line, routing it away from lighting, load power cables, etc.

There is a lot more we have done, so if you think of something ask away, we will either try it or confirm it.

Is anyone running an ControlNet system successfully with near zero comm errors and noise? This whole thing is confined to the MCC, so total cable length is under 50FT. I've seen CNet used in airports with thousands of feet of cable, and while it had its issues too, comm drop and control loss wasn't one of them.

Thoughts?

-J0N

ControlNet has numerous error counters and logical status indicators. Have you logged actual losses of communication, or do you infer them from the drives failing to act on demand ?

I have seen a lot of poorly programmed drive control logic that would have worked fine on a PLC-5 or SLC-500 where the outputs are written at the end of the program scan. But when the outputs can be written mid-logic because of the asynchronous nature of the ControlLogix operating system, you can end up inadvertently sending STOP and START signals at the same time, when they require exclusivity and a rising edge.

I checked your location tag carefully to be sure you weren't in Jonesboro, AR: the one time I've flown on the Rockwell jet was to haul me down there to resolve PowerFlex 40P problems on ControlNet for Frito-Lay that presented in a very similar way.

The issue where you explain a motor failing to respond to a command sounds like programming issue as Ken pointed out.

A start command should be held high until drive active goes high, then the start bit should go low. For stop, the stop bit should go high until drive active goes low, when drive active goes low, then the stop should go low.

If that’s not the order that you see in the logic then I would definitely look into fixing that.

I also after taking the stop away use the ready status bit in series with the start command (need to check which model can do this as some do not go to ready when the stop is removed but can be configured this way).

Ken has posted the best way to do.

Alan.

DumbHammerMechanic said:

REPLACED all of the trunk line. New high end connectors, top quality cable, a $400 crimper set, the works, all on the recommendation of AB, all their parts. ***This did help reduce comm loss and noise about 70%, but its still not as reliable as our newer ethernet drives.***
-J0N

Click to expand...

Hello Jon:
May years ago I was involved in the installation of a car-body assembly line which was controlled by a ControlNet scanner. The ControlNet adapters (about 40 or so) were arc-welding robot arm controllers. Each robot had a number of motion devices controlled by a processor communicating though an internal proprietary bus (high frequency bus similar to PCI or cPCI more specifically) onto which the ControlNet adapter board that the company I was working for supplied (I was providing tech support for this ControlNet adapter board). In other words the six or so drives of the robot and the ControlNet adapter board were sharing the same cPCI bus of the robot controller cPCI master. We found out that the cPCI bus was inducing noise into ControlNet to the point that after a number of robots became online, on the scanner side most of the ControlNet adapters would become unable to communicate. The workaround that was done until the robot manufacturer corrected its hardware is something that you may be able to use as your total cable length is not so long. The system integrator, if I recall properly, isolated the ground for the ControlNet adapter board from the robot controller chassis, each of these ControlNet adapter board's ground were connected to a separate cable and this cable was connected to what was considered a good ground point somewhere close to the panel where the PLC/scanner is installed. It was not a cheap work around because the total length of the ControlNet cable must have been in the hundreds of meters.

As you can grasp from my explanation, English is my second language and I am not a trained electrical engineer or electrician, but I hope you can get the idea on a workaround which is not very elegant (using a cable in addition to the ControlNet media) but for ground-loop problems like the one in this installation I was working at, there may not be other options.