Sendin Home From Anywhere

Depending on your software architecture and needs for any additional operations (release gripper, stop conveyor, etc.) when/before homing and possible obstructions in the cell:

1. Write different homing procedures depending on where the TCP is and what operation it's doing.

2. Write one universal procedure if the required movement is simple enough, like:

1. Rise by 100

2. Set A2 and A3 to some position

3. Turn the rest of the axes to home position.

1. Yes, depending on the state of the cell, you would call different sub programs.

2. For testing purposes, sure you can slow down the robot, though I suggest slowing CP and PTP speeds instead of program execution speed.

3. It was just a general example, as I don't know what the TCP and the robot cell in question looks like. I doubt you would need 70 homing procedures. My approach to homing is to first get away from obstacles, whether by going directly upwards or to a side and then when robot TCP is out of the danger zone, bring in the TCP close to robot, so it could turn A1 to get into/near home position.

And the homing trajectories are not necessarily hard coded or not coded with full positions.

If you have so far been only teaching points (I assume that's what you mean by TP), look into expert programing. Writing any, but the simplest homing procedures by teaching points is the wrong way to do it.

you can write program that records robot positions since robot has left home.

when at home reset the array index.

if asked to run back, use that array to move robot in reverse order from last recorded position. of course prevent updating of recorded positions during this return to home program.

newer KSS version (8.5+) have jogging back along path built in. this allows manual retracting. but if you record data yourself, this should allow you to recover programmatically.

note, this is just robot motions, another thing to evaluate is what the robot tooling is doing. Kuka training Programming3 covers one recovery strategy. It is not the only one though. as long as you know what you are doing, you should be fine.

I have seen a strategy where the robot program writes a new value to a variable like "i_am_in_section"

And then before every point in your program you write:

PTP P1
TRIGGER WHEN DISTANCE=1 DELAY=0 DO i_am_in_section=73

PTP P2
TRIGGER WHEN DISTANCE=1 DELAY=0 DO i_am_in_section=74
PTP P3

And when you create your homing program you do it like:

IF i_am_in_section ==74 THEN

PTP P2

...

Or better use SWITCH CASE statements... its a bit cleaner.

But Mentat suggested that you may be able to just do a relative move upwards like 400 mm and then its straight to home from there.

You know best how many movements are nessessary to get home safely.

Usually up high is pretty safe.

unless it is a ceiling mounted robot for example...

Quote from Zeytey

Thank you! Can you please give more information about Array data using for position records? Or, is there any documents for it?

everything is in system integrator manual. also check recent topics on recording positions to an array using interrupt. example of arrays are found everywhere, including $config.dat.

Quote from Koppel

I have seen a strategy where the robot program writes a new value to a variable like "i_am_in_section"

And then before every point in your program you write:

PTP P1
TRIGGER WHEN DISTANCE=1 DELAY=0 DO i_am_in_section=73

PTP P2
TRIGGER WHEN DISTANCE=1 DELAY=0 DO i_am_in_section=74
PTP P3

And when you create your homing program you do it like:

IF i_am_in_section ==74 THEN

PTP P2

...

Or better use SWITCH CASE statements... its a bit cleaner.

But Mentat suggested that you may be able to just do a relative move upwards like 400 mm and then its straight to home from there.

You know best how many movements are nessessary to get home safely.

Usually up high is pretty safe.

Display More

But with this approach you have to be carefull if someone moves the robot out of the path manually.... So the robot is in the section 74 doing his moves, someone stops the robot, moves it out of this section, then resets the program, puts the robot in EXT, the homing routine runs, where the routine thinks the robot is at section 74 (but robot is on the opposite side for example) then you

can have a crash scenario fast... I have seen this couple of times to happen...

I had to fix this kind of approach couple of times, because the programmer who did it, didn't safeguard against manual jogging, and if someone stops and moves the robot during program execution those values dont apply anymore...

For me better aproach is to record the positions and move backwards(with tool actions) or check the robot positions with real values of the axes and tcp...

There are probably many ways to do this. I have had success using binary values.

;SETTING # VALUE TO HOME POSITION

;DECIMAL NUMBER 0

LOCALKUKATOHMI = 'B00000000'

Here is an example above. Basically after whatever move you do you set the binary value to what you want. Then have a homeout interrupt routine that runs through and looks for that number, and based upon the number you program it to do certain moves to return home. Below is an example of the homeout routine code.

;---------------

;BEFORE LEFT PART PICK

IF LOCALKUKATOHMI == 1 THEN

;PTP P1

PTP XHOME

ENDIF

;---------------

We are using the same concept with triggers. Approaching the part we use trigger at start and departing from the pick we will use trigger at the end of motion.

when then resolve the current_post variable in a while loop until 0 or the Kuka is in $HOME.