Feed optimization and/or correction implementation

[dbtayl]

Hopefully getting a chance to dig into the Path workbench after a few years (sorry sliptonic for the missed PM's from 2016... forgot to check the "email me when PM'd" button, now fixed). That's probably optimistic, but one can dream. Anyway, there are two related topics I was looking at.

The first is what Fusion 360 calls "feed optimization"- basically a setting allowing you to automatically reduce the feedrate when entering an internal corner to mitigate the sudden spike in cutter engagement. This helps avoid chatter in the corners of pockets and, in more extreme examples, broken tools.

The second is well described by the video Haas put out below, but the gist of it is that the effective chip load seen by a tool can vary greatly when doing arcs small relative to the diameter of the tool. Basically programmed arcs move along the tool centerline, but the part of the tool doing the cutting is obviously at the outside edge, and when the arc is small, that difference becomes significant.

Example: a 5mm tool moving in a 1mm-diameter circle. The center of the tool moves ~3.14mm, but the cutting edge travels almost 19mm in the same time, resulting in a much higher than expected chipload. You see this when you finish a helical ramp into a pocket and start clearing the pocket itself.

Haas video: https://www.youtube.com/watch?v=6wLU97gVo5k


I was looking at implementing one or both of the above, but figured I'd ask if anything has already been done in this are before digging too deep- no sense in duplicating effort. My first (probably naive) impression is that neither should be too complicated- in the first case, just reduce feed rate by a specified amount when two adjacent segments differ in angle by more than some amount. In the second case, just scale feedrate based on the ratio of the current arc radius compared to the tool diameter.

Thanks!


EDIT: This is going to wait on my end probably until Python3.10/pivy issues are resolved. I'm running Arch Linux, and don't really want to fight that. Installing Python3.9 from AUR and creating a venv didn't do it (seemingly no way to manually specify a Python version when building), and I don't want to fight it more- did too much of that recently trying to get Machinekit to build.

[sliptonic]

Welcome back! No work has been done on either issue yet and both would be appreciated.

We're gradually refactoring the operation code to make things more testable and easier to read. One change I've been making is to remove all the feed rate calculation from the path generation logic in the ops and centralize it. This isn't merged yet. https://github.com/sliptonic/FreeCAD/bl ... eedRate.py

That's the perfect place to add those optimizations.

[dbtayl]

Oh, nice! I like the concept of figuring out what moves to make and how fast to make them as separate steps- as you point out, makes it tidy to add these kinds of corrections.

I've got spare disks floating around, maybe I should just build up a Debian Bullseye image and use that for dev. Should be easy enough.

[dbtayl]

Got to start poking at this and... I think there needs to be SOME knowledge of the part geometry to implement it.

For arcs (or approximations thereof), you need to know whether you're climb milling or conventional milling. Without that information, you don't know whether you need to increase or decrease the feedrate to maintain the expected chipload. It's easy enough to fake this for testing purposes, so I'll do that for the moment.

For reducing feedrate as you enter into the workpiece, you need some knowledge of what the workpiece looks like. I'm not entirely sure what the right approach is there. You could adjust the generated path to somehow leave a feature to key off of- eg, in the case of a straight-line move that goes directly into the stock, break it up into TWO segments, and use two sequential segments following the same line as an indication that the second one should have a reduced feedrate. I think I'll ignore this piece for the moment.

More generally, there's an argument to be made for labeling different segments of motion. You get rapids separated out because they're G0 commands, but it seems plausible you want to use a different feed rate (eg) for ramping into a cut than you do for the cut itself, which may follow a 3D contour. Differentiating between those could be tricky- you could come up with heuristics, but since we're generating the path in the first place, it sure seems like it'd be better to take advantage of that.

Again, I'll ignore that right now and try to just get the one little piece of adjusting feedrates for small radii implemented. One thing done being better than a bunch of half-baked ideas and all that.

[sliptonic]

For arcs (or approximations thereof), you need to know whether you're climb milling or conventional milling. Without that information, you don't know whether you need to increase or decrease the feedrate to maintain the expected chipload.

Great point. I'll give this some thought. Maybe we need a helper function someplace.

For reducing feedrate as you enter into the workpiece, you need some knowledge of what the workpiece looks like.

I don't understand what you mean. Please elaborate.

More generally, there's an argument to be made for labeling different segments of motion. You get rapids separated out because they're G0 commands, but it seems plausible you want to use a different feed rate (eg) for ramping into a cut than you do for the cut itself, which may follow a 3D contour.

Do you mean differentiating between the vertical and horizontal components of motion? Not following you.

[dbtayl]

For reducing feedrate as you enter into the workpiece, you need some knowledge of what the workpiece looks like.

I don't understand what you mean. Please elaborate.

Say you're putting a slot straight through a piece:

Code: Select all

g0 zsafe
g0 x0 y0
g0 zcut
g1 x20
g0 zsafe

X=0 is presumably at least half a tool diameter away from the stock, but you don't know how much more. You could hit the material at x=1, or x=5, or... you just don't know purely by the moves. Without knowing that, you don't know when to reduce the feedrate as you enter the material to avoid shocking the tool with a sudden load

More generally, there's an argument to be made for labeling different segments of motion. You get rapids separated out because they're G0 commands, but it seems plausible you want to use a different feed rate (eg) for ramping into a cut than you do for the cut itself, which may follow a 3D contour.

Do you mean differentiating between the vertical and horizontal components of motion? Not following you.

The point I was trying to make is that different components of a cut may be treated differently. For example, if you're doing a helix to ramp into a pocket, you should be able to use the feed rate specified for ramping, and may NOT want to apply the correction I talk about above for keeping the outside edge chipload constant. There's no obvious way I see to differentiate between a segment of a helical ramp- where we may NOT want to apply the correction- and any other move that may or may not be in multiple axes (eg, following a 3D contour), where we MAY want to apply the correction.

At a more basic level, ignoring any "corrections" I'm thinking of, you may have different speeds/feeds for (eg) ramping as you do for (eg) a pocket and, if you're not told which type of motion a given segment belongs to, you can't apply the correct feedrate. (that particular example may already be handled- I'm not familiar with everything yet)

[sliptonic]

For reducing feedrate as you enter into the workpiece, you need some knowledge of what the workpiece looks like.

I don't understand what you mean. Please elaborate.

Say you're putting a slot straight through a piece:

Code: Select all

g0 zsafe
g0 x0 y0
g0 zcut
g1 x20
g0 zsafe

X=0 is presumably at least half a tool diameter away from the stock, but you don't know how much more. You could hit the material at x=1, or x=5, or... you just don't know purely by the moves. Without knowing that, you don't know when to reduce the feedrate as you enter the material to avoid shocking the tool with a sudden load

Ok, Then the first G1 after a G0 is an entry move and should be compensated.

The point I was trying to make is that different components of a cut may be treated differently. For example, if you're doing a helix to ramp into a pocket, you should be able to use the feed rate specified for ramping, and may NOT want to apply the correction I talk about above for keeping the outside edge chipload constant. There's no obvious way I see to differentiate between a segment of a helical ramp- where we may NOT want to apply the correction- and any other move that may or may not be in multiple axes (eg, following a 3D contour), where we MAY want to apply the correction.

At a more basic level, ignoring any "corrections" I'm thinking of, you may have different speeds/feeds for (eg) ramping as you do for (eg) a pocket and, if you're not told which type of motion a given segment belongs to, you can't apply the correct feedrate. (that particular example may already be handled- I'm not familiar with everything yet)

It's probably safe to kick this one down the road a bit. Tackle the easy stuff first.

[dbtayl]

Ok, Then the first G1 after a G0 is an entry move and should be compensated.

I don't think that quite works, since doing so would result in a reduced feedrate for the entirety of the slot in my example above. There might be something almost that simple, but it's not jumping out at me. Either way, I'm also ignoring this one for the moment- one thing at a time.

[sliptonic]

If the g1 move is more than 2x to the tool diameter, split it at 2x and compensate the first part. Leave it to the user to set the entry point close enough.

[dbtayl]

A little progress here, albeit not actually integrated into anything FreeCAD yet. The image attached sums it up pretty well. Black is nominal feed rate. Bright red is 5% feed, fading to black as you near 100% feed. Green is over 100% feed, with the brightest being 400%. Tool specified here is a 1/4"/6.35mm end mill, units are mm.

The spiral in the middle is part of an adaptive toolpath- you can see it generally gets closer to the nominal feed as the radius increases. At the top and bottom edges you can see some green where it started to hit edges of the part and cut "outside corners", increasing feed to keep the chip load up.

Basically the algorithm is "fit a circle to up to 10 points, or up to 1 tool diameter worth of segments, whichever is smaller, and adjust feed accordingly". This seems to do what I think it should, obviously requires more testing.

The junk on the lower-right side of the image I hand-edited into the gcode to show another point- it more or less does the "reduce feed when sharp tool load changes are expected" we went back and forth on above. It's a limited subset of that problem, but it's there. Basically it separates off the last <tool_radius> amount from each "long" (ie, longer than a tool radius) segment, and adapts the feed of that last little bit based on how sharp the angle it's entering is. You can see 3 examples of that- two acute angles (90 degrees, then 45 degrees)- both of which reduce the feedrate (red dot). The last one is an "outside" corner, and thus the feed isn't reduced.

Since I'm sure the above isn't easy to parse, the tl;dr is: progress, still needs more work. Notably missing are G2/G3 parsing (nominally the easiest case, just need to tie them in with the G1 move processing) and similarly G0.