Allen-Bradley SLC 500 CPU Faulting - help please

[tensleep]

I have an SLC 500 that is registering a fault. I have been able to reset the fault and keep on running the production line, but before I hook up the laptop and start digging deeper, I would like to know if any of you have extensive experience with this particular PLC. It has been over 10 years since I have really dug into one and would like a bit of insight. I am in touch with my local vendor and factory rep and can bring in an AB engineer if necessary, but I like to figure out these kinds of problems for myself, where possible.

The CPU Fault LED is flashing, but can be reset. The troubleshooting manual says this represents a major CPU fault that could be caused by a hardware/software fault or erratic repetitive power cycling. The remedy is to monitor Status File Word S:6 and clear Satus Files S:1/13,5 &6, then set the processor to run. I have been able to toggle the keyswith to program, then back to run, clearing these files. My next step is to see if I can get one of these ancient laptops to communicate with the PLC so I can pull the code out of S:6.

I'm all ears.

 

[nasadowsk]

Lots of things can do this - including math overflows. You really need the fault code to figure it out.

I don't remember, and it might vary by processor, but math faults tend not to clear. You can get those if an analog card or sensor goes out of range, or you have an overflow that wasn't cleared by the end of scan, or a divide by zero, etc.

Intermittent random faults that do clear, I'd be looking at reseating all the cards if it's in a vibration prone cabinet, or maybe the rack/power supply if it's not. This assumes an older unit. You could also have a card that's going bad, as this will throw faults too.

Get the fault code - it'll give you and idea where to look. I'd be surprised if it's math, though I have a customer who calls about once a year with a random math fault in one of his machines, that comes in for no reason but won't clear. Go figure.

S:1/13 I think is just the fault flag. S:6 and S:5 are where you really need to look.

You shouldn't need the PLC program to get in, but it's useful in case you need to debug the program. SLCs don't save comments or annotations or symbol names, etc in there, so you're blind debugging without them, and that's no fun Of course, I bet the code's fine and you've got a HW issue going on.

Also:

What model SLC processor, are you doing any networking (DH485, etc) or remote I/O with it?

Have fun! (And don't accidently wipe out the program on there )

 

[jocko_nc]

Wow. A Slick 500 issue getting resolved on AK. Amazing.

 

[gadget73]

This isn't by chance connected to an ethernet system is it? Our old PLC/5 at work was faulting and doing random stuff like this and we finally isolated it to some sort of noise in the ethernet connection. The whole works would crash with the fault light on the processor, but we could make it run again by powering it down, and powering it back up again. It would then run for some random amount of time before doing it again. The cheap Linksys switch was replaced with something a little better and an "ethernet surge protector" (whatever that is) was installed and we haven't had trouble out of it since. Semi-related, is your rig on a UPS? No faults with that is there? We also had the UPS batteries crap out. It didn't give any trouble with the PLC but if your power supply occasionally has voltage drops and the UPS isn't picking up the slack properly, that likely isn't helping any.

 

[tensleep]

Thx guys, I don't think it is math related. I replaced a bad digital IO card earlier this month. I am beginning to suspect the power supply or the backplane. I reseated about half of the cards, but will probably go through them all. It ran today just fine. I have a spare CPU card on the way, should be here tomorrow. I was boning up on some RSLinx today. We do have the original program archived, along with the comments. We have an HMI hooked up to the 485 port, but no ethernet or remote access. I will probably go into the program tomorrow, time permitting, just to be sure that I have all of the equipment that I need to program the new card and have it ready as a hot backup. While in there, I will check the files you guys mentioned. One quick question - the jumper on the card should protect the resident program as long as I have it in the right position, correct? Also, the low battery LED is dark, so the battery should still be good? This is a 1706L532 CPU card.

 

[nasadowsk]

Yeah I think the jumper will do that. Also, the battery light being off is a Good Thing (tm)

You'll need RSLinx and RSLogix to get in there. Should have no issue finding the CPU as long as you have the serial port on your computer set up - the auto detect works pretty decently too (it's under the driver setup in RSLinx, or at least is there in Classic).

You replaced a bad card? If it's old enough to start blowing out cards, the backplane and PS are good suspects for random lockups, too. You're right, this doesn't sound like it's math related.

The error code will tell you, IIRC there's a few for card faults and random hardware faults. If you see those, you know something's up.

Reseating is always a good idea to try first. If possible, you could try wiggling cards while the processor's in run to see if it bumps it into fault.

I wouldn't expect the HMI to do anything bad enough to lock the CPU unless it's *really* hammering the poor CPU with bad requests and all.

 

[tensleep]

So far so good....

The new CPU is in my posession and ready to go.