KUKA KRC2 KR180PA Crashed into itself, what logs are available

First rule of robot crashes: take an Archive All backup immediately. This exports the Logbook for detailed analysis. Also, if using KSS 8 or higher, make a KRCDiag, just in case.

Any bug that caused the SPS to halt should show up in the log. You'll want to work backwards from the actual collision event.

An SPS stoppage should not cause the robot to start colliding with things, unless the clearance signals and/or palletizing calculations are being routed through the SPS.

The S icon going grey means that the SPS wasn't just halted (that would be red), but cancelled. This is nearly impossible, unless someone does it by hand (usually requires being in Teach mode), or some line in the Level 1 interpreter issues a CANCEL 0 command to the $CMD channel.

Also very important logs for diagnosing crashes are the files inside the POSLOG folder. The controller automatically stores information on system state when certain events happen. Events could be e.g. emergency breaks, pushing the deadman switch, certain messages, ... . The files can be opened with a Internet browser and show a lot of useful information like commanded and actual positions, program points, ... .. The Event occurs when the time stamp is zero and you can go back right into the past following the negative integer time stamps. Since there is a limited amount of files from the past you should have a KRCdiag taken right when the problem occurred because KRCDiags archives those files.

Back at KUKA we usually used these files to analyse crashes. More than once we were able to show that not the system but bad programming or crashing the robot in manual mode where the reasons though customers stated otherwise.

Fubini

yup... look at every piece of info to get complete picture. there is tons of files in KRC\ROBOTER\LOG

don't look at Logbuch.txt that export could be filtered or manipulated.

use LogViewer to see all messages. make sure to check both Archive and KrcDiag.

i have found more than once that they don't have same messages.

To me also something like this sounds some miss calculated point in the program...

Usually when i got a job to investigate crashes, it was most of the time because of poor robot programing and disaster waiting to happen...

or wrong frames like tool and base. quite common with new guys who learn to do something in KRL without inline form but forget to

initialize correctly motion parameters again (and every time...). for example after some subprogram uses inline form motion it messes up all motions settings.

or incorrect use of interrupts

or don't take care of advance run pointer

or something else...

also submit interpreter can read but not change motion parameters. your program should work just fine with submit not even running (although some KSS versions have check in INI file and complain about no submit, but... even there you can just skip that line and see it moving just fine)

Heck, the last time something like this happened to me, it was while I was gone for lunch -- came back to find a press had eaten a robot that had been running perfectly well for weeks. Grabbed the pendant, opened the log, and... the sequence of events was:

1: Robot in T1

2: Manual Block select -- jump from Line 75 to Line 85

3: Robot in EXT

4: Cycle Start

5: axis over-torque errors

The fact that the log records actual pendant actions is a lifesaver.

Still, the fact that the SPS is getting cancelled points at something hinky going on. The "Axis 3 Limit" error points at a badly calculated point, but it should have preemptively blocked the bad motion, if it was a PTP motion. So given that the robot crashed physically before stopping on this error suggests that the move was a LIN.

maybe someone uses CIRC for palletizing...

Quote from panic mode

maybe someone uses CIRC for palletizing...

Dude, don't even joke about that!

(Okay, that's probably my personal dislike of CIRCs more than a "legit" complaint, but....)

I use UserLogonUSB and hide the Block selection button (and many other things) for the standard user. If something happens, I'm able to tell who did what....

Yeah, KRCDIAG is only on KSS 8.x.

That certainly sounds like someone left the program at a bad line, or skipped over some critical math, before putting the robot back into EXT.

Classic collision, using line select skipped too much code, robot used tool and base from previous point with the calculated point, back to EXT, executed move with 100% $OV_PRO...

That is why i lock all buttons at user level, operator level, and do check if someone is jogging the robot out of the path, then i reset program automatically(if someone is messing with the robot) when back to $EXT, and PLC sends start signal in $EXT only if the robot is in known positions... $IN_HOME,1,2-5, $ON_PATH, $NEAR_POSRET...

Quote from SkyeFire

Yeah, KRCDIAG is only on KSS 8.x.

KUKA has older versions too but they were not included as standard feature befor KRC4.

KRCDiag V1.x is command line utility created in 2005 and it runs on older controllers (Win95 and WinXP)

Quote

Yeah was able to re-create the issue, seems like the second LIN movement causes it to go into lala land when running through the code in manual mode, why would this be, tried using PTP instead which at least casues and error and stops it from moving, is the base reference being reset after the first LIN move

Sounds like a Status and Turn issue. These are handled differently in LIN and PTP moves. PTP moves are not executed when the target position violates limit switches. LIN moves only register limit switches while executing the move.

Moreover block selection commands on PTPs execute as PTPs and you always reach programmed status and turn.. Block selection commands on LINs are LINs and the status and turnaat the end of the block selection command depends on status and turn where this movement command started.

Quote from MrSysInt

Yeah was able to re-create the issue, seems like the second LIN movement causes it to go into lala land when running through the code in manual mode, why would this be, tried using PTP instead which at least casues and error and stops it from moving, is the base reference being reset after the first LIN move

PTP commands can essentially predict when the endpoint of a motion is going to be unreachable for some reason. LINs and CIRCs, however, can't. It's basically b/c a LIN or CIRC consists of many tiny PTP motions, and the "predictor" can only read one PTP ahead.

The fact that the PTP throws an error tells us something about the root cause -- the calculated destination is illegal -- either beyond the robot's physical reach, or violating an axis limit. It's not a path error -- it's possible to have a LIN move where the end point is legal, but the linear path will violate limits or collide en route.

The illegal destination could be due to bad $BASE or $TOOL settings, or something in the calculation of pLayerPosition itself. I notice that pLayerPosition is being shifted relative to its previous position -- if, say, someone were to re-run that portion of the program multiple times, without "resetting" the position, it could "walk" the calculated position well outside of the robot's reach envelope.

Quote from panic mode

yup... look at every piece of info to get complete picture. there is tons of files in KRC\ROBOTER\LOG

don't look at Logbuch.txt that export could be filtered or manipulated.

use LogViewer to see all messages. make sure to check both Archive and KrcDiag.

i have found more than once that they don't have same messages

There could be two reasons for that (also log viewer):

1 - Messages are saved in a ring buffer and therefore older messages could have been overwritten

2 - evt log could be corrupted and contents are not visible anymore (on older version this may be checked with the program fixevt.exe)

Quote from DannyDJ

To me also something like this sounds some miss calculated point in the program...

Usually when i got a job to investigate crashes, it was most of the time because of poor robot programing and disaster waiting to happen..

As you mentioned poor robot programming (like changing BASE or TOOL)

But this mean the point is not miscalculated, simply got the wrong food!

Quote from panic mode

maybe someone uses CIRC for palletizing...

This is actually the best and fastest way to move from one point to another, but it is also very dangerious

I agree with SkyFire:

the problem was sitting in front of the monitor