# SLC 5/05 faulted, won't communicate



## mikey383

Just wondering if anyone else has encountered this. It's a 1747-L552, 32K. 

This processor faulted and I cannot communicate with it at all. Upon power up, the fault light stays on, the Bat light blinks for a second, then all other lights (except for Run) blink for a second, then it repeats this 2 or 3 times until everything but Run stays lit up. I can't hook up a computer to it, no matter what I try. I can't find any information on this in Allen-Bradley's documents. Our main programmer said he hasn't seen this fault on any other SLC (other than what I mention below). I even tried taking it to our plant office and putting it into a SLC rack, but it will not communicate no matter what. I tried pulling the battery and shorting the terminals for 30 seconds, and that didn't work. I've yet to call Rockwell to get their opinion. 

Channel 0 is configured for RS-232 with nothing attached to it, and Channel 1 is on the plant ethernet network, communicating with a Panelview 1000 in the MCC room via 5 port ethernet switch. Neither port will communicate. I even tried DH-485. 

I ended up replacing the processor. 

We have two identical dehumidification units that were installed at the same time about 15 years ago, and I just went through this exact same scenario with the other unit at the beginning of December. I ended up replacing the processor on that unit also.


----------



## dronai

mikey383 said:


> Just wondering if anyone else has encountered this. It's a 1747-L552, 32K.
> 
> This processor faulted and I cannot communicate with it at all. Upon power up, the fault light stays on, the Bat light blinks for a second, then all other lights (except for Run) blink for a second, then it repeats this 2 or 3 times until everything but Run stays lit up. I can't hook up a computer to it, no matter what I try. I can't find any information on this in Allen-Bradley's documents. Our main programmer said he hasn't seen this fault on any other SLC (other than what I mention below). I even tried taking it to our plant office and putting it into a SLC rack, but it will not communicate no matter what. I tried pulling the battery and shorting the terminals for 30 seconds, and that didn't work. I've yet to call Rockwell to get their opinion.
> 
> Channel 0 is configured for RS-232 with nothing attached to it, and Channel 1 is on the plant ethernet network, communicating with a Panelview 1000 in the MCC room via 5 port ethernet switch. Neither port will communicate. I even tried DH-485.
> 
> *I ended up replacing the processor.*
> 
> We have two identical dehumidification units that were installed at the same time about 15 years ago, and I just went through this exact same scenario with the other unit at the beginning of December. I ended up replacing the processor on that unit also.


 Once replaced the problem was solved in both cases ?


----------



## mikey383

dronai said:


> Once replaced the problem was solved in both cases ?


For one, yes. It's been running fine with no issues since the beginning of December. 

For the other, I'm not sure yet. I did an online edit on the new processor of this unit right before they decided to shut this unit down, and the processor faulted just seconds after the edit was accepted, which was simply taking out an XIC from a rung. They decided to shut this unit down until tomorrow, so I'll have to wait to find out what kind of fault it has. 

I'm just curious what would cause two processors of the same age to show the same fault that AB doesn't have online documentation for.


----------



## KennyW

The problem with online edits is a known issue. Seen it at least a dozen times. Update the firmware for the ethernet daughter board. In fact make sure all firmware is current.


----------



## mikey383

Found the problem. Had a little bit of time to play with it some more this morning. Ended up pulling the battery out and I could communicate with the old processor. Put what I thought was a new battery in, and it wouldn't talk. Looked at the battery date...4/01. So I drove to the supply house and got a new battery and it works now. 

I can't say I've encountered this before, but I'll make note of it for the future.


----------



## Jhellwig

Do you guys not pm the batteries?


----------



## mikey383

There is supposed to a PM in the system to replace every battery in every machine once a year, but I haven't seen any of them generate in quite a while. I'm going to bring this to attention.


----------



## mikey383

KennyW said:


> The problem with online edits is a known issue. Seen it at least a dozen times. Update the firmware for the ethernet daughter board. In fact make sure all firmware is current.


I'm also going to suggest this and see what they want to do.


----------



## mikey383

So I guess I spoke too soon. I put the old processor back in the machine this morning, and it faulted out within an hour, same fault lights. Took it back to our office and couldn't get it to clear. Would not communicate at all. Put another new battery in it, same results. 

To further complicate the matter, over the weekend, the new processor I put in last week lost its program and is having communication issues, plus the Panelview had a "Communication driver failed" error this afternoon. 

I'm now wondering if there might be an issue with the backplane, since both processors are faulting.


----------



## dronai

And some here think your job is easy !!!! Good luck.


----------



## dronai

Try PLCs.net forum.


----------



## mikey383

dronai said:


> Try PLCs.net forum.


Thanks. I'll join there. 

I think for now I'm just going to change the backplane and power supply, and put in another rebuilt processor. Simply because that's going to be more efficient than troubleshooting the hell out of this POS machine that's going to have more issues that I can't take care of.


----------



## mikey383

Well, I replaced the rack, power supply, and processor. I took the old units back to the office and found that the processor had lost its program again, probably due to repeated power cycling. Since there are so many other issues with this equipment, it is constantly being turned on and off. I ended up installing a UPS in the cabinet to keep the processor powered up for a while while the HVAC guy does his thing. 

I found nothing visibly wrong with the old backplane, so I loaded a simple program in that processor and will let it run for a few days. I'm thinking the constant power cycling is what is faulting the processors.


----------



## xpertpc

Here's my story, about 2 years ago I ordered a brand new SLC505 which cost about $2800. Needed to swap out a SLC503 as I needed an ethernet port to connect to the AB Asset Centre.

Converted the program from a 503 to a 505 and loaded into the new processor, configured the ip address and all worked well - for about a week then it faulted, the other shift put the old processor back in as I left it in the cabinet and the machine went on its merry way.

A few weeks later I finally got time to look into the problem and had a heck of a time getting connected, If memory serves me right I had to go through the serial port via DH485 protocol but not sure now.

Once connected I looked at the major fault code S:6 and think it was 002A - Indexed address reference is beyond the specific referenced data file.

When I converted the program it asked about keeping data tables sizes which I did, my only thought was the program was a palletizer and used a lot of scratch pad memory that would not of shown up as used in a table search, thinking that the conversion truncated my tables I put a value in the last address and reloaded.

A few days later it faulted again, I spent several months trying to connect but had no success, I read the knowledge base, the white papers, called tech connect, scoured the forums.

I then gave it to our tech parts guy to send to AB for some advice as it fell out of warranty with all the other things going on - the next day I found the SLC505 in the dumpster and soon retired afterwards forgetting to bring it with me.

The only info I got other then the major fault was that another shift tried to communicate through the ethernet port using DH485 cabling and a usb interface converter.


----------



## STEM

Wow. Never though I'd ever hear of someone with this same problem I experienced nearly 20 years ago on SLCs. I regularly blew the processor away back in the day using the AB SLC5 programming software. Something was wrong with the software as AB admitted.

Repeated power cycling should NEVER give you a problem unless the memory battery is low. That's what they're built for. However, SLCs, under certain rare conditions can blow their brains out and go to a mode best described as dim awareness which is essentially a factory default mode in which everything needs to be reloaded from scratch.

A complete loss of program most commonly happens on a comm fault condition and can be caused by comm faults to Panelviews and software SCADAs/HMIs but most often to online programming software. Are you able to examine the fault bits that are causing the problem? Was someone connected on-line at the time? How many devices are actually communicating with this PLC online?

I'm not completely sure of what you have tried - obviously many things but have you tried to just power up the processor that had a fault in program mode with no program in it? Does it eventually fault? How about leaving it with no program but in run mode. Does it fault? You can see where this is going so I'll leave the rest to you. Oh yea... did you actually measure all your power supply voltages and your memory battery voltages as well?


----------



## mikey383

STEM said:


> Wow. Never though I'd ever hear of someone with this same problem I experienced nearly 20 years ago on SLCs. I regularly blew the processor away back in the day using the AB SLC5 programming software. Something was wrong with the software as AB admitted.
> 
> Repeated power cycling should NEVER give you a problem unless the memory battery is low. That's what they're built for. However, SLCs, under certain rare conditions can blow their brains out and go to a mode best described as dim awareness which is essentially a factory default mode in which everything needs to be reloaded from scratch.
> 
> A complete loss of program most commonly happens on a comm fault condition and can be caused by comm faults to Panelviews and software SCADAs/HMIs but most often to online programming software. Are you able to examine the fault bits that are causing the problem? Was someone connected on-line at the time? How many devices are actually communicating with this PLC online?
> 
> I'm not completely sure of what you have tried - obviously many things but have you tried to just power up the processor that had a fault in program mode with no program in it? Does it eventually fault? How about leaving it with no program but in run mode. Does it fault? You can see where this is going so I'll leave the rest to you. Oh yea... did you actually measure all your power supply voltages and your memory battery voltages as well?


Well, the first processor eventually blew its brains out. I can't get it to reset, communicate, or anything. It just keeps flashing the lights. New battery, old battery, no battery, different rack, same problem. 

The second processor I loaded a simple program with alternating timers, let it sit for a couple days, and it faulted. Come to find out, the power to our office was cut twice while a guy was installing a heater. It had the same fault as before - solid fault light, which after another power cycle, resulted in a flashing fault light and had lost its program. So I reloaded the program and let it sit again. As of this morning, it had not faulted yet. It has a new battery in it also. 

All voltages look good. If this processor faults again, I have another one that I'm going to try in that rack, and also try this processor in another rack to see what happens.


----------



## STEM

Do you have the latest firmware in it?
http://literature.rockwellautomation.com/idc/groups/literature/documents/in/1747-in019_-en-p.pdf

Here's a good thread with some excellent ideas. Pay attention to the ground comment. Check your manual - If I remember they ask for a #6 ground wire from the chassis frame to ground.
http://www.control.com/thread/1002036082

Here's another thread about the same problem. Check the very last comment!
http://www.plctalk.net/qanda/archive/index.php/t-26405.html

Cheers


----------



## mikey383

STEM said:


> Do you have the latest firmware in it?
> http://literature.rockwellautomation.com/idc/groups/literature/documents/in/1747-in019_-en-p.pdf
> 
> Here's a good thread with some excellent ideas. Pay attention to the ground comment. Check your manual - If I remember they ask for a #6 ground wire from the chassis frame to ground.
> http://www.control.com/thread/1002036082
> 
> Here's another thread about the same problem. Check the very last comment!
> http://www.plctalk.net/qanda/archive/index.php/t-26405.html
> 
> Cheers



I can't say for sure if they have the most current firmware. Both the second and third processors were remans from AB, but I can't say if they update the firmware. 

I had quickly scanned that second link last week, but failed to notice the last reply about conduit grounds. I'm going to have to check into this, as this equipment was installed by another contractor, and I haven't really paid attention to how they're grounded. We have several dozen SLCs throughout the facility, and these two machines are the only ones we have constant issues with. 

It's kinda funny that you mentioned the last post in the last link...this last processor I installed, I put in an out-of-the-box power supply, and didn't check the jumpers first. I powered the unit up, and the processor immediately faulted. Checked voltages, and everything looked fine. Then I noticed the voltage jumper was in the 240V position. Swapped it to 120, and everything worked fine. I should have known better, but got in a hurry.


----------



## Russ K

One minor item on SLC-5 processors. If the battery is good and power goes down for a few seconds or longer, you will likely come back up fine. If its a quick down and back maybe not. And if you pull a processor out and put it back in under power, most of the time (in my observation) you will fault and have the default program show up. However, the serial port on the 5/05 at least, if programmed for RS-485 will stay as 485. You won't be able to communicate via the serial port with RS-232. 
Likely something to do with the power up sequence that the Rockwell PS does - simply plugging it in puts everything on at once and the processor seems to not know what to do. I've not had that problem with PLC-5 or ControlLogix PLCs so be aware - the SLC is a slightly different and much older beast.


----------



## paulengr

I’ve had problems like this that turn out to be the power supply. Also the battery good/bad light is a liar. Just change batteries on a regular schedule.

But the worst problem I’ve had is that the comms code on these early PLCs is terrible. If it gets a garbled packet it can fault/wipe the processor. Had this happen several times while writing my own PCCC code,


----------

