What is wrong with the PTP speed in T1 on the KSS8.7

Hi,

The PTP speed in T1 mode on the KSS 8.7 is unbearably slow.

How slow? Well let me tell you with the speed test example I run on two systems.

From Y -300 to Y 400 so a 700 mm running distance and measured the time in T1 mode while at 100% speed on the Teach Pendent.

System 1:
KSS 8.6.4

KR C4 Compact

KR10 R1100 Agilus 2 robot (A six axis one)

System 2:

KSS 8.7.4

KR C5 Micro

KR6 R700 Z200 (A four axis scara robot)

&ACCESS RVO1
&COMMENT 
DEF T1_SpeedTest ( )
BAS(#INITMOV,0)

PTP XHOME

;TEST PTP SPEED
;=========================
SPTP {X 500, Y -300, Z 180}
WAIT SEC 0
;Start Timer
$TIMER_STOP[ 1 ] = TRUE
$TIMER[ 1 ] = 0
$TIMER_STOP[ 1 ] = FALSE

PTP {X 500, Y 400, Z 180}
;Stop Timer
WAIT SEC 0 ;For advance run to not stop the timer prematurely.
$TIMER_STOP[ 1 ] = TRUE

;TEST SPTP SPEED
;=========================
SPTP {X 500, Y -300, Z 180}
WAIT SEC 0
;Start Timer
$TIMER_STOP[ 2 ] = TRUE
$TIMER[ 2 ] = 0
$TIMER_STOP[ 2 ] = FALSE

SPTP {X 500, Y 400, Z 180}

;Stop Timer
WAIT SEC 0 ;For advance run to not stop the timer prematurely.
$TIMER_STOP[ 2 ] = TRUE

;TEST LIN SPEED
;=========================
SPTP {X 500, Y -300, Z 180}
WAIT SEC 0
;Start Timer
$TIMER_STOP[ 3 ] = TRUE
$TIMER[ 3 ] = 0
$TIMER_STOP[ 3 ] = FALSE

LIN {X 500, Y 400, Z 180}

;Stop Timer
WAIT SEC 0 ;For advance run to not stop the timer prematurely.
$TIMER_STOP[ 3 ] = TRUE


END

The results.

System 1 (KSS 8.6.4)
PTP time: 9,684 sec

SPTP time: 3,852 sec

LIN time: 5760 sec (Path was close to singularities so slower then necessary)

System 2 (KSS 8.7.4)

PTP time: 47,508 sec

SPTP time: 3,744 sec

LIN time: 5,964 sec

This is nor normal and causes the programmer to test the programs in other modes which is not a safe way to avoid collisions.

Its over ten times slower than SPTP. Why?
Considering this was a 700mm Point to point distance... the speed was 14,7 mm/sec ...

The speed in T1 should be limited to 250mm/s

What is going on?

I do not understand how a link to this thread gives an answer on how to solve this problem.

This thread has another link to German version of Robot Forum.

Fubini wrote there:

Quote

The quick translation is as follows:

This is due to reductions like $red_t1. This is added to the override in T1. If you have programmed slow speeds in a PTP movement, it will be even slower. By the way, this is no longer the case with Spline. There is always limited to 250 mm/s no matter if LIN or PTP, because there are no more factors like $red_t1.

Such general factors usually have historical reasons. In the past, PTP could not be limited to Cartesian 250 mm/s as a pure movement in the axis space. In the meantime this is possible via $speed_limit_teach_mode. But for compatibility you won't get rid of the old method as default. But you can change it somewhere ($custom.dat?). I don't remember the name of the variable, $Red_t1_ov or something like that.

I am not able to find any parameter called $red_t1

Can we solve this problem, as this can be safety hazard because nobody will test a program in T1 if it is not working correctly and happens on all new robots straight out of the box.
It's not like I did something to the robot to act like that... it's how they come out of the box.

There is a quote from Panic mode in this thread:
BAS function speed limit is cummulative in T1 mode and much slower than 250mm/s

Quote

PTP is the fastest motion... and this is why in T1 mode PTP is throttled more aggressively than other types of motion.

but in some cases there is a bug and safety controller reduces speed even further. in such case in T1 mode PTP becomes really really slow, specially when approximated with CP motions... by doing BCO you can skip that super slow part and get straight to CP motion such as LIN and robot will move normally. solution is to contact KUKA. they will tell you how to fix this (for example by changing limits in safety controller or whatever).

I think I am also hit with this bug.

PTP motions are limited by a reduction factor ($RED_T1*max. axis velocity).

If the maximum axis velocity configured for T1 in the safety controller is lower than the maximum possible axis velocity $RED_T1*max., the reduction factor is automatically reduced to prevent the velocity monitoring from being triggered.

In my STEU > MADA > MACHINE.DAT file there are.

$RED_VEL_AXC[1]=11

$RED_VEL_AXC[2]=8

$RED_VEL_AXC[3]=8

$RED_VEL_AXC[4]=10

These values are percentages of the maximum related to these. (values are in RPM)

$VEL_AXIS_MA[1]=5600.00

$VEL_AXIS_MA[2]=6000.00

$VEL_AXIS_MA[3]=5224.99707

$VEL_AXIS_MA[4]=4975.84521

So for example the limit for the first axis would be 11% x 5600rpm = 616 rpm.
I can divide this by 60 seconds = 616/60 = 10,26 rounds per second.

I can multiply this by 360° = 10,26*360 = 3696 °/sec

In my limits in the safety configuration are:

A1 = 30°/sec

A2 = 30°/sec

A3 = 250mm/sec

A4 = 30°/sec

Basically what I understand I need my $RED_VEL_AXC[1] * $VEL_AXIS_MA[1] to be under the 30°/sec value and if it is not then the system reduces the speeds to ridiculous levels.

The numbers are close to a 100 times out, so I don't know if there is a massive 100:1 planetary gearbox in there somewhere or what?

It's a Scara, thats why A3 is linear. And I did contact KUKA.

Their responses were a little too cryptic for me and I also wanted to give something back to the community by solving it "out in the open"

What I wrote above was pretty much the interaction I had with KUKA.

Quote

If the maximum axis velocity configured for T1 in the safety controller is lower than the maximum possible axis velocity $RED_T1*max., the reduction factor is automatically reduced to prevent the velocity monitoring from being triggered.

This explanation is hinting why sometimes the T1 speedlimits are very very slow.
I sent them my files and they pointed out the relevant parameters and gave links to explanations of these parameters. (some xpert.kuka.com page that expires in 14 days)

But when I manually calculated and compared the parameters (3696 °/sec vs 30°/sec) they seem way off.
I didn't want to adjust anything just yet, rather to understand beforehand what all of that means. Because currently the maximum velocity 30°/sec is way way lower than the $RED_VEL_AXC * $VEL_AXIS_MA.

KUKA help concluded that:

Quote

As mentioned, this is something that probably will be fixed in the next major KSS release.

At the moment it's recommended to use the SPTP motion. Thre is no "fix" for this at the moment.