Getting rid of those ridges

[Johannes @ Robots in Architecture]

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

[Xylotica]

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

[Xylotica]

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

[Johannes @ Robots in Architecture]

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