Safe Position after stoppage

If you just reset and start it will continue in the program.

For the other, You need to write a recovery program that takes everything into account, and you set the tool frame and user frame. Then that is the first thing in your main program before you do anything else.

My company requires every robot I program automatically recover from anywhere in the cell.

One idea is to write a unique integer into a register after each move or set of moves depending on how your programs are set up. That way the robot will know exactly where it was last during program execution to either move back home safely or to continue at the appropriate point in the program.

$MOR_GRP[1].$currentline indicates the line number in the program that generated the current or last motion.

Quote from Sergei Troizky

$MOR_GRP[1].$currentline indicates the line number in the program that generated the current or last motion.

Be careful with this one, as line numbers often change.

That's true.
Unfortunately, the OP's "remember where it's at in a program" is not clear. I would restart based on "where it is in the cage".

This being said, it's unclear why abort the program if it has to be resumed/completed.

That is the "Fanuc" way, register or PR to remember your last or next point.

But what if it is inside a machine. And the maintenance guy manually drives it out to work on the machine. Are you going to recover from inside the machine (by returning to that point first?)

Best to look at where the robot is, and create recoveries based on that.

If you have a recovery program that runs after an abort, you can set the UF to 0 in there.

If you're resuming a program, you could setup a condition handler or BG logic program to check if the UF is 0 or not, and set it to 0 when needed. Nevermind, thought you could but forgot that you can't change anything motion related in BG logic or condition handlers.

As far as being able to tell where it is, there are a few different options that work well. FANUC likes to set registers and PRs to indicate the current position. You can use reference positions. You can also setup non-stopping DCS zones and map input bits to them (rack 36, slot 1, start at 1 or the number of the first DCS zone you want to look at).

Quote from ceilingwalker

I already kinda sorta have this. I created PR's that are labeled safe zones and the program tells it to move to these at the end. Unless maybe I am not understanding your suggestion?

I'm suggesting to set a register as a unique integer after every move. So if the robot program execution is stopped for any reason, it will jump back into the path where it left off. You can also have another program with the points in reverse order to back out of your path using the same register.

I find this method useful when the robot must navigate an exact path around an obstacle.

   1:  !JUMP BACK INTO PATH IF NECESSARY ;
   2:  IF R[50:MOVE FLAG]<>0,JMP LBL[R[50]] ;
   3:   ;
   4:  !ROBOT PATH ;
   5:  R[50:MOVE FLAG]=0    ;
   6:L P[1] 100mm/sec FINE    ;
   7:  R[50:MOVE FLAG]=1    ;
   8:   ;
   9:  LBL[1] ;
  10:L P[2] 100mm/sec FINE    ;
  11:  R[50:MOVE FLAG]=2    ;
  12:   ;
  13:  LBL[2] ;
  14:L P[3] 100mm/sec FINE    ;
  15:  R[50:MOVE FLAG]=3    ;
  16:   ;
  17:  LBL[3] ;
  18:L P[4] 100mm/sec FINE    ;
  19:  R[50:MOVE FLAG]=4    ;
  20:   ;
  21:  LBL[4] ;

This is of course subject to user manipulation in the teach pendant and it can also be unwieldy for programs with lots of points, but at least an idea to think about.

This approach only works with fine points. When you use continuous points, the register will change in advance.

But you can set a GO within every movement (that's done in the correct physical position), then use that GO for checking the position.

Quote from hermann

This approach only works with fine points. When you use continuous points, the register will change in advance.

But you can set a GO within every movement (that's done in the correct physical position), then use that GO for checking the position.

What do you mean by "set a GO within every movement "? DB?

On our customers we usually do an automatic recovery on robots every time someone enters the cell or safety is cut. We use both dcs and space functions in order to do it after restarting the program, but... as you say, if space is tight and access to the area this approach is not always a viable option.

So I think the only way to do that would be to maybe store all that points as PR in order, you can try some approaches:

1 - Taking note of the last executed PR -> Problem will be that pointer will be ahead of motion, this can be somewhat solved if you use a trigger like "distance before" like other people have said.

2 - If trajectory is stored in PR you may be able to do a bgLogic where you read the current position of the robot and compare it to an PR list... this has also problems because robot will not pass through the point exactly if you use cnt, you will also need to check with a tolerance and bglogic is executed only every 8ms or so, depending on the controller, also you cannot do loops on bglogic so execution should be splitted in various cycles... also it may not work very well if points are very near.

3 - Split your trajectories into the most manageable form, like a module for approach, another for picking, another for getting out from the zone, and checking on what operation you was and return from home from there.

All this "possible solutions" need a PR list avaiable so you can run the robot backwards or integrate a messy logic on your program in order to jump again into the same motion line you were...

This... has no easy solution, the robot is not an human, the best you can do in the best of the cases with automatic recovery routines is guess where the robot really is, try to move at low speed and hope robot will not collide with anything on his way... if you want to return the program where it was there is no sense in aborting the program and if that happens, I would say it's better to return to a safe position first and drop the piece somewhere or start the process again.

DCS zones (or LPOS/JPOS for the poor man) is the way to go for complex recovery. You may need to combine that with IO state.

Using DCS zones for recovery is overkill, Jm2c. Most time I am struggling with runtime limits of the DCS system just only with the user safety things, that's the thing DCS is intented to be used for.