Troubleshooting 1756-L81E PLC Power Cycle Faults: Causes and Solutions

Question:

Hello, I am experiencing a peculiar problem with a 1756-L81E PLC that faults and loses its program upon power cycle. This happens regardless of whether the power is cycled from the main 24VDC power supply or the Allen-Bradley chassis power supply. The specific faults I am encountering are "Type 01 Power-up Fault" and "Code 61 Non-recoverable Fault with saved Diagnostic Information". After conducting tests, I have observed some interesting results:1. Despite changing the firmware revision from 32.014 to 32.012, the PLC still faults and loses its program.2. Swapping the power supply with a different model (1756-PB75/B) also resulted in the PLC faulting and losing its program.3. Interestingly, removing the PLC from the rack and reinserting it without cycling the power allowed the PLC to retain its program without faulting.4. When testing the PLC on a different rack with a 110v power supply (1756-PA75/B), the PLC did not fault.5. Switching the PA75 supply with the PB75 power supply at the test rack also did not result in any faults. It is worth noting that even powering off the PB75 supply and then turning it back on with the PA75 supply still resulted in a fault. The only reliable way to prevent the fault is to power down and back up using the PA75 (110vac) supply.6. My next step is to test the PA75 supply in the field rack. I am curious if anyone else has experienced this issue and if it could be related to firmware (as updating beyond v32 is a daunting task) or if it is definitively a power supply issue. Thank you!

Top Replies

Losing the program can typically be attributed to either a malfunctioning ESM or power issues with the controller, particularly through the backplane during shutdown. While my experience is mainly with SLC, similar causes are likely for CLogix systems. The culprit could be the power supply, chassis, controller itself, or another module in the rack. It's also possible that the incoming power to the power supply is contaminated. Firmware issues are unlikely in this scenario, and having two faulty power supplies is highly improbable. If the problem persists when testing with the PB75, it's worth examining the power source for the power supply in both the test and operational racks to identify the root cause.

plvlce mentioned that if a program is lost, it could be due to a faulty ESM or power issue affecting the controller during shutdown. This issue is commonly seen with SLC, but similar issues may occur with CLogix. Possible causes include the power supply, chassis, controller, or other modules in the rack. It is unlikely to be a firmware problem. If the issue persists, it is recommended to check the incoming power to the power supply. It is important to note that pulling power during shutdown may contribute to the problem. When troubleshooting, consider the source of power for the power supply in both the test rack and the operational rack. In this context, ESM refers to the Electronic Software Management system.

When mentioning ESM, I am referring to the Energy Storage Module used in L8 processors, which do not have a battery backup. The L8 detects power loss in the logix rack and writes the program to the ESM before capacitors discharge. If the ESM or capacitor integrity is compromised, the processor may encounter faults upon reactivation. Removing the processor from the rack while live prevents the detection of backplane power loss and the triggering of ESM write, allowing the last ESM write to remain intact. It is unclear why there is a difference between the A and B PS, but it is recommended to replace the processor.

After considering the opinions of others, if your processor is out of warranty but still has an SD card inserted, you can attempt the following workaround: 1. Access the Controller Properties in 5000 2. Navigate to the Non-Volatile Memory tab 3. Place the processor in Program mode 4. Open Load / Store 5. Choose Load Image: On Uninitialized Memory 6. Select Load Mode: Run (Remote Only) 7. Click on Store and confirm By following these steps, the project will be saved to the SD card, allowing the controller to boot from it each time. Keep in mind that this process will need to be repeated for any new program modifications.

During a recent project, we encountered a common issue that can easily be prevented with proper precautions. While inspecting the system, I discovered a contractor had installed a new conduit directly above the controller in the NEMA 4 box. As a result, metal filings contaminated the backplane, causing potential damage to the electronic components. To avoid similar issues, it is crucial to protect electronic components with masking tape during construction or modifications to a control box. This simple step can prevent costly repairs and downtime in the future.

Hey there, sounds like you've conducted quite the detailed investigation. From everything you've described, it seems very likely the problem lies in the unit’s interaction with voltage levels from the power supplies. Specifically, it seems the PLC might have an issue with the DC models. It's peculiar that only the PA75 (110vac) prevents the fault. Despite the firmware rollback, the problem persists, which suggests the firmware might not be the root cause. Though daunting, updating beyond v32 could potentially resolve the issue, but I'd certainly exhaust all power supply related options first. However, I'd also recommend contacting Allen-Bradley tech support before taking that route - they may have encountered this problem before and could provide a reliable fix.

This really seems like a challenge you're going through. From what I can gather from your tests, it appears that the issue might not necessarily lie with the firmware or the power supply, but rather compatibility between the specific PLC and power supply. It could be that something about the 1756-PB75/B supply is causing the faulting when not in conjunction with the PA75 in that particular rack. It's also possible that there's some hardware issue with the 1756-L81E PLC itself that is exacerbated when used with certain supplies. An additional firmware upgrade might help, but I would recommend testing with the PA75 in the field rack as you suggested, just to see if a consistent result pops up. Let's hope your issue gets resolved soon!

More Replies β†’

Streamline Your Asset Management
See How Oxmaint Works!!

βœ…   Work Order Management

βœ…   Asset Tracking

βœ…   Preventive Maintenance

βœ…   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

To add a comment, please sign in or register if you haven't already..   

Frequently Asked Questions (FAQ)

FAQ: 1. Why does my 1756-L81E PLC fault and lose its program upon power cycle?

Answer: - The PLC is experiencing a "Type 01 Power-up Fault" and "Code 61 Non-recoverable Fault with saved Diagnostic Information" regardless of the power supply used.

FAQ: 2. What troubleshooting steps have been taken to address the PLC power cycle faults?

Answer: - Tests have been conducted, including changing firmware revisions, swapping power supplies, and observing behavior on different racks with varying power supplies.

FAQ: 3. Why does removing and reinserting the PLC without power cycling prevent faults?

Answer: - Reinserting the PLC without power cycling allows it to retain its program without faulting, indicating a potential workaround for the issue.

FAQ: 4. Why does the PLC not fault when tested on a rack with a 110v power supply?

Answer: - Testing the PLC on a different rack with a 110v power supply did not result in faults, suggesting a possible correlation between the power supply type and the fault occurrence.

FAQ: 5. What is the significance of using the PA75 supply to prevent faults?

Answer: - Powering down and back up using the PA75 (110vac) supply has been identified as a reliable way to prevent faults, raising questions about the role of different power supplies in the issue.

FAQ: 6. Is the firmware version potentially linked to the PLC power cycle faults?

Answer: - Further investigation is needed to determine if the issue could be related to firmware, as updating beyond v32 is considered a challenging task.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  β†’