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
