Override Speeds

$OV_PRO is the variable you need to modify

Sent with my Windows Phone using Tapatalk

in the USER PLC section of the SPS.SUB add code

$OV_PRO=75

if you need to limit speed but allow running slower:

if $OV_PRO>75 THEN
   $OV_PRO=75
ENDIF

if needed you can add exception for T1 mode

if (($MODE_OP<>#T1) and ($OV_PRO>75)) THEN
   $OV_PRO=75
ENDIF

Quote from panic mode

in the USER PLC section of the SPS.SUB add code

Code

$OV_PRO=75

if you need to limit speed but allow running slower:

Code

if $OV_PRO>75 THEN
   $OV_PRO=75
ENDIF

if needed you can add exception for T1 mode

Code

if (($MODE_OP<>#T1) and ($OV_PRO>75)) THEN
   $OV_PRO=75
ENDIF

Display More

Hi, I have tried ti use the if statement inside the sps.sub like sugested in:

if (($MODE_OP<>#T1) and ($OV_PRO>75)) THEN
   $OV_PRO=75
ENDIF

But it seems that the sps ignores the if statements.

of course, because it depends where in SPS.SUB you add it...

if you put it before LOOP or after ENDLOOP, it will not have effect.

as already stated this should be added in correct place like USER fold... (which is inside LOOP-ENDLOOP)

You're right, my bad.

I did a test and it worked just fine.

Very nice safety approach from panic mode .

I was in a situation, where a PLC guy wanted to test his PLC program with the robot program in EXT mode, without my presence that given day. So I instructed him carefully what he should do and should not do. I however, couldn't get out of my head all the different "what if" scenarios when dealing with EXT mode. I was after that meeting all the time thinking about:"Well, what if he did not understood this correctly. What if he manually used the keypads to increase the speed to 100 procent? What if, what if, what if....

So after the kids was put to bed, I drove out to work again, implemented the advice from panic mode and it work so nicely with the code below in the SPS.src.

I just made the speed to 10% instead of 50%

IF (($MODE_OP<>#T1) and ($OV_PRO>75)) THEN
   $OV_PRO=75
ENDIF

Now I can sleep much better until I get back to work again. Perhaps he will complain the robot was too slow in automatic mode, but hey... Safety first!

Hi,

I use this method, override correction is fast as KUKA KRL is capable to run

This program keeps the $OV_PRO on 30% in T2, AUT and EXT mode.

&ACCESS RVO3
&PARAM EDITMASK = *
DEF Override_test()
   INT iOverrideLast  ; previous override
   
   iTargetOverrideInNotT1 = 30    ; target override, a GLOBAL variable
   
   iOverrideLast = $OV_PRO
   
   IF (NOT $T1) THEN
      $OV_PRO=iOffsetOverrideInNotT1
      INTERRUPT OFF 9
      WAIT SEC 0 ; must wait 1 cyle
      INTERRUPT DECL 9 WHEN $OV_PRO <> iTargetOverrideInNotT1 DO Override()
      INTERRUPT ON 9
      WAIT SEC 0 ; must wait 1 cyle
   ENDIF
   
   ; override will be the target you want
   LIN ...
   PTP ...
   
   ; continue program withe the original override
   INTERRUPT OFF 9
   WAIT SEC 0
   $OV_PRO = iOverrideLast    ; 
   
END

DEF Override() ; Override
   $OV_PRO=iTargetOverrideInNotT1
END

sigh... sure but... just another way of doing something stupid. yes i said it...

as stated before, $OV_PRO is a manual control, meant to allow person that works on the robot to test things safely. do NOT take that away... ever!

anyone overwriting speeds continuously should be beaten senseless.

setting that value by program can be justified in some cases. an example is to set the value only initially (for example when mode is changed) or to apply limit. but... ultimately, user should have no problem changing the value (at least reducing the value).

hence code should never continuously overwrite user speed controls... that is abuse and red flag about programmers competence. i do not care about you doing crazy things to yourself and in your own garage. but this is an industrial robot and crap like this can lead to dangerous situations since it prevents others from doing their job safely.

the only good thing about above approach is that is done in KRL which means one knowing what to look for can find it and disable it or adapt it. but world is full of unqualified people doing things they should not...

not long ago i was making changes to a palletizer using KR470 with a massive tooling. the thing was heavily customized and i could not find what was controlling the speeds and where. there was no mention of $OV_PRO and $OV_JOG anywhere in the archive, they must have used something that modifies speeds etc directly through Cross (like KVP etc does). and what a colossal clusterf@#&k job that was... nothing like trying to jog robot in T1 when it is close to some fixture and robot suddenly takes of at crazy speed (excess of 1 m/s). and that alone is illegal in every civilized country - speed in T1 shall not exceed 250mm/s.

This is a very old thread. In the meantime there exist the variable $ov_appl to reduce override with leaving the possibility for the user to reduce the speed by override from hmi. Any way you have the risk that if $Ov_appl is very low, user sets override to 100%, then $ov_appl is changed to 100% on the program, and huiii