Homing filosophy with Fanuc

There are no variables on TP programs, but data registers are permanent.

You have to be careful with setting registers in between movements, in respect of the lookahead pointer. The robot will do the logic statements before he reached the position physically.

So you have to use the DB statements to set the position flags/data.

Bad news: you will break your fingers while punching those programs into the TP.

Quote from hermann

There are no variables on TP programs, but data registers are permanent.

You have to be careful with setting registers in between movements, in respect of the lookahead pointer. The robot will do the logic statements before he reached the position physically.

So you have to use the DB statements to set the position flags/data.

Bad news: you will break your fingers while punching those programs into the TP.

Holy moly I think using the DB statement for this is what I've been missing

From the top of my head my code looks something like this for example:

L P[1] 100mm/s FINE;
R[10]=1;


L P[2] 100mm/s FINE;
R[10]=2;

R[10] is supposed to remember the last point that has been reached by your program. This is used by the homing program. The homing program now needs to traverse the position sequence backwards. So during the work process I go Home -> P[1] -> P[2] now in homing I go P[2] -> P[1] -> Home. The problem is R[10]=1 for example gets executed slightly before the movement one line above has actually finished(this is the lookahead). If a sudden stop happens right then the robot remembers having reached a position it actually hasn't. Normaly your homing program returns to the last reached position first which now creates problems.

DB stands for "Distance before". It allows you to do this:

L P[1] 100mm/s FINE DB 0.1mm, R[10]=1;

L P[2] 100mm/s FINE DB 0.1mm, R[10]=2;

Same principle as before but R[10] is written 0.1mm before the target of the specific movement instruction has been reached. While lookahead is pretty wonky this gives you actual tolerances. You can even set it to 0.0.

Correction:

For some reason you can't directly set R[] values in the DB instruction . Only outputs can be set directly there. Use one of these instead:

DB 0.1mm, POINT_LOGIC;

DB 0.1mm, CALL SETPOSREG(2); // SETPOSREG is just a simple helper program that you'll have to make

May be you can set a dummy GO, that is configured to an unused flag range.

But may be that will not be permanent after a boot up.

On the Select Menu, highlight your SET_REG1 program, press Detail, and set group mask to all asterisks (*,*,*,*,*).

I always imagine that someone could come in and jog the robot to a different position. Then next time the robot starts you could have a crash since the actual position does not match the data register that you are using to keep track of the position.

The Ref Position feature will turn on a Digital Output when the robot is in a certain position.

Agreed. I do not like the Register only method. Instead I prefer to examine the current position and state, then make a decision.

Several options for the robots current position in order of my preference: DCS Zones, Ref Positions, LPOS, JPOS

Then in your homing program you examine the current position (could be in combination with IO state) and then select the correct path to move to home. IO or Registers would be used for secondary information only, such as if there is a part in the gripper, etc.

The benefit of this is that it is completely independent of the program logic. You don't have to worry about forgetting to change a register if the program is modified and you don't have to worry about someone jogging the robot. In my opinion, coupling homing logic or safety logic to process logic is always a mistake. Inevitably it will get into a different state than you anticipated and you will end up crashing the robot if you only rely on the process logic setting the correct register at the right time.

This is a problem, and only can be solved by education of the staff.

And if the homing procedure works in every situation, normally nobody moves the robot manually. So you will not get a problem. It is absolutely essential that the homing procedure works in every situation, otherwise you will run into problems! And it's essential to have a postition check at the beginning of homing. If robot already is in home --> abort homing and begin normal work.

This is my experience in many years of programming cells for different customers.

I have solved it in another way in some installations.

I save a few strategically positioned PRs and based on LPOS and some logic I try to move to one of them that are close by.

From the PRs I have trajectories set up to go to HOME.

If the robot is too close to something delicate, the program gives up and signals that manual intervention is needed.

This is not a good solution for all installations.

This is what I use, it is a MACRO bound to both a DI signal coming from the PLC and a user button as a shortcut.

UTOOL_NUM=1 ;

UFRAME_NUM=0 ;

IF (DO[36:OFF:R_HOME]=OFF) THEN ; //DO36 is the reference home position

IF (DI[20:OFF:Home Robot]=ON) THEN ; //DI20 is the PLC trigger for the robot to go home

OVERRIDE=25%

CALL PINZA_AP //release the grippers

//dicision logic to plan the path home

PR[31:Home robot]=LPOS //save current position to a PR

IF (DO[4:OFF:out of space wheelstabl]=OFF) THEN //DO4 is controlled by BGLOGIC

PR[31,1:Home robot]=PR[31,1:Home robot]-500 //if robot is near the wheels table substract 500mm from X current pos

ENDIF

IF (DO[35:ON :out of space bench]=OFF) THEN //DO35 is controlled by BGLOGIC

PR[31,3:Home robot]=PR[31,3:Home robot]+250 //if robot is near the table increase 250mm from Z current pos

ENDIF

IF (DO[3:ON :out of space barrel]=OFF) THEN //DO3 is controlled by BGLOGIC

PR[31,1:Home robot]=PR[31,1:Home robot]+250 //if robot is near the barrel increase Z by 250 and Y 250

PR[31,2:Home robot]=PR[31,2:Home robot]+250

ENDIF ;

L PR[31:Home robot] 400mm/sec FINE //after calculatins are done move away from fixture with Linear move
JMP LBL[1]

ELSE

LBL[1]

J P[1] 100% CNT100

ENDIF

ENDIF

if the robot is not already at home, and it is not commanded from the PLC to go Home go straight to P[1] without any calculations. If it is commanded from the PLC to go home, drop the total speed to 25%, release the grippers, check where you currently are, safely step away using the calculated PR and after, move to P[1] which is the Home position.

Here is the Background logic.

IF ($DIAG_GRP[1].$CUR_TCP_X<1050) THEN

DO[4:ON :out of space wheelstabl]=ON

ELSE

DO[4:ON :out of space wheelstabl]=OFF

ENDIF

IF ($DIAG_GRP[1].$CUR_TCP_Y<700) THEN

DO[35:ON :out of space bench]=ON

ELSE

DO[35:ON :out of space bench]=OFF

ENDIF

IF ($DIAG_GRP[1].$CUR_TCP_X<(-90) AND $DIAG_GRP[1].$CUR_TCP_Y<(-700)) THEN
DO[3:ON :out of space barrel]=OFF
ELSE

DO[3:ON :out of space barrel]=ON

ENDIF

I would refrain from using Registers and Flags just to keep track of the robot's position, I find it really cumbersome and unproductive way of programming, especially when you constantly create new jobs and tasks for your robot. If you save your current position to an LPOS format and your clearence move is Linear, you dont need to worry about crashes provided you have declared some solid and accurate danger zones.

Quote from PetrBroza

I changed group mask to all *, it worked once, but then I'm getting this error:

Did you forget to set a value for the argument?

If you set the register after a Fine movement, you don't need to use DB, you can just set it directly in the program. The look ahead only takes effect on CNT movements.

Post your programs.

Quote from HawkME

Agreed. I do not like the Register only method. Instead I prefer to examine the current position and state, then make a decision.

Several options for the robots current position in order of my preference: DCS Zones, Ref Positions, LPOS, JPOS

Then in your homing program you examine the current position (could be in combination with IO state) and then select the correct path to move to home. IO or Registers would be used for secondary information only, such as if there is a part in the gripper, etc.

The benefit of this is that it is completely independent of the program logic. You don't have to worry about forgetting to change a register if the program is modified and you don't have to worry about someone jogging the robot. In my opinion, coupling homing logic or safety logic to process logic is always a mistake. Inevitably it will get into a different state than you anticipated and you will end up crashing the robot if you only rely on the process logic setting the correct register at the right time.

Display More

This is good information, but I'm curious about a couple things: I get using DCS Zones to see if robot is here or there, but once you've determined you are inside that DCS zone are you then using LPOS to see where the robot is inside that Zone? How are you determining then where the robot is compared to the programmed position(s) to bring it home? Do you query each point of the program and see how close LPOS is to each point? Saying that out loud to myself sounds silly, so I know I'm missing something very obvious...Thanks for any input you can/may provide. I'd love to replace my lazy use of the breadcrumb trail (i.e. register setting). I definitely have seen where it can fail to do its job.