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 dark
end 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.