Hello PLC Talk Community! Can anyone provide insight on the 1756-DNB Diagnostic Counters and their significance? These counters can be accessed through RSLinx, as shown in the attached photos, which display diagnostic error counts and the process of clearing the counters. I am on a quest to enhance my troubleshooting skills for Bus-Off errors and understand their root causes. Despite reviewing Rockwell's DNB Manual and Knowledge Base, I am still struggling to pinpoint the exact origin of these errors, which can be quite challenging. Recently, I encountered a Network Status Error on a faulty DNet Comms Module, RDNA-01, which led to a Bus-Off error on the DNB Scanner. Although it was a guess, replacing an ABB ACS800 VSD seemed to resolve the issue, as the DNB Scanner has been running smoothly for about 7 hours now. However, I am still unsure of how and why the RDNA-01 DNet Comms Module could trigger a Bus-Off error on the DNB Scanner. I have also observed Bus-Off errors caused by Allen Bradley DNet Comms Modules in Power Flex VSDs, particularly when multiple devices are removed from the Devicenet Network during an MCC Power Failure. What could be causing these Bus-Off errors in such scenarios? Your insights are greatly appreciated. Thank you. - Jaco van Niekerk
Hello Jaco. CAN bus errors, which DeviceNet is based on, can stem from two main causes. The first cause, which I don't believe is the issue in your case, is when a device in the segment has a different baud rate than the scanner and other nodes. This mismatch can lead to CAN bus errors, potentially triggering the scanner to enter a bus off condition if the scanner's counter exceeds 256. This can require manual intervention or an automatic restart. When setting up a DeviceNet network or changing devices, this discrepancy may occur. However, if you've had a machine running smoothly for years and suddenly encounter these issues, the root cause is likely related to faulty hardware. This could be due to poor termination, loose DeviceNet connectors, or a short circuit. To troubleshoot, try disconnecting nodes one by one to pinpoint the source of the error. Additionally, check for any sealed micro M12 field-attachable connectors that may be causing signal shorts. It's also possible that the cable length exceeds ODVA specifications or the cumulative length of stubs surpasses the recommended values, though these issues would typically manifest earlier. The ODVA website offers a helpful publication on wiring and troubleshooting DeviceNet networks. Ultimately, if all else fails, it may be necessary to replace a damaged device causing the errors.Disconnecting this device should stop the error generation. Good luck in resolving the issue.
Hello Alfredo, Thank you for your detailed response. Unfortunately, I do not have a NetMeter or any diagnostic tool to help pinpoint the issue. If you could recommend a NetMeter for purchase, it would greatly simplify the process. In the meantime, I will continue to manually disconnect devices during planned shutdowns. I started a new job about 7 months ago, and the bus-off issues are currently my main challenge. There is limited information about past incidents, with most people simply saying "it never used to be like this". Replacing the ABB ACS800 VSD Comms Module, RDNA-01, seems to have temporarily resolve the bus-off errors. The DNet Network's Scanner is showing continuous error counters when viewed through RSLinx. I will need to systematically disconnect each device to identify the culprit, especially during situations where multiple devices are lost like during a power failure in the MCC to Allen Bradley Power Flex VSDs. Additionally, I will be checking the baud rates. Thank you for your understanding. Best regards, Jaco.
Hello Jaco, it's great to hear from you. The ABB ACS800's RDNA-01 has given us a helpful clue. Unfortunately, the NetMeter by Molex has been discontinued. You may want to try your luck finding it on eBay. Alternatively, GEMAC offers a tool called CANbus Tester 2 that can help identify MAC IDs of communicating nodes in real-time. This tool can plot the waveform of each MAC ID, providing valuable insights that would be challenging to decipher with just an oscilloscope. By analyzing the waveform, you can determine which nodes in the segment have good or bad communication signals, which can indicate potential issues like loose screws or damaged cables. While the CANbus Tester 2 is a bit pricey at over EUR 5K, there may be a more cost-effective solution for isolating specific nodes in the DeviceNet segment. Using two CAN to fiber-optics repeaters can help electrically isolate problematic nodes, allowing the PLC program's scan list to communicate effectively. This method can help identify the faulty node by observing a decrease in CAN errors when using the repeaters. Good luck with resolving the issue with your DeviceNet segment! If you'd like to explore the fiber optics repeaters option further, check out the link provided for more information.
Hello Alfredo, I am interested in exploring the Canbus Tester 2 as it could greatly assist in identifying MAC Addresses or identifying noise sources on the bus. This tool would save time compared to analyzing the network with an oscilloscope. The use of CAN Repeaters is an effective way to isolate the good and bad parts of the segment electrically. Wishing you all the best for 2024 and the upcoming New Year. Thank you and kind regards, Jaco.
Hello Alfredo, I am happy to report that the Bus-Off error problem with the ABB ACS800's RDNA-01 communications module has been successfully resolved for over 5 months now. This issue no longer persists, and the D-NET Error Count on RSLINX is no longer increasing. Last week, I encountered and fixed a BUS-OFF Error on another 1756-DNB Module linked to Allen Bradley PowerFlex VSDs. Upon inspection with the Electrician in the MCC, we discovered a duplicate address causing the error. After addressing this issue, the BUS-OFF Error disappeared and the Error Counters have remained stable. In my experience over the past 11 months in my current position, I have learned that BUS-OFF Errors can be attributed to faulty device (VSD) communications modules and duplicate addressing. Best Regards, Jaco
Hey Jaco, your dedication to enhancing your troubleshooting skills is admirable! Now, to your question: the 1756-DNB Diagnostic Counters are essentially a tool to give you a snapshot about the network status at a given moment. They can reveal issues with cabling, termination, nodes, etc. Coming to the "Bus-off" error you mentioned, this is typically brought about when the DNet detects serious faults on the network, causing it to quit its attempts to transmit data. The RDNA-01 DNet Comms Module could trigger such an error if it has a hardware fault or if there's an issue with the network connection itself, such as a short or an open circuit. During a power failure, if multiple devices get removed from the network, the sudden change might cause a network fault, leading to Bus-off errors. You can leverage the 1756-DNB counters to help locate the node that's causing the problem. Look for counters that are incrementing quickly as it might narrow down the problematic node. Sometimes, isolating sections of the network and monitoring the error count can be a practical approach.
Hi Jaco, Bus-off errors can be a real headache, especially when the root cause isn't obvious. They usually occur when a device in the network fails to receive or send a message correctly. The 1756-DNB diagnostic counters can help shed light on these issues as they provide a "health check" for each device on the network. However, they're not always straightforward to interpret. In your case, a Bus-Off error on DNB Scanner following a Network Status Error on the RDNA-01 DNet Module might signify a communication issue between the two modules. Because Devicenet is master-slave network, if your DNet Comms Module (master) gets faulty, it can affect your DNB Scanner (slave) hence triggering the Bus-off error. The replacement of the ABB ACS800 VSD could have resolved a possible intermittent communication issue between the devices. As for your observation about the power failure, the sudden power cut could disrupt the communication cycle, causing these modules to enter into Bus-Off state. This is more likely when multiple devices disconnect at once. For more accurate diagnosis, you can try using DeviceNet analyzer tools.
Hi Jaco! It sounds like you're dealing with some complex issues involving the DNB Diagnostics and Bus-Off errors. From my experience, Bus-Off errors can often be linked to physical layer issues—like wiring problems, device misconfigurations, or improper terminations—especially when dealing with multiple devices on the network. The RDNA-01 might be causing this due to a faulty communication link that could disrupt the entire bus when it goes offline, impacting the other devices connected to it. Since replacing the ACS800 seemed to stabilize your system, it suggests that it might have been causing excess network traffic or faults that the DNB Scanner couldn't handle. It could be worth double-checking the power requirements and ensuring that all device settings align correctly. Keep an eye on that setup, as intermittent faults can sometimes be elusive!
âś… Work Order Management
âś… Asset Tracking
âś… Preventive Maintenance
âś… Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - The 1756-DNB Diagnostic Counters provide error counts and can be accessed through RSLinx. They are useful in identifying issues and monitoring the health of the network.
Answer: - Bus-Off errors in Devicenet networks can be caused by issues such as faulty DNet Comms Modules, power failures in MCCs, or the removal of multiple devices from the network.
Answer: - Resolving Bus-Off errors triggered by specific devices may involve replacing the faulty device or conducting a thorough troubleshooting process to identify and address the root cause of the errors.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.