I am currently experiencing a strange issue with Ethernet IP communication between an ABB CI873 (EthernetIP Module) and a 1756-L83ES. The setup consists of the ABB CI873 connected to a Stratix 5700 switch, which then connects to a 1756-EN2TR with a 1756-L83Es in Slot 0 of the backplane. The ABB CI873 is configured as a Master, receiving information from the CLX via Produced Tags and sending data to the CLX via Class 3 explicit MSG. The Stratix 5700 switch has a basic configuration with just an IP address, Name, and smartports on the Automation Device for both ports used. Despite this, the CI873 encounters a Connection timeout error on the Class 1 Produced Command every 2 minutes before functioning normally for another 2 minutes. The system initially worked flawlessly when directly connected from the ABB Module to the EN2TR card (bypassing the switch). However, when reintroduced to the switch, the issue resurfaced at the same interval. After resetting the switch to its default settings, the system ran smoothly when connected. Any attempt to reconfigure the switch resulted in the recurring problem. Can anyone provide insight into what might be causing this issue?
Fascinating! Today, I discovered that CI873 is the specific part number assigned to the interface module connecting an ABB xA distributed control system with EtherNet/IP networks and Rockwell Automation controllers. Do you happen to know the Required Packet Interval (RPI) that CI873 needs for the Produced Tags from the ControlLogix? Is there an option to establish this connection using Unicast or Multicast? While the Smart Port configuration could be a possible culprit, it may not be the definitive cause. It's possible that the lack of two-way traffic for Produced/Consumed data is causing the port to be removed from the multicast domain every two minutes. One interesting feature of the "Automation Device" SmartPort is its limitation to one MAC ID per port, preventing downstream switch connections. Could CI873 potentially utilize a second or virtual MAC ID, or are redundant CI873 units being used on the link? Consider configuring a mirror port and utilizing Wireshark to identify which device is ceasing communication and if any connection termination messages are being transmitted.
Ken Roach inquired about the RPI setting for Produced Tags from the ControlLogix CI873 and whether it supports Unicast or Multicast connections. Unfortunately, the CI873 only supports Unicast connections. He also wondered if the CI873 utilizes a second MAC ID or if a redundant pair of units is being used, but this does not seem to be the case as both units are isolated on different switches and encountering the same issue. To troubleshoot further, Ken suggested setting up a mirror port and using Wireshark to identify any communication disruptions or termination messages. However, he was unable to download Wireshark due to a lack of internet access and typically relies on Frontline NetDecoder, which he left behind in Alabama while testing in Milwaukee. Ken noted that the issue arose once an IP address was assigned, despite experimenting with different settings like leaving smart ports at none or disabling CIP. He suspected a potential connection to the creation of a Management VLAN during configuration, pointing out that removing the IP address from VLAN 1 resolved the problem. He was planning to replicate the scenario in his lab and provide NetDecoder files for further analysis.
Ken Roach expressed his curiosity after discovering that the CI873 serves as the interface module connecting an ABB xA distributed control system with EtherNet/IP networks and Rockwell Automation controllers. He inquired about the RPI specified for Produced Tags from the ControlLogix and whether the connection can be established via Unicast or Multicast. While the Smart Port configuration appears to be a potential issue, there may be other factors at play, such as the absence of two-way traffic leading to the removal of the port from the multicast domain every two minutes. Notably, the "Automation Device" SmartPort only accommodates a single MAC ID, prohibiting downstream switch connection for access sharing. It prompts the question of whether the CI873 utilizes a second or virtual MAC ID, or if redundant CI873 units are employed in the link. The suggestion to configure a mirror port for Wireshark analysis to identify communication disruptions and potential connection termination messages was also proposed. Ken was successful in setting up a functioning system and replicating the issue with a Stratix 5400, offering access to either Wireshark or Frontline NetDecoder for further investigation. If interested, assistance in troubleshooting the matter can be provided. Thank you.
After some investigation, I found that un-checking the default setting for IGMP Querier resolved the communication issue. Further research revealed that IGMP Snooping functions by directing Multicast/Broadcast messages to specific ports rather than broadcasting them everywhere. This adjustment successfully resolved the problem.
Thank you for the follow-up! In a network with a single managed switch, the combination of IGMP Snooping and Querier features helps to control and limit multicast traffic to specific ports within the multicast domain. While not as crucial as before, as most devices now use Unicast for EtherNet/IP cyclic I/O connections, it's still worth monitoring. You can check the connection type in Studio 5000 or use Wireshark to observe multicast traffic between Logix and ABB-CI873 during data exchange. If you suspect issues with IGMP Querier settings, it could be due to multiple Queriers on the network causing election conflicts. Regularly monitor and adjust these settings to prevent reconfigurations and disruptions. Though not an expert, I have enough knowledge to troubleshoot these issues effectively.
From what you've described, it sounds like the Stratix 5700 switch might be the likely cause of your issue. If the system config worked fine without the switch and resetting it to default settings seemed to temporarily fix the problem, there might be some peculiar tweak in the switch settings that is causing the CI873 to timeout. I would advise checking the port settings, duplex mode, or VLAN configurations on the switch. The problem might arise from miscommunication between the switch and the ABB module due to mismatched parameters. It could potentially be a spanning-tree protocol issue or a function of smartports that you should consider. It's also worth it to make sure the firmware of your switch is up to date. Hope this helps!
It sounds like this issue may be stemming from your Stratix 5700 switch settings. Since you mentioned the system runs smoothly when the switch is reset to default, it's possible the issue reoccurs due to a specific setting being altered during reconfiguration. You might want to take a closer look at those settings, particularly the managed switch services like VLAN segregation, IGMP Snooping, or QoS those can impact the communication significantly. Always ensure that flow control is turned ON, this prevents packet loss in high traffic situations. Ultimately, you might want to experiment with modifications while closely observing how the ABB CI873 responds, or consult directly with Stratix technical support.
It sounds like you've done a thorough job troubleshooting the setup. Given that the connection issue only arises when the Stratix switch is in play, it might be related to the switch's VLAN settings or multicast configuration, which can sometimes interfere with Ethernet/IP communications. You could try checking if IGMP Snooping is enabled and if the switch ports are correctly set to handle multicast traffic. Additionally, if possible, consider monitoring the network traffic between devices to see if any packets are being dropped or if there’s excessive latency when the switch is introduced. Sometimes, even subtle configuration changes can lead to these types of issues, so reverting to the default state seems like a good call!
It sounds like you're dealing with a classic case of networking quirks with real-time protocols. Since the setup worked perfectly when directly connected, it seems like the switch configuration could be the root of your problems. Have you considered checking the Quality of Service (QoS) settings on the Stratix 5700? Sometimes, these settings can impact communication, particularly with time-sensitive protocols like Ethernet/IP. Ensuring that your ports are configured for the right VLAN settings and that there are no unnecessary broadcast storms or other network issues might help stabilize the connection. Also, double-check the firmware versions on both the switch and the CI873, as mismatches can occasionally lead to unpredictable behavior.
✅ 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 issue might be related to a Connection timeout error on the Class 1 Produced Command occurring every 2 minutes before functioning normally. This problem resurfaces when connected via a Stratix 5700 switch, despite working fine when directly connected.
Answer: - The setup involves the ABB CI873 connected to a Stratix 5700 switch, which then connects to a 1756-EN2TR with a 1756-L83ES in Slot 0. The ABB CI873 acts as a Master, receiving information via Produced Tags and sending data via Class 3 explicit MSG.
Answer: - Despite resetting the switch to default settings resulting in smooth operation, any attempt to reconfigure the switch leads to the recurring problem. This suggests that the switch configuration might be causing the issue.
Answer: - Troubleshooting steps may involve checking the switch configuration, verifying network settings, examining cable connections, and ensuring compatibility between devices
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.