Posts by Koppel

If IN[33] is what makes your program number 1 run in CELL.SRC, then keeping it HIGH even after the program finishes will produce the message "Wait for not Input 33"

Otherwise the program would just repeat itself over and over again.
If you want to tell the PLC that the program has started and there is no need to keep sending IN[33] to robot, you can check the signal $IN_HOME.
It is fair to assume that when robot is not $IN_HOME anymore the program has started. And when the robot is back $IN_HOME the program has finished.

You could also add some "handshake" at the end of your robot program to make sure that a specific program has finished and not just any random program. So you can create some signals / assign some inputs and outputs to set high when the program has finished.

PROG_1_DONE = TRUE

WAIT FOR PLC_Acknowledge

PROG_1_DONE = FALSE

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.

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.

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"

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?

What do you mean by "Safety controller" Is this some physical part of the Kuka cabinet? Can this be accesssed by WorkVisual or by TeachPendent or by modifying parameters in $MACHINE.DAT ?

How can I change the limits in the safety controller?

I am sure I have hit the "bug" you are referring to because Kuka help responded with:

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.

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.

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?

Thank you. This was not immediately clear.

If the CELL.SRC requires the robot to be HOME then I cannot use the CELL.SRC to run a program to safely take me to home.

If I just change the variable CHECK_HOME = FALSE ... no evaluation is done and the robot will accelerate directly to home with 100% velocity.

Is it advisable then to get rid of both the

;FOLD CHECK HOME

;FOLD PTP HOME

So that the CELL.SRC will start running the CASE loops.
Then I can use my PLC logic to check if the robot is not Home I can run the "BringMeHomeSafely()" program.

KSS 8.7 on a KRC5 micro.

The robot complains that this Syntax is a problem and does not even let me open the file. Not even outside the KRC:\R1 folder

When I try to copy the file to R1 folder, it says

"File format not correct (header syntax).... "
Originator: ReadHeader()

I delete the GLOBAL and everything is fine.

GLOBAL DEF OpenGrip ( )
PULSE (PleaseOpenGripper, TRUE, 3600)
WAIT FOR GripperOpen
PleaseOpenGripper = FALSE
END

So how do I create small programs that can be called from larger programs globally?

"1. map some IO between PLC and KRC"

DONE

"2. configure on robot side AutoExternal interface (this is covered in KUKA programming 1)"

DONE

"3. create PLC logic to handle AutoExternal interface"

I usually enable the REFLECT_PROG_NR and I compare what I want with the one that is reflected and if they match I send. PGNO_VALID... Is this what you mean?

"4. create KRL code that will check if correct program is selected. if not correct - deselect it. if no program is selected, select one you want. this uses CWRITE commands and example is already inside CELL.SRC but it is before the loop. i like to do this inside the loop so it ALWAYS works, not only on boot."

KRL code?

"5. select EXT mode (this is still manual but controller will remember it...)"

"6. there is no BCO mode in EXT mode (even if there is a message telling otherwise). this means when you tell robot to move in EXT it immediately moves at programmed speed. So if robot is not already at home you need to either abort and ask for human intervention OR you need to create own program that can safely bring robot to home position from anywhere. this can be tricky and it is meant for advanced programmers only. If you take KUKA training, this is covered in 3rd programming course."

I cannot find "Programming 3" And we have attended Programming 1 and 2.

Robot programmers | KUKA College

Any feedback on this PTP vs SPTP speed difference in T1 mode?

Quote

I think I managed to delete half of my post before posting.

A new Scara robot with KSS 8.7.4, straight out of the box.

A blank SRC file with just:

BAS(#INITMOV, 0)

SPTP XHOME

SPTP MYPOINT

SPTP XHOME

Is behaving like expected... ca 250 mm/s in T1 mode.

Whereas the same thing with PTP movements is like 10 times slower.

BAS(#INITMOV, 0)

PTP XHOME

PTP MYPOINT

PTP XHOME

No problems with speed in T2 on AUT modes.

Display More

Hi,

I have an enclosed production cell. A Siemens S7-1500 is the master controller with a Siemens HMI.

Operator safety signal is wired through the safety door relays - so no safety risk

KRC5 micro with a new KR Scara robot. KSS 8.7

I want to be able to just turn on the production cell without the operator needing to go and press "Acknowledge general motion enable" , picking the right program, doing the BCO run and setting the robot to EXT mode. So the operator only operates the Siemens HMI and not the robot Teach Pendent.

I know you can somehow automatically start a program with SPS.SUB

I can run an interrupt program that can go from $POS_INT to a directly high safe Z positon and to XHOME.

Can you guys point me to the right direction?

Quote from n0909

... and make sure the IO Device is activated if you're planning to use a Siemens PLC as PN Master and KRC5 as PN slave IO device.

Connect the PLC to the KRC5 on KLI2 and then assign a PN name from accessible devices from the TIA portal.

What do you mean "make sure the IO Device is activated" ?

What do you mean "Connect the PLC to the KRC5 on KLI2"? I have just "KLI" tab under Start-up > Network Configuration

I connected the PLC to the XF5 port on the robot controller, set a Fixed IP address to the controller. I can ping this address just fine with my laptop.

I added PROFINET to the Bus structure in WorkVisual and deployed the project back to the controller

I added the KRC5 GSDML file in TIA Portal.

I set the IP address in TIA Portal to match the one in the controller.

Still "Not reachable"

EDIT:
Ok... so under WorkVisual I had to right click on PROFINET under the Bus Structure, choose "Settings" and put a checkmark infront of "Activate PROFINET device stack" and have the Profinet device name also match with the one in TIA Portal.

XF5 port seems fine for the communication. The device is now green in TIA Portal.

First time using a KRC 5 micro aswell.

Imported the project from controller in WorkVisual.

There is no "PROFINET" under the Bus structure or under the "Fieldbusses" tab.

How do I do the IO mapping to profinet?

Profinet S v6.0.4 installed on the robot and the option package is also installed in WorkVisual v6.0.24 build 1632.

I think I managed to delete half of my post before posting.

A new Scara robot with KSS 8.7.4, straight out of the box.

A blank SRC file with just:

BAS(#INITMOV, 0)
SPTP XHOME

SPTP MYPOINT
SPTP XHOME

Is behaving like expected... ca 250 mm/s in T1 mode.

Whereas the same thing with PTP movements is like 10 times slower.

BAS(#INITMOV, 0)

PTP XHOME

PTP MYPOINT

PTP XHOME

No problems with speed in T2 on AUT modes.

So what is the solution then? I also got a new robot and the PTP speeds in T1 mode are unbearably slow.

SPTP movements have a reasonable speed.

I cannot find what Fubini said.

Quote

But you can change it somewhere ($custom.dat?). I don't remember the name of the variable, $Red_t1_ov or something like that.

Do I just change all the PTP movements to SPTP or is there a better solution?

Yeah...you guys got me.

At first I was... "order of points matter" ... how can that be, the software asks for the points in a specific order that I follow.

BUT... I wanted the origin to be at the top left corner hence the flipping of the Z.

As this cannot be I have to resort to the origin being at the bottom left corner.

Thank you guys!

Hi,

KSS 8.5

I am starting to work with different BASE systems and shifting frames for palletizing. So far I have managed to avoid using different BASES, I have just calculated new coordinates for the next part to pick and everything was in WORLD coordinates.

Now I have a project where using BASES makes sense.

However when I create a new base using "calibrate" with the 3-point method (touch up the origin, the X axis and the XY plane) the Z axis is pointed downwards.

This annoys me because the approach positions for picking are meant to be above the surface... so the Z value should be higher when I go up.

It is illogical to have the approach point at -100mm, this creates many opportunites for typos and crashes.

At first I thought this is dependent on the tool I use to teach this base. If the tool has its Z the other way around, than so might be with the base. But this was not true. I tried both ways and still the C angle was 180 degrees, therefor flipped.

I thought that if I dont mess with the angles myself and use a calibrated tool and a calibrated base using that tool, everything would be as standardized as possible.

Am I doing something wrong?