Sendin Home From Anywhere

    Greetings,

    Dear readers, I hope you are all well and everything is okay in your works! I have really specific question about KUKa robot homing (from PLC Command with only one button) from anywhere in an automation line.

    Automation Line Info:

    In this system, KUKA robot is lining parts in to boxes and putting separetors between the floors. Also, when the filling is done by a command from kuka it sends the boxes to taping line and after taping the boxes kuka robot takes the boxes and lines on the wooden pallets.

    What I want to do:

    In this cycle, after a fault occures and if KUKA stops or something else like that. I want to make that robot go home from anywhere without crashing any part of the automation system. As, Stäubli robots have I want to do such configuration like Stäubli robots have. Let kuka go home position (which means if kuka is in home position, system can be started again from zero) and wait for main start.

    Little info for Stäubli Robots, if robot stops while the cycle is running on Stäubli Robot's TP there is an home button and after you push the button robot goes home from anywhere even if robot is between the injection mould. Stäubli Robot goes out from the place it stopped as backward it gets inside to anywhere. With this crazy tought is there anyone that can give me a clue or information about it? This configuration is really important for so I'm open for any ideas!

    THANK YOU ALL FOR YOUR ATTENTION AND HELP IN ADVANCE!

    SORRY IF MY ENGLISH IS TOO BAD FOR YOUR UNDERSTANDING!

    Waiting for your replies!

    Have a nice day all!

    Automation Engineer

  • Go to Best Answer

    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.

    First of all all programs are written by TP and there was no KUKA Sim Pro used. So there no automation line drwaings that robot knows via simulation program. Please see my questions down below which they are asked substance to substance.

    1. These homing procedures are like sub programs that I should call for position robot is in?

    2. I understood that you are telling me, after a safe position robot got. I should engine the main homing program with safety speeds for example $ov_pro:%20

    3.I understood that a2 and a3 axises should be on safe positions. To avoid TCP damaged by any peripheral materials.

    4. no need for question.

    In this system robot is gets inside the boxes and there so many angle movement (from a4 a5 a6). I think If I'm not worg we should prepare so many homing procedures for every position inside the boxes cause for each box (in the system there are 2 boxes) we have 70 sub programs. And its about 280 points.

    Is there any otherway or not? Thank you for your reply in advance!!!!

    Automation Engineer

    • Best Answer

    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.

    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 Mentat

    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.

    Thank you for your reply. The TP is TeachPendant actually. We haven't used the KukaSimPro for this project. I have taken this project from another company over. I wish there was a mode that when I push the button Robot program could be executed by backward running ^^.

    Thank you!

    Automation Engineer

    Quote from panic mode

    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.

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

    Automation Engineer

    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.

    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

    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


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

Advertising from our partners