Safe Position after stoppage

  • Hello. I am on this machine tending robot that needs to maneuver into some pretty gnarly positions. I already have written in my programs to have the robot move to a safe location and it works well. My concern is, let's say the robot is stopped for any reason while a program is being executed. Is there a way I can make sure the robot will remember where it's at in a program and complete that program after an abort? My concern is that the UF gets changed somehow and the robot crashes into something. I need to make it so that it must finish wherever it left off in a program to keep it crashing. Thank you

  • Place your Ad here!
  • 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.

  • 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.

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

    This is exactly what I want. The problem is, I have 4 machines and 3 conveyors that this robot is tending. I already created the DCS no-go zones and with this giant gripper the wrist must be in a certain position at a certain time to avoid the DCS alarms.

  • 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.

    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?

  • 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.

    If I were operating the robot, I would know to do this. Unfortunately, this company brings people in off the street and say "You're now a robot operator", without appropriate training. I have argued this with them but it falls on deaf ears. They're a very good customer so I have to figure out how to make this as idiot-proof as possible. I thought about not even providing an abort option on the HMI however, if they cold start the system, won't that have the same affect as abort?

  • 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.

    I do have PR's that indicate safe zones/positions however, if it hasn't completed a move to a PR, it won't see that it's nearby. Of course all my safe zone PR's were established in UF 0.

  • 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).

  • 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).

    I love it! I forgot about using DCS passively so that it could only trigger I/O! That's a great idea. I create this block in front of each area that could be detrimental so the robot knows it's in one of them. Thank you

  • 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.

    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.

  • 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.

    Thank you for this info. I am still very new at this.

  • 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners