1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. KUKA Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

How to limt the speed of KUKA robot

  • Abel Wong
  • January 28, 2021 at 9:25 AM
  • Thread is Unresolved
  • Abel Wong
    Trophies
    2
    Posts
    12
    • January 28, 2021 at 9:25 AM
    • #1

    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.

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,371
    • January 28, 2021 at 3:35 PM
    • #2

    Does this limitation need to be safety-rated?

  • Abel Wong
    Trophies
    2
    Posts
    12
    • January 29, 2021 at 6:12 AM
    • #3
    Quote from SkyeFire

    Does this limitation need to be safety-rated?

    This limit is a global limit, as long as the robot is in #EX mode, the speed value is limited to 200m/, and there is no safety-related.

  • hkaraarslan
    Trophies
    3
    Posts
    2
    • January 29, 2021 at 7:09 AM
    • #4

    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.

  • micahstuh
    Reactions Received
    7
    Trophies
    3
    Posts
    31
    • January 29, 2021 at 2:01 PM
    • #5

    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.

  • panic mode
    Reactions Received
    1,262
    Trophies
    11
    Posts
    13,027
    • January 29, 2021 at 2:39 PM
    • #6

    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

    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

  • hkaraarslan
    Trophies
    3
    Posts
    2
    • January 29, 2021 at 3:14 PM
    • #7
    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?

    Code
    $SR_OV_RED = 20   
    
    IF $MODE_OP==#EX THEN 
       $SR_VEL_RED = TRUE
    ENDIF                  
  • panic mode
    Reactions Received
    1,262
    Trophies
    11
    Posts
    13,027
    • January 29, 2021 at 3:24 PM
    • #8

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

    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

  • Koppel
    Reactions Received
    19
    Trophies
    3
    Posts
    132
    • October 22, 2021 at 4:05 PM
    • #9
    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?

  • Fubini
    Reactions Received
    270
    Trophies
    9
    Posts
    1,866
    • October 22, 2021 at 4:22 PM
    • #10

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

    Yes you can record actual velocities using the oscilloscope feature.

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,371
    • October 22, 2021 at 4:46 PM
    • #11
    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.

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Tags

  • KUKA
  • configation
  • KR C4
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download