I have a KRC4 with ver 8.3
i seem to have an issue with $stop_mess. When $STOP_MESS changes state IR_STOPM is called and appl_run goes to false, when i reset appl_run should go true but it does not.
The robot will still run and the only way to get appl_run to turn on is to stop and start the robot again.
I added an output instruction into IR_STOPM, it turns on when it is called and turns off when finishes.
This output stays on when appl_run does not turn back on. It is like IR_STOPM is not completing correctly.
Am I missing something?
IR_STOPM
-
ChrisF -
April 26, 2017 at 10:13 PM -
Thread is marked as Resolved.
-
-
check manual again....
IR_STOPM is called when there is a stop mesage ($STOP_MESS turns TRUE).
to reset $STOP_MESS you need to remove all conditions that caused stop message and then you need to acknowledge messages.
if you are using EXT mode, acknowledgment is done on rising edge of $CONF_MESS ($STOP_MESS does not depend on state of APPL_RUN...) -
I understand that stop_mess is not dependant on appl_run. But the state of appl_run is dependant on stop_mess.
When stop_mess is true ir_stopm turns off appl_run, then waits for stop_mess to go false then on restart turns appl_run is set back to true.
however this does not happen everytime. stop_mess goes false and robot runs program but appl_run does not turn on
I can not see what is stopping appl_run from going true, if stop_mess goes falseCode
Display More&ACCESS R3 &REL 1 &COMMENT HandlerOnRobotFault DEF IR_STOPM ( ) ;----------------------------------- ; Error Handling Robot Controller ; Switch OFF and Switch ON processes ; KRC Version >= V5.5 ;----------------------------------- ;FOLD DECLARATIONS ;FOLD USER DECL ; Please insert user defined declarations ;ENDFOLD (USER DECL) ;FOLD BASISTECH DECL BOOL ApplicationRunFlag DECL CHAR ID[3] ;ENDFOLD (BASISTECH DECL) ;ENDFOLD (DECLARATIONS) ;FOLD BASISTECH INIT INTERRUPT OFF 3 STOPM_FLAG=TRUE ;Reflects state of interrupt 3 to activate/deactivate $Stopmess interrupt ID[]="CTL" If ($STOPMESS==TRUE) THEN BRAKE ;ENDFOLD (BASISTECH INIT) ;FOLD USER STOP ;Make your modifications here ;ENDFOLD (USER STOP) ;FOLD BASISTECH STOP P00 (#EXT_ERR,#PGNO_GET,ID[],128 ) ApplicationRunFlag=FALSE IF (Appl_Run>0) THEN IF $OUT[Appl_Run] THEN ApplicationRunFlag=TRUE $OUT[Appl_Run]=FALSE ENDIF ENDIF REPEAT POWER=SYNC() HALT UNTIL (($STOPMESS==FALSE) AND ($POWER_FAIL==FALSE)) ;ENDFOLD (BASISTECH STOP) ;FOLD BASISTECH RESTART P00 (#EXT_ERR,#PGNO_GET,ID[],0 ) IF (ApplicationRunFlag==TRUE) THEN IF (Appl_Run>0) THEN $OUT[Appl_Run]=TRUE ENDIF ENDIF ;ENDFOLD (BASISTECH RESTART) ;FOLD USER RESTART ;Make your modifications here ;ENDFOLD (USER RESTART) ;FOLD BASISTECH REACTIVATE Endif INTERRUPT ON 3 STOPM_FLAG=FALSE ;Reflects state of interrupt 3 to activate/deactivate $Stopmess interrupt ;ENDFOLD (BASISTECH REACTIVATE) END
-
[size=2]from what you mentioned so far i think it is safe to say that you are way of beaten path, navigating dangerous waters. just make sure to not modify IR_STOPM.SRC or P00.SRC. even in SPS.SUB an d$CONFIG.DAT there are specific folds for user to make their own changes. it is not a bad idea to avoid the rest...[/size]
[size=2]If you are trying to setup AutoExternal IO there are few things to be done:[/size]
[size=2]1. have some I/O (hardware or fieldbus) between KRC and PLC. Check this by turning on signals on one side (PLC for example) and verify that they are activated on other side (KRC). Then do it on other direction.[/size][size=2]2. configure AutoExternal signals[/size]
[size=2]3. if you want to use AutoExternal interface, modify CELL.SRC. But... Only add program names in places of examples. If you need to add more cases, that is ok but make sure to duplicate example case(s) exactly (including P00 line). Note, P00 handles all handshaking. it has several parameters but the only one you need to keep an eye on is the second parameter. it tells what action P00 is supposed to do (get program number, acknowledge program number etc.). I have seen people copy wrong line thinking that they are all the same... they are not.. if unsure if you changed something in CELL.SRC, just delete it and create new one then insert your program names.[/size]
-
Sorry maybe I am not explaining this correctly.
I do not wish to change anything.
I just want to understand why Appl_Run is not turning back on when the robot is running my program. -
APPL_RUN is set by P00, through use of line:
P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )
in your CELL.SRC
-
SWITCH FUNCT
;*******************
CASE #PGNO_ACKN
;*******************
IF (PGNO_REQ>0) THEN
$OUT[PGNO_REQ]=FALSE
ENDIF
IF (PGNO_REQ<0) THEN
$OUT[PGNO_REQ*(-1)]=TRUE
ENDIF
IF (APPL_RUN>0) THEN
$OUT[APPL_RUN]=TRUE
ENDIF -
As I understand when Cell.src runs it call p00 which turns off APPL_RUN
Then with PGNO_ACKN turns it back on.Then when running if $STOP_MESS is turns true IR_STOPM is called and APPL_RUN is turned off
When $STOP_MESS goes false IR_STOPM turns APPL_RUN on again.Is this correct?
-
why don't you follow outlined steps?
if you need more help, post more info about your setup.
-
OKAY
i am using AUT_EXT
and the default cell.src with only changes to call my programs
When i run cell and call my program APPL_RUN turns on just fine. As expected.
Program running and i turn off $MOVE_ENABLE which causes $STOP_MESS to turn on
This causes Interrupt 3 to call IR_STOPM which turns off APPL_RUN. As expected
To start the robot i turn on $DRIVES_ON wait for $PERI_RDY then turn off $DRIVES_ON
Then turn on $CONF_MESS and wait for $STOPMESS to go off then turn off $CONF_MESS
Then turn on $EXT_START which turns on APPL_RUN and $PRO_ACTThis works for about 70% of the time the other 30% APPL_RUN does not turn on
If this is normal than I will not work about itI don't know what outline steps you mean
-
if you did not modify CELL beyond inserting program calls, that part is probably fine.
note, robot can respond differently based on configuration of IO, for example:
what is the PGNO_TYPE?
what is the APPL_RUN setting?
what is the PGNO_VALID setting?
...some signals are edge triggered and this has to be taken into account.
some signals require specific timing and this too has to be taken into account (i recall recommendation for 20ms).simple workaround for edge triggered signals is to produce multiple edges (use pulsing signal).
-
These are the only setting for these I am aware of are there any more?
INT PGNO_TYPE=1 ;coding type of ext. pgno
INT PGNO_VALID=6 ;validate ext. pgno input
INT APPL_RUN=9 ;application program is running output -
[size=2]those are only few of many settings. time diagrams for handshake are in the system integrator manual. [/size]
[size=2]sequence is to powerup drives, clear messages, start main program (CELL), present PGNO, then issue PGNO_VALID.[/size]
[size=2]timing is important as some of signals are edge triggered. those must be low for a while, then high for a while where "while" is 20ms or more. if either state is too short, controller may not catch it and you will see what you describe (this is one scenario, there are others when people edit wrong things).[/size] -
Okay now its kind of making sense.
What we do is use cell to call what ever job that we need to run and then just loop in that required program until a job changeover is required. This means we may not return to cell.scr for days.
does PGNO_VALID need to be issues whenever we stop the robot and start it again, even if we don't go back to cell.
Also we noticed this only happen when we stop the robot enter the cell, and step through the program with the pendant.
We were thinking it had to do with moving the program pointer by using block selection. However it does the same thing if we just step through the program.We also noticed that it does not matter if we are in ext/aut, T1, or T2 we get the same issue.
If we hold the enable APPL_RUN turns on the press the Start button its still on, if we let go of the Start button it stays on, however if we let go of the enable while still holding the start button
if goes off and the only way to get it to turn on again is to release both and then confirm messages (even if there are none) and press enable the startSo if in T1 we can cause the same issue but not correctly releasing the button and have to follow a set way to reset it
with that line of thought it is possible that the way the robot is being started in ext/aut could be my issue not anything with the robot itself.There are 6 different timing charts in the manual . Two for automatic system start and then the rest for restart.
do i use that same start no matter what or use the automatic system start when we first load the job and need to call it from cell, then the restart sequence depending on how we stop the robotSorry for the long post
Also its 10 robots that do the same thing.