Malfunction in Allen-Bradley SLC 5/04


Thread Starter


We have installed SLC 5/04 (Allen-Bradley) for our control process in DM plant. We are facing the problem of abnormal behaviour of the PLC intermittently, wherein some of the valves of the process streams get open without command. Most importantly, we do not get any logging of abnormality in RSView (connected with PLC) or the rungs.

We had migrated from old PLC PLC-5 (cards 1771) and added new streams in the new PLC with the same logic.

We have carried out the following exercises:

1. Replacement of ASB card
2. Checking of logic
3. Checking of processor & other cards

Kindly share your experiences on these incidents.

Bob Peterson

It is almost impossible to tell you what your problem is with the minimal information you supplied. I can tell you that I have heard this kind of thing many, many times, and always blamed on hardware. Virtually every time I have tracked it down it has turned out to be bug in the logic. PLC hardware is by and large extremely reliable and prone to fail in predictable ways. Once in a blue moon you will find a hardware related problem that is difficult to debug (I have run across a few) but the vast majority of the time it is a bug in the logic. The chance of you having a hardware related problem on a mature platform like a SLC5/04 is remote, IMHO, unless you bought used hardware on eBay or something equally stupid.

Since you gave us almost no information to work from, I can't see you getting much response.

Are these valves controlled by analog outputs? Digital outputs?

Is there anything else on the same card doing something goofy when this happens?

When you migrated from the 1771 I/O did you replace them with 1746 I/O? Or did you use RIO to talke to the existing cards? If you replaced them with 1746 I/O cards, a card failure will fault the processor, and you will get an indication of which card faulted in the status table.

Kevin Cooper

I agree with Bob, I have heard and seen this situation several times and it has, without fail, always been a logic problem. It often feels like it is a hardware problem. Check the logic again. Are there other rungs writing to the registers that affect the output to the valves? I think you will find that something either directly or indirectly is causing this in the program. Please let us know what you find.

Issac Issachar

The PLC 5 worked fine, right?

Has the SLC 5 ever worked flawlessly since the changeover?

If the answer is no, then your problem is most likely logic error in the changeover or hte added functions.

You 'used the same logic to add streams'. What didn't get changed to the new process?

Intermittent problems? Never had that before... (yeah, right).

1. Check the output by using counter up like XIC O:0/1 CTU C6:0 to make sure you catch the output going true even for just one rung. Don't trust visual logging.

2. Since you converted PLC applications to SLC, maybe the fact that SLC processing speed being slower is now catching up. Whatever logic flaws hidden by the PLC's quickness maybe evident now. Do you have multiple OTE and OTL/OTU for an output? That could be a problem.

3. Swap the wiring assignments between the mysterious valve and normal one. If the problem stays with the valve, then it's hardware problem. If the problem swaps to the normal one, then it's logic problem.

This should point you at some direction, at least.


Bob Peterson

I would point out that usually the scan time of comparable PLC programs in a slc is faster than in a PLC5. I seriously doubt this is the issue.
I have came across a problem like this once, it was casued by the bit overflow. When you changed over from the old PLC 5, what size memory does it have? I assume your SLC 5/04 has the same or more than your old PLC 5, but if it does not, check your addressing, you may be assigning a value greater than what the memory holds, thereby giving you a false output. However, usually you will get a processor fault which you can see under the error in the processor status. Hope this helps.