SLC 5/05 faulted after online edit, not sure how to bring it back

[defcon.klaxon]

Hey guys,

I'm currently at a wastewater plant where I needed to make a simple edit of a SLC 5/05 scaling block, but I guess it got messed up when I was in online edit mode. Now the PLC is faulted, the FAULT LED is solid red and if I go from RUN/REM/PROG the ENET light blinks red.

Wondering if anyone can help me figure out what to do here, the entire plant is shut down at the moment and I'm quite worried about getting this back online and some Google searches have really worried me.

Thanks for any help!

 

[scott.lawrence]

silly question, but are you able to communicate with the processor?

 

[defcon.klaxon]

silly question, but are you able to communicate with the processor?

Not currently no; if I ping it in DOS it doesn't come up, it's not recognizable in RSLinx and it doesn't show up in BOOTP-DHCP.

 

[scott.lawrence]

this guy solved a similar problem by replacing the battery


http://www.electriciantalk.com/f28/slc-5-05-faulted-wont-communicate-82273/#/topics/82273?page=1

 

[defcon.klaxon]

this guy solved a similar problem by replacing the battery


http://www.electriciantalk.com/f28/slc-5-05-faulted-wont-communicate-82273/#/topics/82273?page=1

I'll try pulling the battery to see if that helps, but these SLCs were installed only a few years ago so I doubt that'll help.

I did pull the SLC out of the rack, removed the battery, and moved the Protected/Program jump from Protected to Program and powered on; now the ENET light is green, but nothing else is lit. If I ping it, nothing comes up. I'm thinking this may hopefully mean it's just a blank slate and I can reload, if I could get the damn thing to communicate?

 

[defcon.klaxon]

Also odd is now whenever I restart the PC workstation and open RSLinx Classic, it immediately crashes. Not sure if that's related or not, but it's got me worried.

edit: deleting the Harmony files fixed this, so I'm back to how to interact with this SLC.

 

[Maxkling]

What does the lights on the processor show when placed in run now? If you pulled the battery and the program was just in the volatile memory and not on the EEPROM then there is a good chance the program is lost.

Have you tried the BOOTP server now after pulling the battery? Have you successfully used the BOOTP tool before, because it can be a huge PITA if you don't know a few tricks?

 

[defcon.klaxon]

OK well I pulled the battery entirely and put the Protect/Program jumper back, and got to a blinking fault but green ENET. Was able to reload program to the SLC and it seems to be working.

Now I'm just trying to figure out how to get the data from this PLC back onto RSView32; right now all the data that usually comes from this PLC is just blank, but the PLC does show up in RSLinx. But I'm not sure if RSLinx is set up properly since I had to delete the Harmony files, since under the SLC it just says Channel 0 DH-485 and under that, 01 SLC 5/05. Do I need to add something below that to get RSView to properly communicate with it?

 

[Maxkling]

What is the channel configuration in RSView? Is it using RSLINX as an OPC?

 

[defcon.klaxon]

What is the channel configuration in RSView? Is it using RSLINX as an OPC?

Here's the odd thing, the Channel Configuration has one channel as TCP/IP but it said the Primary Communication Driver was "none". I set it to AP_ETH-1 which is the RSLinx driver name, and then it started working. So that was odd, but it looks like I'm back in business here.

 

[OkiePC]

The Protect/Program jumper is unrelated, but draining the backup capacitor with the battery removed is a step needed to set the SLC back to a default state.

It has been my experience that the Ethernet port settings are not lost when a CPU gets hosed, but I suppose a seized up CPU might not allow the Ethernet daughter card to do anything useful including respond to a ping.

The Protect/Program jumper is for use when updating firmware and should always be left in the Protect position unless you are performing a firmware upgrade.

Glad you got "back in" to it. Solid red fault LED is never a good thing, getting it to blink is a sign of hope...

I had some SLCs on a big plant LAN I used to support and once a while (especially with one particular large application) one would cr@p out during an online edit. None of the standard advice (like the connection counts and settings in RSLinx) made my problem disappear, I just had to be prepared to run out to the machine with a laptop in case of an "uh-oh" and avoided doing online edits during times of critical production.

 

[defcon.klaxon]

draining the backup capacitor with the battery removed is a step needed to set the SLC back to a default state.

Thanks for confirming this; saw it in Google searches but wasn't sure if it was solid info or not. I mean it did work for me, but I'll put that in my backpocket as a confirmed way for dealing with this in the future.

It has been my experience that the Ethernet port settings are not lost when a CPU gets hosed, but I suppose a seized up CPU might not allow the Ethernet daughter card to do anything useful including respond to a ping.

That's exactly what seemed to happen to this system; ENET was down, but when I did the power drain the program was blank but all the ethernet settings were saved and I didn't have to do BOOTP or anything. What a relief that was.

The Protect/Program jumper is for use when updating firmware and should always be left in the Protect position unless you are performing a firmware upgrade.

Thanks for the info on this. In hindsight I shouldn't have messed with it, but now at least I know the actual purpose for it.

Glad you got "back in" to it. Solid red fault LED is never a good thing, getting it to blink is a sign of hope...

Oh man I am too! I was seeing some pretty onerous Google search results when I specifically searched for "solid red fault", with many results saying things about needing to replace the processor entirely...I was pretty worried there.

I had some SLCs on a big plant LAN I used to support and once a while (especially with one particular large application) one would cr@p out during an online edit. None of the standard advice (like the connection counts and settings in RSLinx) made my problem disappear, I just had to be prepared to run out to the machine with a laptop in case of an "uh-oh" and avoided doing online edits during times of critical production.

Sounds like you've dealt with exactly what I've seen here. So I've read that the onboard battery being dead could be the cause of this; did you ever change the battery to see if the issue went away? You mention the standard advice wasn't successful so it sounds like no firmware upgrade or battery replacement or Linx setting ever fixed it? If so, I will definitely not want to do any changes remotely (the plant is an hour away, and previously I had been making changes via TeamViewer...sounds like I was walking through a mindfield, unaware!).