CIRC motion is not getting faster than T1 speeds

    Hi,


    What is the limiting factor if I cannot get the CIRC motion (probably LIN aswell) to be faster than seemingly T1 speeds.


    At the beginning of my program I have.

    BAS (#INITMOV, 0)

    SPTP xHOME

    BAS (#VEL_PTP, 20)

    BAS (#ACC_PTP,10)

    BAS (#VEL_CP,1)

    VAS (#ACC_CP,1)


    Playing with the VEL_CP and ACC_CP values makes a difference but it seems to hit a limit... It will not go faster... I can set VEL_CP to be 10m/s (36 kmh) and ACC_CP to 2 m/s^2...
    The thing should go like a rocket... but its still super slow.
    All the PTP motions react to VEL_PTP and ACC_PTP changes as expected.


    What are the hidden limiting factors here?

    I do not have SafeOperation.


    The same limitation applied for SPLINES... (SLIN) faster than 1m/s seems impossible... I can increase the value but the speed does not increase.

    I use an Agilus 2 KR10 R1100 robot with a KRC4 compact controller.


    Is there perhaps a limit for the ability of the Controller / Encoders... that cannot assure a perfectly linear or circular motion if the speed is increased.
    The robot has to move all of its 6-axes in degrees... and the sum of them all must assure the linearity of the tool center point. Not a simple task at all.

    replace

    VAS (#ACC_CP,1)


    with

    BAS (#ACC_CP,100)


    it is not VAS, it is BAS, and unit here is % and not m/sec2 so value you specified is only 1%, not 1m/sec2.


    if you are going to use BAS() make sure to read it. or at least test it. every single instruction or line of code you plan on using always need to be tested independently to become familiar and you find about any side effects or unexpected behavior early... only then you should consider using it... (when programming, don't assume anything). this also means trying wide range of values for parameters ( including invalid values... like: -7492.8). if you don't test it sufficiently, you will find out eventually but... by then it may be too late or very expensive.

    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

    Quote from Koppel

    ... The robot has to move all of its 6-axes in degrees... and the sum of them all must assure the linearity of the tool center point. Not a simple task at all.

    This is the normal "work" a robot has to do. That is a essential ability of robots, nothing special.

    Of course there are physical limitations like maximal acceleration and speed but the robot should be able to make circles and linear motions faster than in T1.

    Now you say that you don't get the robot faster than 1m/s, That speed will not be possible in T1, Think this movement is slower in T1 than in AUT?

    You have to note the accelerations that are needed to reach the 1 m/s. The robot is a small one, so he has not much time to accelerate, until he has to decelerate for reaching the endpoint. For me the 1 m/s seems to be ok: in the datasheet there are given 140 cycles/minute for a movement 25mm up 305mm horizontal and 25mm down. This results in a speed of 0.8 m/s.


    There are some special limitations if the robot has to move through his singularity f.e.: when axis 4 and 6 are near a straight line. This limits the velocity very strong.

    I don't think you guys are getting what I try to communicate.
    I will make a better attempt.


    BAS (#VEL_CP,0.1)

    BAS (#ACC_CP,1)

    RESULT: Robot is moving slowly


    BAS (#VEL_CP,0.5)

    BAS (#ACC_CP,1)

    RESULT: Robot is moving faster than before


    BAS (#VEL_CP,1)

    BAS (#ACC_CP,1)

    RESULT: Robot is moving faster than before


    BAS (#VEL_CP,2)

    BAS (#ACC_CP,2)

    RESULT: Robot is not moving faster than before


    BAS (#VEL_CP,20)

    BAS (#ACC_CP,20)

    RESULT: Robot is not moving faster than before


    So changing the values work... but it seems to hit a limit. There seems to be a difference between BAS (#VEL_CP,1) and BAS (#VEL_CP,2) but I am not sure.

    There definitely is no difference between BAS (#VEL_CP,2) and BAS (#VEL_CP,20) even If I increase the acceleration aswell...


    The question is... What could possibly limit this that I am not aware of? It was not the acceleration. I started doubling both the speed and the acceleration with no apparent effects. I increased the length of the linear trajectory to give the robot more time to accelerate... still no difference.

    Def_vel_cp in $config.dat. Looking in Bas.src should reveal this. Def_acc_cp for acceleration, ...


    Also $acc_ma and $vel_ma are limitations in machine data. You should not change these without consulting KUKA.

    Hi...


    In the $CONFIG.DAT file:

    • DEF_VEL_CP=2.0 [m/sec]
    • DEF_ACC_CP=2.3 [m/sec^2]

    These must be the default values from the factory.

    Can we conclude that this was my limiting factor and no matter what I set with BAS (#VEL_CP, ????? ) it will not go higher than the limit set in config.dat?


    Thank you Fubini !

    Probably. Open bas.src and look for yourself. It is only plain KRL in there so it should be readable for you. If you set bas.src visible and use incremental step you can step through it and look up what's happening.


    Might also be you reach maximal orientation velocities or accelerations. It is totally analog to my previous comment.


    What happens when you directly set $vel.cp and $acc.cp? That is not using bas.src.

    Both values are lower than the limits DEF_VEL_CP and DEF_ACC_CP, so this is not a problem.

    Quote from Koppel

    I increased the length of the linear trajectory to give the robot more time to accelerate.

    How long is your trajectory? Increasing says nothing in this context.

    Quote from Koppel

    I don't think you guys are getting what I try to communicate.

    that is correct, you still did not explain how you are testing it:

    1. what is the operating mode?

    2. what is the override setting?

    3. what are the points?

    4. are you having problem with your code only or the issue is present even if you create new program and use standard inline form motions?

    etc.


    this is why you were asked to check READ FIRST and share the details that are relevant.


    Code
    I will make a better attempt.

BAS (#VEL_CP,0.1) ; 0.1% of 2m/s^2 is only 0.002 m/s^2, but you want 1000x more (2m/s^2)
BAS (#ACC_CP,1)
RESULT: Robot is moving slowly

;....

BAS (#VEL_CP,20)
BAS (#ACC_CP,20)

    that is not better at all...


    you still did not do one thing i told you to try - set CP acceleration at 100%.


    and you are not changing ONE thing, you keep making changes to multiple settings (both speed and acceleration) and try to corelate results from only 4 tests? should we guess how is that working out? that can work if you have lots of measurements and if you know how to process results.


    if you want to test something, try changing one thing and change it in different increments (big and small).


    but you did try changing CP velocity to 20... this parameter is not in percent, it is in m/s so values exceeding max will trimmed it down to 2-2.3m/s.


    in fact KUKA made it confusing here:


    BAS(#VEL_PTP, 100) ; unit is % - just like $VEL_AX[]

    BAS(#ACC_PTP, 100) ; unit is % - just like $ACC_AX[]

    BAS(#VEL_CP, 2.0) ; unit is m/s - just like $VEL.CP

    BAS(#ACC_CP, 100) ; unit is % - unlike $ACC.CP which is in m/s2


    do you now see the point about making changes to one thing only when trying to see how it behaves through experiments?


    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

    Thumbs Up 1

    Most of my confusion came from mixing up the units.... % and m/s2 like panic mode pointed out.

    Quote from panic mode

    BAS(#ACC_CP, 100) ; unit is % - unlike $ACC.CP which is in m/s2

    I was absolutely sure that I was dealing with m/s2 ... and bumping up the numbers was such a small change that I perceived nothing.

    I tried CIRC, SLIN, LIN ... everything seemed to not get faster than some limit.


    Ok. I made a little speed test with timers. Code below.

    Basically a linear race for 1600mm... Y -800 to Y 800... back-and-forth with three speeds.


    1m/s = 2148 ms

    2m/s = 1788 ms

    3m/s = 1788 ms


    We can clearly see that the speed limit in CONFIG.DAT (2 m/s) is kicking in - a limit that I was not aware of before and am happy to have learned about.


    And even with 50% acceleration the results are almost the same:

    1m/s = 2580 ms

    2m/s = 2472 ms

    3m/s = 2472 ms


    And that was at a 1600mm track. Easy to make the conclusion that changing the speed numbers made no difference. And also changing the acceleration at very low values made no noticeable difference.


    Once again... Thank you "panic mode" for pointing out my noob mistake.



    Edited 2 times, last by Koppel ().

Advertising from our partners