AB Devicenet

Had a call from a customer that had a simple logic problem with a machine today that turned into a devicenet problem. I can't get there for a few days, so I was working with them over the phone and it sounds strange and does not make a lot of sense. They have a SLC with a devicenet card in the rack.
They have a Buss out fault 91. Had them check the voltage 24VDC on all devices Checked the resistance on the can wires 60 ohms. Everything looks good. Unplugged all the drives the encoder and the HMI come up ( they are on the end of the line ) plugged in Node 10 all good 11 12 13 any one of them cause the fault. Any idears would be appreciated.

Node 10 to 13 are AC drives 14 is a HMI 15 is an encoder.

Have the customer check the grounding of the drives.
Also, I would recommend that they connect the shield and the V- to the ground on the 24 VDC DeviceNet power supply. If this does not work, there may be a short between CAN H signal and shield or CAN L signal and shield somewhere. They would need to disconnect all nodes and measure whether there is short with shield somewhere in the cable.

In addition, check the Baud Rate setting on each of the devices that can appear to cause a Bus Off condition when connected.

Most A-B drives are default set to auto-baud detect, but a device hard-set to a different baud rate can cause bus-off just by transmitting its MAC ID Duplicate Check packet at the wrong time.

Thank you, I will pass that info along, and see what happens. But it has been running for years why would 3 drives change?

>why would three drives change ?

My best guess is that somebody adjusted their DeviceNet settings, on purpose or accidentally, at some point in the past.

The usual failure mode for that sort of thing was:

1. Someone went online with RSNetworx intending to examine some drive settings, but didn't have the actual project file open, so the software had only the default parameter settings available.

2. The person clicked "download" instead of "upload" and did not read or understand the warning message.

3. The download of EDS-default parameters configured the drive or device for Node 63, Auto-Baud Detect, which is default.

4. When power was cycled days or weeks or years later, the affected drives or devices were all set to Node 63 so they had a MAC ID conflict.

Your system differs at Step 3, so there would have to be some additional mistakes or steps in the process.

The easy (-ish) way to figure it out is to check the DeviceNet settings on the device via a keypad or physical examination.

Were any of these units replaced recently? Is it possible that someone had to repair the wiring on any of these connectors? I only ask because we had an issue a few years ago that was traced down to a set of wires on the connectors that weren't stripped properly. When the connector was plugged in, the wires would occasionally short out if the machine vibrated hard enough. When it was unplugged, there was no strain on the cable or connector so the short went away. It took us a while to find. Unfortunately, I do not remember the fault we were getting back then.

Thanks for the ideas I will hopefully find out Monday and let you know. Have a good weekend.

Certainly short and open circuits in the wiring can be a problem as well, especially on systems that vibrate hard or take a lot of impact and tugging on the cables.

DeviceNet isn't immune to fraying of conductors, or poor stripping of insulation, or loosening of screw terminals. It's just fairly resistant to them.

I was just thinking about this again. Everything is daisy chained with both in and out conductors under a single ferrule. When the 3 nodes are not connected the scanner was showing the missing nodes. 11-12-13?

CENTER, I am not following you. Maybe I have an "English as a second language" problem. When you say "the three nodes" you mean nodes 11, 12 and 13, which are AC drives?
When nodes 11, 12 and 13 are unplugged, is the bus off fault condition cleared? In DeviceNet a bus off condition does not allow any communication to take place as there an internal counter of CRC errors is in the CAN bus controller of the scanner's hardware which if its maximum is reached, the bus controller stops communicating, as per CAN specification.
I think the Rockwell scanner automatically reinitializes the bus controller, but if the error counter reaches its maximum again the scanner goes into bus fault. One device in the network with the wrong baud rate will cause the bus off condition almost immediately. So if you disconnect the nodes that cause the fault (let's suppose the culprits were 11, 12 and 13), the scanner would attempt to reestablish communication and some diagnostic software may indicate that the nodes that are disconnected are missing, because the scanner is trying to reestablish connections but the requests time out, of course, as you have unplugged them.
If this is the case, then the problem is more likely to be what Ken says, in other words, instead of being a wiring/hardware related issue as I originally thought (a physical layer or layer 1 problem), you are dealing with data-link layer (layer 2) problem if the baud rate settings are not the same for all nodes. Hence, the first thing I would advice you to verify is that all nodes are set to the same baud rate, and I recommend you do not use the automatic baud rate recognition mode. It is much better to manually set the same baud rate for all nodes, for the reason Ken explains in his first post above.

When nodes 11, 12 and 13 are unplugged, the bus off fault condition is cleared. Then I go back to how did the baud rate change on 3 of the 6 devices. But don't forget I was working with operators over the phone.

Do these devices have DIP Switches for MAC address and baud rate? Or are these devices configured only by software? If they are only configurable by software, if you do not have a DeviceNet interface and RSNetworx, you will need to use the scanner itself to check and set the baud rate and MAC addresses. If the problem is due to different baud rates, I think the only way you can verify the settings is by connecting only one device at a time to the scanner.

Self-infliced, they should have had a 120 ohm resistor on the scanner itself. Found it on the cabinet floor installed it and every thing worked. Thanks for everyone's input.

Good news.

If the network had insufficient terminating resistors, the troubleshooters should not have measured 60 ohms between the CAN signal wires (blue and white).

It's likely that there were loose or damaged wires and they were fixed on purpose or coincidentally at the same time as the troubleshooters were experimenting with adding or removing terminating resistors.

But that's good to hear that the network is back up !