RSLogix User Fault Routine

jthornton

Member
Join Date
Jul 2002
Location
Poplar Bluff, MO
Posts
295
From the help manual (yes I read it alot):
"Every application program should start up in a known predictable state. This can be especially critical if the application was running and was powered down while running. One method of starting in a known state if the system was powered down while running is to enable this feature, which causes the execution of a special ladder subroutine before the normal ladder subroutine begins execution.

To set this protection either double-click the Processor Status icon in the project tree or double-click the status (S2) file; then select the Errors tab.

Startup Protection Fault S:1/9

When this bit is set and power is cycled while the controller is in the REM Run mode, the controller executes the user fault routine prior to the execution of the first scan of your program."

Now I'll be danged if I can find any info on the "user fault routine".

Where is it?

Does anyone use it?

Thanks John
 
To add confusion, here's a little more about it (from the help file):

[attachment]

This seems to contradict the "causes the execution of a special ladder subroutine before the normal ladder subroutine begins execution" statement :unsure:

I just use the S:1/15 bit to run that "special ladder subroutine" when I need one.

It makes more sense that this "Fault Routine" executes only when a user fault occurs, but what the heck is a "user fault"???... I carefully type in "user fault" at the Knowledge Base... Whaddya know, no results... :rolleyes:

beerchug

-Eric

faultroutine.jpg
 
Yo, John:

I just ran a few experiments with a spare SLC-5/04 to refresh my mind on this "user fault routine" subject. You might find this interesting.

With a brand new program, add a new ladder file to use for a "fault routine". I made mine "unlucky" #13. In this file, place one unconditional rung:

ADD F8:0 1.0 F8:0

In other words, take the value in F8:0 - ADD 1 to it - place the result back in F8:0. This will give us a count of how many times the processor executes the "fault routine". (And no, a counter wouldn't work just as well).

To tell the processor that this a "fault routine", look under "Processor Status" and go to the "Errors" tab. Where it says: "Fault Routine S:29", enter 13 - the ladder file number.

Now place the processor in EITHER the RUN or REMOTE RUN mode. Note the value in F8:0 - it should still be 0.0 at this point. Now kill the power to the processor - and then bring it back up. The value in F8:0 should still be 0.0 - we didn't get a fault - so we didn't execute the fault routine.

Now turn on the "Startup Protection Fault" bit S:1/9 on the "Errors" tab. Again note that the value in F8:0 is still 0.0. Now (with the processor still in RUN or REMOTE RUN mode) kill the power the system again and then bring it back up. Notice that the processor is now FAULTED - if you go to the Status file you'll see the error description is:

"Startup protection after power loss. Error condition exists at powerup when bit S:1/9 is set and powerdown occurred while running."

Also check the value in F8:0 which is now 1.0 - looks like the processor ran through our "user fault routine" one time before it shut down.

Now what possible use could we make of this? How about instead of a our simple test "count-up" rung in the fault routine, we add in something like:

MOV 2048 N7:0

an unconditional rung to move a "start up" setpoint to a pump speed.

And maybe:

OTU O:1.0/0

an unconditional rung to UNLATCH a previously latched-on hydraulic ram.

And maybe:

OTL O:1.0/1

another unconditional rung - to LATCH ON a recirculation pump that we really want to run when we finally get the machine up and runnning again.

As you play around with these, keep in mind that these outputs may also be controlled (in normal operation) by additional latches and unlatches in other ladder files in our program. Our "fault routine" won't affect the NORMAL operation of these outputs - since the rungs in ladder file #13 only execute when we have a fault condition.

Now suppose that these "startup condition" rungs are in place and our system is running along smoothly when all of a sudden ... the power fails. Now (thanks to our "user fault routine") when the power finally does come back on, the pump speed setpoint will be automatically changed to the 2048 "startup value" - and the hydraulic ram's bit will be turned off - and the recirculation pump's bit will be turned on. Of course NOTHING is going to run right away because the processor is faulted. But that MIGHT BE just what we want. This way we don't have to worry about the machine simply coming back up in the GO mode after a power failure - which is exactly what usually happens when you just cycle power to a runnning processor. Now a "fault" condition might seem a little extreme at first glance - but consider this: If we use this method, the machine operator will need someone (like a technician or a supervisor) with access to the processor to clear the fault and get things going again. And incidentally, if the processor has a keyswitch, you can reset the fault by turning the key to PROGRAM and then back to RUN. You don't need the laptop.

Want to have more fun with faults? Add a rung in ladder file #2 like:

XIC B3:0/0 MOV 32768.0 N7:0

This rung will TRY to move 32768 into N7:0 when you toggle bit B3:0/0 on - but (as you are probably aware) that's too big a value to fit in an integer location. So we get a fault when you execute this rung and the processor shuts down. But look at the value in N7:0 after you've tried this. It should be the 2048 "startup value" - courtesy of our "user fault routine" which executed when our "overflow" MOV rung caused the fault. In other words, we tried to move the 32768 value but that caused a fault. (In case you're wondering, the processor did the best it could and moved the value 32767 into N7:0 - it was the extra "1" overflow that caused the fault). But as soon as we had a fault, our "fault routine" ran and changed the value of N7:0 to our required "startup" setting of 2048.

Now let's get crazy. Add this rung at the bottom of our fault routine in ladder file #13:

OTU S:1/13

This new rung, believe it or not, tells the processor to reset its own "Major Error Halt" bit. In other words, we're telling the poor processor to RESET HIS OWN FAULT and keep on running. Now when we execute the "overflow" rung, the overflow still DOES cause a fault - but the processor keeps right on ticking along - because we told him to reset the fault bit and keep on going. And watch the value in F8:0 climb. That's because the "fault routine" has to keep executing everytime we cause a fault - which is EVERYTIME we scan our "overflow" rung with B3:0/0 on.

Now this "automatic fault reset" is certainly not the type of thing you'd want to do in every program - but it does open up some neat possibilities in critical cases where the machine just absolutely HAS to keep on running. One memorable example I've run across featured the following:

If we have some kind of math error in the "bean-counter's data collection" subroutine, just reset the math error and don't run that particular subroutine anymore. Keep the rest of the machine running in production mode - to heck with the bean-counters and their data. Can you figure out how to do that one? Hint: Check out all of the information on the "Errors" tab under "Processor Status".

Another (even better) one:

Suppose one of our input or output modules goes belly up late one Saturday night - but maybe the inputs or outputs on this particular card are non-essential ones that our system COULD temporarily live without. But, wait a minute ... a bad or missing module always causes a faulted processor - right? Well, there is a way (in MOST but not in all cases) ... to have the processor AUTOMATICALLY keep right on running ... until we come in on Monday morning, and replace that defective module.

My conclusions as to your original post: You can set up a "user fault routine" by programming a ladder file to carry out your "if-I-have-a-fault" instructions. This file (whose number is specified in S:29) will execute WHENEVER your processor experiences a fault condition.

Further, you can tell the processor that you want it to "fault out" if it happens to be POWERED DOWN while it is operating in either the RUN or the REMOTE RUN mode. (Normally that situation wouldn't qualify as a fault - but it WILL be a fault if you turn on bit S:1/9).

Finally, if all you want to do is PREVENT a "come-back-up-in-the-go" mode after a "while-you're-running" power-down, you don't really need to set up a fault routine at all. Just turn on that S:1/9 bit - the processor will fault out when the power comes back on. The error description in this case will be:

"Invalid or non-existent "startup protection" fault routine."

and you can just manually reset the fault to get the system back in operation.

I wish I had more time to play.

Best regards,

Ron
 
Last edited:
Thanks Ron. This is a very good tech support .

I am studying this part with the manual. Your post is just came on time for me. I would rather read your post than the manual or the help files.
 
Thank You Ron for the explanations on user fault routine, never known of such capabilities built in. It was really good.
 
Ron, that was an excellent description of how to use the fault routine. I would like to add a couple things to your post.

#1 It is called a User Fault Routine (and user fault) because the fault occurred because the program did something it wasn't supposed to. The program the user wrote; thus the "User Program". This is opposed to a hardware failure in which the User Fault Routine does little good.

#2 Because the "User" faulted the processor, the user can clear the processor (using the S:1/13 and the OTU as you described). This can be VERY helpful in allowing the system to start a shutdown sequence instead of having everything slam to a halt. By the way, I always set a B3 bit in the fault routine as a flag to let me know a fault has occurred. Just a OTE with an unused binary bit.

#3 in your explanation of the S:1/9 bit

Also check the value in F8:0 which is now 1.0 - looks like the processor ran through our "user fault routine" one time before it shut down.

The fault routine actually ran one time on power-up and then since the S:1/13 bit was set (by S:1/9) the processor faulted.

With this bit I usually nest and trigger a subroutine inside of my fault routine. This file becomes my "Reset equipment due to a power loss while running" subroutine. Then I can control whether or not I want the fault cleared (and put into Run) after these functions are performed. This all takes place before the regular First Pass Bit, S:1/15, would ever come into play.

So with all of these wonderful bits I can:

Make something happen on powerup (no fault) using S:1/15
Make something happen if a fault occurs using a fault routine and a B3 flag.
Make something happen on power-up after a power loss while running using S:1/9

So much to know, so little time!

OG
 
After I reread my earlier post in this thread, I realized that I might have given some of our beginner readers a false impression. John's original questions were about "user fault routines" and so I directed all of my comments toward that topic and tried to offer some "entry-level" examples of how such programming methods MIGHT be used. Later I realized that (by jumping through all of those "fault routine" hoops) I might have inadvertently led some readers to believe that the "suggestions" I had made were the "right way" to ensure that a machine always starts-up from a "known condition". Actually, the practice of intentionally FAULTING a "running" SLC processor after a power failure is NOT the only way to handle this problem. And even though all of the points that I made in my earlier post are valid, I wanted to make it clear that I'm not recommending that particular programming method and, in fact, I've never seen it used in the real-world.

On the other hand, what you WILL see quite often is the method which Eric Nelson mentioned in HIS earlier post.
I just use the S:1/15 bit to run that "special ladder subroutine" when I need one.
Specifically, using the "first scan" bit S:1/15 to execute an "initialization" routine whenever the processor first starts up after any "power down" condition is a VERY common practice. It works like this:

At the top of ladder file #2, you program a rung similar to the following:

S:1/15 +--JSR----------------------+
----] [--------| Jump to Subroutine |
| SBR File Number U:10 |
+---------------------------+


S:1/15 is the processor's "First Pass" bit. In other words, whenever the processor first starts to scan its program, this particular bit is true - for one scan only. In addition to this JSR rung, we'll also set up ladder file #10 and make sure that it contains whatever "startup" or "initialization" conditions that we might need for our system's "known condition". Here are a few example rungs:
[attachment]
Sometimes the "unconditional" appearance of these rungs causes some confusion. Since they don't have any "switches", many beginners assume that these rungs will always be executing continuously. They won't do that. Remember, we're only going to send the processor through this subroutine for one scan cycle. After that, these rungs will (in effect) be disabled.

Now for a few more specifics about the "First Pass" bit S:1/15. This bit will be true (for just one scan) whenever:

1. the processor was operating in the RUN or in the REMOTE RUN mode - then it lost its power - and later it has its power restored.

2. the processor was idling in the PROGRAM or the REMOTE PROGRAM mode - and then it gets placed in either the RUN or the REMOTE RUN mode.

3. or, in other words, whenever the processor first starts to scan its program.

Finally, all of the examples in my previous post, and in this one, are intended for use with an SLC-5/04 processor. Just be aware that if you're working with a MicroLogix system there will some differences (the user fault routine is PREDEFINED as ladder file #3, etc.) but the basic ideas will be the same.

Best regards,

Ron

P.S. Now that I've read Operaghost's addition, I've got to go run through some more experiments - maybe I missed something here. Maybe more to follow -

cut2.jpg
 
I think some of the inital confusion was over the definition of 'user fault'.

Ron or OG will correct me if I'm mistaken here, but can I conclude that 'user fault' means an error during the execution of the PLC program (user program), such as division by zero?

This would be in contrast to 'user-defined fault', which would indicate an abnormal condition on the machine being controlled.
 
Wow! Automatic Recovery is a hell of a hassle by itself without having to go through extra hoops. The whole thing can be handled in the main-ladder. If the routine is not required, then SKIP it (ie, JUMP over it). Or, you can call ANY Sub-Routine.

I think the only reasonable solution was suggested by Eric.
That is, use a special bit to "call" the "special recovery routine".

Now, bear in mind... just because this description might be a little long, that doesn't necessarily mean that the concept I'm describing is any more complicated than the other descriptions that have been posted. It just means that I am discussing more of the aspects of the concept that, while present in all forms of the concept - regardless of discussions to this point, have not been addressed in any of the other discussions. (Perry Mason ???)

I'm just adding things that I think need to be said in terms of the concept.

So, what is the nature of that "special bit"?

Whenever the process begins running a cycle, "SET" any RETENTIVE bit indicating that the process is "IN-CYCLE" (that, is the special bit). When the Process finishes the cycle, "RESET" that RETENTIVE bit. As soon as the cycle begins again, "SET" that bit! And so on and so forth...

Now, at ANY Time, and, under ANY Condition, if the process stops while "IN-CYCLE", then that RETENTIVE bit stays ON.

The "Conditions" can be...
  • Power Loss
  • E-Stop
  • Process Fault
  • ???

CASE: Power Loss (I ain't even gonna try to cover 'em all!)
When the power is restored, NOTHING should happen! NO RECOVERY - NO NOTHIN' !!!

Whether the power comes back on expectedly or unexpectedly, you don't want things to start moving until everyone and everything is ready. That means getting the people ready and verifying that the PLC is indeed ready to function properly.

For example, if the power loss took out one of the Input Cards, and the recovery process relied on that card, then jumping into recovery might not be a good idea... depends.

So, if all is ready, then, when the PLC powers up, the first-scan bit catches the "special bit" and indicates to the program that the process needs to activate the "special recovery routine".

Then, with all ready, the operator presses "GO". The Process, knowing that the process stopped mid-cycle, executes the "Special Recovery Routine"! Once the recovery is done, the operator pushes "GO" again to really GO. (Before doing so, the operator might need to clear out some of the collateral damage!)

The content of the "special recovery routine" depends on the nature of the process. Basically, the routine would consist of whatever action YOU would perform MANUALLY to recover the process. (Don't Jump-the-Gun yet...More later)

That Manual Action might involve one or more of the following:
  • Moving BACKWARD in the Cycle to the PREVIOUS STEP.**
  • Moving FORWARD in the Cycle to the NEXT STEP.**
  • Bringing ALL moving parts back to their "HOME" Positions.
  • ???

** This indicates that there might be a need for more than one special bit!

Certainly you need the one that indicates "IN-CYCLE". But, you might also need a special-bit to indicate the "CURRENT-STEP". You might even need to identify the "CURRENT-STEP" in a given "MODULE"; where you then have to handle your recovery on a "Module-Basis"... depends!

The whole deal is, in too many cases, the PLC does NOT know the REAL, PHYSICAL STATUS of your process.

EX: On power-Up, a Pulse-Type encoder has NO IDEA where the monitored device is at (at least, not on its own)! The PLC might know where the device started and where it was supposed to go, but, when the lights go out, the Pulse-Type encoder goes stupid. Even if the PLC remembers the last valid pulse-count... What did the device do When the Lights Went Out? Coasting? Settling?

Now, here's the tricky part...
It's really NOT a case of how would you manually recover the process.
It really IS a case of, how would you manually recover the process "in the blind"!

That is, YOU are the Computer! You are in a darkend room with nothing more than a few indicators, pencil, paper...

Somehow, you do have an understanding of the physical layout of the process. Now, what do you have to do in order to bring the process to a known-good state without causing further collateral damage?

If you don't keep track of where you were when the "problem" occurred, then you have to figure out the absolutely WORST CASE situation and build your recovery routine to satify that condition.

If you do keep track of where you are...

If you are lucky, you can build a recovery routine that can be used for ANY and ALL conditions. That is, if you have a recovery routine consisting of Step(s)-A, -B, -C,... -F, then, even if Step-A and Step-B DON'T need to happen, there is no harm in having the routine execute and verify that they are done, or simply verify that the required conditions aleready exist. The routine then proceeds with -C, -D, -E and -F. At that point, the system is ready.

If you haven't been a good boy (i.e., you ain't lucky) then you might have to develop special solutions for each special case.


All of the stuff I discussed above is to be considered for ANY recovery process - no matter how the recovery is implemented. That already sounds like a lot of grief to me without having to deal with predefined special bits and special files.
 
Terry:

There are at least three issues / subjects being discussed in Ron's reply. Don't get confused and blend them together.

1) What the S:1/9 bit does, in essence, is tell the PLC "Treat Loss-of-Power as a Fault". That means that the PLC comes back to life "faulted" instead of "Running" (which may or may not be a good thing), and can run a special routine dedicated to dealing with faults, if such a routine exists.

2) Fault Routines. The AB has special subroiutine call that the PLC can used between "Help! - I'm in trouble", and "That's it, I quit!". It's a nice, if underused feature.
Ron went into some possible, but not necessarily recommended, ideas for what to do with the Fault routine. I'm not going to argue about the validity of his examples, because they were just that - examples. Each system is going to be different, and whether something starts up or not when power is restored is an engineering decision that only the local engineer, not second-guessing web-surfers can make.

3) Startup Routines. Ron also combined the two concepts of "Power Down=Fault" with "Run Fault Routine" to touch on "Run (Fault) Routine on Power-up". Again, with examples.
Can you do it in "regular logic"? Sure. Some things you may only want to do on a one-shot, just on the the first scan. AB provides a "first scan" bit. You can roll your own easily enough (Last line of ladder, put an unconditional coil. PLCs typically clear all coils before scanning. Use the -|/|- of that bit to execute logic the first time (as opposed to using the -| |- of S:1/15)



Things I've used the Fault Routine for:
1) "Identical" SLCs, with different I/O modules, but the exact same program (some controlled 2 reactors, some only one, with anticipated expansion). Downloading the same program to the SLCs that didn't have the proper I/O cards, caused a Fault. The fault routine, checkd the "Fault Number", and if that was the cause, disabled the Empty Slots, and the program was back in business.

2) "Myserious" math errors. A PLC will fault on a negative timer. With production being held up while I attempted to troubleshoot - I had the Fault routine For-next through the timers, log which one was negative, and write a "good" number, and put the PLC back in operation. This let production continue while I tracked the down through the HMI / PLC to find out what calculation/entry is coming up negative.
 
Last edited:
Friends and neighbors:

I wrote the "follow-up" (see below) late last night but didn't get to post it until now. Allen Nelson is absolutely correct: In my original post, I was replying to someone who had posted "what-the-heck-is-it?" type questions about the "User Fault Routine". I wasn't trying to promote any specific style of programming. I'm sorry if anyone got that impression - and I tried to make that point clear in my second post to this thread. Continuing on ... in answering the original question (as is often the case) I learned quite a bit on the subject myself - as mentioned in the follow-up below.

----------------------------------------------------------------------

A few "final" thoughts on the USER FAULT ROUTINE question.

I had never noticed that the name "User Fault Routine" is somewhat ambiguous. I had always considered it to mean: "A routine, written by the user, which responds to (any type of) faults".

After a careful reading of Operaghost's post, and making a few more experiments, I have reworked my "User Fault Routine" definition to: "A routine which responds (only) to USER FAULTS".

With this in mind, a statement which I made in my first post to this thread needs a minor (but important) correction. My original statement was:

"This file (whose number is specified in S:29) will execute WHENEVER your processor experiences a fault condition."

This should be corrected to read:

"This file (whose number is specified in S:29) will execute whenever your processor experiences a USER FAULT condition."

As OG correctly pointed out, the User Fault Routine will not respond to hardware faults. It responds instead to faults which are related to the user's program. The distinction between "hardware faults" and "user faults" is a rather fine line. For example, the fault caused by a missing I/O card (which I would have assumed to be hardware related) is defined instead as a "user fault" - and therefore the "User Fault Routine" which we have been discussing will indeed respond to this type of fault.

For those of you who haven't had quite enough of this particular style of torture, you might want to go to the RSLogix500 Help menu item; click Contents; click the Index tab; and go to the entry for "SLC Controller Major Error Codes". This topic contains a list of many error codes and breaks them down into "user" and "non-user" categories. If you're anything like me, you'll want to do some experimenting before you bet the rent on this information - but it seems to be the best starting point I've come across so far.

Finally, this particular list might be of interest to Eric Nelson who asked (along with many of the rest of us): "What the heck is a user fault?" in his earlier post to this thread.

----------------------------------------------------------------------

Best regards to all - and thanks again to OG - and to Allen Nelson,

Ron
 
Ron Beaufort said:
begin clipping...

"SLC Controller Major Error Codes". This topic contains a list of many error codes and breaks them down into "user" and "non-user" categories.

end clipping... (due to dull scissors)
Well, yes, that sure clears things up a bit! Thanks Ron... :D

beerchug

-Eric
 
User Fault Routines

Hi Ron

I have read your repy on User Fault Routines with interest, but I have not been able to keep the processor running with a non essential card missing from the rack.

I have written zero into the location S;9, and also unlatched bit S:1/13. There is obviously more to it. I would be interested in your comments.

Many thanks for your help

Derek
 

Similar Topics

Hi all, I'm almost embarrassed to say that I can't work this out. I've never had the need to, because very early on I started entering my rung...
Replies
3
Views
3,691
hello every one as i am new to this forum i want to know detial of udt in rslogix 5000 does all tags in udt get in my program? if i have to write...
Replies
6
Views
15,927
I'm working on an RSLogix 5000 v15 applications and when opening one of the User-Defined data types I receive the error: "This data type was...
Replies
3
Views
9,333
Hi, I created my own tag (6 reals and 2 dints). I tried to send it via msg to another PLC, and error 16#0013 "configuration data size too...
Replies
6
Views
18,296
Is there a command that you can use against a UDT that will fill it with zeros? Of course the UDT has dint, bool and strings... EX: FLL...
Replies
14
Views
11,188
Back
Top Bottom