Any Robot Programmer here to discuss auto recovery

Hello All,

I would like to know how do you guys write a program to do auto recovery at the cell.

Currently, at my workplace, we use ABB robots and most of the cell have auto recovery features. we define a variable call "Current_Task" in every routine and assign a number to that variable.
For example, assign 10 to variable "current_task" if picking up the part from infeed and clear current_task once out of that routine, assign 20 if servicing Machine, Assign 30 if dropping the part at outfeed conveyor and we also define world zone in the program to know the position of our robots as well.

Once robot crash, we check the current task and depending on the current task, jump to recovery routine of that task and just hit play and robot will come out and move to home position.

But the problem with such kind of auto recovery method is, let's say if robot crash inside the machine (motion supervision) and someone tried to recover the robot manually by jogging and made it halfway but he realized oh I have recovery routine and then tried to auto recover, robot will go back to where it was crashed and recover from there which could possibly cause another crash.

I am really interested in some innovative idea to do automatic recovery by itself without the help of anyone.

For example, we can find the position of each axis of the robot by getting the value from a resolver and we already know the dimensions of each machine and objects in the cell and we do have safe move on each cell in robot work area. once robot get motion supervision in the cell, find the position of each axis of the robot and then know where the robot is right now and recover automatically and alarm up the machine, and robot continue running and servicing other machines and won't go in that machine until someone clear the fault because robot might drop the part during auto recovery.

What do you guys think of it? is it possible to do that or just curious to know what kind of auto recovery are you guys currently using in the workplace and would love to learn from you.

Thank you for the great ideas and knowledge in advance.

Thank you,

What you've described is very much the same way I do it for ABB, Fanuc, and Nachi. Every normal program move also has an associated recovery move that is executed if the robot is not within Xmm of a pounce position when starting up, an e-stop recovery, or other condition that drops the robot out of auto.

I use robots as dumb servos, even controlling the end-of-arm tooling with the PLC. So a robot program is just a main routine that looks for move requests from the PLC, executes the move, and returns to the main routine and tells the PLC its ready for the next move. This is the standard that GM and Ford use in their robot templates and it works very well.

As far as a operator grabbing a pendant and moving the robot, its discouraged, but the first thing that happens when a robot returns to Auto, the PLC checks the actual location against the last known location and either faults, prompts if the robot can move to the closest pounce or home position or execute the last assigned recovery routine.

Yeah, it sounds like a lot of work but once a template is designed, it gets pretty easy to commission new robots.

Jstolaruk,

Thank you for the reply. I think we have a pretty much same method and I would say this is the very common method used in industry and robot always wait for PLC move command and do the task until someone is not using an external controller for that commands and want to use robot i/o to connect sensors and other field devices.

I am brainstorming different ideas and was thinking to use some sort of calculation to find surrounding obstacles (Because I know the dimensions of my cell from .SAT drawing and will know the position of my robot) when robot crashes and according to those numbers, i can generate a value which can be pass to variable and use in instruction to move the robot itself at slow speed and if somehow I messed up with those numbers and robot will try to make any crazy move, It may violate my safe zone, which will stop the robot anways.

What do you think? Is it possible? have you ever thought of another way of doing auto recovery without human efforts?

Thank you again for the great input

Thanks,

As I mentioned, one of the recovery options is to execute the last known recovery. This is always the operators choice and it's very rare the operator has to grab the teach pendant.

With respect to avoiding obstacles, this can be done with fanuc's dcs option, ABB's Safemove, and Nachi's RMU option. It is primarily for creating safety fences but with a lot of work, the user program can interact with it and avoid those non safe situations. I don't know that the payoff is worth the time invested.

jstolaruk said:

I use robots as dumb servos, even controlling the end-of-arm tooling with the PLC. So a robot program is just a main routine that looks for move requests from the PLC, executes the move, and returns to the main routine and tells the PLC its ready for the next move.

Click to expand...

This is why I always find it really weird when interviewers ask if I've worked with robots.

jstolaruk said:

As I mentioned, one of the recovery options is to execute the last known recovery. This is always the operators choice and it's very rare the operator has to grab the teach pendant.

With respect to avoiding obstacles, this can be done with fanuc's dcs option, ABB's Safemove, and Nachi's RMU option. It is primarily for creating safety fences but with a lot of work, the user program can interact with it and avoid those non safe situations. I don't know that the payoff is worth the time invested.

Click to expand...

Thank you for the valuable input I will definitely think about your input and i liked the idea too

Thank you again,

VAN said:

This is why I always find it really weird when interviewers ask if I've worked with robots.

Click to expand...

hahah good one!

backendcode said:

Thank you for the valuable input I will definitely think about your input and i liked the idea too

Thank you again,

Click to expand...

You're welcome, check out the robot-forum.com also. And thanks for sharing.

jstolaruk said:

You're welcome, check out the robot-forum.com also. And thanks for sharing.

Click to expand...

Thank you for the forum link

VAN said:

This is why I always find it really weird when interviewers ask if I've worked with robots.

Click to expand...

Robotics can get quite complex. Sure if you doing simple moves in open space, then it can serve as simple servo. But if you working on more complex stuff, then you can't do much just with PLC programming knowledge.

I know this is an old thread, but jumping in on this, I recently started working with robots, and one of the things that's actually totally useable in a lot of situations, even though it isn't, is how to home the equipment.

This does require knowing about the part, and establishing what we can call "Perch zones". These are known unique positions that the robot can return to from different points through it's motion, before doing a linear/joint move to a home position.
This would prevent the need to "Jog robots to home" using the pendant.
At least for Fanuc:
Define the zones which might have unique perch zones in the DCS. Energize an output when the TCP is in the DCS zone. For complex parts you can also add joint limits to the DCS "status", have not tried this 1st hand.
Write a "Home" program which looks at the unique perch zone, and then backs out to the particular perch position, then goes to home. This prevents the part from crashing when you just want to jog to home.

This TP program can also be called in from the PLC, if that's more your flavor.

Regards,
-PreLC

Yop, that's used quite a lot. In ABB world it's called world zone. Or you can just define cube by two points (x,y,z), read actual position of TCP (CPos) and then compare it with with defined points.

In Fanuc world you can use LPOS, or you can create background task where you can use command $SCR_GRP[1].$MCH_POS_X /y/z and execute same logic. But be careful as the position is not updated when robot is jogged. Then I have another BG task where I detect, if robot was jogged (DO[1]=$MOR_GRP[1].$JOGGED=1)

Other solution is to have register, and every time you reach some position, save unique number to resister. Then if you call homing routine, based on the number in register, execute motions to get to the home.

backendcode said:

Hello All,

I would like to know how do you guys write a program to do auto recovery at the cell.

Currently, at my workplace, we use ABB robots and most of the cell have auto recovery features. we define a variable call "Current_Task" in every routine and assign a number to that variable.
For example, assign 10 to variable "current_task" if picking up the part from infeed and clear current_task once out of that routine, assign 20 if servicing Machine, Assign 30 if dropping the part at outfeed conveyor and we also define world zone in the program to know the position of our robots as well.

Once robot crash, we check the current task and depending on the current task, jump to recovery routine of that task and just hit play and robot will come out and move to home position.

But the problem with such kind of auto recovery method is, let's say if robot crash inside the machine (motion supervision) and someone tried to recover the robot manually by jogging and made it halfway but he realized oh I have recovery routine and then tried to auto recover, robot will go back to where it was crashed and recover from there which could possibly cause another crash.

I am really interested in some innovative idea to do automatic recovery by itself without the help of anyone.

For example, we can find the position of each axis of the robot by getting the value from a resolver and we already know the dimensions of each machine and objects in the cell and we do have safe move on each cell in robot work area. once robot get motion supervision in the cell, find the position of each axis of the robot and then know where the robot is right now and recover automatically and alarm up the machine, and robot continue running and servicing other machines and won't go in that machine until someone clear the fault because robot might drop the part during auto recovery.

What do you guys think of it? is it possible to do that or just curious to know what kind of auto recovery are you guys currently using in the workplace and would love to learn from you.

Thank you for the great ideas and knowledge in advance.

Thank you,

Click to expand...

I like this question, and being a robot programmer, of course I also had to chip in.

Half of the robotic work cells I've worked with have had auto-recovery routines, the other half did not. Both types will make you money, the auto-recovery takes time to program, and for work cells that don't have it, you have to spend time training maintenance how to manually jog and recover and set the robot program back to main after homing and resetting the necessary stations.

I've worked with Fanuc, Kuka, and Wittmann robots that have had auto-recovery, and also Nachi and Fanuc robots that did not have auto-recovery.

The cell that had Nachi robots required the operators to home the robots every single time there was an error on the machine that I believe had 13 different stations and 3 robots. There was a lot of homing required and I'm surprised that since it was the company's biggest money maker, they didn't invest in a good recovery routine.

To answer your question, first of all, it is not a good practice for someone to jog a robot half-way home and then let the recovery routine take over. As someone mentioned earlier, there are perch positions and other methods to give you a full recovery without ever switching the key switch from Auto to T1 or T2 (manual modes). This saves a lot more time.

For Fanuc robots, one way I've seen is to know your work space cubes (dimensions of what the work areas are of your machine). For example, you have a pick cube, a place cube, a molding machine cube, and a reject scrap bin cube. When the operator requests to home the robot (usually from the HMI), the robot will set LPOS (linear position) to a position register and then in the recovery routine will determine which work cube it is in. The program also checks if a part is in the robot or not to know how to deal with this if to also go to a scrap bin, drop point, or simply back home. After you compare and know which cube you're in, you have a specific home sequence that is 'likely' safe for any position the robot would be stuck in while working in that cube. For example, for a material handling job, you may simply only have to move Z+ for 200mm to make to a clear safe point (perch position for cube A) and then you can call a joint move straight home. If you have spot welding clamps inside a part, then first command a linear move X- 300mm, and then Z+ 200mm and back to home with a joint move.

Another work cell I've worked with has had 3 Fanuc robots next to eachother spaced less than 1 feet apart all working together on a glue dispensing operation to decrease cycle time since the glue dried so fast. In this cell, each robot used "zones" that would set a bit to the PLC to let it know which ones were clear for the other robots to travel into. More simply stated, the original programmer made safety zones that were the max 2 dimensional distances on a flat plane the robot TCP could travel before signalling to the PLC that it was out of that zone. The auto-recovery was simple. Robot 1, or 2, or 3 would wait for the other robots clear from it's work zone before homing. So first robot 1 would check it's zone bits are clear and then perch to Z+300 and joint move back home, then robot 3, then robot 2.

Now in the case of a crashed robot, and the part is stuck in the gripper, then yes, I recommend someone qualified/trained manually jogs the robot to a safey position, removes the part, and then jogs the robot home and resets the program back to main and homes the specific station the robot was at last. If the part was scrapped, you can signal from the HMI to home that station so the robot will wait for another part present, etc or put a finished part in the station and signal from the HMI either station abort or station complete.

Hope this helps to answer your question.

With ABB Robots you could record the movements you are doing and just replay them backwards. That is quite a nice feature for recovery. Don't remember how that was exactly done and what are the limits, but anyway.