SLC-5/03 Fault 1F5A(hex); Diagnostic Help ?

[Ken Roach]

New Forum member Lima0411 recently posted this question to an old thread that had evolved to a discussion of New Zealand rugby, so to start off on the right foot I've re-posted his question here:

----------------------------------------------------

I need help about this fault in SLC500 (5/05 CPU) in natural gas station. After a power surge in UPS, CPU exhibited the RUN and FLT blinking LED OFF. With RSLogix 500, we saw that the failure is as follows "interrupt hardware problem. Exact slot can not be determined" and a code of hexadecimal 1F5Ah failure.

We check each of the slots in each of the racks (there are 3 in total), were suspicious of cards 3150 - MCM and the CPU. We exchanged all for existing in the warehouse and we could not pull this failure ...

Could anyone suggest some new research path ???

What would be a likely source of this type of fault code ???
I see that a few colleagues had such "luck" in your applications.

 

[Ken Roach]

Usually when there is a damaged or defective module, the controller can determine which Slot it is in. Sometimes that is not the case, as you have seen.

I think you are going to have to do a methodical module-by-module troubleshooting process.

For each module:

1. Power down and remove one module from the system.

2. Power up, go online with RSLogix 500, and Inhibit that module in the I/O configuration. This is done in the Processor Status window, on the IO tab, with the I/O Slot Enables bits that are in Status data file elements S:11 and S:12.

3. Use RSLogix 500 to clear the Fault, then try to use the keyswitch to go into RUN mode. Use the Errors tab of the Status file dialog to monitor the Major and Minor errors and Clear errors.

When you finally encounter the damaged module, you should be able to clear the fault and the controller should go into RUN mode.

It's also possible that the chassis itself has been damaged. I know that's not encouraging because you have a system with multiple connected chassis, but it's a possibility you will have to consider.

Important: The SLC-500 platform does not support removal and insertion of modules under power. Always turn off the power before removing or inserting an SLC-500 family controller or I/O module.

 

[BruceB47]

HI:
Also be careful as if there is a power supply problem the SLC500 system will clear the memory and put it into fault mode.

 

[Lima0411]

Dear Ken Roach

I am very grateful for your attention to my questions and for his quickness in responding and able to help. I followed your instructions and first isolate each module of each of the 3 racks through RSLogix 500.

At first, the fault remained. But your suggestion opened the prospect of isolating rack to rack physically (unplug the flat cable between racks and removal of all modules from racks); then we did a test logic (without the complexities that had the original logic) just to refresh and we rotate each insertion of a module in the rack, upgrading the IO Config.

Did you disconnect the first rack (Rack 0) and the other taken from all modules of this. We downloaded the test logic and immediately after updating the IO Config, CPU came out of failure. Hang up and reconnect the power supply to each insert a module in Rack 0 and similarly, updating the IO Config. Continued to CPU without any sign of FLT LED blinking and RUN sólido.Lembrando the Rack 1 is where estam installed two 3150-MCM modules, prime suspects of failure.

We continued successfully throughout the Rack 1 (which only has three digital output modules) with the actions mentioned above and when we called the Rack 2 (third module) failure recurred.

We did some tests could be one of the Rack modules 2 and put different types of modules and the fault remained. Even without any module inserted into the rack. The suspect was related to Rack 2 and then replaced it with an existing on another drive (which we use as reserves).

Resumed testing, as done in Rack 0 and the fault did not recur. We conducted download the original logic unit operation and she returned to normal operation without failure.

By analyzing the electrical connections of the sources of racks, we found no insulation and protection for surges coming from UPS. A suspicion is the fragility of Rack 2 after the outbreak of the UPS that led to this failure. Let's look at a form of protection does not occur for something and isolate with protective power supplies racks.

Thank you for support and when to come to Brazil, will our warm welcome and cold beer.

Greetings and hugs.