Mastering homemade external axis with a KR150 KUKA motor

    Hello:


    I have a question about mastering a homemade external axis with a KUKA motor.


    Robot type: KR150 L150
    Software Version: KR C V4.1.6 SP 3
    Control cabinet: KR C2


    Our goal is to mathematically couple the external axis and the robot. We've built a 1-axis positioner external axis. We took a motor for an A2 axis off of a KR150 L 150 and are using it for the motor of the external and then built our own mechanics around it (photo attached). For mastering, we have not installed any mechanical zero or consistent home position: we simply go under Setup > Master > Dial > External Axis 1 > *move the external axis a little in the negative direction* > softkey "Master". So, every time that we master the external axis, it has a different home position then it had the last time it was mastered.


    I think it's because of this process that we're getting a huge error (around 700 mm) every time we try to do a Root Point calibration. To bypass this, we've just been calibrating with "Root Point (numeric)" by placing the TCP of a calibrated reference tool at the Root Frame of the external axis and displaying TCP position with the $POS_ACT variable, but I've read that that's not very accurate. Our programs are not running per the simulation supplied by offline programming (Rhino and KUKA|prc), and I think it's because we're not mastering the external correctly.


    So, I'm wondering what to do next on creating a home position for the external. Since it's an A2 motor, does that mean the home position can't just be anywhere (i.e., does it have to be the same as the home position of the robot A2 axis relative to the motor)? Since, it's a KUKA motor, is it better to remove a mastering gauge cartridge from a stock robot and then install that onto our external axis, so that it can be mastered with an EMT tool?


    Please let me know thoughts, thank you.

    Mastering the positioner axis that way should work perfectly well, until you have to master it again. At that point, any difference between the new and previous masterings will feed directly into your position error.


    Did you carry out the kinematic integration of the positioner as detailed in the KUKA manuals?

    ideally you would install mastering cartridge so E1 can be mastered with EMT
    but at the very least for Dial mastering, i would scribe a mark on the edge of turntable.

    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

    Yes, as Panic says -- for an external axis like this, Mastering is less about accuracy than it is about consistency. Even if your first Mastering is 10deg off what it 'officially' should be, once you set up your kinematic integration and your jig fixture on the positioner, the most important thing is to keep Mastering that axis the same way every time.


    Of course, it's best to ensure it's right the first time, but you don't need micron-level accuracy here -- repeatability is much more important.


    Another thought occurs to me -- did you set up the $RAT_MOT_AX value correctly? That's a definite prerequisite to carrying out any kinematic calibration -- you have to set that to tell the robot the relationship between motor rotation and positioner rotation. If the positioner rotate 20deg when the robot only thinks its moving 10deg, you'll never get accurate motion.


    Also: https://www.robot-forum.com/ro…manual/msg52775/#msg52775

    Edited once, last by SkyeFire ().

    SkyeFire : so even if I unmaster and remaster all axes (robot and E1) and not just E1, that difference between new and previous masterings for E1 will feed into the position error? If that's what you're saying, that is fantastic news.
    And yes, I am 99.9% confident that kinematic integration has been carried out successfully (per the KUKA manuals, this forum, KUKA tech service, and the robotsinarchitecture.org forum)


    panic mode: okay good, last night I left a message with KUKA asking for a quote on a replacement mastering gauge cartridge and notch. I've seen in past forums that it's not too expensive. Tried to mine the mastering notch out of one of our stock robots to no avail..

    Quote from jschmidt


    SkyeFire : ah, hold on. I'll check $RAT_MOT_AX again and get back to you. That variable setting was the work of another employee.


    Well, you'll need to test it empirically, since whatever custom mechanicals you added between the motor and the table will be part of the ratio. So you'll need to set up a way to accurately measure the actual rotation of the table, and compare that to what the robot reports the rotation being. So, if you set up marks 90deg apart on the table, set the table at one mark, and command something like PTP_REL {E1 90} on the robot, if $RAT_MOT_AX is correct, the table should match the second mark. If they don't match up, then you'll need to iteratively adjust $RAT_MOT_AX until they do.

    SkyeFire : thank you for this explanation! I just tested out the $RAT_MOT_AX through your process and the table only turned about 15 degrees.
    Looks like I'll need to iteratively adjust the variable like you said. Unfortunately I'll be out of office for the next 5 days, but when I get back and correctly adjust it, I'll report back.
    Thank you again for your help!

    SkyeFire @panicmode


    Okay, I sort of have an update here.
    Everything seems to be working correctly, but I'm not sure how.
    I didn't add a mastering gauge to the table or change the process of how we are mastering it.


    I've attached an image of the robot milling the (also attached) .src program with the external kinematic system.
    Offline programming: Rhino3D (CAD) and KUKA|prc, the plugin for grasshopper (CAM)


    This started working about a month ago when a software developer from Octopuz came to prove out the Octopuz CAM software on our robot. Long story short, Octopuz got their software to run a program accurately on our robot/table set up, and then they left, and I ran the attached program (octopuz.src) on the robot without changing anything in it, and it suddenly worked. It hadn't worked before Octopuz came.


    The Octopuz employee said it was a matter of changing from "dynamic frames", and that the problem was that the Root Point frame on the table and the $TOOL frame on the robot flange were following the same angle, and he changed it so that they were following separate angles.


    So far, I've found this post (https://www.robot-forum.com/ro…orum/external-axis-types/) to be sort of helpful, but I still dont understand exactly how to separate the frame of the robot flange and the frame of the table flange, or really what that means.


    I've procrastinated posting an update on here because I don't really understand why the problem is solved.
    So, any insight as to what this fix entails is greatly appreciated! Thank you!

Advertising from our partners