Kuka crash

[tyhu]

Robot Type: KR16 L6-2

We had a crash two days ago. After analysis, I found one "special feature" from Kuka might be the root cause. I can reproduce this "special feature" on another robot and this reproduction can lead to crash. It is called "special feature" from kuka, because it is not generated by customers/users. The description is as:

(1) The robot is running in External Mode, and stops at Position 1. 
(2) We switch robot mode from External Mode to T1 mode to check EOA tool. In T1 mode, we jog the robot from Position 1 to Position 2 to ease our observation of EOA.
(3) We switch robot from T1 to External Mode. We give command A to move robot. (Here comes the special feature.) The robot automatically generates a trajectory from Position 2 to Position 1, and then execute command A. This generated trajectory might be controlled by some algorithm from Kuka, and this trajectory could be any unpredictable motion. (I tested three combinations of Position 1 and Position 2, and the trajectory is unpredictable but I believe some algorithm is behind the trajectory.) This unpredictable motion led us having a crash.

Have you guys have any knowledge of this?

Happy first working day of 2012.

[kr16_2]

This is how I understnd your problem:
You stop the robot at Position1 and then manually jog the robot off the path to Position2 (Main Run Pointer - white line still sits at Position1)
Upon program start in EXT mode robot executes PTP to last known position when it left the program path which is Position1.

Can you manually (in T1) put the robot back to Position1 and then execute the program?

[tyhu]

>>You stop the robot at Position1 and then manually jog the robot off the path to Position2 (Main Run Pointer - white line still sits at Position1)
--- Position 1 is result of the previous command. So the white line does not sit at Position 1 any more, but sits at a "wait for". The Robot is waiting for a second command, because the previous command is successfully executed.  At this moment, the robot and code are all healthy.  Later we switch from External mode to T1, then from T1 to External.

>>Upon program start in EXT mode robot executes PTP to last known position when it left the program path which is Position1.
---  We issue a second command. Upon program start in EXT mode, the robot automatically first moves to Position 1 and then executed the second command. This Automatically is unexpected. I dont know the trajectory is made from PTP , or Linear, or Spline. But it looks like PTP.

Thanks a lot.

[kr16_2]

Because you manually move the robot off the path it will come back to last known position (in your case this is Position1)
I don't know other robots but this seems logical - that explains "special future" 

What I think you can do is use variable (it is an output) called ON_PATH.
On_PATH is reset (false) as soon as robot leaves a program path (you will find this output in AutExt setup screen)
This could trigger interrupt in your case.
Once you come back to automatic mode robot could execute interrupt which will move robot to current position - PTP $axis_act - no motion.
This will put robot on path so then I believe it will go to your next command after WAIT FOR which is Position2.

I never tried that but I guess it makes sense 

[Martin H]

Yes, I have seen this before.

My view is as follows:-

1.  You have moved the robot from P1 to a new point, let's call it P99.

2.  The robot does not have any knowledge of how to safely go from point P99 to P2.

3.  The robot believes (possibly incorrectly) that if it has been moved from P1 to P99, there must be a safe route back to P1.

4.  The only safe route in all of this, that the robot knows, is how to get from P1 to P2.

My guess (but also my expectation) is that the move from P99 to P1 is a PTP move.  Unfortunately, this is where I believe Kuka's programming logic is wrong, as in my opinion, most manual operator executed moves are predominantly linear, and therefore the route the robot takes back to P1 is unlikely to be the reverse of the move the operator made to achieve P99.

Unfortunately, taking a robot out of EXT, moving it manually, and then allowing it to run again from an unknown position, will ALWAYS be open to issues.  The only way to reduce these issues is to program as many possible scenarios that you can think of, to enable the robot to move back to a known position.

KR16_2's suggestion is valid, but still means that the robot will follow an unprogrammed path to P2 from wherever it is (ie P99).

If this is something you do frequently (ie go from EXT to T1, then back) at this point in the program, write P1 into one of the HOME variables before you do the move.  Set the home position tolerance to be what you consider 'safe' to allow the robot to move back to P1 on its own, after a manual move.  After the WAIT command, check the IN_HOME flag to see whether the robot is, in your opinion, safe to move.  If it is, let the robot move.  If not, HALT and let the operator move it back manually.

You could also program more points, which are not actually used in your program under normal circumstances.  For example, you could program a point P80, which is a 'get out of trouble' point, but is not actually anything to do with the route from P1 to P2.  If, for example, the robot is at point P99 which does not have a safe route back to P1, but P99 is near to P80, you could move to P80, then to P1.

[SkyeFire]

This isn't a KUKA problem, it's an operator error.  ANY robot brand will do something like this.  Putting a robot, ANY robot, into automatic without making sure it is properly on-path first is a rookie mistake that experienced operators should know better than to commit.

When you put the robot into automatic, it will move from wherever it is to whatever point is currently selected in the program.  KUKAbots try to protect against this with their BCO requirement, but that generally only applies at the very beginning of a program.  Under all other circumstances, the controller assumes that the human operator is smart enough not to create a collision potential.

Bottom line:  if an operator interrupts a program when the robot is at Point 1, and manually jogs the robot away to some position that is not part of the programmed path, there are only two correct procedures:
1:  manually jog the robot back to Point 1 before going into Automatic mode, or
2:  manually jog the robot home and reset the program to start over again from the very beginning (generally less desirable, especially in material-handling applications, but sometimes necessary)

[tyhu]

Thanks, kr16_2 , Martin H  and SkyeFire.

Yes, this BCO message is what I saw on the teach pendent.

SkyeFire, we are on the way to use the second method.


Great day

[Martin H]

A fairly simple solution to 2, which I have used in the past, is to write a section into the SPS, to cancel all running programs when the mode is changed out of EXT.  As SkyeFire said, this can be annoying, but does hopefully avoid robot-initiated crashes.

[kykam]

On the machine that I'm currently working on, I don't give the robot the start bit (through a PLC) until it's at a known position. I use about 4 "queue" positions for each task the robots must do.  If it's at an unknown position, then I force the user to run a homing routine.

If the robot is at an unknown position and not in any of the workspaces, then the user has to move the robot to HOME or a queue position in T1.

[MeanRobot]

A fairly simple solution to 2, which I have used in the past, is to write a section into the SPS, to cancel all running programs when the mode is changed out of EXT.

I have done the same on nearly every robot project I have ever worked on.  (Additionally I have the SPS immediately afterward select the "main" program so the PLC can take over via Automatic External.)

[SkyeFire]

I have a few systems where the PLC monitored the "on path" status signal from the robot, and would not send starting signals unless that signal was active.  That essentially forced the operator to at least get the robot back on path before returning to EXT mode.