TCP speed in conjunction with positioner speed

    The value of MACHINE_DEF[2].ROOT = {X 920.966919,Y -1698.5,Z 708.146423,A 0.224600002,B 0.282000005,C 0.109399997} is roughly correct as well?


    If you set the robot to home A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0 deg and position yourself so that you look at the robot flange. If now you set a static base to $NULLFRAME the BASE.X+ should point at you, BASE.Y+ should point to the right an BASE.z+ upwards (can be checked by jogging in the current base system). In this coordinate system is the external kinematic approximately located at X 920.966919,Y -1698.5,Z 708.146423 measured from the middle of the robots base structure?


    Fubini

    MACHINE_DEF[2].ROOT is correct. I did as you said, and the coordinates {X 920.966919,Y -1698.5,Z 708.146423,A 0.224600002,B 0.282000005,C 0.109399997} are at the middle/root point of the external axis.


    Within the $BASE function all variables are correct.

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

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


    MACHINE_DEF[2].MECH_TYPE = #EASYS


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


    Because all variables seem to be correct, it is most likely that the function is not being called/mentioned properly, as it still doesn't use the external axis as (external kinematic) base.

    Edited once, last by Micka ().

    Just to be sure:


    Not setting external moving base now only refers to selection on the HMI Base drop-down list or does it also not work correctly when activating the external moving base when you directly call it from a program using EK?


    Fubini

    Jogging the robot to the root point of the turntable and setting different bases through Configure -> Set tool/base:


    Whenever a static base (Base no. 10) is set and cartesian coordinates are monitored, then these coordinates are approximately the same as MACHINE_DEF[2].ROOT = {X 920.966919,Y -1698.5,Z 708.146423,A 0.224600002,B 0.282000005,C 0.109399997}.

    When the turntable base (Base no. 17) is set, the cartesian coordinates (XYZ) are approximately 0.


    The program calls the $BASE with the EK function

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

    But using this function of $BASE seems to not work correctly, as $VEL_ACT is 0 while TCP is stationairy and turntable is rotating.

    $VEL_ACT of 0 is totaly normal since it is the process speed. As $POS_ACT is always the current TCP in relation to the current $BASE $VEL_ACT denotes the current speed of the TCP in reference to the $BASE system. If the robot as no own movement therefore $VEL_ACT will always be 0. If you need the speed of the external axis use $VEL_AXIS_ACT[7].


    Fubini

    Alright, so I tested multiple different configurations to maybe find a solution.


    If MACHINE_DEF[2].ROOT is the same as BASE_DATA[17] and vice versa, robot program will start at the desired point in space. If either have different values, robot goes to an unwanted point in space.


    In addition, Fubini also mentioned (in the quote below) that the Offset in the syntax of the $BASE EK function is optional. When I removed this value, and nothing changed in the robot's movement. I will therefore omit the Offset as this may cause some (unnecessary) confusion.


    To test/prove if the extruder function works, I changed $VEL_ACT with $VEL_AXIS_ACT[7].

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

ANOUT ON AO_EXTRUDER_V = 3.001 * $VEL_AXIS_ACT[7]+0.0 DELAY=-0.2

    $VEL_ACT = 0, but $VEL_AXIS_ACT[7] has a (relatively low) fluctuating value thus causing a low extruder speed but not the correct and desired extrusion speed.

    To get the desired extrusion speed I was thinking about creating a custom variable which implements multiple other variables to calculate the extrusion speed:

    • $VEL_ACT (The velocity of the TCP)
    • $BASE (The root point of the external kinematic system)
    • $POS_ACT (The distance of the current TCP in relation to $BASE)
    • $VEL_AXIS_ACT[7] (The velocity of the external axis)


    By the way, what I found a bit confusing is that you and SkyeFire are contradicting each other about $VEL_ACT.

    Quote from Fubini

    If the robot as no own movement therefore $VEL_ACT will always be 0.

    Quote from SkyeFire

    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.

    Edited 2 times, last by Micka ().

    Quote from Micka

    $VEL_AXIS_ACT[7]

    is a percentage value and not the real velocity. To get the real velocity you need to calculate it using $VEL_AXIS_MA[] and RAT_MOT_AX [] from machine data.


    Post
    RE: External Axis (on Rotary Table) - Rotation Speed Control
    $Vel_axis_ma[] is the maximal motor velocity in rpm. If you have some sort of gearing as well you also have to consider $rat_mot_ax[,] which tells you the number of motor cycles per axis cycle. Finally if you also have some coupling $exax_coup[,] contains the coupling factors.

    https://www.roboterforum.de/ro…n/?postID=69566#post69566

    Fubini
    Fubini


    Fubini

    $VEL_AXIS _ACT is not going to get you what you need. For one thing, it's the rotational speed of the axis, not the speed of the TCP relative to the positioner table. So unless you hold the TCP exactly in place and only rotate E1, and correct for the TCP's distance from the E1 center of rotation, and convert from % to mm/s...


    $VEL_ACT should be reflecting the speed of the TCP relative to $BASE, regardless of any other factors. The only thing I can think of is that your kinematic integration is wrong. My best suggestion is to make a backup, then nuke the kinematic integration entirely and start over from step 1.

    Hi all,

    The problem has been found. The robot now follows the turntable when jogging using external axis and base mode. The same goes for when a program is running.


    The problem was the start type. A proper "Cold" start hasn't been done in a long time, as it was set on "Hybernate".

    90 Have You Tried Turning It Off and On Again? ideas | it crowd, british comedy, crowd


    Yet another problem surfaced. Whenever a program is set where TCP is static and turntable is rotating, the TCP stayed static on the $BASE system but not $WORLD system. This caused the robot to move with the turntable, even though that was not planned.

    This is most likely a CAM software fault, so i'll look into that.


    Thanks for all the help!

    Edited once, last by Micka ().

    Quote from Micka

    Yet another problem surfaced. Whenever a program is set where TCP is static and turntable is rotating, the TCP stayed static on the $BASE system but not $WORLD system. This caused the robot to move with the turntable, even though that was not planned.

    This is most likely a CAM software fault, so i'll look into that.

    Well, the TCP will follow the turntable whenever the turntable Base is active. So for portions of the program where you don't want that to happen, the simplest answer is to simply activate a different Base, like Base 0 ($WORLD).

    Quote from Micka

    The problem was the start type. A proper "Cold" start hasn't been done in a long time, as it was set on "Hybernate".

    :uglyhammer2: It's almost always the stupidest little things.... well, good to hear it works now.

    Quote from SkyeFire

    the simplest answer is to simply activate a different Base, like Base 0 ($WORLD).

    Hmm, that does not seem to be the solution.

    Because $VEL_ACT is being used to calculate the extrusion speed, this cannot be 0.

    When activating another base, like Base 0 ($WORLD), this means the TCP is stationairy in $WORLD, causing $VEL_ACT to be 0.


    $VEL_ACT has to have a value greater than 0 to be able to get an extrusion from the robot. This means the turntable base still has to be used, causing $VEL_ACT to acquire a value in relation to the external base.

    Ah! I misunderstood the problem. Yes, to accomplish a motion where:

    1. The TCP is stationary in $WORLD

    2. The turntable is rotating

    3. $VEL_ACT is reading the TCP velocity relative to the turntable


    The Turnable EX_KIN Base would have to be active, and each robot motion point would have to be programmed with the E1 value for the turntable and the correct XYZABC for the TCP relative to the turntable Base.


    So, for a simplified example where E1 is a linear axis parallel to the $WORLD Y axis, something like this:

    LIN {X 0,Y -1000,Z 0,A 0,B 0,C 0, E1 0}

    LIN {X 0, Y 0,Z 0,A 0,B 0,C 0, E1 -1000}

    should achieve the desired effect. From the perspective of $WORLD, the TCP would be stationary while E1 moves -1000mm, but from the perspective of the external Base, the TCP just moved +1000mm.


    So your CAM postprocessor would have to be aware of the external kinematics and output motion coordinates accordingly.

    It indeed was a CAM software fault. Issue has been resolved, as it was just a matter of setting the external axis correctly in the CAM software. It had to do with the way the X and Y axes were defined.


    Everything is up and running now.

    :cheer:

Advertising from our partners