1756-DNB Ser.D Bus-Off Error

[Jaco van Niekerk]

Hi good day PLC Talk Community.

Can somebody please shed light on 1756-DNB Diagnotic Counters and what they mean. DNB Scanner Diagnostic Counters can be accessed under RSLinx as per attached photos, one with diagnostic error counts & the other where I have cleared the counters.

I'm on a mission to try & understand trouble shooting of Bus-Off error experienced and their causes. Reading up on Rockwell 's DNB Manual & Knowledge Base on how to identify and fix Bus-Off errors unfortunately doesn't help me with an effective method to pin point the origin or root cause their of which can be a bit of a nightmare.

Today I had a faulty DNet Comms Module, RDNA-01 had a Network Status Error, replaced of an ABB ACS800 VSD after experiencing a Bus-Off error on the DNB Scanner. It was purely just a guess, DNB Scanner is now Running for about 7hrs without any further Bus-Off errors, time will tell. How & why the RDNA-01 DNet Comms Module can possibly cause a Bus-Off error on the DNB Scanner cannot be proven by me, or at least I don't know how to. I have also previously experienced Allen Bradley DNet Comms Modules on Power Flex VSDs causing Bus-Off errors (Different Scanner) especially when a whole lot of them (Devices) are removed from the Devicenet Network when a MCC Power Failure is experienced. What causes the Bus-Off in this case? Thank you.

Kind Regards;

Jaco van Niekerk.

 

[AlfredoQuintero]

Hello Jaco.
In general CAN bus errors (DeviceNet is based on CAN), can be caused by two main reasons.
The first is the one I do not think is causing your problems, so I explain it first. If for some reason a device in the segment has a baud rate different to the baud rate set to the scanner and other other nodes, this immediately causes can bus errors and if the counter of the scanner goes beyond 256 the scanner will go to the bus off condition (that is no more transmission or reception), until the scanner is restarted. Some scanners do this automatically after some time, others require manual action. When commissioning a DeviceNet network this could happen, or when a particular device is replaced and the DIP SW is set to the wrong baud rate, this could happen.

But if you have a machine that has been working for years and out of the blue you start seeing these problems, then the cause is generally more difficult to find because it is due to bad media. That can be bad termination (too many or too few termination resistors), or some DeviceNet connector where some of the screws became a bit loose and there is poor contact. Maybe there is a short somewhere.
If you to not have NetMeter or some diagnostic tool, you will have to disconnect nodes one by one, and see if the error generation stops after you disconnect a particular node. If there is any sealed micro M12 field-attachable connector watch our because these are not easy to assembly and the CAN_H signal can short the shield.
It could also be that the length of the cable exceeds the values specified in the ODVA spec, or that the cumulative length of the stub exceed the values in the spec. But in that case you would have been seeing the problems long ago. In the ODVA website there is a very good publication that explains wiring and troubleshooting of DeviceNet networks.
https://www.odva.org/wp-content/uploads/2023/05/PUB00027R1_Cable_Guide.pdfhttps://www.odva.org/wp-content/uploads/2023/05/PUB00027R1_Cable_Guide.pdf
https://www.odva.org/wp-content/upl...viceNet-Plant-Floor-Troubleshooting-Guide.pdfhttps://www.odva.org/wp-content/upl...viceNet-Plant-Floor-Troubleshooting-Guide.pdf

Finally, it could be that one particular device is damaged and requires replacement. That is unusual, but if this was the case, the moment you disconnect that device the CAN error generation should stop.
Hope this helps. Good luck.

 

[Jaco van Niekerk]

Hi Alfredo.

Thank you for the comprehensive reply. Unfortunately for me I don't have a NetMeter or some diagnostic tool to help identify the problem area, if you can suggest a Netmeter one can purchace perhaps to make life a bit easier it would be appreciated. Thus, disconnecting devices one by on during planned shuts will be my forté.

I've started a new job about 7 months ago, hence the bus-off issues experienced is my biggest headache at this point in time as there are no one that can really supply me with past history regarding this issue besides the usual 'it never used to be like this".

Replacing the ABB ACS800 VSD Comms Module, RDNA-01, seems to have helped for now as no bus-off errors has been experienced for 6 days running thus far.

The other DNet Network's Scanner has just about every error counter continuously running/accumulating when viewed via RSLinx, which in this case I'll propably have to put in the hard yards & disconnect each device in turn as to see which one/s is causing a bus-off especially when 4 x Devices or more are lost in the event such as a MCC power failure to Allen Bradley Power Flex VSDs. Checking of baud rates will be checked as well.

Kind Regards;

Jaco.

 

[AlfredoQuintero]

Jaco, hi.
OK, so this ABB ACS800's RDNA-01 has provided a good hint.
Unfortunately the NetMeter was discontinued by Molex.
You can try your luck at eBay.

There is a tool called CANbus Tester 2 from GEMAC with a very good add-in that can figure out the MAC IDs of the nodes as they are communicating, and thus can plot in real time the wave form of each MAC ID, which you would not be able to figure out with an oscilloscope unless you were willing to spend hours studying the DeviceNet specification, and I am sure you have more pressing things to do, fun as though it may be. Seeing the wave form indicates you which nodes in the segment have a good wave and which have a bad shape. Usually if you have a media problem, where the nodes waves start getting bad is the first place to have a look (loose screws, maybe a cable that has been crushed by a machine, a cable submerged in oil, whatever).
Unfortunately, this tool would set you back over EUR 5K plus shipping charges from Germany.
https://gemac-fieldbus.com/en/can-bus-tester-2/

But since it seems the problem in your case is a specific node, maybe this hack could help and it may be cheaper than CANBusTester2. If you can get two CAN to fiber-optics repeaters, such as the ones in the link below, instead of disconnecting node by node you could "electrically" isolate one or several nodes in the DeviceNet segment by plugging the two repeaters connected to each other via a short fiber link, thus allowing all nodes in the PLC program's scan list to communicate. The fiber optic bridge will separate a bad segment from the good one. I hypothesize that when you find the offending node you can prove this is the bad node if the number of CAN errors diminish significantly in RSLinx when using the CAN repeaters, compared to the condition in which this device is connected directly to DeviceNet.
Good luck.
http://www.adfweb.com/home/products/optics_fibres_can_bus_repeaters.asp?frompg=nav11_2&loc_phy=1009343&k001=p&cmpg1-k1=can%20bus%20over%20fiber%20optic&d=c&pos=&gclid=Cj0KCQiAv8SsBhC7ARIsALIkVT3uBf6qvUWKfj0Cs666GkZ0Nupdox4rXk_0Z7gJfRD47ZXIkyYK1vwaAsQdEALw_wcB

 

[Jaco van Niekerk]

Hi Alfredo.

I'll investigate the Canbus Tester 2 as it would be very useful to be able to determine which MAC Address or problem area noise on the bus originates from as I unfortunately don't always have time to disect the network by means of oscilloscope anylises.

The CAN Repeaters is a viable method in electrically isolating the good/bad parts of the segment.

All Of the Best For 2024 & the New Year.

Thank you.

Kind Regards;

Jaco.