DeviceNet Troubleshooting

DeviceNet... she is a fickle mistress.

I am wrapping up a big expansion project at a Saskatchewan potash mine that included a pair of GE Fanuc RX3i PLCs, lots of IC694DNM200 DeviceNet modules on each PLC, many, many E3+ starters, and several Rockwell VFDs (700, 700H models). On this project we have encountered some frustrating and mysterious DeviceNet problems.

If you're banging your head against the wall with your DeviceNet network, or can't figure out how to get your PLC to recognize a node, here are my tips:

1. Search Google for "turck devicenet troubleshooting guide 2.2". Download the PDF. Read it from front to back. It is your new bible. Carry it with you everywhere and sing its praises. Most problems that you encounter while commissioning a new DeviceNet network (or making modifications to an existing network) can be solved with this manual's guidance.

2. After an unscheduled plant-wide power outage, we'd sometimes lose nodes - a VFD or E3+ that was happy a day earlier would disappear from the network entirely when everything was powered back on. Not visible on the PLC, not visible with RSNetWorx. On the Rockwell VFDs (on the 20-COMM-D module), the PORT light would be solid green, MOD flashing green, and NETA solid red. Check the following, in order of ease:

a. Power cycle the VFD/E3+/starter in question. Maybe it just needs a power cycle to register on the scanner (ie, your PLC).

b. Check the node address of every. single. node. on your DeviceNet network and make sure there are no duplicates. If someone has inadvertantly created a duplicate address by changing DIP switches, this will cause network problems the next time everything starts up. Make sure each node address matches what is configured in your PLC. You never know who has been sneaking around in your MCC, so don't rule this out.

c. If you are using auto baud rate on your scanner (PLC), power down your non-working node. Change the baud rate on the node from "auto" to match whatever the network is actually running at (125, 250, or 500 kbps). Power up the motor again. Does it work? Wow, magic. Power it down, set it back to auto baud, and power it up again. It should still work. This just happened to me a few days ago on a Rockwell VFD with a 20-COMM-D DeviceNet module. This was after replacing most of the hardware and trying most of the other solutions I've listed here.

d. Power cycle the DeviceNet network: make sure all DeviceNet power supplies are turned off (there can be multiple 24V power supplies per network, so keep your eyes open!). Caution: this impacts communication between all the nodes on your DeviceNet network and your PLC. I've seen nodes return to life after a network power cycle.

e. Power cycle your scanner / PLC. Caution: this impacts your whole process, in my experience it's only possible on a shut-down day or during commissioning. I've seen nodes come back from the dead after power cycling the PLC.


Got any other tips for fixing bad DeviceNet codes? I'd love to hear about them. Send me an email (neufeld@brahm.ca) or leave a comment on this post. Thanks and good luck with your networks!

Update Nov 2015 - In the past few years I've developed a much better understanding of DeviceNet... it's actually a reliable protocol, so long as it's installed and commissioned correctly. I am leaving this post online as a reminder of how frustrating it can be to work on a system that you don't have the proper experience or training on!