I am currently in the process of setting up a Parallel Redundancy Protocol (PRP) system in a laboratory environment. The L73 PLC is located in rack 4, with 3 IO racks numbered 1, 2, and 3. Previous discussions about this system can be found at https://www.plctalk.net/qanda/showpost.php?p=937884&postcount=1. Following feedback from Rockwell network engineers on an updated version of the network sketch, the PRP network has been approved as compliant with PRP rules. Necessary parts have been ordered and have now been delivered. Hardware has been installed, connected, and is operational. My focus now is on detecting and addressing failures before they impact the process (i.e. equipment malfunction due to communication issues). Racks 2 and 4 feature a 1756-EN4TR set to mode 4 (PRP), while racks 1 and 3 have 1756-EN2TP modules. Each rack is equipped with 2 cat6 copper connections - Channel A connects to a Stratix 5400 switch, and Channel B to a Stratix 5410 switch. The configuration of the Stratix switches is pending approval from the IT department. Currently, communication is functional without any issues between the racks. Redundant power supplies and cabling are in place for each switch and module. I am working on implementing a system to detect and alert on single points of failure, such as network cable disconnection, retries, CRC errors, etc. In my research, I have come across recommended messages for each rack but it is unclear what the bits in the returned DINT represent. I am also monitoring message instructions for .ER, but it seems to have a 30-second delay in detecting an unplugged cable. I am seeking input from others experienced with PRP systems and their strategies for detecting and addressing issues promptly. If you have any insights to share, please do so.
I am currently experimenting with this setup in a lab environment. You can find the EIP_Diagnostics_AOI in the Rockwell sample library for testing. Although it may be challenging to use it without faceplates, you can simply enter your path in the EIP_NodeTable.Public_Operations.Set_NewNode and input a 1 in EIP_NodeTable.Public_Operations.CmdCreateNewNode. This will help you add the module to EIP_NodeTable.Public_NodeTable[1], and each subsequent creation will contribute to the array of nodes. This feature allows me to access a wealth of module data, including link status.
Forebiz mentioned that they are currently experimenting with EIP_Diagnostics_AOI in a lab setup. They suggested checking out this AOI in the Rockwell sample library. Without the use of faceplates, navigating the AOI may be a bit challenging. By entering your path in EIP_NodeTable.Public_Operations.Set_NewNode and inserting a 1 in EIP_NodeTable.Public_Operations.CmdCreateNewNode, you can add the module to EIP_NodeTable.Public_NodeTable[1]. Each additional module you create will be added to this array of nodes, allowing for easy access to a wealth of data, including link status. Thank you for your feedback. I am encountering difficulties locating the EIP_Diagnostics_AOI. Despite searching for it under Sample code on the Rockwell website, no results are found. Searching for just AOI yields 191 results, none of which are the EIP_Diagnostics AOI. I am currently using V33.01 of Studio and it seems that the various sample code bundled with the Studio package does not list the EIP_Diagnostics AOI. Could you please direct me to where I can find this AOI?
When searching for information, I was unable to locate it initially. However, upon searching for 94841, I discovered a resource titled "EtherNet/IP Diagnostics Faceplates for ME and SE V3.1." While my original search term was EN2TR, similar results can be found using EN4TR as well.
Forebiz mentioned that the search for "EtherNet/IP Diagnostics Faceplates for ME and SE V3.1" under code 94841 yielded the desired results. Originally sought through EN2TR, the same logic can be applied for EN4TR. A helpful link provided on the Rockwell Forums allows access to the necessary AOI without the need for a service agreement, making it accessible even when not logged in. You can find the download link here:https://www.rockwellautomation.com/...29fd-f3ff-d748-41975636ab5b;deepLinking=false. Thank you for the assistance!
The AOI system has been successfully installed and set up in the lab, with 4 racks connected to 2 Stratix switches as explained earlier. We plan to run tests over the Christmas break to ensure the code operates smoothly. Although the AOI user interface lacks the convenience of Factorytalk View, it still functions properly. In January, we will commence testing to confirm that any potential failures on the rack side (such as disconnected Ethernet cables, cable damage, or port speed issues) are promptly detected and alarmed. The Stratix AOI will be integrated into the lab program once the IT department finalizes the configuration and IP addresses. Through the Stratix AOI, we will also check for any failures on the switch side (like power supply issues, removed SFP, disconnected network cables, or network noise) to ensure comprehensive monitoring.
Looks like you've made considerable headway in setting up your PRP system. Regarding your query about detecting and resolving issues in a prompt manner, it's crucial to establish a comprehensive monitoring system. You can use automated tools like Nagios or PRTG which are capable of detecting network issues within seconds of occurrence. As for the bits in the returned DINT, each bit signifies a state or an event - you would need to refer to your PLC's manual for detailed explanations. On another note, if the .ER message instruction takes too long to determine an unplugged cable, you might want to consider using direct rack I/O status tags which are quicker albeit requiring more extensive coding. It's also useful to remember that prevention is better than cure – make sure you have robust cabling and secure connections to minimize cable-related issues. Keep up the good work!
Your setup appears to be quite robust and well thought out. From my experience, if you're working with PRP, you might want to consider implementing a diagnostic routine using the GSV (Get System Value) and SSV (Set System Value) instructions to gather real-time module information. These instructions provide a wealth of real-time diagnostic data which can aid in early detection of failure points. For the .ER issue, remember that this data is polled, which means it might not be the quickest way to detect cable disconnects. Maybe try exploring more dynamic methods for cable health monitoring.
✅ 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 key components of a PRP system in a laboratory environment typically include PLCs, IO racks, network switches (such as Stratix switches), and redundant power supplies with cabling connections.
Answer: - Failures in a PRP system can be detected and addressed by implementing systems that monitor for single points of failure, such as network cable disconnections, retries, CRC errors, etc. Additionally, setting up alerts and monitoring message instructions can help in detecting issues promptly.
Answer: - Racks 2 and 4 typically feature 1756-EN4TR modules set to mode 4 (PRP), while racks 1 and 3 have 1756-EN2TP modules. The 1756-EN4TR modules are tailored for PRP applications, while the 1756-EN2TP modules serve other networking purposes in the system.
Answer: - The bits in the returned DINT represent various information related to the status of the rack
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.