Q&A Community

Troubleshooting Recurring Auto-Reboot Issue in Compact GuardLogix CPU

Question:

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?

Top Replies

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.

More Replies

The controller is not configured to reload the program from the SD card. A video provided by the customer shows the CPU encountering a fault condition, which does not seem to be caused by a power interruption but rather by internal diagnostics leading to the solid red OK light. Additionally, the customer is using a second CPU and has received a preloaded replacement for the PLC CPU, which did not resolve the issue. The customer also attempted to install a larger power supply independently, but this did not result in any changes.

Is there a local rack with 5069-OW16 cards installed? I experienced a similar issue where auto-recovery did not always occur with a non-safety PLC, and the culprit turned out to be related to this specific type of card.

The rack layout consists of the following modules: 5069-L306ERS, 5069-IB16, 5069-OB16, 5069-IB16, 5069-OB16, 5069-IB16, and 5069-OBV8.

Is there a connection between MOD and SA power sources, or are they distinct entities? And if they are separate, do they share any commonalities?

Steve Etter asked if the MOD and SA power sources are the same or different, and if they are connected in any way. Click to find out if they share a common source.

My next move would involve separating them.

What are the potential reasons for the CPU fault and the red OK light, despite no major or minor faults showing in the log?

It seems like the startup process for a Programmable Logic Controller (PLC). This is why Steve recommended separating the power for the MOD and SA to ensure no power supply issues. Is your equipment exposed to high levels of vibration, like in a press? Make sure all connections are secure and properly plugged into the terminal strips. A few years ago, we had a similar issue with a piece of equipment. After closer inspection, we found a wire that appeared connected but was actually broken inside the insulation, resulting in poor contact with the remote IO block.

The act of disconnecting the power did not have any impact. I have recorded video evidence of the issue occurring, which did not resolve itself upon restarting the system. I am currently at the location and have carefully adjusted and checked all connections. If the problem lies with a loose connection on a connector or backplane, it should have caused the issue to reoccur.

The issue I encountered was determined to be caused by switching noise from an inductive load, as stated by AB. The problem specifically affected 5069-OW16, 5069-OW4I, and 5069-OX4I modules, ultimately resulting in processor faults. I cannot be certain if a fault was logged in the PLC. To address this issue, it is recommended to use snubbers or suppressors for inductive loads. If the problem persists, try disconnecting all wiring terminals from the I/O modules and observe if it has an impact. This troubleshooting method may help in resolving the frequent occurrences of the issue.

Can you please share the solution to this issue? I am facing the same problem and would appreciate your help.

Frequently Asked Questions (FAQ)

FAQ: 1. What could be causing the Compact GuardLogix 5380 CPU to repeatedly auto-reboot after running for 5 minutes?

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.

FAQ: 2. How can I troubleshoot the recurring auto-reboot issue in a Compact GuardLogix CPU overseeing a network of 8 nodes?

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.

FAQ: 3. Why does the error in the Compact GuardLogix CPU cause disruption in ethernet communication and trigger the red OK LED?

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.

You must be a registered user to add a comment. If you've already registered,
sign in. Otherwise, register and sign in.