Fault at PLC Power up

I’m having a problem with an Allen Bradley SLC500. A fault occurs during power up of plc. The Status Error description indicates that a piece/rungs of code needs to be put in place to handle power up, but everyone I talk to say they never experience this problem. My feeling is that it might have something to do with a High Speed Counter card/module (HSCE2), added for use with encoders.

Can anyone help me with this one.

Need some specifics

Can you post the .rss file?
If not, can you give the error code you get when the fault occurs?
What do you do to finally get it going?

Here's the .rss file. I still feel that the fault is being caused by the high speed counter card. I didn't write that part of the program, but my understanding is that setting up the high speed counter card is fairly involved (programming wise). Its setup is mainly/solely found in the 8 & 9 subroutines.

As far as the exact Fault code, I don’t have it written down. But the fault description that came up specifically implied that the fault was caused by not having certain rungs of code that deal with power up.

I didn't mention it, but this fault is more of a hindrance than a major problem, as turning the key switch from remote run to idle, then back to run or remote run makes the fault disappear.

Try to replicate the fault and give us the fault code, everything else will only provide guesswork.

Here is some guesswork:
It is not impossible that the HSCE2 card needs some setup parameters in order to work. The HSCE card I have tried (not HSCE2) required quite a few software settings - RTFM.

I have a solution

Disable "startup protection fault" S:1/9.


The following paragraph has nothing to do with the original question
First of all, I noticed that when you created multiple branches you started a new branch every time (see first part of attched pic). You can do this much easier, and actually save scan time by highlighting at the same location as in the picture, right click, and select "extend branch up" or "extend branch down".
Sorry, just something I noticed...


This part does have to do with the original question
Now, back to the point. If you have S:1/9 =1, the SLC will try to scan the file you have specified at S:29 "fault routine", on power up. As you can see the specified fault routine is currently 'zero' in your program. If used, S:29 cannot be 0,1, or 2.
If you put a zero in S:1/9, or create a new LAD file 3 or greater and put the new routine's file # in S:29, this error will no longer happen.

And another thing...

S:54 is "last major error"

Thanks, I plan to give it a go when im out there next.

... something else to think about ...

lalion,

Our colleague 93lt has done a good job of pointing you to the bits that are causing the symptoms ... but there's still one thing that hasn’t been mentioned that you need to keep firmly in mind here:

The original programmer may have set the bits in question ON PURPOSE in order to force the processor to fault when it first comes up in the Run mode. The main idea is that if the machine is running ... and the power fails ... and the power comes back on ... then the processor will fault ... and the machine will not restart without some manual intervention on the part of a technician. As you’ve already mentioned, with the SLC-5/03 processor you're using, the "manual intervention" required might consist of simply turning the processor's keyswitch to the Program mode and then back to the Run mode. This will usually reset the fault and get the machine back in motion. BUT - naturally the technician would be expected to check the machine's present position, the presence of raw material, the presence of finished material, etc., etc. before putting the machine back in operation.

Just be careful and think ALL THE WAY THROUGH any changes to the program before you make them - and by all means perform some systematic “what-if” type experiments by cycling power to the processor before you consider this particular project completed. By simply eliminating the “processor faults on power up” operation you just might be setting yourself up for a potentially embarrassing (if not disastrous) situation.

In “normal” programming, if the power fails while a processor is in the Run mode ... and then the power is subsequently restored ... then the processor just goes right back into the Run mode ... and the machinery starts moving again. In many cases (maybe in yours?) this is NOT what we want to happen. Some types of machinery MUST be manually cleared and carefully brought back into a “safe at home” condition before being fired up again. Again, this just MIGHT be the reason why the original programmer set those bits up the way he did. Then again, maybe he just simply goofed and left them set by mistake. Things like that do happen sometimes.

Just something else to worry about - it keeps life interesting.

Ron Beaufort,

You're absolutely correct to point out that the original programmer may have wanted the PLC to fault on power-up.

I do, however, have to take issue with your statement

In “normal” programming, if the power fails while a processor is in the Run mode ... and then the power is subsequently restored ... then the processor just goes right back into the Run mode ... and the machinery starts moving again.

Click to expand...

In any systems I've ever worked on, power failure stops the machine and it doesn't restart until an operator tells it to restart. Simply restoring power should not be interpreted as a command to restart.

There may be cases where you need to restart a machine when you turn on the power, but they're pretty rare and there ought to be a compelling reason for the behavior. If I were purchasing a machine I'd make the OEM prove that it couldn't work any other way before accepting it.

... a very good point, Steve ...

Yo, Steve Bailey,

Certainly you are correct and I have no intentions of arguing the point - but I specifically put quote marks around that troublesome little word “normal” in my post on purpose. As a former president might have said: “It all depends on what your definition of ‘normal’ is.”

Most of the systems where I’ve seen this “processor-faults-on-power-up-on-purpose” programming technique used to good effect is in the case of machines which have a semi-skilled “operator” who is allowed to start and stop the operation in “normal” operation (there’s that word again) ... but which require a more highly-skilled technician to put the machine back in operation after a “power failure” situation. In these cases, the “operator” did not have access to the processor’s keyswitch - the “technician” did. If I remember correctly, the application involved some type of raw material which would solidify in the machinery if the power stayed off for too long. The operator had a habit of just pressing the “go” button and wrecking the machinery after a power failure. The technician - having more of a vested interest in preventing a wrecked machine - could be counted upon to clear out the solid junk before restarting the process.

I sort of figured that someone might call my use of “normal” programming into question - thus the quote marks - and I’m quite pleased that there are capable people such as yourself out there who are willing to view everything posted with such a critical eye toward detail. I personally tend to think of the threads on this excellent forum as something akin to “ideas in the rough” which, through their various posts, are passed back and forth from hand to hand from one responder to the next. And with each and every pass these ideas become ever more finely polished - until they finally take on a luster of accuracy and precision which will benefit all who might happen to read them in the future. Thanks for taking part and for helping to polish my latest contribution. I’ll admit, there certainly was room for some extra discussion there.

Finally, by “normal” I simply had in mind a program which did not make use of the bits in question ... but would merely let the processor go directly back into the Run mode after a power failure. Clearly I should have gone into more detail about the use of “manual intervention restarts”, and so forth. And also I suppose that it would have helped if I had made more of a distinction between the machine’s “operator” and the “technician”.

Again, thanks for watching.