Use search function of the forum.
A good starting point is Re: Cancel Program and Send Pointer to Cell.
Code in SPS to auto RESET via PLC. I_RESET_PROGRAM signal from PLC, O_RESET_PROGRAM signal to PLC. RES1, RES2, RES3 markers.
.;FOLD Auto RESET PROGRAMA.
;Auto RESET
IF (( $PRO_STATE1==#P_ACTIVE) AND ( $MODE_OP==#EX ) AND ( NOT $PRO_MOVE ) AND ( I_RESET_PROGRAM )) THEN
CWRITE($CMD,STAT,MODE,"STOP /R1/BINPICKING_TPV()")
RES1=TRUE
O_RESET_PROGRAM=TRUE
ENDIF
IF (( $PRO_STATE1==#P_STOP ) AND ( RES1 ) AND ( $MODE_OP==#EX )) THEN
CWRITE($CMD,STAT,MODE,"RESET /R1/BINPICKING_TPV()")
RES2=TRUE
ENDIF
IF (( $PRO_STATE1==#P_RESET ) AND ( RES2 ) AND ( $MODE_OP==#EX )) THEN
CWRITE($CMD,STAT,MODE,"RUN /R1/BINPICKING_TPV()")
RES1=FALSE
RES2=FALSE
O_RESET_PROGRAM=FALSE
ENDIF
;Auto RESET first START
IF ((( $PRO_STATE1==#P_RESET ) OR ( $PRO_STATE1==#P_STOP )) AND ( $MODE_OP==#EX ) AND ( NOT $PRO_MOVE ) AND ( I_RESET_PROGRAM )) THEN
CWRITE($CMD,STAT,MODE, "STOP /R1/BINPICKING_TPV()")
RES3=TRUE
O_RESET_PROGRAM=TRUE
ENDIF
IF ((( $PRO_STATE1==#P_RESET ) OR ( $PRO_STATE1==#P_STOP )) AND ( RES3 ) AND ( $MODE_OP==#EX )) THEN
CWRITE($CMD,STAT,MODE, "RESET /R1/BINPICKING_TPV()")
RES3=FALSE
O_RESET_PROGRAM=FALSE
ENDIF
;Auto select PROGRAM
IF (( $PRO_STATE1==#P_FREE ) AND ( $MODE_OP==#EX )) THEN
CWRITE($CMD,STAT,MODE,"RUN /R1/BINPICKING_TPV()")
ENDIF
;ENDFOLDThat looks like exactly what I'm trying to do. My question though is if the BINPICKING_TPV() is running on SPS.sub, how does the program know to reset if it gets stuck inside BINPICKING_TPV()? I thought the interpreter could only process what it's currently executing plus the advance run. Is it able to continue checking SPS.sub, or does this only get checked after you've finished running through BINPICKING_TPV()?
I started looking into the TRIGGER method Hermann referenced, but I haven't figured out how to start over at the beginning of the main loop after triggering the reset code yet. Currently it triggers, runs the reset, and then resumes where it left off in the main loop instead of starting at the beginning.
My question though is if the BINPICKING_TPV() is running on SPS.sub, how does the program know to reset if it gets stuck inside BINPICKING_TPV()? I thought the interpreter could only process what it's currently executing plus the advance run. Is it able to continue checking SPS.sub, or does this only get checked after you've finished running through BINPICKING_TPV()?
That's not how this works. The SPS runs in the Level 0 interpreter, and the "normal" programs run in the Level 1 Interpreter. Each interpreter can issue $CMD Run/Cancel commands against the other interpreter, but not against itself.
So when the SPS is triggered by some event to issue a $CMD RUN for BinPicking_TPV, that program gets loaded into the L1 Interpreter, and runs there. It is not run as a subroutine of the SPS, and if BinPicking_TPV gets hung waiting for something, the SPS keeps right on going.
(or should -- a well-written SPS has no WAIT statements or "blocking", but runs as a state machine. A badly written SPS could be written in such a way that a WAIT in the BinPicking_TPV program could cause the SPS to hang)
However, there are a few caveats: $CMD RUN does not actually start program execution -- it works more like the Select button on the teach pendant. The robot must still receive $EXT_START (for EXT mode) or have the start button on the pendant pressed (T1, T2, AUT modes).
Also, issuing a $CMD RUN when the interpreter is already occupied won't work. That is why the example program uses $PRO_STATE and other $CMD commands, in proper sequence, to first Cancel the current program in the L1 interpreter, then load BinPicking_TPV.
read manual for CREAD/CWRITE about selecting/stopping program
you can press START/STOP program manually or use these commands, does not matter what line of code instruction pointer are at.
code shared by Hermann is correct. it still uses EXT mode as usual but has added feature tht program can be aborted. if you select program again, it is automatically reset. the thig to watch with any of this is that you really really need to know what you are doing to prevent collisions (there is no BCO in EXT mode). in other words the safe return to home must be programmed and called after each abort. example is covered in KUKA training Programming3
actually there is more to it. i did some tests maybe 2 years ago and CWRITE can start and run program without $EXT_START (checked on 8.3 and 8.5). drives are on and move enable is on, "RUN PROG()" does both select and start functions. also in this case $DRIVES_OFF did not work either. if i recall the only thing that did work as expected (and all the time) was move enable...
I started looking into the TRIGGER method Hermann referenced, but I haven't figured out how to start over at the beginning of the main loop after triggering the reset code yet. Currently it triggers, runs the reset, and then resumes where it left off in the main loop instead of starting at the beginning
It doesn't resume in the main loop, but in the mainprogram, because the interrupt is declared in mainprogram, and so you have a complete restart except the declaration of the interrupt. And by the way, you don't have any problem with the advance pointer.
You really need a bulletproof strategy to move the robot to home (grundstellung) with that method, or at least a check, if he is in home before starting a new task.
actually there is more to it. i did some tests maybe 2 years ago and CWRITE can start and run program without $EXT_START (checked on 8.3 and 8.5). drives are on and move enable is on, "RUN PROG()" does both select and start functions. also in this case $DRIVES_OFF did not work either. if i recall the only thing that did work as expected (and all the time) was move enable...
Something that can bypass $DRIVES_OFF? Yikes! Did the robot move, or were you only able to execute non-motion programs?
Starting without $EXT_START could be handy, but also high-risk.
I'm assuming that test was the SPS issuing the $CMD RUN command to L1? Because having the L1 program issue one select&run the SPS would not be remarkable, regardless of Drives status.
the first one when i saw the issue was a palletizer. and yes it moved very quickly, everyone who saw it was stunned. yes it is behind the fence and safety is on but... it was unexpected and very fast motion not too far from the fence. and of course that is where everyone was.
then i did some test in OL and saw the same thing. so when i got back to our shop i decided to test it on a another robots with different controllers. first one was Agilus and second one was Quantec with big servogun (i think KR210). checked both KSS8.3 and 8.5. Sure enough they too, took of like a bullet...
the issue is that command like
CWRITE($CMD,STAT, MODE, "RUN PROG()")
does not just select program, it actually runs it too if conditions are right (intermediate circuit energized and no faults). and if the conditions are not right (move enable off for more than 1sec or so), then yes, it would only Select program. Since safety still need to be correct, this was not too bad,.. unless someone used home version of a jumper plug. The orange X11 jumper plugs from KUKA have button that need to be pressed and held to test AUT mode. DIY jumper plugs have operator safety bridged as well... it is not rare that some cell ends up operating like that... so be very careful
until then i would routinely set move enable and $DRIVES_OFF to true when in EXT mode, etc and wait for external start... but not any more.
Like panic mode and SkyeFire said be very careful about reset. I always in the begining of the program check if the robot is in home position and if it's posible to return to home (if the application allows that).
Example In the program BinPicking_TPV() i can return to home if i'm in the workspace of the bins. I easily go -200 Z in tool direction and return to home position the same path.
We are using reset because of the PLC programming. Our firm has strict PLC program requirements. If the application stops at any reason we must to carryout reset of the whole application (included robots).
Display Morerobot:KR10 R900 Sixx
contorller:KRC4
If the operator push emergency stop button while robot is working, after reset the button ,in standard,we need to make robot back to home position safe and then wait next start cycle,
but how we can make robot jump out the program he is running and enter the cell program to wait PGNO ?
Try this.
IF $MODE_OP==#EX THEN
CWRITE($CMD,STAT,MODE,"RUN /R1/prg_MAIN()")
ENDIF
IF $IN[n]==FALSE THEN ;SAFETY GATE
CWRITE($CMD,STAT,MODE,"STOP")
ENDIF
IF $IN[n]==TRUE THEN ;PROGRAM RESET
CWRITE($CMD,STAT,MODE,"RESET")
ENDIF
just always have fail safe on all your programs.
hope this helps you
The reset works beautifully! I meant to thank you earlier, but my son was born shortly after implementing these changes, and things got a bit hectic.
I see what you're saying about the robot automatically starting without waiting for operator input. I have some ideas I can try to make sure the robot doesn't take off without operator input.
As far as the reset goes, I'm fortunate to have a relatively simple layout with very few obstructions. I wrote a really neat reset program using FK to determine the safest path home. It may not be the prettiest piece of code (I think there are some existing functions I could have used but didn't know about), but it's stood up to all our testing.
Again, thank you very much for your help! I learned a lot about how SPS works.
Hello
Can you please teach me step by step how to reset the robot program with plc?
Hello
Can you please teach me step by step how to reset the robot program with plc?
Just read this thread.
