Rod...
So... the operator is watching the operation and then he sees that one of the punches has blown.
He hits the Cycle Hold button. The operation stops.
While the current status is Hold Cycle... the operator is allowed to operate the various axis in manual.
It doesn't seem reasonable to allow manual operation while the E-Stop is pressed... does it?
He operates the X, Y, and Turret to bring the blown punch to the tool station. The tool is replaced.
Now... he presses the "RESUME" button.
The expectation here is that the machine will "rewind" and return to that point in space and time... just before the first operation of the blown punch. When all is ready the process resumes seamlessly.
Generalizing... There are many types of Punch Sequences. Here are a few cases...
1. Single Punch per Index: The blank is indexed in, the punch happens, the part is ejected, done.
Index, Punch, Eject part - Index, Punch, Eject part
2. Multiple Punch per Index: The blank is indexed in, several punch operations, the part is ejected, done.
Index, Punch-1 ... Punch-X, Eject part, Index, Punch-1 ... Punch-X, Eject part
3. Multi-Stage Punch Operation:
There are several different punch operations happening simultaneously on each punch cycle. The blank feeds in to the first position, punch, index to next position, punch,... repeat until punch at last position, then eject part. The punch-die might consist of any number of positions (steps). It takes as many cycles as there are steps to fill the die. Once the die is full, a part is produced on each cycle.
The general form of Case-1 is...
"Load the Part"
"Punch the Part"
"Unload the Part"
The general form of Case-2 is...
"Load the Part"
"Punch the Part"
"Unload the Part"
The general form of Case-3 is...
"Load the Part"
"Punch the Part"
"Unload the Part"
The only difference shows up in Case-2. In this case, "Punch the Part" consists of several "sub-modules" each controlling a particular punch operation.
"Punch the Part"
--- "Punch with Tool-1"
*
*
*
--- "Punch with Tool-X"
Now, the idea of creating a sub-module for each of the possible tool-positions might or might not seem reasonable. If the only difference in the various sub-modules is the tool... then perhaps a single, general purpose sub-module can be created. If so, then sets of parameters can be passed to the sub-module for each punch operation. An operator can create custom sequences through an interface. Of course, this is easy to say.
Back to the primary issue...
When the operator presses the "Resume" button, he expects the process to return to the point just before the first operation of the blown tool. Of course, the operator doesn't know that the tool is blown until after the fact. The question is, how much "after the fact". The operator might be a little slow on pushing the Hold Cycle button.
How can the program "know" where it needs to go before resuming?
The program can "cache" all of the pertinent operating parameters when the Hold Cycle or E-Stop is pressed. This is a "snap-shot" of where it is and what it is doing when the Hold Cycle or E-Stop is pressed.
Now, it is important to realize that this is nothing more than a "snap-shot" of conditions when the Hold Cycle or E-Stop is pressed... not necessarily the conditions existing when the first blown-operation occurs. This "snap-shot" will always be "after the fact". It would be great if the program could detect a blown-operation as it occurs!
The biggest clue will become obvious when the blown tool is changed. If the particular sequence isn't too complicated then it should simply be a matter of "stepping backwards" through the code to the last point where that tool was used.
Now, the sub-module (or parameter set), where the particular tool was last used, has a beginning and an end. In between the beginning and the end, the tool might go through any number of various operations. For instance, this particular tool might be used to deliver several strikes before the sub-module is complete.
So, having rewound to that particular module, where do you want to resume from? Do you want to resume at the beginning of the several strikes, thus repeating all of the strikes... or the end of the strikes... or somewhere in between? Maybe the number of strikes is important... maybe too few or too many might cause a problem.
I have no idea what any particular sequence might be. The possibilities are unlimited. As such, it becomes very hard to develop a "general solution" for resuming from any particular point within the sub-module. If it won't cause a problem then the easiest point to resume from is the beginning of the sub-module where the last use of the particular tool occurred.
Now, it might be the case that the particular tool was blown earlier than the last use...
1. Tool-1,
2. Tool-2 (blown),
3. Tool-3,
4. Tool-2 (blown - last use of Tool-2),
5. Tool-4
"HOLD CYCLE" => Tool-2 is replaced.
"RESUME"
Now... where should the program go? Step-4... the last use? Or Step-2?
Can the operator "know" that the first failure was on Step-2? Is it important that the process resume from the first blown-operation... or... is it OK to resume from the last blown-operation?
If this is a Multi-Stage process (Case-3), does the material have to be indexed backwards a few places?
All I'm trying to do is cover the possibilities... I have no idea how complex a particular sub-module might be.
The ideal solution is a "general solution". A "general solution" will handle any situation. Of course, the complexity of the "general solution" is entirely dependent upon the worst-case complexity among all of the sub-modules.
So, let's assume that the program "knows" where to "rewind" to.
BTW, if the operator pressed the E-Stop then he would have to pull the E-Stop before being able to change the tool. At this point, the process "expects" to be restarted with "RESUME". If the operator happens to push "START" instead of "RESUME" then maybe there should be a message asking for verification.
The Turret is at the tool-station. The operator presses "RESUME". ("Are you sure? Y/N")
First, the Turret returns to the place where it was when the Hold Cycle or E-Stop was pressed. It has to follow a path that is guaranteed to be safe.
Once in position, the program rewinds and loads the particular parameters. The machine then steps slowly to bring the physical conditions to match the expected conditions for the particular sub-module.
Once completed, the screen indicates that the machine is ready to resume running. This is the last chance for the operator to verify that all is well and that it is OK to run. ("RESUME RUNNING? Y/N")
OK... since I have no idea of the particulars... I pulled all of this out of my a$$...
So... does any of this give you any ideas?