LOAD DETERMINATION AND KUKA.LOAD IN KUKA ROBOT

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

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.

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.

ok, just note that i am a busy guy

so far i received nothing

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.

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

I had asked a question in this thread:

Load Data Determination - "no identification of load data"

And as I am reading this one, I think that what I had asked about ABB armload is what Kuka calls supplemental loads?