Hello everyone, seeking advice for a specific issue we are experiencing. Currently, our controlnet bus consists of (6) CN2DN devices and (2) PowerFlex 700's. We have encountered instances where multiple CN2DN devices fail, while the VFDs remain operational. Most of the devices connected to the CN2DN are E3P overloads. To troubleshoot, we conducted tests by disconnecting various points in the loop, such as the 'A' bus, to observe the network's reaction and attempt to replicate the issue. Typically, disconnecting the 'A' bus results in a switchover to the 'B' bus. However, there have been cases where disconnecting at specific locations causes certain nodes to drop out. To clarify the situation, it appears that the CN2R/B card is not indicating a fault. Instead, the fault is being triggered by the CN2DN devices. Our current AOI examines the CN2DN Device failure registers, in addition to a MSG instruction (CIP Generic) that references f0 Instance 1 Attribute 83 to identify faults on the CN2DN devices. If more information is needed to provide further assistance, please don't hesitate to reach out.
Upon reading your post this morning, I recalled a past experience that might be helpful to you. Several years ago, I encountered an issue with ControlNet while working for a board manufacturer. We had a ControlNet scanner/adapter board integrated with a robot arm controller for welding applications. The noise generated by the robot's motion control caused communication errors on the ControlNet bus. After seeking assistance from Rockwell, we were advised to ground all the robots to a single point in the building, which resolved the issue. Before attempting any solutions, it is recommended to monitor the error counters on the ControlNet interfaces for unusual counts. A stable network should have minimal error rates. If errors persist, addressing grounding issues may be necessary. It is important to reference Rockwell documentation for ControlNet specifications to ensure proper troubleshooting.
How can the 1788-CN2DN modules be brought back online? Do they recover automatically or require a manual reset or a reconfiguration of the ControlNet system? Your system may be experiencing multiple issues. It is possible that there is faulty media or interference on Channel B. Additionally, there may be a factor causing the 1788-CN2DN modules to restart or disconnect from the ControlNet simultaneously, such as a shared DC power supply dropping below the required operating level (typically 18V for these units). There may also be a heavy load or voltage discharge on a DeviceNet network causing disruptions that affect the ControlNet system as well. Many systems power the 1788-CN2DN modules from the DeviceNet network power supply, but this setup eliminates the advantages of isolation and independence between system components. It is unclear whether the classic 1788-CN2DN modules have removable CNet and DNet daughter cards like the FlexLogix, or if everything is fixed in place. Issues like corrosion or wear would likely not impact all modules simultaneously. Diagnostic steps could involve monitoring the ControlNet media counter objects from all network nodes to observe any increases at specific times. In past experiences, having a ControlNet signal meter helped in isolating individual node broadcasts for analysis on an oscilloscope, as well as provided LED indicators for signal quality at each node number. This tool was used in combination with media counters and status objects, along with referencing protocol specifications for GSV and messaging details.
Upon further examination, it was confirmed that the 1788-CN2DN module is equipped with its own independent control power supply, located on top of the device, and does not draw logic power from the DeviceNet. Even when the power from DeviceNet is turned off, the module can still be connected and operated through ControlNet.
AlfredoQuintero shared: Good morning! After reading your post, I couldn't help but think of a couple of forum members who are experts in this field. While my experience with ControlNet dates back several decades and I may not have the technical expertise, I do recall a similar issue I faced in the past. I was working for a board manufacturer that utilized a ControlNet scanner/adapter board for various applications, including robot arm controllers for welding. The noise interference from the robot's control system was causing communication errors on the ControlNet bus. With help from Rockwell, we resolved the issue by connecting all the ground wires from the robots to a single point in the building. This simple solution significantly improved communication. If you are experiencing errors with ControlNet, it's worth checking the error counters in the interfaces and consulting Rockwell's documentation for further guidance. Remember, a reliable network should have minimal error rates. If errors persist, addressing grounding issues may be necessary. Regarding your experience with Rsnetworx for ControlNet, it's not uncommon to encounter difficulties with the software. In our tests, we also noticed that disconnecting the 'A' bus did not always trigger a network refresh. Have you had a chance to use the 1788-CNCHKR device before?
Ken Roach asked about methods for bringing the 1788-CN2DN units back online. Will they recover automatically, or do they need a manual reboot or ControlNet re-schedule? There may be multiple issues at play, such as bad media or noise on Channel B and potential power supply problems causing the units to reboot. Systems powering the 1788-CN2DN from the DeviceNet network may lose benefits like isolation. Diagnostics could involve monitoring ControlNet media counters and analyzing node broadcasts with a ControlNet signal meter. Troubleshooting the network during an upset can be challenging when the CN2DN units come back online immediately. Checking redundant DC power supplies and using appropriate diagnostic tools, such as RSNetworx for ControlNet, may help. The older ControlNet signal meter model, 1788-CNCHKR, is obsolete, but it was useful for monitoring signal quality. Disconnecting bus lines for testing purposes can help identify issues, such as a CN2DN unit going down due to a bad signal on one bus line.
If the CN2DN devices are the one's tripping with the PowerFlex 700's remaining fully operational, it possibly signifies an issue with the network communication between devices or a concern with the CN2DN devices themselves. Have you tried swapping a well-functioning CN2DN with a failed one to see if the problem persists? Also, considering you're using E3 overloads, have you thoroughly inspected these for any signs of faults? Additionally, I'd suggest checking your AOI failure registers and ensure they are correctly set up to detect any faults. At least by doing this, you can possibly narrow down the root cause of the problem between either a hardware issue or a programming glitch.
It sounds like you've already done a fair bit of testing and troubleshooting. From my understanding (and experience with a similar issue), the problem might lie within either the wiring or settings involving your CN2DN devices. Something you could consider testing is replacing or checking the cabling and connections to these devices, especially if it was a setup inherited from a previous system. Another possible reason might be network loads and timeouts. Ensure that your network traffic isn't overloading capacity or that timeouts aren't set too narrowly causing devices to drop out. Furthermore, do inspect if there are any software/firmware updates needed for your devices. I hope this helps, and good luck with your troubleshooting!
Hello! I've also worked with similar issues in a ControlNet system before. From your description, it sounds like there might be a redundancy failure in the 'B' bus whenever you disconnect the 'A' bus. This could be due to several reasons like issues with your cable, connectors, or terminators. Also, the CN2DN devices failing points towards a possible fault tolerance issue. You might want to check your power supply levels and the status of your ControlNet taps. Additionally, deploying some network diagnostic tools may shine a light on whether you've got signal quality problems or repeater issues. Don't overlook minor things such as IP addresses, the CN2DN configuration, and the compatibility of your devices with the current ControlNet version. Did you also validate if your AOI includes all possible fault code checks for the CN2DN devices?
It sounds like a complex issue you're having there. I first recommend checking for possible ground loops or noise on the network. Often overlooked, these factors could be affecting the performance of the CN2DN devices. Additionally, consider updating the firmware of the CN2DN devices if it hasn't been done yet. Sometimes out-of-date firmware has compatibility issues with newer devices or features. I would also suggest addressing power quality issues, if any. A sag or swell in your power supply might cause temporary power loss that resets the devices. Lastly, if the issue persists, it would be beneficial to engage with a field service expert or the manufacturer directly for more specialized guidance.
It sounds like you've already done a thorough job of troubleshooting the setup! One thing to consider might be the grounding and wiring conditions of the CN2DN devices, as intermittent faults can sometimes be linked to noise or grounding issues that aren’t immediately obvious. Additionally, double-checking the configuration settings for the E3P overloads might reveal if there’s an overlap or a particular configuration that’s causing the failures. Have you tried updating the firmware on the CN2DN devices? Sometimes, updates can resolve underlying issues that might not be apparent until they cause more significant problems. Keep us posted on your progress!
It sounds like you're dealing with a pretty complex issue! Have you checked the cabling and connections for any loose or corroded points? Sometimes, physical layer problems can lead to unexpected node dropouts, even if the control cards are functioning properly. Also, since you mentioned the overload devices, it might be worth looking into whether they are signaling any intermittent issues or if their load ratings are being pushed beyond limits intermittently, which could affect the CN2DN communication. A scope might help you visualize what's happening on the bus when these failures occur. Good luck, and keep us posted!
✅ 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: This could be due to specific issues within the CN2DN devices themselves, separate from the VFDs. Troubleshooting may involve isolating the problematic devices and examining their functionality and connections.
Answer: One approach could be conducting tests by disconnecting various points in the loop to observe network reactions and replicate the issue. Monitoring how the network behaves when certain connections are altered can provide insights into the root cause of the failures.
Answer: While the CN2R/B card may not be indicating faults, the issue seems to be triggered by the CN2DN devices. It's essential to investigate the CN2DN Device failure registers and utilize MSG instructions to pinpoint faults accurately.
Answer: By utilizing these tools, you can identify specific faults on the CN2DN devices, aiding in
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.