How to limt the speed of KUKA robot

  • Hi!

    How should I operate or configure to limit the speed of KUKA robot in #EX or #AUT mode to 200 mm/s, just like the maximum running speed of the robot in T1 mode is 250 mm/s.

  • 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


    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 $OV_PRO>20 THEN

    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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • hi panic mode

    Can I do this proccess with this code?

    $SR_OV_RED = 20   
       $SR_VEL_RED = TRUE
  • 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


    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







    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?

  • 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now