Problem with calibrating tool

    Hi.
    KRC 4
    KR360R2830 C4 FLR

    I have a big problem with calibrating a new tool and finding TCP. I've tried a two methods (Numeric input and XYZ 4-point method) and none of them gave a good results.
    First when I try XYZ 4-point method, I choose a points with different angles greater than 10deg on all rotations, but KUKA gave me a error 30mm. When I try with smaller and smaller angles the error began to decline. At the end I came to error of 0.4mm but the angles of rotations being on the edge of difference(very very small). After finding the TCP I use ABC 2-point method for defining the orientation. When I finish all procedures I've tried to rotate the TCP but the results are very bad. When I rotate A of the tool the error was 24mm for rotation of 180deg, for other rotations error was approximately the same.

    Second method I've used was Numeric input. I enter All values for offsets, mass, moment of inertia from CAD. And then when I try to rotate A, I see almost none error, but when I rotate B error was aprox. 20mm for 180deg, for C is worse. Also it seems they rotate around different points.

    Before all I've master all axes with dial gauge.
    Robot
    KRC 4
    KR360R2830 C4 FLR

    Firstly, you say you mastered all axis using ‘dial gauge’ is this the EMD or an actual dial gauge. If you are using a manual dial gauge, are you sure you mastered in the bottom of the ‘v’ and not at the bottom of the leading or falling edge?

    Secondly, do you have an external axis (like robot sat on a liner track) which may not be set-up correctly in the project (robot base coordinates wrong)?

    Thirdly, are you using the correct robot in your project (using correct machine data)? If your actual robot has a 'reach' modification but machine data doesn't match, this would cause similar errors. (Robot flange coordinates wrong).

    If you jog the robot flange can you orientate around the centre of the flange or does that wander off?

    Edited once, last by Mr.E (July 4, 2017 at 10:37 AM).

    I've used manual dial gauge. For Axes 1,2,3 i can see that I'm in the 'v', for other axes first I've made bigger rotations back and forth to be sure that I'm in the 'v'.
    Also after measurements, I made second mastering on all Axes and when I check in the mastering Log file results of first and the second mastering has been very similar.

    For second question. No has not External Axes.

    Quote

    I've tried to rotate the TCP but the results are very bad.

    How did you rotate? Jogging mode or program? Is your robot equipped with an absolute accuracy package? In cartesian jogging mode absolute accuracy is deactivated leading to a rotational drift.

    What mastering mode did you use? Reference or Dial? If you master inside the "v" in robots with mam-File ($MAMES_ACT[] != $MAMES[]) you need to use reference as mastering mode.

    Fubini

    Edited once, last by Fubini (July 4, 2017 at 11:35 AM).

    I try rotation with Jogging and also with program, results are almost the same. Robot is equipped with an absolute accuracy package.
    And I had used Dial mastering mode.
    I don't understand why I need to use Reference mode.

    $MAMES_ACT[]={A1 0.124672,A2 -89.9957733,A3 89.9865265,A4 0.00705800,A5 -0.0454720,A6 -0.0163620}

    Quote

    I don't understand why I need to use Reference mode.

    Sorry I think you are right. I mixed it up. Long time ago the mastering notches where exactly placed by a worker at $MAMES during production at Kuka. Nowadays this is done only approximatly by the worker and the exact position of the mastering notch is determined by a mathematical identification method afterwards. Hence the actual notch position ($MAMES_ACT) is calculated from measured values. Therefore during mastering at exactly the notch $MAMES_ACT is the mastering position and is set as this by "Dial mastering mode". "Reference mastering mode" still sets as in the past $MAMES as mastering position. This is useful if you demaster a previously mastered robot. In this case you can make a "PTP $MAMES[]" unmaster the robot and set mastering again. Useful especially in case of endless rotational axes to get rid of the revolution count.

    So in short: Dial Mastering sets $MAMES_ACT and reference mastering sets $MAMES as the current position.

    Fubini

    Any robot with Absolute Accuracy needs to have the First Mastering (No Load) performed, then the Tech Mastering With Load performed, in sequence, and the associated LOAD_DATA values must be correct, or else AA is useless.
    Still, AA will not result in a 30mm error while performing the 4pt Tool calibration. Do you have a minimum 45deg separation between each of the four points?
    If you jog the robot to axes 0,-90,90,0,0,0, does the robot make an inverted L shape?
    For such large TCP errors, poor mastering is most often the cause. Incorrect motor parameters can also cause this, but it would be hard for this to happen unless someone has been tampering with the system configuration files.

    In order to set tools, robot must use correct MADA and be calibrated correctly. If this is done it is easily checked by moving robot known distances and verifying with measure tape.


    When measuring TCP using 4point method, change flange orientation sufficiently. I try to make each approach at least 30deg different.
    As soon as this is done you can check TCP... Select ANY Cartesian coordinate system (world is fine), and jog using A, B and C. Robot should move about TCP.


    If above cannot be achieved start at begin and make sure every step is done correctly including correct MADA, calibration, choosing reference point that does not move or flex, tool that does not move or flex, make due to use SAME tool point each time (mark it if needed).


    Once above is ok do tool orientation.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from SkyeFire


    Any robot with Absolute Accuracy needs to have the First Mastering (No Load) performed, then the Tech Mastering With Load performed, in sequence, and the associated LOAD_DATA values must be correct, or else AA is useless.
    Still, AA will not result in a 30mm error while performing the 4pt Tool calibration. Do you have a minimum 45deg separation between each of the four points?
    If you jog the robot to axes 0,-90,90,0,0,0, does the robot make an inverted L shape?
    For such large TCP errors, poor mastering is most often the cause. Incorrect motor parameters can also cause this, but it would be hard for this to happen unless someone has been tampering with the system configuration files.

    First Mastering is performed with no Load, after that is performed Teach Mastering With Load(That is performed from the previous operator who operate the robot).
    I try to calibrate with 45deg separation between points but Kuka could not calculate, and error was astronomical.
    If I Jog the robot to 0,-90,90,0,0,0 he is like an inverted L.

    Mastery log file

    Date: JUN 05 2017 Time: 11:03:55 Axis 1 First Mastering by Gauge (FirstEncoderValue: 52.793428)
    Date: JUN 08 2017 Time: 15:46:23 Axis 1 First Mastering by Gauge (FirstEncoderValue: 54.628143)
    Date: JUN 08 2017 Time: 15:51:20 Axis 2 First Mastering by Gauge (FirstEncoderValue: 6.757965)
    Date: JUN 08 2017 Time: 16:02:45 Axis 3 First Mastering by Gauge (FirstEncoderValue: 42.591250)
    Date: JUN 08 2017 Time: 16:14:25 Axis 4 First Mastering by Gauge (FirstEncoderValue: 40.285490)
    Date: JUN 08 2017 Time: 16:34:55 Axis 5 First Mastering by Gauge (FirstEncoderValue: 61.347434)
    Date: JUN 08 2017 Time: 16:42:41 Axis 6 First Mastering by Gauge (FirstEncoderValue: 67.117148)
    Date: JUN 29 2017 Time: 14:10:26 Axis 1 First Mastering by Gauge (FirstEncoderValue: 53.334502)
    Date: JUN 29 2017 Time: 14:38:57 Axis 1 First Mastering by Gauge (FirstEncoderValue: 53.334502)
    Date: JUN 29 2017 Time: 14:42:32 Axis 1 First Mastering by Gauge (FirstEncoderValue: 56.810303)
    Date: JUN 29 2017 Time: 14:49:57 Axis 1 First Mastering by Gauge (FirstEncoderValue: 52.890929)
    Date: JUN 29 2017 Time: 15:19:34 Axis 1 First Mastering by Gauge (FirstEncoderValue: 53.432006)
    Date: JUN 29 2017 Time: 15:26:57 Axis 2 First Mastering by Gauge (FirstEncoderValue: 7.529755)
    Date: JUN 29 2017 Time: 15:35:25 Axis 3 First Mastering by Gauge (FirstEncoderValue: 43.677520)
    Date: JUN 29 2017 Time: 15:41:19 Axis 4 First Mastering by Gauge (FirstEncoderValue: 34.495696)
    Date: JUN 29 2017 Time: 15:49:27 Axis 5 First Mastering by Gauge (FirstEncoderValue: 61.679743)
    Date: JUN 29 2017 Time: 16:04:22 Axis 6 First Mastering by Gauge (FirstEncoderValue: 69.933767)

    Quote from SkyeFire


    Well, that looks okay. I would check $TRAFONAME[] against the robot's data plate.

    If you activate Tool 0 and Base 0, and jog the robot linearly, does it follow a straight line over long distances? Are the axes parallel to the $ROBROOT axes?

    When I move robot in Tool 0 and Base 0 with jog, robot is following straight line on all axes but problem is in 'x' and 'y' axes on the robot. It seems they are not orthogonal. I try one experiment with granite etalon.
    Etalon has a straight angle on it. On the flange i mount dial gauge. If I move the flange back and forth in 'x' direction and rotate the etalon while error on the dial gauge fall under 0.1 mm and then if I move the flange in 'y' direction i see big error on dial gauge.
    On the picture Dial is on the z plain. When I move 'x' Dial is on 'y' plain.
    Also if I calibrate for 'y' I see the same error when I move 'x'.

    That... sounds like one axis (or more) might have a bad $RAT_MOT_AX ratio. That's hard to diagnose remotely, though.

    Once you align the etalon to the robot X axis, what is the error/travel ratio on the Y axis?

    When you do that test, where is the etalon located, relative to the robot? I would suggest performing this test with the etalon located at two different locations: one in front of the robot (etalon located near Y=0), and once to one side of the robot (X=0). This might help us narrow down which axis is the issue.

    If you have a way to measure how far an axis rotates, I would suggest going through each axis, one at a time, jog it 90deg (on the teach pendant display), and measure the actual physical rotation of the axis.

    Quote from SkyeFire

    When you do that test, where is the etalon located, relative to the robot? I would suggest performing this test with the etalon located at two different locations: one in front of the robot (etalon located near Y=0), and once to one side of the robot (X=0). This might help us narrow down which axis is the issue.

    If you have a way to measure how far an axis rotates, I would suggest going through each axis, one at a time, jog it 90deg (on the teach pendant display), and measure the actual physical rotation of the axis.

    I've already tried this with laser tracker, not on the etalon. When I measure near 'Y=0' and define coordinate system on the laser with 'x-z' plane on the robot. If I Jog only in 'X' or 'Z' direction i see no shifts(error) on other axes, but when I Jog in positive 'Y' direction shift on 'X' is very big(y=0 to 300mm, x=0 to 2,5mm) shift on 'Z' was very small (0.2mm i think).
    After that I rotate only A1 axis for 90deg. Now I see no errors when I move 'Y' or 'Z', but when I Jog 'X' positive 300mm, shift on 'Y' was exactly the same 2.5mm(but on different axis).

    What was the laser tracker using as a frame of reference, and how was it aligned to that frame?

    Does the laser tracker data show that the three axes of motion are not mutually orthogonal?

    Your results indicate that the $ROBROOT XY plane is correct, but something is causing a single-axis error, or there is an issue with the A rotation. Based on this, the first thing I would check is the Mastering of A1 -- that's the easiest place for this error to creep in. There's also a possibility that A1's $RAT_MOT_AX could be wrong, or that $MAMES could be wrong. But either of those would be very unlikely, unless someone has been tampering with the config files.

    What is this robot's history? What's been done to it since it left the factory, and who's been making changes to it?

Advertising from our partners