Posts by Koppel

First time I hear about this KUKA.AppTech and Home2Home features. I must take a deeper look into that.
Recovering and going back to home position was always a challenge and required manually doing so because you cannot risk it. No way that you have thought about all possible scenarios to program a collision free path back to HOME.

Robot programming in record time with KUKA.AppTech

How to KUKA.AppTech: Home2Home

For small Agilus robots I have never had success with custom inertia values. Everything was always smoother when the default "0" value was used.

Kuka interface wants the values to be "kilogram meter squared"

You can use Festo "Mass moment inertia" engineering tool to see if you are in the right ball park. Very easy to use tool and it convert the units when you click on the unit name.... Its under the "Calculation" sub menu.

https://www.festo.com/za/en/e/engineering-tools-id_650881/

For example an Aluminum disk with a diameter of 200mm and thickness of 20mm weighs roughly 1,7kg.
Its mass moment of inertia is 84,823 kgcm^2 or 0.008 kgm^2

If I remember correctly the Kuka user inerface allows only three digits... so the 0.008 becomes 0.01.

I don't know if this was my problem but everything always worked better when kept at the default value.
I guessed it was more important when using larger robots with larger payloads.

If you have a long tool, the TCP of the tool does not change but you can still rotate the long tool in a way that hits the robot arm.

KUKA.SafeOperations package allows you to defeine the Safe tool with up to 12 spheres that represents the tool.
And this can then be used to evaluate if the tool will hit some static workspace.
But there is no method to see if the tool can hit the robot arm.

There is a webinar by Kuka about this subject:

How do you get 4A?
If the load is 1,3kVA and you provide 208V ... then the amperage would be 1300/208 = 6,25A

If the manual requires you to use a 16A fuse... why not do that?

I am just curious... The 3-point method micahstuh gave as a solution. Does this assume that the 3 points/frames all intersect in the one correct point?

Because in reality if teaching the points they would never be exact, the vectors would never intersect in the one and only correct point and the equation would not solve.

3 points on a plane always defines a circle... 4 points in 3D space defines a sphere. You can be very inaccurate but still get a result.

But trying to find an intersection point could lead to an unsolvable situation.

How many GPS sattellites you require as a minimum to get a location... its 4 right!

If you buy the Siemens S7 1200 F series PLC... meaning a safety PLC you are able to use ProfiSafe to talk to the robot over just the profinet cable.

You can still use the E-stop button on the robot teach pendent.
You can also wire a new E-stop button to the S7 PLC and use these inputs in the PLC to program your safety program - this however is not 100% correct because the input card is not safety rated and the inputs are only read once every PLC cycle and don't have redundancy. If the PLC cycle is 150ms ... your E-STOP signal will also be read in the worst case that much later... like 150ms later.

If you have a small program the cycle time is probably close to 3...4ms.

You can buy a safety rated input moudule to the PLC to increase the number of I/O-s. These I/O-s are evaluated independently of the main PLC program cycle.

Yes. That is called EXTERNAL MODE... where the PLC is signaling the start of the program and picking the right program to run.

In your robot there is a default program called CELL.SRC
This will loop and wait for a program number to be picked by the PLC and waits for a start to run this specific case statement... CASE 1... = program nr 1 ... CASE 2 = Program nr 2... etc.

Setting this up with a Siemens PLC over Profinet has been discussed here quite a lot.
First you must know if your robot has the safety signals over ProfiSafe or over the X11 safety interface.

If you have ProfiSafe you would also need a safety PLC... in Siemens world this would be the F-marked PLC... like S7-1513F

• Get the GSDML files (Kuka Profinet Device description files) from the KUKA WorkVisual software installation location.
• Add these files to the Hardware library in TIA portal.
• Add your KUKA controller to your TIA project.
• Add correct IP address and profinet name to your KUKA controller.
• Map the KUKA internal inputs and outputs to profinet addresses in WorkVisual. There are a lot of important ones. MOVE_ENABLE, DRIVES_OFF (inverted), PGNO_REQ, PGNO, PGNO_REFL, PGNO_VALID, EXT_START, CONF_MESS, PRO_ACT, APPL_RUN ... etc.
• Create Tags for the KUKA signals in TIA portal. If your KUKA aadresses start from byte 50, then OUT[1] from KUKA is going to be INPUT[1] for the PLC... and since they start from Byte 50... its going to be I50.0 ... the next one I50.1 ...
• Program the logic for the robot inputs and outputs.

Then in the PLC logic / sequence you can decide when to start running what program number.

I think starting the robot without a confirmation key "START CYCLE" is not safe.
Very good chance of involuntarily starting the robot and killing someone.

You must read a lot more about the subject from the "Operating and Programming Instructions for System Integrators"

If you want to vist the same exact position again, then this is the way to do it.
Your explanation is a bit hard to understand to me:
If TOOL #1 allready took the part form P1 ... then there is no more part in P1 for TOOL #2 to take.

I also think that you have to move a bit away from the picking location, change the tool and then come back down again with TOOL #2.
You will crash if you start to do the tool rotating while still exactly in place for picking.

P1 TOOL #1
P1 RELATIVE Z 200mm with TOOL #1
P1 RELATIVE Z 200mm with TOOL #2
P1 TOOL #2

If tools (grippers) are different then you just change the tool in code and go to the exact same position... just with another tool.

Each tool is defined and has its own TCP (Tool Center Point) this is where the robot controller guides the robot.

If the other tool needs to rotate 180° then just define Tool #2 XYZABC accordingly.

Do I understand correctly that you want to pick and place two parts at a time?

P1 with TOOL #1
P2 with TOOL #2
P3 with TOOL #1
P4 with TOOL #2

... etc ...

But if you use an external camera that is connected to the PLC, you do not have other options for transmitting the target locations to the KUKA controller. You have to send the X Y Z and Rotation angle using the 32 bit signals. Right?

Thats not how to connect them.
You should have "Device description files" / GSD files for the KUKA profinet and you load them in TIA portal.

So in TIA, in the tree under "devices and networks" you are able to see your robot controller. You assign a IP address and a profinet name for this controller in TIA portal.

Then you map your PGNO and EXT_START and PGNO_VALID and DRIVES_ON and all others to some Profinet addresses in Kuka WorkVisual software.

Once this WorkVisual project is deployed to the KUKA controller you are able to see the tag values in TIA protal and write the outputs.

In the robot controller you can have EXT_START declared as INPUT[1000] ... you map this to profinet_input nr 1. In TIA portal you set up the KUKA controller to start taking addresses starting from byte 100 and then the first bit of this byte you know is your EXT_START with the address Q100.0
Its going to be an output on the PLC side of things.

So in summary. Get the GSD files for Profinet and add them to TIA portal (You can get them from inside the controller if you minimize to the windows environment or from inside the WorkVisual program folder). Add the new device KUKA controller. Map all the inputs and outputs you need. Check the Integrator manual signal diagram to figure out what bits you need and when to switch them.

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?