SLC 5/05 Not Retaining Memory After Power Cycle

[mkg123]

Hello PLC friends. I've been going through a saga of diagnosing and fixing an old PLC setup that I inherited. I am learning as I go.

Initial Error was in temp readings associated with a 1746-NT4 thermocouple module. Saw temps going off the rails. But also experienced communication errors with SLC 5/05 that appeared as Error 612 or 613 on our PanelView. Could thermocouple module failure propagate to SLC 5/05?

We replaced the 1746-NT4 module and our temps looks normal. But our SLC 5/05 starts up in Fault mode. We switch Key to program and push the configuration file to it and then go back to Run and it's happy. But if we power cycle we start back up in fault mode.

Troubleshooting steps:
1) Replace Battery 1747-BA on the SLC 5/05. No change (new battery measured 3.0 V open circuit prior to install)
2) Replace SLC 5/05. No change (same behavior with new module!)
3) Replace Power Supply Module. No change

Questions:
1) Are both of these CPUs bad?
2) Am I doing something that breaks these SLC 5/05 modules in the same way?
3) Is the setup/procedure bad and the modules are just fine?
4) Are the batteries crazy old and we need new ones?


Thank you for any insight!

 

[plvlce]

We replaced the 1746-NT4 module and our temps looks normal. But our SLC 5/05 starts up in Fault mode. We switch Key to program and push the configuration file to it and then go back to Run and it's happy. But if we power cycle we start back up in fault mode.

Can you check (via RSLogix) what the actual fault you are getting is?

What are you referring to as the 'configuration file'? Do you mean you are downloading the program via RSLogix? If so, are you doing so because it has lost its program entirely, or for some other reason?

To address your questions...
1)Unlikely.
2)Maybe. *Something* is causing them to be faulted on startup, but without knowing what the actual fault is it's difficult to say more
3)I suspect the modules are fine
4)If the batteries are several years old it might be a good idea to replace them, but if you get a full 3V I would expect them to hold the program at least for a brief power cycle.

One question for you: Is there a memory module installed?

 

[mkg123]

Yes, Config File= program. Downloading with RSLogix500 via ethernet connection.

At power on, we have flashing Fault light and green flashing ENET. We cannot establish any communication/go online with RSLogix until we download the program. Doing this clears the Fault light and errors on PanelView. But then it appears that everything is fine, no faults. I have not seen any fault log once we go "Online".

We do not have a memory module yet, but I ordered one to see if that will have any impact.

Thanks!

 

[joseph_e2]

If you can, I'd try connecting via RS232 when it's faulted as well. It may be losing its IP address when it faults (unusual, not impossible). Can you ping it when it's faulted?

 

[mkg123]

I believe we can ping when faulted. I'll double check. We established the IP with BOOTP after we replaced the module. Haven't had to do that again, just downloading the program works.

I will try the RS232 route. Had some separate COM port issues I need to resolve there too, that I assume isn't related (COM port already in use?).

 

[OkiePC]

The memory module is a means of storing a snapshot of the PLC program and data files that can be set up to load on power up, or load on memory error. It is not going to address the root problem of what is causing the faults.

I am surprised to hear that you are unable to connect with RSLogix 500 while the PLC is faulted. Even a hard fault that wipes the program usually leaves CH1 configuration unaffected. You need to be able to get online while the fault exists in order to see the error before clearing it.

Next time it happens, if you have the time to spend taking screenshots of what you are seeing in RSLinx when the PLC is faulted and refusing to "talk", maybe we can help figure it out.

It's been 10 years since I worked with the Thermocouple modules, but I do recall having one that was giving us all sorts of fits and finding out there were better ways to configure and diagnose it than was was provided on that machine by the OEM.

A bad rack power supply can definitely cause the SLC to lose its program even with a good battery in my experience, but you've already replaced it...

 

[mkg123]

Thanks!

I'll try to get some screenshots (likely Monday though).

Could a faulty power supply have damaged the CPUs? Now that we've replaced the Power Supply should we try a new CPU?

 

[OkiePC]

The CPU is the least likely to be the culprit.
Was the replacement power supply new?
Was the replacement 1746-NT4 new?

I will try the RS232 route. Had some separate COM port issues I need to resolve there too, that I assume isn't related (COM port already in use?).

I typically force windows to see my favorite USB to serial adapter as COM1 by going into Device Manager and the Advanced tab of the adapter. Even though windows often thinks its already in use, I set it there anyway and it will stick ... for a few months, then windows will screw with it again and I have to repeat that. Each time I have to change it, I have to unplug it and plug it back in. Once I have ensured that it takes COM1, I can trust it to work fine for a long period of time.

 

[plvlce]

I asked about the memory module to rule out any possibility that the fault on startup might be caused by an incorrect program being loaded, which you then were overwriting... unlikely, but I once had it happen on a MicroLogix. Having a memory module is generally a decent idea, but it's not going to address the actual problem here.

I'm with OkiePC, it's very strange that you can't connect while it's faulted. Clearly it's not a communication issue since you can immediately download...

Prior to downloading (while faulted), does the processor name show correctly in RSLinx, or does it show a default name? If the latter then the program is getting dropped.

The power supply is by far the most common culprit for program losses that aren't due to battery running low, but I have also heard of the rack itself causing it, as well as an unrelated module in the rack (specifically an analog module in that case).

Assuming it is losing the program, I'd suggest isolating the CPU in a rack by itself, then downloading a small program that doesn't particularly do anything and seeing if it will hold that. This will eliminate everything but the CPU, the rack, and the power supply (the last already replaced) as possible culprits if the issue is still present.

I don't want to say it's impossible for the CPU to be faulty, but my experience as well as what I have seen from others on this site seems to be that the CPU is very rarely the cause of program loss.

 

[tlf30]

I've seen a similar issue on a 5/02 where it would boot faulted and require a redownload. It started to happen after starting the skid after sitting for several years. The battery was replaced and the issue did not go away. The fix was simply to replace the controller. The best I can figure is that something in the controller memory was slowely failing. I've seen other posts on the forums with simular issues on the SLC 5/0x controllers though, and others had different solutions. You might try searching the forums.

 

[I_Automation]

When I have a SLC losing memory like yours the second thing I replace is the power supply.

I have replaced a lot of power supplies, but on SLC's if there is an internal issue on an analog card that can take down the backplane at power off and wipe the CPU.

The first thing I check now is for analog cards and start replacing them, also since this seemed to start when you replaced the NT4 card it seems to me to be the main culprit.

 

[dummy_bit]

When I have a SLC losing memory like yours the second thing I replace is the power supply.

I have replaced a lot of power supplies, but on SLC's if there is an internal issue on an analog card that can take down the backplane at power off and wipe the CPU.

The first thing I check now is for analog cards and start replacing them, also since this seemed to start when you replaced the NT4 card it seems to me to be the main culprit.

Ditto.

Also happens when you use the 24VDC off the power supply and it gets shorted. The SLC dumps the program and faults.

We also had a very noisy power feed to the one machine. We installed an isolation transformer and the issue went away.

 

[I_Automation]

Also happens when you use the 24VDC off the power supply and it gets shorted. The SLC dumps the program and faults

Never use the 24v off the power supply for anything external of the enclosure. And then only through relay contacts to PLC inputs or indicator lights.

 

[RedSoxFan3]

I had a very similar issue a this past year, but it was with a power supply that had slowly cooked over the years.

Whenever the room would get cold, the PLC would shut down and reboot every 60-120 seconds. We'd then go open the door and it wouldn't turn back on. When the room heated back up, everything would be fine.

We finally replaced the power supply. The old one was a 1746-P2 and I put in a 1746-P4. This one has more capacity. The problem hasn't returned thus far. We'll see though.

That said, the PLC5 power supplies can be even more finicky. The 1771-P4Rs in particular, the lights never show up the way you would expect. I hate those things. If you don't have enough power to run the chassis, some of the IO modules may simply not turn on at all and you could end up with strange behaviors. One rack in particular, if we cycled power to the whole control panel some of the IO wouldn't come on. But if turned power on and then power cycled the 1771-P4Rs all at the same time, everything would turn on no problem. Eventually I found one of the redundant power supplies was bad, but it took forever to figure out which one wasn't working.

Long story short is that you might want to try estimating the power requirements for your chassis and consider upsizing the power supply to one with more capacity.

It's possible that the 1746-NT4 card was good the whole time, but everything is pulling a bit more power than it did in the past because its old. Or maybe the power supply was always marginal and the system always had this problem.

Did you test everything you removed from the rack in a controlled setting? I work at a factory with dozens of PLC5 and SLC500 systems and I have a test environment in my office permanently ready to go for this reason.

 

[Geoff White]

One thing I remember when working with 5/05 plcs was they had a terrible habit of losing their **** if you connected to them using an ethernet ip driver communications config. Always use a plain ethernet connection with a typed in ip address.

May be irrelevant for this case but it was so traumatic back in the day that it is written in fiery letters in my memory.