Advertising

LOAD DETERMINATION AND KUKA.LOAD IN KUKA ROBOT

  • Hello People! How are you?


    I'm trying to identify a problem! I have a KR10 robot that works in a certain process, that process before the load determination had a cycle time of 6.6 seconds, after the determination 7.6 seconds. I inserted the load determination in Kuka.Load and the robot is not overloaded, but its static efficiency is not very good.


    I would like to know what this static efficiency influences the robot's movements to make them slower, so that it can find a solution that even with determination the robot works quickly.


    Attached is the print of Kuka.Load with the robot I mentioned above.

  • AD
  • when efficiency is less than 100%, you are not using axis to its potential. like using large truck to transport single tootpick.

    when efficiency is exceeding 100%, you are exceeding axis limits and there will be consequences such as robot is not approved or it is approved but amx speed has to be limited etc.

    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

  • when efficiency is less than 100%, you are not using axis to its potential. like using large truck to transport single tootpick.

    when efficiency is exceeding 100%, you are exceeding axis limits and there will be consequences such as robot is not approved or it is approved but amx speed has to be limited etc.

    I undestand, this is the robot's actual load determination, do you know why it works slower when I insert it into the tool? As I informed above, it increases the cycle time of the station by 1 second and it is visually noticeable that the robot works slower.

  • i am not sure i understand the question or more specifically if i can help.

    you started by evaluating static load but trying to apply observation to dynamic performance.

    i am pretty sure that if robot is static (no motion), there will be no cycle time difference regardless of load.


    there is no mention how the load settings compare (before and after), there is no program or video to look at, no mention if the load is really the only change, no traces etc. obviously moving CoG etc will affect system dynamics. how exactly is that taken into consideration by KSS i don't know. don't have access to KSS source code.

    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

  • i am not sure i understand the question or more specifically if i can help.

    you started by evaluating static load but trying to apply observation to dynamic performance.

    i am pretty sure that if robot is static (no motion), there will be no cycle time difference regardless of load.


    there is no mention how the load settings compare (before and after), there is no program or video to look at, no mention if the load is really the only change, no traces etc. obviously moving CoG etc will affect system dynamics. how exactly is that taken into consideration by KSS i don't know. don't have access to KSS source code.


    Sorry, I posted the other attachments for you to see if there was anything that could be impacting this loss of speed.


    I will answer your notes!

    The robot code has not changed, I just did the load determination, and when using it, the robot increased by 1 second in cycle time. I can't post the code because it's from a multinational company. But the program consists of 3 machines with the robot manipulating parts with a double tool. The machines are 1m away from each other.


    The robot's movements are similar to the one in the video below but is KUKA robot:


    There was no load determination before, it was like the attached images.

  • Counterspeller on Your second screenshoot, the values are of Mass, Inertia and CoG are zeroed.


    Anyway, If You select the nominal values for a KR 10 R1420 on KUKA.Load, You will have results that are worst than Your first screenshots.


    The robot was previously configured with -1 in mass field?

  • no... that would happen if mass was negative


    but he set everything to zero so robot was told to have the most favourable sitation when in fact it was moving load close to rated limits.

    load data changed drastically. so load change for this robot was: mass went up from 0 to 80% and Izz from 0 to 170% of default. and default load is normally at or slightly above rated.


    i glanced briefly over video and as far as i am concenred the motions are not approximated, i see robot stop after pretty much ever move.

    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

  • Thanks for the help Massula and Panic Mode!


    Okay guys, what mass of the tool would be good for the robot not to change the cycle time of the line so much?


    Currently it is like the first print, 8kg, lx, ly and lz are 3, 1 and 72, respectively. And the lx, ly and lz kgm² are at 0.11, 0.11 and 0.17, respectively. The cycle time is 7.6 seconds, but I want to reach 6.6 seconds again with the correct load data.

  • first you need to validate results though if the mass is about 8kg, then it is well above needed minimum for LDD to determine all load data accurately.

    so the values obtained should be good and not changed. btw tool mass is ok but inertia is definitely on the high side, particularly about Z. that indicated that tool is large (very wide, like 40cm across). what is the shape and size of the tool, is it attached firmly? if unsure, take the tool off, weigh it, put it back on, enter mass as measured, then repeat LDD. or determine load data using using alternative method and compare (use CAD or manual calculation).


    next you need to check your code. any slow segment need to be adapted. avoid advance run stops even for handshake and interlocks, use approximation and increase approximation distance, minimize use of CP motions, PTP is faster, crank up acceleration, don't mix motions instructions that use different motion planner, remove unwanted motions etc.

    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

  • first you need to validate results though if the mass is about 8kg, then it is well above needed minimum for LDD to determine all load data accurately.

    so the values obtained should be good and not changed. btw tool mass is ok but inertia is definitely on the high side, particularly about Z. that indicated that tool is large (very wide, like 40cm across). what is the shape and size of the tool, is it attached firmly? if unsure, take the tool off, weigh it, put it back on, enter mass as measured, then repeat LDD. or determine load data using using alternative method and compare (use CAD or manual calculation).


    next you need to check your code. any slow segment need to be adapted. avoid advance run stops even for handshake and interlocks, use approximation and increase approximation distance, minimize use of CP motions, PTP is faster, crank up acceleration, don't mix motions instructions that use different motion planner, remove unwanted motions etc.

    Hello Panic Mode!


    I sent the code in private to you. I am attaching the drawing of the tool for you to see

  • all code comments are in Protugese which i don't speak but i can still see that there are several issues. the most important ones are:


    1. all loads are set incorrectly. they need to include all data, not just mass... inertia, CoG and inertial axes are all very important.


    2. supplementary load for A3 is placed at the flange. so even though tool is set to 0kg, supplementary is 8kg - at the flange. when you run LDD and get another 8kg for the tool, you are actually adding another 8kg to the flange. no wonder robot slows down. it is surprising it works at all since it thinks it is overloaded both statically and dynamically.


    3. advance run stop is triggered way too often. this kills the cycle time. with better management you could halve the cycle time.


    4. validating load based on supplied drawing is impossible. there is no dimensional data or material properties listed or even which side connects to flange. it does confirm that tool is very wide and explains large inertia about flange Z axis.


    i strongly suggest getting familiar with loads and advance run pointer. this is covered in basic training (Programming1), programming manual for system integrators and was discussed in forum numerous times. good luck.

    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


  • Thanks for the load determination study you gave me.


    Regarding point 3, which $ advance would be good for the program? In which the robot did not check any wrong sign of the machine.


    Regarding the supplementary load, I didn't check it, I was going to use the Kuka.load standard, but only without mass, as there are only 2 cables passing over the A3 axis.


    Again, thank you very much!


    You are a master at KUKA robots.

  • >>"Regarding point 3, which $ advance would be good for the program? "

    all right, this clearly tells me that you really don't understand it.


    it is not about changing $ADVANCE value... it is about the programming and code structure (actual instructions and their order...).


    value for $ADVANCE usually does not matter much - it tells how many points should be gathered before robot gets to use them. as long value is greater than 0 you still can get appriximated motions. this means $ADVANCE=1 works fine when points are not dense - which is pretty much case for all programs where points are taught manually (since points are tens or hundreds of mm appart). larger values for $ADVANCE only make sense if path has many close points like data clouds generated by CAD to path programs.



    every time advance run stop is triggered, motions cannot be approximated... and your program runs slower and robot axes stop abruptly... and at the exact same position (millions of times) which is not good for belts and gears. it is better if robot does not stop but smoothly glides from one path segment to another. not only this is less tear and wear but it improves cycle time.


    this means you need to know:

    1. what advance run is and how it works

    2. what causes advance run stop

    3. what problems and risks are related to advance run


    then you can write programs that are both robust and efficient - at least in terms of cycle time (does not mean that code will be shorter and - usually it isn't).



    >>"Regarding the supplementary load, I didn't check it"

    common mistake


    >>"I was going to use the Kuka.load standard, but only without mass, as there are only 2 cables passing over the A3 axis."

    so how did 8kg got in there? also you cannot do "standard, but only without mass". either you use default settings for all load values or you enter all of them yourself. cannot have it partial. all values must be entered.



    LDD works only for loads attached to flange. so magical "press one button and forget it" does not exist. no such thing as free lunch.

    all other loads (supplementaty loads) cannot be determined by LDD and therefore need to be set manually. but one need to know what he is doing... just punching in some random values or settings values to zeroes is a bad idea. in your case robot was stressed beyond design limits. the only reason it caught some attention is because it did not meet the expected cycle time. this is an example of scenario where robot is tortured senslessly, causing dramatically increased wear and tear, premature component failure (motors, belts, cables, drives...).


    systems installed with competence do not stress or torture parts of system or pose risks to users. they work for very long time with minimal maintenance and energy consumption. i see badly designed or configured systems all the time because many people obvisouly don't understand what they are doing (or not doing). i cannot stress enough need for proper training. even those who had basic training and have certificate to prove it - get of your high horse and read the manuals. training is vital but - it only covers some of the topics. even topics that are covered, may not be covered in depth or training would take months instead of days.

    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

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