SLC5/04 Power Up Cycling

[mgman 0]

We are using a SLC5/04 (1747-L542 ser. B proc. rev. 3). It had been powered down for a couple of weeks for a UPS power supply change. When it was powered back up it would not operate or communicate with a PC. The LEDs are cycling such that it appears to be repeating the Power Up Cycle. The LED Sequence starts: FLT, ALL And then repeats: FLT, DH+ yellow, DH+ green, DH+ red, ALL, DH+ yellow, ALL, OFF, pause and repeat We have tried to connnect with DH+ and with DF1 with no success. Autoconfigure in RSLinx does not work. Fortunately we had a spare processor, but we are now trying to determine the problem with this one. Any idea to the cause or solution for this?? Thanks in advance. M Edited 25 Aug 2006 by mgman

[TimWilborne 108]

Battery dead? When was it last replaced?

[mgman 0]

It was found that after starting back up that the battery was quite old. We replaced it with a new one, and it still cycles. M

[TimWilborne 108]

Is the RUN, POWER, and FORCE LEDs doing anything? I know you say all but just checking. What is the BATT LED doing? Actually just be specific about all LEDs.

[Mickey 71]

Have you tried this ClearMem.pdf

[mgman 0]

ok, here is the precise sequence: (LED's listed are ON in that step.) Power on: 1: FLT 2: RUN, FLT, BATT, FORCE, DH+ (green), RS232 3: FLT 4: DH+ (yellow) 5: DH+ (green) 6: DH+ (red) 7: RUN, FLT, BATT, FORCE, DH+ (green), RS232 8: DH+ (yellow) 9: RUN, FLT, BATT, FORCE, DH+ (green), RS232 10: pause 11: goto 3 M

[TimWilborne 108]

Yep, I'm coming up with the same conclusion you are. I could just blame it on the power supply but I think this is a problem that would be best handled by calling Rockwell Support and explaining it to them. Let us know what you find

[mgman 0]

We did default the processor (ie go to factory default settings), and it did remedy the problem, but this doesn't tell us how this may have happened. I'm just curious as to why it happened and how we can prevent it from happening again. Thanks for your help. We tried looking everywhere on the internet and knowledgebase and everywhere else. We may just have to call Rockwell, I will let you know what I find. M Edited 25 Aug 2006 by mgman

[TConnolly 13]

Since 1) your battery was quite old and 2) the memroy clear procedure solved the problem, I suspect that processor memory became corrupted because the battery was not able to preserve the memory contents. To borrow a line from Mircale Max "There's a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there's usually only one thing you can do." You should not expect memory to just be wiped clear when a battery gets weak - rather it becomes corrupted with meaningless bit patterns. Volatile memory is an unpredictable thing where one bit will reset when battery voltage falls below a certain level while the next bit won't reset until a lower voltage is reached. This is the very reason for shorting the pins on the back of the CPU card together so that memory resets completely. The way to keep it from happening is to establish a PM system whereby you change out the battery every couple of years and before any extended down time. Edited 25 Aug 2006 by Alaric

[TimWilborne 108]

Yes, leave it to our link man to solve the problem. I've got to learn to search better Great job Mickey

[Mickey 71]

More soup for me.

[ICTechs.com 0]

Same thing happened to me a while back with one of our processors, Shorted VBB/Grd for 30 seconds to set it back to default, changed the battery, reloaded "downloaded" the file, and its was fixed. What I have implemented now for all of ours units is, that before a CPU is down for more than 24hrs. I'll do a Upload to save all the calibration parameters and data table info. Once the unit get powered back up. I'll set the processor(s) back to default, and then perform a download. So far it has eliminated most issues upon start-up. If its to be down more than 72 hrs then the battery gets replaced just as a precaution. my .02 Edited 27 Aug 2006 by ICTechs.com

[gravitar 3]

something else worth mentioning is the backup memory module (1747-M13). This is another layer of security against processor memory loss!