Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - AADPL

Support / Re: Calibrating KP1-V500 with KUKA|prc
July 07, 2022, 05:31:21 PM
Here's the latest grasshopper definition!
Support / Re: Calibrating KP1-V500 with KUKA|prc
June 21, 2022, 06:21:07 PM
Quote from: Johannes @ Robots in Architecture on May 20, 2022, 08:57:54 PM

Reversing the rotation axis of the turntable should flip the rotation direction as well - see the attached example!

Okay, so using Karl's x*-1 approach, I can now successfully reverse the turntable direction in my main Grasshopper definition, but this is still resulting in the same issue where I can see the A value increasing like before, rather than staying in a similar range.

Quote from: Johannes @ Robots in Architecture on May 20, 2022, 08:57:54 PM

Otherwise the approach would be to look into the machine data file, but let's keep that option for later.

I'm confused why this is the other option because the robot is doing what it is being told to do from the KRL, its more that the simulation isn't matching the KRL, if you understand what I mean?


Support / Re: Calibrating KP1-V500 with KUKA|prc
June 08, 2022, 12:17:10 PM
Sorry for the long delay, has been very hectic here!

Recompute doesn't seem to be changing anything here.

Attached is the grasshopper file.


Support / Re: Calibrating KP1-V500 with KUKA|prc
May 23, 2022, 06:21:12 PM
Hi Johannes,

Thank you for replying on your holiday! No rush needed with the replies.

So if you see the YouTube link below I don't think the reversed direction is working consistently? Angel came up with the solution to use the flipped surface which worked on both our computers at some point, but now I try and do the exact same process and it doesn't reverse?
Support / Re: Calibrating KP1-V500 with KUKA|prc
May 20, 2022, 12:05:08 PM
Just sending the files because I still haven't managed to figure anything out!
Support / Re: Calibrating KP1-V500 with KUKA|prc
May 18, 2022, 03:12:00 PM
Yes, staying at the current position would be good. It's possible that the turntables are going in different directions, but how do I swap this? If I flip the turntable on the robot then the coordinate system would have Z in the wrong direction and the robot would try and reach underneath the turntable, and I can't seem to find a way to flip it in PRC? I tried flipping the axis on the custom turntable block, but that didn't change anything.

Support / Re: Calibrating KP1-V500 with KUKA|prc
May 17, 2022, 05:36:42 PM
Hi Johannes,

So I've managed to get the turntable jogging correctly, and am now very close to getting everything working! Although KUKA support were very unhelpful with the explanation of why the error could be so high for the calibration.

My main issue now is that the A value for my XYZABC targets in the KRL code is consistently increasing, meaning that my Axis 6 locks out after the first layer of the milling strategy. I know I can make Axis 6 have endless rotation, but this also isn't matching the simulation in PRC which shows the tool just approaching from one spot. I'm unsure why the A value is increasing, since I have the rotary axis vector set, and in the past that essentially locked the A value to be near constant i.e. the tool is always approaching from the same direction.

Support / Re: Calibrating KP1-V500 with KUKA|prc
May 10, 2022, 07:21:32 PM
Hi Johannes,

Thanks for the response. Sorry, I've been busy with some other things so haven't had a chance to play around some more with the turntable until now. Also, I'm aware that the issues I'm having are slightly more from the system integrator side of things rather than the KUKA prc side of things, so thank you for your help!

So I'm still not 100% sure about whether the turntable is set up correctly. I can't seem to get it to jog while keeping the robot tool TCP and external axis reference point moving together. And I've tried trawling through the machine.dat etc and the turntable does seem to be set up correctly in terms of allowing synchronous movement etc. but I've not been able to do as you suggest to:
Quoteyou move the turntable in a Cartesian mode and the robot keeps its position in relation to it

Otherwise, the config.dat for the bases looks fine.

The one bit that is a little suspicious to me is that the frame for external axis in the machine.dat is all blank?

Further to that, why does the external machine have a root in the config.dat as well? Should the Z value here actually be 0.0 and then in the machine.dat then FRAME $ET1_TA1KR should have Z = 686?

And then I suppose the final piece of evidence I have for things going wrong is that if I actually select a base in KUKA prc and try to run this on the robot then all I get is a software limit switch error after the robot has reached the start/home position and when it tries to do the first PTP move.

Its not a riveting watch but here is a video of me calibrating the root point of the external kinematic system. Am I doing something stupidly wrong here? I still don't really understand why the error is in the 10s of millimetres really?

From the KUKA prc side of things, do you know which values/calibration/coordinate system in the plugin is responsible for the some sort of an offset between the X and Y values of the target planes I provide vs what actually gets spat out into the KRL? I.e. if I gave it a target plane of X 10, Y 20, Z 30, is there a way in KUKA prc (I guess not using bases and frames) of having the KRL have that same plane translated to X 20, Y 30, Z 30, effectively with an offset of X +10, Y +10, Z 0?


Support / Calibrating KP1-V500 with KUKA|prc
April 28, 2022, 07:03:09 PM
I've followed Karl Singline's video tutorial ( on how to set up a custom turntable in Grasshopper and now have a lovely path which can be seen in the attached Rhino and Grasshopper files. To get it to work, I used the custom turntable block and set X = 1382, Y = 666, Z = 705, which results in a satisfactory simulation.

When I tried to run the program on the robot though, the robot tries to reach the coordinates very literally, which means that the robot starts reaching for a point near the "origin", which is somewhere in its own base. i.e. the highlighted coordinates in the left image correspond correctly to the KUKA|prc geometry in grey in the right image, but actually the robot's origin is shown relatively in green in the right image. So essentially, the grasshopper simulation doesn't correspond to the physical movements of the robot.

Some more exploring led me to Karl's top tip #1 ( for making sure you actually define what base the robot should be using, and then petrvacek's post (,1126.0.html) about calibrating external kinematics. Which both to me sounded like a good point to trouble shoot.

That led me to try and carry out step 2 for Calibrate External Kinematics Root Point for my KP1-V500 (see picture below). But when trying to do this step, if I rotate E1 manually to 4 different angles, and get our calibrated spike to touch the engraved cross at all 4 points then I get an error that is larger than 100mm, and if I just try and locate the root point in the middle 4 times then it says there is not enough movement between the points.

So essentially, I'm confused. I'm not sure if I'm doing the Calibrate External Kinematics Root Point right, and if this will indeed solve my problem, or if there is somewhere else I'm going wrong in the Grasshopper/prc plugin.

Thanks for the help!