AB Drive comms over DeviceNet to SLC 5/05

[Amish 0]

Hi all, We have a mining conveyor drive that has two VFDs - a 1336 IMPACT and a PowerFlex 700. The drives load share through a current loop, but use devicenet to receive a speed reference from the PLC, and to send drive data to the PLC. Anyway, when I power up the drive, everything comes up OK. However, once the drives are signaled to start, I will get port adapter faults on both drives cooresponding to the scan/DPI port with the Devicenet adapter installed, and on the 1747-SDN in the PLC, I get a fault 78 for both drive nodes. Once in awhile, I will just get a fault 78 on one node, but either way, if I try to run it again, I get a fault 91, which I guess is the Devicenet giving up. I don't know why it doesn't fault out until the drives are commanded to start, unless it has something to do with incrased traffic? The power supply voltage doesn't dip or anything. I'm pretty sure its a problem with cabling, though I haven't found anything yet. This drive was just moved across the mine, and I wouldn't bet that both drives' Devicenet adapters failed simultaneously. That's my reasoning, but I wanted to see if anyone with more Devicenet experience had any other theories. This is my first real Devicenet troubleshooting experience. Thank you.

[Ken Roach 189]

This sounds like a classic electrical noise problem. First, check the DeviceNet termination; there should be one 120 ohm resistor across the blue and white wires are each extreme end of the trunk. Un-power the network and measure resistance between blue and white; if you don't have 60 ohms, go track down the termination resistors. Check also to be sure that the DeviceNet cable shield is grounded at one location only. Usually this is at the DeviceNet power supply, which usually has V- grounded as well. Is the power supply dedicated to the DeviceNet only, or is it shared with other circuits ? Drives are notoriously noisy and the sharing of power supplies between the network and other I/O circuits is a very typical way that the DPI/DeviceNet isolation gets circumvented, allowing bulk 24V bus noise to crash the network.

[Amish 0]

Thanks for the reply. I believe you are likely right about the terminating resistors being the issue. I remember there was one at the safeties node (Wago remote I/O), which was loose and we tightened it up. I looked at the other end of the bus, which is at the PF 700, and there was no terminating resistor. However, the connector was tight and I only saw a resistor in the prints at the safeties node. I figured whoever put it together knew something I didn't, or maybe the resistor was built in to the Devicenet adapter and moved on, but I will go throw one in when I get a chance on Monday. I'll also check the shield. Suprisingly, the power supply is dedicated to the Devicenet. Thanks again.

[PLCMentor.com 59]

Your best bet would be to power down the network and check resistance as Ken suggested. I am not familiar with the 700 - maybe it does have a dip switch or something for termination. It will be obvious if you check resistance and see 60ohms. You also mention the drive being moved. Is it possible that it was added on to a network and the terminating resistor needs to be moved? If you read 60 ohms, it may be worth pulling the DN plug on the 700 and measuring the rest of the link again. If you still get 60 ohms, you have two terminating resistors just placed incorrectly. Check the troubleshooting section in the SDN manual for the codes, but 78 means the device in the SDN does not exist on the network, 91 (as you mentioned) is DN going bleauh. Bus off and comm comm errors. Seems to me I used to get that when I disconnected bus power. Generally if you are getting all this on drive start then you have a noise problem. If its not the terminating resistors, check and make sure your drives are properly grounded. With all this, I am assuming that you have checked both drives command reference to insure you are really communicating successfully.

[Ken Roach 189]

I don't know of any A-B device with internal DeviceNet termination; I've seen that only on a tiny handful of DeviceNet products. Measuring the resistance between CAN-H and CAN-L (white and blue) is a definitive measurement; 120 ohms means only one present, and 50 ohms or lower means more than two. 60.5 means you've got the exact correct termination. Error 72 usually shows up first; that indicates a dropped cyclic I/O stream. Error 78 shows up if the slave doesn't come back online immediately; it indicates that configuration messages aren't going through. Error 91 is a Bus-Off error, indicating that the scanner can't make any sense of the data on the CAN data bus. Error 92 is a Power-Off error, indicating the 24V power on the network is absent. I've been through a few really difficult drive noise mitigation efforts but most of them have been solved just by routing the network away from the drive outputs, making sure the drives are solidly grounded (I use braided ground straps to drain high frequency noise to ground) and shielding the DeviceNet cable.

[Amish 0]

Thought I'd post an update I went down and worked on the drive today. First I checked the terminating resistors - there was indeed one at the other end of the trunk, but it was a 100 ohm, so I replaced that with a 121 ohm. Next, the portion of the trunkline that runs from the controller to the safeties node was hung up with a set of motor leads, so I pulled it out and routed it away. Then, I looked at the trunkline that traveled through the 1336 - a zip tie had broken loose and the cable was resting on the DC bus, so I put that back up where it belongs. At this point, I tried to run the drive. It ramped up for maybe 4 or 5 seconds, which is more than it had been, but still gave me a 78 fault on the 700. I could start it up again and get a fault 91 right away. So, I pulled apart the connectors for the trunkline between the two drives and measuring the resistance. I found that the power wires pulled out easily from one of the connectors when it was taken apart, so I put those back in. The first time it ran, I got a fault 91. I started it again, it ramped up for 5 seconds, then got a fault 72, then 78 on the safeties node, which is a new one. I did notice as I watched it fault out previously that it started as a fault 72, then 78, regardless of the node, as long as it didn't go right to a fault 91. At this point, the day was over and utility had to do some belt work, so I was done. I think everything helped out a little bit, but there must be something else. I didn't look much into the shielding, other than looking at the Devicenet power coupler(?) in the controller, there was nothing wired into the shield input, just the power wires. I measured resistance from that terminal to ground, and only found 1 ohm, so figured it was grounded somewhere for now. I guess I'll just keep chipping away at it. Thanks for all the help.

[Conor 4]

Hi Amish, Are you sure that your Scanner card is ok? I know that this is probably not the problem. We had an issue with DeviceNet a few months ago where our Scanner card was going faulty. The way that you describe your problem sound very like what was happening to us. My faulty Scanner card was on a PLC 5. We had another Scanner card go on the same PLC about a month after we had the first one go. This was easier to find as it was going straight to 91. Conor

[Amish 0]

I figured I should update this and put what we found, which was pretty disappointing. After fiddling with Devicenet connectors between the control box, drives, and safeties box, and getting intermittent changes, we disconnected all the Devicenet cables, swapped them around and plugged them back in. We haven't had a comm error yet (knock on wood). I guess thats what you get when the bulkhead connectors for your Devicenet are 6-pin thomas and betts hardwire I/O connectors designed for 10-16 gauge wire.