I am currently troubleshooting a Compact GuardLogix 5380 CPU [5069-L306ERS2] installation facing a unique issue that is new to me. This CPU is overseeing a network of 8 nodes, a setup commonly found in various fields with minor differences. Recently, we upgraded from Kinetix 300 drives to Kinetix5100. The problem arises when the CPU runs for approximately 5 minutes, triggering an error that turns the OK led red and disrupts ethernet communication. The error lasts a few minutes before the system automatically recovers, resumes operation, only to repeat this cycle continuously. During the error, all nodes on the network respond to pings except the CPU. Although no ethernet errors are recorded when the CPU is online, no significant or minor faults are logged either. I attempted logging faults in the controller fault handler, but all values show zero once communication is restored. I am remotely diagnosing the issue through a secure Tosibox tunnel, ensuring the network remains isolated from external connections. Does anyone have suggestions on how I can identify the root cause of this recurring fault?
Diagnosing issues remotely can pose challenges. Is there anyone available on-site who can provide assistance? If I were there with a managed switch, I would configure port mirroring to analyze traffic with Wireshark directed to the controller. This way, we can investigate if the issue is consistently triggered by a specific packet.
When dealing with remote diagnostics, the lack of on-site support can pose challenges. If someone is available locally, could they offer assistance? If I were present with a managed switch, I would suggest setting up port mirroring to analyze traffic to the controller using Wireshark. This could help determine if a specific packet is consistently causing the issue. Unfortunately, the site currently utilizes unmanaged Stratix 2000 [1783-US8T] switches, limiting diagnostic capabilities. It is uncertain whether the problem stems from an Ethernet issue or an error within the CPU preventing communication during errors.
Could a corrupt SD card be causing the program to fail to load, resulting in the controller crashing? It's possible that you're unable to access fault information if the program is constantly being reloaded from the SD card.
dmroeder inquired if an SD card is set up to reload the program in case of corrupted memory. It is possible that the controller crashes, making it difficult to access fault information as the program is reloaded from the SD card. The first thought is that the controller may be resetting for unknown reasons, as indicated by the red OK LED during power-up diagnostics.
I suspect the issue may be related to power, although I have limited experience with Compact GuardLogix systems (my first one is currently unopened). I conducted a power cycle test with my 5370 (1769-L33ER) and observed all LEDs turning off immediately, with the OK light briefly flashing red. Once power is restored, the OK light turns red while the system reboots. During this process, the system is inaccessible and cannot be pinged until it fully boots up. Once booted, the system functions as intended.
From my own experience, it sounds like a possible firmware mismatch issue. Since you recently upgraded your drives, I would cross-check the firmware version of the Kinetix5100 drives with the Compact GuardLogix 5380 CPU. Sometimes, upgrading components without a corresponding firmware upgrade can lead to sporadic issues like the one you're describing. Also, consider that the issue might be related to a resource overload or a subtle incompatibility between hardware and software. Don't forget to assess network traffic too - there may be some congestion at certain intervals causing this intermittent fault. Best of luck with your troubleshooting.
Sounds like a tricky situation. It seems that you've covered some of the basic troubleshooting steps, so kudos for that. One thing that comes to mind is checking the CPU's firmware version. Sometimes, such issues arise due to incompatibility between the firmware version and the new hardware (Kinetix 5100 in this case). If there's a newer firmware available, it might be worth giving that installation a try. Additionally, peak at the CPU's resource usage pre- and post-fault to potentially identify any noticeable patterns or overloads that might be triggering the error. Also, certain diagnostic indicators could help provide further insight, such as the status of the ENBT status indicators. Finally, while remote troubleshooting might present limitations, try running an RSlinx enterprise module if you haven't already, as it can help diagnose device issues down to the firmware level and beyond.
✅ 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: Answer: The issue causing the auto-reboot could be related to a fault triggered in the system that disrupts ethernet communication, leading to the red LED error on the CPU. It is essential to investigate potential causes such as network configuration issues, firmware compatibility with the upgraded Kinetix5100 drives, or any hardware malfunctions.
Answer: Answer: To troubleshoot the issue, you can start by checking the network setup, firmware versions, and hardware compatibility. It is recommended to analyze any error logs, review network communication settings, and ensure proper isolation of the network during diagnostics to identify the root cause of the fault.
Answer: Answer: The error causing the disruption in ethernet communication and the red LED on the CPU could be a critical fault that temporarily halts operations. This could be due to software issues, hardware malfunctions, network configuration problems, or compatibility issues between the CPU and the Kinetix5100 drives. Further investigation and troubleshooting are necessary to pinpoint the exact cause.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.