Recent Posts

1

Support / Re: Calibrating KP1-V500 with KUKA|prc

« Last post by Johannes @ Robots in Architecture on May 17, 2022, 06:27:39 PM »

From the XYZABC it looks like you would like the tool to more or less stay at the current position, right?
So if A moves by 8 degrees, then E1 does the negative -8 movement.
Is it possible that the real and simulated turntable turn in different directions? So instead of -8 + 8 = 0 you get 16?

Best,
Johannes

2

Support / Re: Calibrating KP1-V500 with KUKA|prc

« Last post by AADPL on 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.

3

Support / Re: Getting rid of those ridges

« Last post by Johannes @ Robots in Architecture on May 16, 2022, 08:15:11 PM »

I've only got my own experience in that C_VEL tries to keep a constant speed at the expense of accuracy. We've had success on larger-scale 3D printing where constant speed is important but a few mm difference do not matter. Unfortunately the C_VEL parameter is without units (0-100) so it's hard to quantify.
Have you tried the S-movements yet? Might be smoother for you!

Once business is rolling you could invest in KUKA.CNC, I have heard great things about its toolpaths (and terrible things about the integration process). But it's one of the most expensive tech packages.

Best,
Johannes

4

Support / Re: Getting rid of those ridges

« Last post by Xylotica on May 16, 2022, 04:59:21 PM »

Please don't take this the wrong way, but if you need expert access to all values, you will need to interface at the code level. Here's an example for a LIN component with basically all input. You may need to set the correct path to your libraries for it to work.

Thanks ! I'll give it a try.
What I need to grasp is the use case for CVEL vs CDIS.
Some kind of high-level view of when it is preferable to use one or the other.
I'm still struggling between a jerky robot with too little interpolation and a fuzzy robot that smooshes my shapes...

5

Support / Re: Getting rid of those ridges

« Last post by Xylotica on May 16, 2022, 04:54:56 PM »

Regarding my first statement, I was confused by the fact the LIN component has no interpolation option (black label on the bottom) until it gets fed with inputs.
But indeed, as soon as it is, it defaults to C_DIS.

You are right regarding the tool offset : I see how taking out the interpolation just before the offset might create a tool mark.
Maybe you could propose a new tool offset type that would "overshoot" tangentialy the last frame along the trajectory and THEN offset in the tool axis.
The input would be the "overshoot" distance + the "Offset" distance and it would add a little CIRC movement to blend the trajectory and the offset...

6

Support / Re: Getting rid of those ridges

« Last post by Johannes @ Robots in Architecture on May 15, 2022, 02:21:24 PM »

You can right-click the symbol/name of each movement component and change the chosen interpolation method.

I see that ; there is even a "no interpolation" option.
The trouble is that it isn't very easy to manage because again, the option is not accessible as an input.
If it were, it would be easy, in a list of LIN movements to have a coresponding list of "Interpolation methods".
Then depending on , say, the angle between successive movements, one could chose between methods.

It would be possible to change the approximation parameters via the Custom KRL component, if needed.

As a workaround, perhaps I might try it out. It's just string formatting after all...

Regarding defaults, the controller keeps the last value, as far as I know.

I have absolutely no idea what "typical" settings are use for milling.
Since milling can involve sharp edges, I would expect these values to be quite small, but exactly "how" small is still OK in terms of robot jerkiness : that's what I'd like to know.

Also, you might give the SLIN movements a try, they can be a bit smoother. It's an option in the Code Generation settings.

I don't want smoother. I want control over where it can be smooth, and where it shouldn't.
I checked the KSS doc. on SPLINE blocks, and as always, I came out even more ignorant as before.
It's always blunt, sterile description...
Even this Chinese video does a better job of explaining : https://www.youtube.com/watch?v=yIv9Yr9ynOE
Could you point me to any well-made documentation on these types of movements ?

If I get the idea behind this option, if it is pressed, all the movement types will be converted to the new "S" type and inserted in spline blocks, is that right ?

Please don't take this the wrong way, but if you need expert access to all values, you will need to interface at the code level. Here's an example for a LIN component with basically all input. You may need to set the correct path to your libraries for it to work.

Best,
Johannes

7

Support / Re: Getting rid of those ridges

« Last post by Johannes @ Robots in Architecture on May 15, 2022, 02:10:11 PM »

I notice that, even though I heve no interpolation method set in the LIN component, my LIN movements end-up having the "C-DIS" option in the .src file
Could that be a bug ?
I also notice that LIN movements for tool offsets don't have an interpolation option in the in the .src file (which makes sense).

What would make sense is that , when there is a tool offset, the interpolation method be "no interpolation" for the LAST LIN movement just before the offset.
That could solve at least the ridge problem I had on my beer bottle cap milling...

If I create a toolpath consisting of two linear movements with no interpolation and add the tool axis offset, this is what I get:

Code: [Select]

LIN {X 18.16, Y 8.094, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 18.16, Y 8.094, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 40.16, Y 17.019, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 40.16, Y 17.019, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
With interpolation it looks like that:

Code: [Select]

LIN {X 18.16, Y 8.094, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
LIN {X 18.16, Y 8.094, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
LIN {X 40.16, Y 17.019, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
LIN {X 40.16, Y 17.019, Z 50, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0}
I'm a bit torn regarding that, but you would like me to manually get rid of the last C_DIS before it rises up?
While I see that it would help with your issues, there will also be users who do NOT want the tool to briefly stop.

Best,
Johannes

8

Support / Re: Getting rid of those ridges

« Last post by Johannes @ Robots in Architecture on May 15, 2022, 02:03:19 PM »

I generated two .src files (I could never understand why they are not simply called .krl files) :
-One with KRC2-style movements
-One with "S" or "Spline" movements

First, I am surprised that there are no Spline blocks. Isn't that what actually tells the controller that the subsequent movements are spline "segments" and that they should all have curvature continuity ?
Then, I found that the "S" segment movements each require their $VEL statement, whereas the old-school movements use the last value found in the code... not that it's a big deal, but it does make the "S" file larger for no good reason...

While the "S" in e.g. SLIN stands for Spline, as far as I know, they just signify a new algorithm for the pathplanning. In online teaching they are now the default. But you can put them into a Spline block if you want to.
There are some things that work a bit differently from what I remember, but at least for me I've never felt that the S-movements are significantly better.

Best,
Johannes

9

Support / Re: Getting rid of those ridges

« Last post by Xylotica on May 13, 2022, 03:38:48 PM »

I notice that, even though I heve no interpolation method set in the LIN component, my LIN movements end-up having the "C-DIS" option in the .src file
Could that be a bug ?
I also notice that LIN movements for tool offsets don't have an interpolation option in the in the .src file (which makes sense).

What would make sense is that , when there is a tool offset, the interpolation method be "no interpolation" for the LAST LIN movement just before the offset.
That could solve at least the ridge problem I had on my beer bottle cap milling...

10

Support / Re: Getting rid of those ridges

« Last post by Xylotica on May 13, 2022, 03:21:19 PM »

I generated two .src files (I could never understand why they are not simply called .krl files) :
-One with KRC2-style movements
-One with "S" or "Spline" movements

First, I am surprised that there are no Spline blocks. Isn't that what actually tells the controller that the subsequent movements are spline "segments" and that they should all have curvature continuity ?
Then, I found that the "S" segment movements each require their $VEL statement, whereas the old-school movements use the last value found in the code... not that it's a big deal, but it does make the "S" file larger for no good reason...