Homeposition

Mippaloo

What is the best way to solve the function that wherever you are in the robot program you can press stop and then press a button that means go to homeposition. The robot should then move backwards along a safe path until it gets to its homeposition. Every solution i can think of means a lot of programming and i want a simple way of doing it. Maybe use the path recorder. The problem with that is knowing when to start and stop the recorder to get the simplest and fastest way to homeposition without colliding with something.

claudio

Hi

I use the following three options (in order of complexity):

1. Go up linear to a fixed Z then MoveJ to home. (e.g. pick & place applications).

2. Testing the current axis values (via CJoint), decide a way to get home in a small set of prefined paths.

or, for most complex layouts:

3. Think the set of all robtargets as a graph:

                   HOME
rbt100          rbt200             rbt300
rbt110    rbt210 rbt220

In this example, the robot usually moves, during its work cycle, from HOME to rbt100, then to rbt110, then back to rbt100 and home, or from HOME to rbt200, then rbt210 or rbt220, etc.
Given this graph, and given the current robot position, it's easy to write an algorithm to take it back to home using a safe path.
More, if the robot is stopped in a point between rbt100 and rbt110, the safe path is going first to rbt100, and then to HOME.
In conclusion, the information to store is just the last position reached.
The safest way I found to do that, is using a MoveLSync (or J), running a small procedure that store the position reached in a persistent string:

...
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";
MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
...

PROC SP_100()
  ! position 100 is reached
  sLastPos:="POS100";
ENDPROC

PROC SP_110()

  ! position 110 is reached

  sLastPos:="POS110";

ENDPROC


PROC RegainHome()
  WHILE sLastPos<>"HOME" DO
     TEST sLastPos
        CASE "POS100"
           MoveLSync rbt100,fine,v300,tlGripper, "SP_100";
           MoveJSync HOME, fine,v300,tlGripper, "SP_100";
           sLastPos:="HOME";
        CASE "POS110"

         &nbs p; MoveLSync rbt110,fine,v300,tlGripper, "SP_100";
           sLastPos:="POS100";
        ...
     ENDTEST
  ENDWHILE
ENDPROC

During the automatic home procedure, positions are visited via "fine" points, but this is not usually an issue since the path is the same you get running the work cycle step by step.
Sometimes you have to "mask" positions, because - for example - you may not want to get back to a pick or place position during a RegainHome.
Another issue is the following. Suppose that POS100 is the last position reached. In principle you don't know if you are going to POS110 from POS100 (but you never reached it), or you are coming back to HOME from POS100, so you don't know if the robot must move J or L.
A simple solution is pre-storing the next position:

! Forward along the graph - store reached positions
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";

MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
! backwards along the graph - pre-store next position
sLastPos:="POS100";

MoveL        rbt100,z100,v1000,tlGripper;
MoveJSync HOME,z100,v100,tlGripper,"SP_HOME";

Usually I first write the program (w/out Syncs). Then I decide names for positions, and I write the RegainHome procedure. Finally I sync all the moves in the program thinking how the robot should get back to home.
Using "talking names" for positions is usually a good idea to simplify the debug (POS_PICK instead of POS100 for example).
Technically it should be possible to build the graph at runtime using the work cycle (maybe overloading Move instructions), and then to use it in a second time for homing purpose, but since now, I always used hand-made graphs.
Another intersting scenario is using a PC tool to build graphs and automatically write the RegainHome routine.

Using the method here described, I wrote an automatic homing procedure for a robot holding a 130Kg gripper picking parts from 11 different stores.
The example given above is also a trick to reposition the robot when you are inside a narrow space where you can only move linear, that is a very common situation.

Bulo_11

claudio said:

Hi

I use the following three options (in order of complexity):

1. Go up linear to a fixed Z then MoveJ to home. (e.g. pick & place applications).

2. Testing the current axis values (via CJoint), decide a way to get home in a small set of prefined paths.

or, for most complex layouts:

3. Think the set of all robtargets as a graph:

                   HOME
rbt100          rbt200             rbt300
rbt110    rbt210 rbt220

In this example, the robot usually moves, during its work cycle, from HOME to rbt100, then to rbt110, then back to rbt100 and home, or from HOME to rbt200, then rbt210 or rbt220, etc.
Given this graph, and given the current robot position, it's easy to write an algorithm to take it back to home using a safe path.
More, if the robot is stopped in a point between rbt100 and rbt110, the safe path is going first to rbt100, and then to HOME.
In conclusion, the information to store is just the last position reached.
The safest way I found to do that, is using a MoveLSync (or J), running a small procedure that store the position reached in a persistent string:

...
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";
MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
...

PROC SP_100()
  ! position 100 is reached
  sLastPos:="POS100";
ENDPROC

PROC SP_110()
  ! position 110 is reached
  sLastPos:="POS110";
ENDPROC

PROC RegainHome()
  WHILE sLastPos<>"HOME" DO
     TEST sLastPos
        CASE "POS100"
           MoveLSync rbt100,fine,v300,tlGripper, "SP_100";
           MoveJSync HOME, fine,v300,tlGripper, "SP_100";
           sLastPos:="HOME";
        CASE "POS110"
         &nbs p; MoveLSync rbt110,fine,v300,tlGripper, "SP_100";
           sLastPos:="POS100";
        ...
     ENDTEST
  ENDWHILE
ENDPROC

During the automatic home procedure, positions are visited via "fine" points, but this is not usually an issue since the path is the same you get running the work cycle step by step.
Sometimes you have to "mask" positions, because - for example - you may not want to get back to a pick or place position during a RegainHome.
Another issue is the following. Suppose that POS100 is the last position reached. In principle you don't know if you are going to POS110 from POS100 (but you never reached it), or you are coming back to HOME from POS100, so you don't know if the robot must move J or L.
A simple solution is pre-storing the next position:

! Forward along the graph - store reached positions
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";
MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
! backwards along the graph - pre-store next position
sLastPos:="POS100";
MoveL        rbt100,z100,v1000,tlGripper;
MoveJSync HOME,z100,v100,tlGripper,"SP_HOME";

Usually I first write the program (w/out Syncs). Then I decide names for positions, and I write the RegainHome procedure. Finally I sync all the moves in the program thinking how the robot should get back to home.
Using "talking names" for positions is usually a good idea to simplify the debug (POS_PICK instead of POS100 for example).
Technically it should be possible to build the graph at runtime using the work cycle (maybe overloading Move instructions), and then to use it in a second time for homing purpose, but since now, I always used hand-made graphs.
Another intersting scenario is using a PC tool to build graphs and automatically write the RegainHome routine.

Using the method here described, I wrote an automatic homing procedure for a robot holding a 130Kg gripper picking parts from 11 different stores.
The example given above is also a trick to reposition the robot when you are inside a narrow space where you can only move linear, that is a very common situation.

claudio said:

Hi

I use the following three options (in order of complexity):

1. Go up linear to a fixed Z then MoveJ to home. (e.g. pick & place applications).

2. Testing the current axis values (via CJoint), decide a way to get home in a small set of prefined paths.

or, for most complex layouts:

3. Think the set of all robtargets as a graph:

                   HOME
rbt100          rbt200             rbt300
rbt110    rbt210 rbt220

In this example, the robot usually moves, during its work cycle, from HOME to rbt100, then to rbt110, then back to rbt100 and home, or from HOME to rbt200, then rbt210 or rbt220, etc.
Given this graph, and given the current robot position, it's easy to write an algorithm to take it back to home using a safe path.
More, if the robot is stopped in a point between rbt100 and rbt110, the safe path is going first to rbt100, and then to HOME.
In conclusion, the information to store is just the last position reached.
The safest way I found to do that, is using a MoveLSync (or J), running a small procedure that store the position reached in a persistent string:

...
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";
MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
...

PROC SP_100()
  ! position 100 is reached
  sLastPos:="POS100";
ENDPROC

PROC SP_110()
  ! position 110 is reached
  sLastPos:="POS110";
ENDPROC

PROC RegainHome()
  WHILE sLastPos<>"HOME" DO
     TEST sLastPos
        CASE "POS100"
           MoveLSync rbt100,fine,v300,tlGripper, "SP_100";
           MoveJSync HOME, fine,v300,tlGripper, "SP_100";
           sLastPos:="HOME";
        CASE "POS110"
         &nbs p; MoveLSync rbt110,fine,v300,tlGripper, "SP_100";
           sLastPos:="POS100";
        ...
     ENDTEST
  ENDWHILE
ENDPROC

During the automatic home procedure, positions are visited via "fine" points, but this is not usually an issue since the path is the same you get running the work cycle step by step.
Sometimes you have to "mask" positions, because - for example - you may not want to get back to a pick or place position during a RegainHome.
Another issue is the following. Suppose that POS100 is the last position reached. In principle you don't know if you are going to POS110 from POS100 (but you never reached it), or you are coming back to HOME from POS100, so you don't know if the robot must move J or L.
A simple solution is pre-storing the next position:

! Forward along the graph - store reached positions
MoveJSync rbt100,z100,v1000,tlGripper, "SP_100";
MoveLSync rbt110,z10, v100,tlGripper, "SP_110";
! backwards along the graph - pre-store next position
sLastPos:="POS100";
MoveL        rbt100,z100,v1000,tlGripper;
MoveJSync HOME,z100,v100,tlGripper,"SP_HOME";

Usually I first write the program (w/out Syncs). Then I decide names for positions, and I write the RegainHome procedure. Finally I sync all the moves in the program thinking how the robot should get back to home.
Using "talking names" for positions is usually a good idea to simplify the debug (POS_PICK instead of POS100 for example).
Technically it should be possible to build the graph at runtime using the work cycle (maybe overloading Move instructions), and then to use it in a second time for homing purpose, but since now, I always used hand-made graphs.
Another intersting scenario is using a PC tool to build graphs and automatically write the RegainHome routine.

Using the method here described, I wrote an automatic homing procedure for a robot holding a 130Kg gripper picking parts from 11 different stores.
The example given above is also a trick to reposition the robot when you are inside a narrow space where you can only move linear, that is a very common situation.

Ok Claudio, do You know how to write sLastPos without creatina a routine for each "step"?
If i write the variabile without movelsync, that variable Will be be written before arriving because of the zonedata (z200)

Thank you

Micky

Hello,

maybe you can use the software option "RobotWare Machine Tending" that already offers a homerun concept.

https://new.abb.com/products/robotics/application-software/machine-tending/roboware-machine-tending

The concept uses position numbers which are used to name the movement routines (contains only moving instructions) and to identify each move instruction.

<p> PROC mv32_10()</p><p>&nbsp; &nbsp; MT_MoveJ <b>32</b>,p32,v1000,z10,ToolData1\WObj:=wPallet1\NoMove;
<span>&nbsp; &nbsp; MT_MoveL <b>321001</b>,[[-547.612257925,-1109.64,1600],[0.43,0.429,0.75129,-0.2452],[-1,0,-1,0],[9E9,9E9,9E9,9E9,9E9,9E9]],v1000,z10,ToolData1\WObj:=wPallet1;
</span><span>&nbsp; &nbsp; MT_MoveL <b>10</b>,p10,v1000,z10,ToolData1\WObj:=wDCM1;</span></p><p>ENDPROC</p>

I a homerun strategy routine the current position number is evaluated and, if necessary, the gripper is opened or closed, or other things are executed position-dependent before the required move instruction is called.

/BR 
Micky

Micky

Hello Bullo

Ok Claudio, do You know how to write sLastPos without creatina a routine for each "step"?
If i write the variabile without movelsync, that variable Will be be written before arriving because of the zonedata (z200)

you have trigger always the writing of the position value because the program pointer is not synchronized with the motion pointer.

That means, you have to use the instruction MoveLSync or the Instruction TriggL to assign the position value if the robot reaches the target position or the zone.

Only if you use a fine point or you use the instruction "WaitTime\Inpos" or "WaitRob\InPos" you can assign the position value directly in the program,

If you use a group output to assign the position number and you use the instruction MoveLGO or TriggL you can assign the position number direct in the Move instruction and you do not need a sync routine for each position.

BR

Micky

lemster68

You can look at this discussion regarding recovery here:
https://forums.robotstudio.com/discussion/comment/27737#Comment_27737