Getting rid of those ridges

[Xylotica]

I'm looking for better acceleration settings for milling as I keep getting areas where the tool plunged and exited in diagonal instead of straight.
This has nothing to do with trajectories defined within KUKA|prc. I I used "Reduce toolpath for instance, it could "round-off my trajectories, but here, it's really the robot that's not really going through all the waypoints.
I tried adding an extra point to "overshoot" the entry point and exit a bit further, and I still get this effect ; I suppose that the dynamic settings of the robot are still too "loose"...
If anyone facing the same problems has found just the right settings for this, I'd be glad to hear from him.

[Johannes @ Robots in Architecture]

Hello,

It's probably related to motion blending. You could try to constrain the path more, maybe add an extra movement like 0.25mm above the last point of the toolpath. So the tool lifts off to 0.25mm and then to the final height. The Reduce Toolpath component will get rid of that extra command, so ideally you add it afterwards. I have an alternative idea in case that's too tricky.

Best,
Johannes

[Xylotica]

On those detailed millings like engraving and such, I have been getting very poor results because of that "motion blending" thing... What would be a set of better settings for these motion blending parameters ?
I get the extra point idea, but as I told you, I already did it by overshooting the final position : it doesn't suffice.
I could overshoot more, but this is starting to look really fuzzy and cumbersome at the same time.

EDIT : I just tried the extra vertically displaced point : still got those aweful ridges.

[Xylotica]

I offset verticaly the first and last point of the loops and I still see the ridge.

[Johannes @ Robots in Architecture]

Just to double-check: So you are having three points. Assuming the tool is at Z=0mm and the safe plane is at 50mm, you would have the last point at 0mm, an extra point at 0.25mm and the third point at 50mm?
You can also try turning off C_DIS motion blending for the first and last position, this will have a very similar effect.

Best,
Johannes

[Xylotica]

Just to double-check: So you are having three points.

Yes, exactly : that doesn't work.
Similarly to milling specs (spindle speed, feed rate, and depth of cut,...) for a given material and end mill, I'd like to have some feedback from people who have found good values for :
C-PTP
C-DIS
C-VEL
C-ORI
CP
PTP
...for the purpose of milling wood.
The results I have right now with the defaults are just terrible :
-Ridges at the end of loops
-Sharp edges/features on my parts being "eaten-up" by interpolation

[Johannes @ Robots in Architecture]

Hello,

For milling you probably aren't going to use C_PTP, so C_DIS and C_ORI is where it's at, mostly.
Unfortunately I cannot really help you with any hard numbers. My guess is that as always there is no "best" solution and you would have to optimize for a specific use-case, which might then be less ideal for another use-case.
The logic for C_DIS is that it's the distance in millimeters from where the TCP starts blending. So with C_DIS set to 2, it will leave the toolpath 2mm before the the next position. The maximum blending is half the distance, so if you have got two positions that are 1mm apart, it should blend after 0.5mm, even if C_DIS is set to 2mm.
Again, this is just my understanding of these values, and I might be wrong.
I believe the same logic applies to C_ORI but with degrees - but I'm even less sure on that one and didn't check the manual properly.

Best,
Johannes

[Xylotica]

Thanks for clarifying. I have read the documentation about these values in the KSS document, and the first time it mentions C-DIS is some tangled explanation about replacing LIN - CIRC with SLIN - SPL - SCIRC...
From my personnal interpretation, this "Aproximation" business is a way to make it easy on the motors / avoid abrupt direction or velocity changes.
But would it be really bad to set these values to zero ? I mean, what's the worse that could happen ?
Isn't the whole point of having a NC being able to make precise stuff ?

[Xylotica]

Looking at the .src structure, I realize that there is a "C.DIS" at the end of each LIN command, and a C_PTP at the end of each PTP command.
Does that mean that these values can be set differently for each and every command ?
KUKA|prc only allows to make a global setting ; isn't that a limitation?
Moreover, as you said, different jobs might require different values. Isn't that a good reason to expose them as inputs, and not be "static" inside the main component ?

Other subject : I suppose that if I enter no value, the controller uses defaults stored somewhere.
Where would that somewhere be ? I'm curious to know what lazy values give me so aweful results ; it will help me decide what new values to set in the hope of making decent stuff with my Orange beast.

[Johannes @ Robots in Architecture]

Hello,

You can right-click the symbol/name of each movement component and change the chosen interpolation method.
It would be possible to change the approximation parameters via the Custom KRL component, if needed.
Regarding defaults, the controller keeps the last value, as far as I 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.

Regarding why to blend: Without blending there is no way to make a polyline with a smooth movement - the robot would briefly stop at each control point. This is a fundamental challenge and not something related to KUKA robots in particular.

Best,
Johannes

[Xylotica]

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 ?

[Xylotica]

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

[Xylotica]

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

[Johannes @ Robots in Architecture]

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

[Johannes @ Robots in Architecture]

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 Expand

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 Expand

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