SLC 5/05 Fault

Was there a reason why you couldnt' just change the battery? I'm just wondering why he would have you clear the memory when the only problem was a dead battery.
 
Last edited:
Sorry, the battery was replaced first. When the processor didnt come back, then unplugged the battery and then shorted the pins.
 
Were you testing these units in the same backplane? If so you might want to try another if you have one available. I have seen simular problems with faulty backplanes/powersupplies. Just a thought.
 
I'm sure you are being as accurate as you can, but there's something that seems wrong about this story.

The RAM backup batteries in SLC-5/0x controllers will generally last for two years with the power off. With the power on, they can last indefinitely; I have seen ten year old controllers with good batteries, though self-discharge life can be as short as 4-5 years in a hot environment.

The SLC operating system OS501 Series C FRN 9 was released in November 2004, so the oldest these controllers could be is about 4 years. If they've been powered up most of the time, they are on the short end of battery lifespan.

What's indisputable is that the controller should not lose its program when it is powered off and the battery removed long enough to install a new battery. The capacitor will retain the user program for days, weeks, sometimes months.

So what we have is controllers that have failed batteries in a relatively short period of time and displayed uncharacteristic behavior before diagnostic work began.

That, to me says damage. Lightning damage, humidity damage, heat damage, ESD damage, don't know what kind. But firmware is bringing up the very back of the parade on the list of things I'd be looking at in these controllers.
 
According to my rep, there are 0 replacement processors available.

Maybe your guy is making a very nearrow inquiry, like checking only for remanufactured units or a specific old hardware version. I can't imaging he's lying, but we might be talking about different questions.

What i've decided i'm going to do is purchase 2 series A replacements and purchase the firmware upgrade to upgrade them to C. It will save some money and my customer will have his replacements.

SLC controller revisions can be a little bit confusing because there are Series letters both for the hardware and the operating system.

Currently manufactured controllers are Series C hardware and also have the OS501 Series C operating system in them.

Series C hardware introduced the 10/100 Mb/s Ethernet daughtercards, and was introduced at the same time as OS501 Series C FRN 9 firmware in November 2004.

You can load the current firmware, which is OS501 Series C FRN11, into any SLC-5/05 controller ever made, no matter if it's Series A, B, or C hardware. You won't get 100Mb/s hardware performance in the old controllers, but you will get all the other features and functions of the current operating system.

You should not be able to purchase Series A hardware SLC-5/05 controllers from any A-B distributor because they have not been manufactured in nearly a decade.

My guess, based on the information you have provided, is that the same damage will befall the replacement controllers that affected the originals.
 
To answer some of your questions.

Chance, The processors were brought back to our office to test in a separate rack to test the same theory. While they were moved around to the different racks at the plant they were installed in, we still felt using a rack/powersupply from a different environment was a good idea. Our test rack performs the same as the racks in the field.

Yes, these controllers have been installed and running every day for about 4 years. The batteries were showing bad which is why we went to replace them.

Yes, we were looking at remanufactured processors. I should have clarified as it caused confusion.

I am aware of the performance difference, however the system that these processors are running does not utilize that communication speed and it can be sacrificed.

I am also aware that series a and B are not currently available new, however we'll be purchasing a used one at a far lower cost than what rockwell charges to repair a bad processor.

I had the same assumption you had yesterday; That these processors were toast. With that known, i repeatedly shorted pins followed by a power up retest over and over and I was able to get one working again. This processor is running and continues to run as we speak regardless of power cycle. Yesterday after i was able to get it to run and communicate a cycle of power would have a 50/50 chance of solid fault or running the test program. This is not the case now, i've been unable to get a solid fault after letting it run all night. I've tried duplicating the issue and am unable to do so after 24 hours of testing. I'll let it run at my bench for another week peridically cycling power before i make a decision as to replace it or not.

Yesterday when I was able to get the processor to communicate and run for a couple hours and then solid fault again after i cycled power, i started thinking that whatever problem these processors share was not caused by replacing the battery. I think that whatever happened it happened prior to the battery replacement and powering it off triggered it. It reminds me of a computer OS who's start up routine is damaged. Sometimes it will come up, sometimes it wont; however, once it is running, it stays running.

The second controller is a different story. I did find out a little more information this morning. I was able to talk with the programmer who originally changed the batteries. While he was on the phone with Rockwell, one of their agents asked him to move the firmware jumper to "PROGRAM" to see if the light pattern changes. Because of this, i think this processor does not have a firmware loaded anymore. This would confirm as to why shorting the pins has no effect. Cant restore default settings for software that doesnt exist. Either way, the firmware upgrade kit is on its way so who knows, maybe it will work.

I just find it odd after all my years working with electronics that 2 units go bad at the same time the exact same way. This wouldnt suprise me if it was a common issue, however Rockwell states there are no known documented cases that match this issue. Thats why I posted here. I wanted to see if others have had this issue and that Rockwell is denying it. It wouldnt be the first time. Control logix L55's ;)
 
Last edited:
We installed a system for one of our customers in Sept. of 2005. It has a 5/05 processor and last year the customer had to replace the processor because the original processor lost the program. They tried downloading the program again but basically it kept dissapearing so they replaced the processor. I had not seen this before. I thought about it because it sounded similar to the issue Stgmavrick is having. I believe their processor started losing the program after a power loss also.
 
Nope, sorry.

The fault light stays solid red. Battery will flash once. Then Batt, force, enet, and rs232 lights will flash once, then it will repeat.
 
Ive had the same issue with at least 5 units on one of my projects. They have all failed in the manner described above. Most have failed during a download or online update using the Enet port.
 
Did anyone have any luck with this? I've just had the same problem with a 5/03 I bought second hand. The problem may or may not have been caused by me starting it up with J4 in "program" but not actually performing an upgrade. The processor works fine straight after a factory reset, but after a power cycle it goes back to flashing away at me angrily
 
If you're REALLLY desperate, I can overnight a new procesor to you on Monday. Just PM me with your coordinates and we'llmake arrangements for payment / replacement.
 
Ken Roach said:
The RAM backup batteries in SLC-5/0x controllers will generally last for two years with the power off. With the power on, they can last indefinitely; I have seen ten year old controllers with good batteries, though self-discharge life can be as short as 4-5 years in a hot environment.

What's indisputable is that the controller should not lose its program when it is powered off and the battery removed long enough to install a new battery. The capacitor will retain the user program for days, weeks, sometimes months.

So what we have is controllers that have failed batteries in a relatively short period of time and displayed uncharacteristic behavior before diagnostic work began.

That, to me says damage. Lightning damage, humidity damage, heat damage, ESD damage, don't know what kind. But firmware is bringing up the very back of the parade on the list of things I'd be looking at in these controllers.


You say that the capacitor can maintain a program in RAM for weeks or even months. However the hardware manual says this:​

"The SLC 5/03, SLC 5/04, and SLC 5/05 processors have a
capacitor that provides at least 30 minutes of battery back-up
while the battery is disconnected. Data in RAM is not lost if the battery is replaced within 30 minutes."


Granted they are probably being conservative about this but I wouldn't want to go days without a battery. If you look at my earlier post I mention a customer having to replace a 5/05 processor because it would not hold a program. Well the same thing happened again just last week after they had a Labor Day shutdown. I'm not sure how long the system was off but when they tried to power the system back up there was no program in the processor. They were able to download the program and resume operation but a few days later the processor faulted and this time they could not download. They kept getting a message that the program was incompatible with the processor. They replaced the processor and were then able to download. I really don't know what's going on with this system but 2 processors in 4 years is not good. I have not seen this with any other SLC system we have installed in the last 15 years.

 

Similar Topics

Hello all! I have some machines that run an SLC 5/03 and occasionally a fault is generated. Recent Example: A power supply wasn't screwed in...
Replies
3
Views
401
hello at work we have a machine controlled with an SLC 500 fixed, model 1747-l30c at fault, i plan to migrate to a micrologix controller. I'm...
Replies
7
Views
2,987
Has anyone ever seen this fault or have any insight as to what it was. I found this on an SLC 505 after we had the main breaker off working in...
Replies
1
Views
1,406
Hello everyone, I got called down to a plant to service a powdered metal press. It has an SLC 500 5/02 CPU that was faulted for the code 0002h...
Replies
9
Views
1,757
Hello! We have a drum rotation machine controlled by a AB SLC 500. The drum rotation inputs comes from a encoder into a 1746-HSCE. We are using 2...
Replies
0
Views
1,128
Back
Top Bottom