How to limt the speed of KUKA robot

Does this limitation need to be safety-rated?

you can use this code $OV_PRO = X

X = percentage value of nominal speed

if you write it in sps, you can not change the speed while the program is running.

As hkaraarslan mentioned, you can force $OV_PRO to a set speed, but one issue with this is now you can't manually override the speed if you want to watch the robot work slower. Also someone COULD shut off the submit interpreter, thus allowing the speed to be overridden to a higher, potentially unsafe and untested speed.

You can program the linear/circular speed limit using $VEL

$VEL is a structure with three components:

 CP: Path velocity in [m/s]
 ORI1: Swivel velocity in [°/s]
 ORI2: Rotational velocity in [°/s]

so in your SPS.SUB user loop, you can place this to prevent the speed from being above your desired 200mm/s in #EX mode:

IF (($MODE_OP == #EX) OR ($MODE == #AUT)) AND ($VEL.CP > 200) THEN

$VEL.CP = 200

ENDIF

Keep in mind only linear and circular moves are expressed in mm/second. It also can be defeated if the SPS.SUB is stopped.

PTP moves are expressed in degrees/second. PTP moves do not refer to the $VEL variable for speed. They refer to $VEL_AXIS which has a component for A1-A6 expressing the percent speed limit from 0 to 100.

correct, limiting $OV_PRO should prevent larger value than desired but not interfere when user selects lower value.

IF $MODE_OP==#EX THEN
    IF $OV_PRO>20 THEN
      $OV_PRO=20
    ENDIF
ENDIF 

as long as this is in SPS loop and SPS is running, this will easily override any user attempt to increase speed.

but manipulating $VEL, $VEL_AXIS[] etc from SPS is another story.

SPS cannot modify those since SPS is asynchronous to level-1 interpreter and therefore so such variables are write protected for Submit interpreter(s).

and even if this was used in robot program, this will only work for motions that do not use inline forms.

inline forms set the speed etc in every motion instruction.

since inline forms and plain KRL motions require different solution, the simplest workaround is to use $OV_PRO

Quote from panic mode

correct, limiting $OV_PRO should prevent larger value than desired but not interfere when user selects lower value.

Code

IF $MODE_OP==#EX THEN
    IF $OV_PRO>20 THEN
      $OV_PRO=20
    ENDIF
ENDIF 

as long as this is in SPS loop and SPS is running, this will easily override any user attempt to increase speed.

but manipulating $VEL, $VEL_AXIS[] etc from SPS is another story.

SPS cannot modify those since SPS is asynchronous to level-1 interpreter and therefore so such variables are write protected for Submit interpreter(s).

and even if this was used in robot program, this will only work for motions that do not use inline forms.

inline forms set the speed etc in every motion instruction.

since inline forms and plain KRL motions require different solution, the simplest workaround is to use $OV_PRO

Display More

hi panic mode

Can I do this proccess with this code?

$SR_OV_RED = 20   

IF $MODE_OP==#EX THEN 
   $SR_VEL_RED = TRUE
ENDIF                  

variables with names that start with $SR_ are safe robot variables. question was already asked if limit is safety-rated

Quote from micahstuh

PTP moves do not refer to the $VEL variable for speed. They refer to $VEL_AXIS which has a component for A1-A6 expressing the percent speed limit from 0 to 100.

But what is BAS(#VEL_PTP, 20) referring to? Its 20% of something.

I know

$VEL.AXIS

Velocity of the robot axes in the advance run

The variable contains the programmed axis velocity as a percentage of the

maximum axis velocity $VEL_AXIS_MA defined in the machine data (variable in the file …R1\Mada\$machine.dat

And in this File I have

$VEL_AXIS_MA[1]=6000.0

$VEL_AXIS_MA[2]=6000.0

$VEL_AXIS_MA[3]=7999.2

$VEL_AXIS_MA[4]=6000.0

$VEL_AXIS_MA[5]=5796.52148

$VEL_AXIS_MA[6]=7288.8335

What units are used in this file? 6000 degrees per second?

I knew about it like a year ago... and now I cannot find what is limiting my speeds. I remember there are some limits in the BAS function, and when exceeded a default value is used.
So this time I want to document all the different ways the speed of a robot can be limited.

Is there a good way to visualize the actual speed values during a running program. The oscilloscope feature maybe?

RE: External Axis (on Rotary Table) - Rotation Speed Control

Yes you can record actual velocities using the oscilloscope feature.

Quote from Koppel

But what is BAS(#VEL_PTP, 20) referring to? Its 20% of something.

20% of maximum. That's all.

$OV_PRO comes into play -- it applies a % multiplier to all programmed moves. But generally it should be 100% outside of debug testing.

Motions are limited by the slowest joint. If a PTP move commands A1 to move 10deg, but A6 to move 180, A1 will slow down so as to start/stop simultaneously with A6.

Speeds are also derated by payload, reach, and inertia. The robot's motion planner takes the carried payload into account, and "caps" each axis's maximum speed based on the stress that payload will put onto that axis. This is further complicated by the fact that the payload will stress axes differently, in different directions, at different poses.

Likewise, acceleration and distance come into play. If you command an axis to reverse direction suddenly, the motion planner takes its current velocity, and the associated inertias, into account. And commanding a 20mm move at 100% speed means that the robot will simply accelerate to the best speed it can achieve in a 10mm distance before it begins decelerating again.

And of course, accel/decel are also programmable, and also get derated in real time by payload, inertia, robot pose, etc.

Each axis has an absolute physical maximum speed, accel, and torque. All three of these are constantly in play, and whichever limit is approached first slows the axis down. Likewise, all the axes are evaluated in real time (and in advance, by the path planner and $ADVANCE), and the first axis to approach its limit slows down all the others to synchronize.