Does anyone have insight on the conditions necessary for Rockwell to switch a Module Status from Running to Comm Loss when pulling via GSV? Similarly, what are the requirements for Rockwell to activate the "ConnectionFaulted" bit in the "CONNECTION_STATUS" Type of a Produce Consume UDT?We are experiencing intermittent trips of these statuses and are struggling to pinpoint the root cause. Despite thorough searches, we have been unable to locate this information in Rockwell literature.
In general, a cyclic EtherNet/IP connection is considered lost due to a timeout if 4 times the RPI has elapsed without the Originator (the PLC) receiving a data frame from the Target (the I/O adapter). This applies to both Produced/Consumed Tags and I/O connections. Although the EtherNet/IP specification allows for the timeout to be set at any multiple of the RPI, in my experience, Rockwell products typically use a multiplier of 4 and do not offer adjustment options. Each production of cyclic data is assigned an incremental transaction ID. By capturing data frames with Wireshark, you can observe the transaction IDs increasing with each transmission. Analyzing these IDs can help identify missing values. The connection statistics webpage on the controller will also flag missed packets, indicating potential packet loss within the infrastructure.
Ken provided a detailed explanation on the concept of "Comm Loss" in IO status. When querying the EntryStatus using GSV and masking it, several possible states can be derived. These states include Standby, Faulted, Validating, Connecting, Connected, Shutting Down, Inhibited, Waiting, Reconfiguring, Firmware Updating, and Configuring. To describe the state of being offline, terms like CommLoss, Disconnected, LinkDown, or Offline can be used. The logic of wanting the device to be connected but it isn't due to inhibition best represents this state. The term Sts_Offline may be preferred, or perhaps Sts_Down. Ultimately, the key is understanding that a connection being inhibited does not necessarily indicate a complete Comm Loss situation.
Ken, thank you for providing the essential information I needed to troubleshoot effectively! Jeremy, your insight is on point! The AOI being utilized examines various statuses and classifies them as Down if they are not inhibited or connected. It can be a challenge to determine the level of detail to include in my posts, as there is a constant balance between the importance of details and the tendency for readers to only skim the first few sentences.
I am currently addressing an intermittent issue and made an intriguing observation while working on it. I implemented the same logic to log communication failures in both PLCs that are exchanging data. Last night, PLC1 detected a 2.7s period where the .ConnectionFaulted (Connection Status datatype) of the received tag from PLC2 turned true. Surprisingly, PLC2 did not register a .ConnectionFaulted status for the tag received from PLC1. As of now, PLC1 has recorded 5 communication losses, while PLC2 has only recorded 1. This discrepancy is puzzling to me. How is it possible to experience communication loss from PLC2 to PLC1, as seen in PLC1's logs, without experiencing the same loss from PLC1 to PLC2 at the same time?
JankyPLC noted: I am still troubleshooting an intermittent issue and made an interesting observation. I implemented identical logic in both PLCs that exchange data with each other to log communication failures. Last night, PLC1 detected a 2.7-second period where the .ConnectionFaulted (Connection Status datatype) of the data received from PLC2 turned true. However, in PLC2, the .ConnectionFaulted bit of the data from PLC1 did not turn true. Currently, PLC1 has recorded 5 communication losses, while PLC2 has only registered 1. This discrepancy is puzzling. How could there be communication losses from PLC2 to PLC1 as documented in PLC1, while there are no communication losses from PLC1 to PLC2 as observed in PLC2 simultaneously? Could the PLC that did not detect the issue have been placed into Program mode?
From my experience with Rockwell PLCs, a 'Comm Loss' status usually indicates a break in communication between the controller and the particular module - this could be due to a variety of issues. I'd suggest checking your network infrastructure, cable integrity, network load, or even a faulty module. Regarding the 'ConnectionFaulted' bit, it typically activates when there's an issue with the communications path to the consumed tag. It might be the case that the producer of the tag is not available or there's an error at the network level. It often requires a bit of sleuthing to pinpoint the exact cause, but ensuring your system's network is stable is a good start.
Based on my experience, a transition to "Comm Loss" status could be due to multiple reasons, ranging from an interrupted network connection to a break in the data path. First, confirm whether there are intermittent network issues or any problem with the Ethernet cable. Secondly, verify your firmware version, because an outdated version may lead to inconsistent behavior. As for "ConnectionFaulted" bit triggering, it's typically triggered when the connection can't be established or when it's lost during operation- this could be due to timeouts or communication glitches. Applying the latest corrective patches and updates from Rockwell may combat these issues.
✅ 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: 1. What are the conditions necessary for Rockwell to switch a Module Status from Running to Communication Loss when pulling via GSV? - Rockwell typically switches a Module Status from Running to Communication Loss when there is a loss of communication between the module and the controller. This could be due to network issues, wiring problems, or configuration errors.
Answer: - The "ConnectionFaulted" bit in the "CONNECTION_STATUS" Type of a Produce Consume UDT is activated when there is an issue with the connection between the producing and consuming devices. This could be caused by network interruptions, configuration mismatches, or hardware failures.
Answer: - Intermittent trips of Module Status and "ConnectionFaulted" bit activations in Rockwell systems could be caused by various factors such as intermittent network issues, fluctuating signal strength, loose connections, or incompatible firmware versions between devices.
Answer: - Detailed information about Rockwell's Module Status changes and "ConnectionFaulted" bit activations can usually be found in Rockwell's technical documentation, user manuals, or knowledge base articles. If you are unable to locate this
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.