TCP speed in conjunction with positioner speed

    Hi!

    Robot: KUKA KR 200 L140-2

    Controller: KRC2 (ED05)

    Servo motor: KK55Y-YYYY-030

    Servo drive: KSD32A


    I have a robot setup consisting of a stationary KUKA robot equipped with a 3D printer end effector. Normally we print on a fixed table, but we also want to be able to print on an external rotation axis. We made our own positioner with a single KUKA servo motor and the corresponding servo drive is mounted in the controller.

    A problem we encountered is the communication between the robot and the positioner. The robot must work simultaneously with the positioner, which means the TCP speed must be adjusted to the speed of the positioner. Is there already a variable that considers both the speed of the TCP in conjunction with the speed of the positioner, or does a custom variable have to be created?

  • Micka March 14, 2022 at 10:57 AM

    Changed the title of the thread from “3D printing on external rotation axis” to “TCP speed in conjunction with positioner speed”.

    Read about EK-Command and EX_BASE in this forum. It allows you to activate geomtric coupling between external kinematic and robot, see e.g.

    Post

    External axis DKP 400.1 syntax for src to activate $Base =EK(MACHINE DEF........

    Does anyone know this syntax works also for DKP 400.1 , 2 rotary axis?

    It seems to not accept EK variant from only one axis table as below:

    DEF EX_BASE(BASE_NO :IN,MACH_IDX :IN)

    INT BASE_NO , MACH_IDX

    MY_FRAME = BASE_DATA[BASE_NO]:{x 0.0,y 0.0, z 0.0, a 0.0, b 0.0, c 0.0}

    $BASE=EK(MACHINE_DEF[MACH_IDX].ROOT, MACHINE_DEF[MACH_IDX].MECH_TYPE,BASE_DATA[BASE_NO]:{x 0.0,y 0.0, z 0.0, a 0.0, b 0.0, c 0.0})

    $ACT_BASE=BASE_NO

    END



    Thank you
    robot-cnc
    January 17, 2022 at 12:17 PM

    You need at least a base measured in on the external kinematic and where the external kinematic root is in relation robot base. Also your external drive needs to be configured as an external kinematic in R1/ $machine.dat, see e.g.

    Post

    Re: 2 external axis+ceiling robot

    Hi,

    the transformation chain for any external kinematic is (see R1/$machine.dat)

    $ETn_TA1KR(Ex1) : $ET1_TA2A1(Ex2) : $ETn_TA2A1(Ex3) : ETn_TFLA3, n = 1,..., 6 (n = number of the external kinematic),

    where always the "z-axis" inside these coordinate systems is the axis of revolution/translation according to the axis type (linear/rotational, see $AXIS_TYPE).

    Which axes Ex1, Ex2, Ex3 are used inside which external kinematic is defined by $ETn_AX, n = 1,..., 6 (n = number of the external kinematic).…
    Fubini
    June 18, 2016 at 12:44 PM


    Fubini

    Last month I have been looking into the whole KUKA system and corresponding manuals as I was not familiar with KUKA.
    Now I think I understand your reply Fubini.

    The positioner is properly loaded in both the robot & our CAM software and calibrated to operate. This was done by another person. It has been used before, but at that time it was only used by rotating the turntable at a fixed set speed.
    At that time the function

    $BASE = BASE_DATA[17]

    was used. If I understand correctly I should use the following function to replace it;

    $BASE = EK (MACHINE_DEF[MACH_IDX].ROOT, MACHINE_DEF[MACH_IDX].MECH_TYPE, BASE_DATA[BASE_NO]:{x 0.0,y 0.0, z 0.0, a 0.0, b 0.0, c 0.0})

    Since the positioner is already calibrated, this will activate the mathemetical coupling, correct?

    The turntable setup was successful and the external axis now moves simultaneously with the robot as it is mathematically coupled, but I encountered a new problem during operation.

    The extruder of the 3D printer does not get a signal to output filament as soon as the turntable moves but the TCP doesn't ($VEL_ACT=0). See code below.

    Code
    ANOUT ON AO_EXTRUDER_V = 3.001 * $VEL_ACT+0.0 DELAY=-0.2

    I figured that to fix this problem, the $VEL_ACT has to be replaced by a variable that includes the following:

    • TCP velocity ($VEL_ACT)
    • Turntable (angular) velocity (?)
    • Turntable root point (BASE_DATA[17])
    • TCP to root point distance (?)

    The extrusion speed has to be calculated as more material has to be extruded depending on the turntable (angular) velocity and TCP to turntable root distance.

    I’ve looked in multiple files and other places such as forums and manuals but I wasn’t able to find any variables that I want to have.

    What is the best way to do this? And where can I find/read/monitor the required variables?

    Any help would be greatly appreciated! :smiling_face:

    Hm... I haven't tried using ANOUT ON with an external kinematic, but from what I recall, $VEL_ACT should be determined by the TCP velocity relative to the active $BASE. So, if the external kinematic is active and your TCP is moving exactly with the rotary table[1], you probably will get 0 (+/- noise) from $VEL_ACT.

    If the external kinematic is active, and the TCP is moving relative to it[2], then you should be getting a usable value on $VEL_ACT and, by extension, to the ANOUT.

    This is how KUKA handles feedrate control on their multi-axis arc welding systems, as far as I know, so it should work for what you're doing.

    [1] If the TCP is staying "stuck" to a single spot on the positioner while the positioner rotates, as in this video:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    In this video, $VEL_ACT should be 0, because while the TCP is moving relative to $WORLD, it is not moving relative to the rotary table, which in this case is the active external kinematic. Basically, in a properly tuned external kinematic, you don't need to program anything for the turntable speed or position, b/c the robot handles all that inherently.

    [2] If the TCP is moving across the positioner surface while the positioner is stationary or moving.

    I just ran the same program in which the turntable rotates and the TCP is stationary/not moving. This time I monitored the value of $VEL_ACT.

    It indeed seems that the $VEL_ACT is calculated relative to $WORLD instead of $BASE, because $VEL_ACT is 0 (+/- noise), which leads to the conclusion that the turntable is not kinematically set correctly.

    In my code I have filled in the $BASE EK syntax from Fubini (see below), but I guess this is not enough to activate the external kinematic?

    Code
    $BASE = EK (MACHINE_DEF[2].ROOT, MACHINE_DEF[2].MECH_TYPE, BASE_DATA[17])

    MACH_IDX = 2 (EASYS)

    BASE_NO = 17 (Turntable root point/coordinates of offest base)

    As Fubini said:

    Quote from Fubini

    Ek activates a moving base attached to a external kinematic. Without Ek its only a static base.

    Besides this EK function within $BASE, I went through every step of the kinematic system procedure within the KUKA External Axes manual (7.1.4 Starting up a kinematic system with KUKA motor).

    What caught my attention is that I found the following in the kuka external axes manual:

    Quote from KUKA External Axis

    9.2.1 Programming a mathematically coupled motion
    Precondition

    Program is selected.
    Operating mode T1 or T2
    Root point of the kinematic system has been calibrated.
    Procedure

    1. Program the motion with an inline form.
    2. To activate mathematical coupling, select the offset base in the option window Frames as the base to which the robot motion is relative.

    It refers to "Frames", something I looked up but couldn't find. Could this possibly be the culprit of why the external kinematics are not active? Or is it possibly something else that I've overlooked?

    This "Frames" refers to a gui submenu if you use inline forms to program your motion instruction. If you open a inline form you should see a tab "Frames".

    Do you use inline forms at all? If not you need to activate external base as described previously. If yes you do not need to call EK manually but only need to select the correct base on the frames tab. Then the system does implicitly call EK for you using the bas.src.

    Fubini

    I do not use inline forms. I accidentally overlooked that, so that won't be a solution.

    As you said:

    Quote from Fubini

    Do you use inline forms at all? If not you need to activate external base as described previously.

    I went back to your first reply and re-checked everything.

    1. The turntable is measured (BASE_DATA[17]) and mastered
    2. All ET1 data is loaded in the axisconfigurator and R1/machine.dat
    3. BASE EK command is in .src code

    What I think the current problem is, is the calibration between the robot and the external kinematic base. As said before, it indeed seems that the $VEL_ACT is calculated relative to $WORLD instead of $BASE, because $VEL_ACT is 0 (+/- noise), which leads to the conclusion that the turntable is not kinematically set correctly.

    Did I miss something? I included the .src code below in case anyone wants to have a look. To generate this code we use CAMRob.

    Hm... $VEL_C.CP might be worth a shot, just to see if it makes any difference, but it shouldn't.

    Does your robot and positioner move together the way the one in the video does? You should be able to place the TCP touching a point on the positioner, and when jogging the positioner (in WORLD or BASE modes, not AXIS) the TCP should follow the positioner exactly. If you had a pen in the tool touching the positioner, you should only get a dot (or a very small blob). That's the acid test for the proper kinematic setup of an external axis.

    The robot and positioner do not move together as in the video. This is quite likely because the EK command only is called within the program .src code, but not global. This means that when the robot is jogged, it does not use or call the EK command.

    The only other problem I can think of is the lack of transformation. As I said before, all defined data was set up by another person. This includes everything within the axisconfigurator. As can be seen in the screenshot below, the only defined translation is $ET1_TPINFL.X = -500.0. This indicates the reference marking.

    Is the EK command necessary to be able to move like the setup in the video?

    Do I need to implement the EK command in machine.dat or config.dat?

    Is defining the transformation necessary?

    Why is

    BASE_DATA[17]={X 920.96698,Y -1698.5,Z 710.0,A 0.224999994,B 0.282000005,C 0.108999997}

    identical to the ROOT Offset

    MACHINE_DEF[2].ROOT = {X 920.966919,Y -1698.5,Z 708.146423,A 0.224600002,B 0.282000005,C 0.109399997}

    Thats a bit odd. If BASE_DATE[17] is located exactly in the middle of the external axis flange it should be $NULLFRAME.

    Fubini

    Good question. BASE_DATE[17] is indeed located exactly in the middle, so I have replaced BASE_DATA[17] with $NULLFRAME.

    I tested jogging and running a program, but still not the result I want.

    What was quite noticable, is that the robot seemed to start moving towards the ROBROOT. I stopped the program early as it did not make the programmed movements and to avoid any collisions.

    Just to be sure, I did an offset base calibration to re-measure BASE_DATA[17]. I got the following value:

    BASE_DATA[17]={X -0.259,Y -1.1475,Z -0.102,A -2.5185,B 0.0846,C -0.0873}

    All these values are quite close to 0, just like with $NULLFRAME.

    Still same result as message above though.

Advertising from our partners