Nonsensical TCP behavior

Hm... no obvious smoking gun, but that Z motion is definitely odd. Do you get similar effects rotating around the tool X and Y axes? Just to eliminate one possible source of error, try making this test move into a program, instead of jogging the robot. Run the test with the tool rotated 90deg around the spindle (X?) axis, and see how that rotation change affects the anomalous motion. Also, try the test at different locations -- say, once directly in front of the robot (on $WORLD.X), then again 90deg off on the $WORLD.Y axis. See how the test results change in each location.

$LOAD is set correctly when you run this test, right?

Can the robot move that pointer linearly along some test reference lines? Isolating motion error along $WORLD X, Y, and Z might help narrow down any potential axis issues.

Getting different runout at different parts of the robot's motion envelope is pretty normal, given robot kinematics. However, any Mastering error will amplify such effects drastically. What we want to look for is systematic error -- error that changes in a consistent way based on the TCP's position in the motion envelope, or for certain TCP orientations.

Is your robot absolute accurate? Then it's essential to set all load including additional loads data precisely. Also you would have to consider that in jogging absolute accuracy is deactivated. Did you check using a program or jogging?

Fubini

Do you have some transform like external axis?

Depends on setup... it could do what you are seeing.

Btw your problem description is not detailed enough. If you ask 5 people with same robot to read your post and try to recreate situation, there could be 5 different solutions...

Get robot mastered properly

Then remeasure tool. Make sure to use sufficiently different orientations (60-120 deg different from each other). This will get you first three coordinates (XYZ is TCP only). Then you also need to get tool orientation (ABC values)...

With both sets of data you get complete frame XYZABC.

May I ask a stupid question?

In wg´hich coordinate system did you actually move?

Quote from Wall-E

Would you say that it is feasible to master the robot with sufficient accuracy for milling with the dial gauge tool ?

Depends on your skills.

It's highly recommended to use an absolute accurate robot for your application.

Edit:

Inaccurate setting of A/B/C of the tool has no effect to the behavior your robot shows.

The used coordinate system has no effect to the behavior your robot shows, as long as you use the correct tool, and do only movements in A/B/C.

Actually for a non emt mastered robot without absolute accuracy I do not think your results are bad considering not modelled effects like backlash, torsion and other stuff. If I remember correctly Kuka usually talks of positional accuracy for non absolute accuracy robots of something in the range of 0.25. Of course this is not over the whole work envelope but only inside a special area in front of the robot of a specified size according to the relevant norms. And of course always with specific norm specified load and emt mastered.

your tool is long and TCP seem to be good 500mm away from flange. getting 0.45mm error at this distance is very good. this would suggest that mastering is also good. without actually seeing what you do (and how) there is no way to tell with certainty what the problem is. are you sure this is not just coincidence for example you are just leaning on space mouse? basic KUKA training would likely do wonders here.

yes, it is accessed through "Conversation" icon in upper right corner but do not contact me - i am not interested in becoming private tutor.. see point 2 in signature at the bottom of my posts.

Well, at this distance, I can only make some generic suggestions. If we assume that the robot is Mastered correctly, it's possible to "tweak" in the TCP iteratively, rather than using the 4-point method. That said, given basic robot backlash, a TCP that is hyper-fine-tuned at one pose is liable to be much less fine-tuned at another pose. Basically, we're always just trying to get the center of the spread to the location we want.

This process can also be used to test the TCP at different poses.

The process is similar metaphorically to truing up a workpiece in a lathe 4-jaw chuck. If your pointer is a good cylinder, coaxial with the spindle axis (and near-0 runout in the cylinder and spindle), then you can mount a dial indicator somewhere, press the side of the cylinder against the indicator, then rotate the robot around the TCP spindle axis (you're using X, I think?) 90deg, and see how the dial indicator moves. Then tweak the values of the TCP along its own Z axis, re-run the test, and lather rinse repeat until the runout is minimized.

Then rotate the entire test by 90deg and repeat for the TCP Y axis.

Going more advanced, this process can be done for the X axis as well, if you swap your pointer for a "lollipop" -- basically, a sphere (on a narrow shaft) mounted in the spindle such that the center of the sphere is where you want your TCP to be. Rotate the sphere against the dial indicator, one TCP axis at a time, until runout in minimized.

That'll work for the TCP position. After that, you'll need to do a similar process running the cylinder longitudinally along the dial indicator while tweaking in the ABC values. For your setup, the rotation around the spindle axis is irrelevant, so you can get by with fine-tuning the other two TCP axes to be perfectly orthogonal to the spindle axis.

One thing I found, doing this, is that if I repeated the process, tuning in the 2nd or 3rd axis would throw the 1st axis back off. I usually had to do repeated iterations and just spread the average runout as thinly as possible

You mentioned a laser tracker? That can speed up the process over using a dial indicator.

The trick is to tweak the TCP in its own reference frame. What I mean is, if you see a 0.1mm error in your TCP's Y axis, then do something like:

$TOOL = $TOOL : {X 0,Y 0.1,Z 0,A 0,B 0, C 0}

This shifts the TCP along it's own Y axis by 0.1mm. It might need to be -0.1 depending on which direction the error is. Ideally, instead of doing this by hand, you would write a program to semi-automate the process.