Posts by Micka

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.

Yes! Correct!

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.

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

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!

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.

Quote from Fubini

$BASE = EK (<Root>, <Kinematic identifier>, <Offset>)

where:

<Root> = Position of external kinematic root in $WORLD

<Kinematic identifier> = #EASYS or #EBSYS or ... or #EFSYS

<Offset> = (optional) additional offset frame from the external kinematic flange

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

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.

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

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

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.

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

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.

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.

I attached the $config.dat. It's from the directory C:\KRC\ROBOTER\KRC\R1\System.

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?

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.

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?

$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?

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.

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!

Thanks 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?

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?