1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. KUKA Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

Mastering homemade external axis with a KR150 KUKA motor

  • jschmidt
  • May 8, 2018 at 4:50 PM
  • Thread is Resolved
  • jschmidt
    Trophies
    3
    Posts
    32
    • May 8, 2018 at 4:50 PM
    • #1

    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.

    Images

    • IMG-5662.JPG
      • 982 kB
      • 2,448 × 3,060
      • 105

    Files

    IMG-5662.JPG_thumb 33.5 kB – 277 Downloads

    Edited once, last by jschmidt (May 8, 2018 at 4:55 PM).

  • SkyeFire
    Reactions Received
    1,061
    Trophies
    12
    Posts
    9,465
    • May 9, 2018 at 2:59 PM
    • #2

    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?

  • panic mode
    Reactions Received
    1,300
    Trophies
    11
    Posts
    13,143
    • May 9, 2018 at 3:02 PM
    • #3

    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

  • SkyeFire
    Reactions Received
    1,061
    Trophies
    12
    Posts
    9,465
    • May 9, 2018 at 3:13 PM
    • #4

    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/robotforum/man…52775/#msg52775

    Edited once, last by SkyeFire (May 9, 2018 at 3:15 PM).

  • jschmidt
    Trophies
    3
    Posts
    32
    • May 9, 2018 at 3:20 PM
    • #5

    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..

  • jschmidt
    Trophies
    3
    Posts
    32
    • May 9, 2018 at 3:34 PM
    • #6

    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.

    Edited once, last by jschmidt (May 9, 2018 at 4:02 PM).

  • SkyeFire
    Reactions Received
    1,061
    Trophies
    12
    Posts
    9,465
    • May 9, 2018 at 4:30 PM
    • #7
    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.

  • jschmidt
    Trophies
    3
    Posts
    32
    • May 9, 2018 at 5:54 PM
    • #8

    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!

  • jschmidt
    Trophies
    3
    Posts
    32
    • June 26, 2018 at 12:33 AM
    • #9

    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/robotforum/kuk…nal-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!

    Images

    • IMG-6007.JPG
      • 1.52 MB
      • 3,264 × 2,448
      • 70

    Files

    octopuz.src 25.86 kB – 25 Downloads IMG-6007.JPG_thumb 30.63 kB – 247 Downloads

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • krc5
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • krc5
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download