Kuka KRC2 machining setup ROBROOT and world out of sync and TCP issues.

Hello,

We have a Robotics Solutions milling cell we bought second hand from an auction. It is a KR60-l45HA coupled to a KRC2 ed05 controller, running CAMROB 2.3. We have a rotary table, a laser tool setter as well as a tool changer with rack. All cell components work fine and are set up correctly. This cell was bought by the university of California San Diego campus for one of their student projects. I have it working fine using RoboDK and fusion 360 using 3 axis methods but would like to be able to do full 5 axis or at least properly aligning indexed toolpaths. The problem I am having that prevents me from doing this is there is some kind off offset programmed into the world coordinate system that makes it different than what the ROBROOT coordinate system should be. IE, when i jog the robot in world mode with dominant axis on, the numbers that the Cartesian coordinates display move in the x and Y when i jog just the Z. The same for if i jog the X the Y and Z chance. Same for the Y, X and Z change. I would expect the x and Y to stay the same if I have dominant axis on and I just jog the Z. Seams like there is some kind of calibration data or offsets in play that I am not aware of. Also if I look at the numbers, when I jog in any axis the machine does not jog in a straight line. Its jogs in a very large arc. Something like 2mm out of straight over 8'. It moves out then back in, as if it was going along a large radius instead of a straight line. Also when I pick up a TCP the robot shows a rather large TCP error (around 4-6MM) and when jogged in tool mode with the correct tool# selected it jogs about that much off center from the actual physical TCP I touched off from. Any ideas what is going on here? It seams like it is something intentionally done in the controller not a physical hardware issue. The robot runs really smooth and cuts accurately shaped parts when used in one orientation in a purely cartesian manner. If it was a physical hardware issue I would expect the #s to look correct but the robot to move incorrectly. In this case the robot does exactly what the #s say it is doing so far as I can tell. Thank you for reading this. I know its a lot to digest. I would greatly appreciate the help of a more knowledgeable person on this subject than myself.

I am jogging the robot using the spacemouse on our KCP2 but jogging with the keys has the same result. I am using base 0 $NULLFRAME. We have one external axis which is a rotary mounted to the floor. The robot itself is mounted to the floor. I have checked the MADA. $robroot is all zeros, as I believe it should be. Other than that I am not sure what to check. We have mastered the robot using our KTL mastering set. We check the master every few days. Its almost always checks out good. Only had to remaster a couple of times. Yes, this is an HA robot. I am not sure how to check if high accuracy is enabled though. Thank you for your response.

Fubini,

Thank you for your quick response! Yes, it appears that high accuracy is enabled. I will create a program that moves the robot along each axis and see if HA being turned off while I am jogging is what I am observing.

I very much appreciate your insight into this!

Fubini,

I just did a test. When I run a program that travels the machine linearly in Z then X, then Y. The Readouts in cartesian mode show the same difference I am seeing when I jog the robot manually. This makes me think there is something going on in the controller to cause the world coordinates or ROBROOT to be off. I made sure my reference frame in roboDK was not rotated or out of plane in any way. The problem is definitely on the robot side of the setup.

Ok, I believe I understand. The machine readouts being slightly out of plane is normal on an HA robot due to the difference between travel move accuracy and jog move accuracy. Can live with that if I know its normal. Now, any idea why my TCP is offset from the physical TCP that I pick up. I'm not certain of it but it appears to be offset only in the Z in relation to the flange. As if the spindle flange is a little taller than it actually is. Is there a way that it could have an offset in the Z in relation to the flange, that adds to the TCP when I pick it up, making it offset from the physical TCP I have picked up? See the following video to see what I am talking about. https://drive.google.com/open?id=1Bu_5N…xVwei5ZyyfllcLf

I figured it out. The z offset was wrong in the tool definition I was using. I was trusting that the robot model they sent me was correct. It was not. I used a height gauge and a granite set up plate to get the correct offset. It now rotates on the TCP as I expect it to.