Feed optimization and/or correction implementation

[sliptonic]

Very cool!

[memfis]

This, apparently, is just the beginning. The relationship to counter- and tail milling is very similar to religious issues, but definitely affects the force that is overcome by the cutter. And besides that, there are also "along and across the wood fibers"-these are factors that theoretically can (and apparently should) be tried to take into account (just as, for example, there are attempts to account for the elasticity (al...) of the material- translation problems)

Also, taking into account the actual way Path algorithms are implemented, it is noted that the "engrav" code implementation is done by linear approximation of g1, and edge tries to use g2\g3 where possible (and still g1 when specifying an additional offset), which in itself when working with a material actually moves the cutter along really different trajectories. And I would say - if g1, then always and everywhere g1. Uniformity, repeatability = very sensible and useful.

[dbtayl]

Also, taking into account the actual way Path algorithms are implemented, it is noted that the "engrav" code implementation is done by linear approximation of g1, and edge tries to use g2\g3 where possible (and still g1 when specifying an additional offset), which in itself when working with a material actually moves the cutter along really different trajectories. And I would say - if g1, then always and everywhere g1. Uniformity, repeatability = very sensible and useful.

Depends on your viewpoint, I guess. I'd argue that if you're doing an arc, and there are commands that exist solely for the purposes of making arcs... does it not make sense to use them? Fewer commands to parse, and accuracy will be as good as the machine/controller, not limited to how fine you make your line approximations.

Anyway, still plugging along at getting adaptive feed rates going- re-writing my test code using existing FreeCAD functions and using PIL to visualize instead of hacking around with Matplotlib. The approach I'm taking basically operates as a GCode post-processor, which allows it to also be used outside of FreeCAD (assuming you have a FreeCAD installation, of course, to utilize the libraries).

I'm bothering to reply with basically no news because of some... odd behavior I'm seeing in the GCode I generated from FreeCAD. I've attached the test part I made- basically I just wanted both G02 and G03 arcs. In the test part, all arcs are just filleted 90-degree corners, going from perfectly horizontal to perfectly vertical (or vice versa). As such, I'd expect to see exactly ONE of I or J be nonzero, which is... not so. Here's a snippet from the GCode:

Code: Select all

G1 X53.168 Y63.792 Z14.650 F1999.998 
G2 X46.000 Y56.825 Z14.650 I-7.175 J0.211 F1999.998 
G1 X33.792 Y56.832 Z14.650 F1999.998

In this case, a 6.35mm end mill is going around a 4mm radius, from a vertical edge to a horizontal edge... so the I-7.175 is exactly what I'd expect to see, but what's up with the J0.211 bit? Error is off by a different amount for the "inside" corners than the "outside" corners, but it's the same for all corners of the same radius.

If I turn off the "use comp" option to not put cutter radius compensation in the GCode, it gives numbers as expected, so... something wonky with the GCode generation there, perhaps? Or something intentional I'm just blind to?

[dbtayl]

Probably done for the day, but again, more or less working... Under the hood improvements include actually handling non-G1 moves (G0, G2, G3), using FreeCAD functions/constructs (Command data type), and prettier plotting of output.

Quick demo run attached- bright red is saturated at 50% feed, bright green is 200%, yellow is 100%, blues are rapids- numbers basically picked to give good contrast. The green in the middle is the initial ramp into the part that's ignored. Overall pretty close to what we want- I'm not sure that the deceleration in the corners of the adaptive toolpath is actually useful, but I also haven't actually run any of this code. And I suspect some smoothing would be warranted.

Script also attached- you'll need to point it to your FreeCAD libs folder and a GCode file to parse. If you don't get a pretty plot popping up- and no other obvious errors are present- you may need ImageMagick installed for PIL to show it. So... not polished, but it lets others give it a try.

[dbtayl]

I've almost finished cleaning up the code into a more reasonable standalone program- seems like low-hanging fruit, might as well.

I really would like to look into actually integrating this into FreeCAD, though. I don't think the original plan of "calculate paths and feeds separately" approach works as it exists today. My impression from doing the work above is that you really need some metadata about the path to correctly adapt feedrates.

Two examples come to mind: First, you need to know if a part is being climb milled or conventional milled- otherwise you can't tell if an arc needs to be slowed down or sped up. Right now I just have a boolean in my code that assumes you know that, but obviously that information needs to be sent to the code somehow.

Second, you may want to treat different parts of an operation differently- notably, you likely don't want to adjust the feedrate for a helical ramp into a pocket, even though that's a relatively tight arc that would naively have a much slower feed- presumably the feed specified for ramping is the one you actually want to use there.

AFAICT, you can either calculate/correct feeds at the same time as the toolpath itself is generated, or pass additional metadata to the feed generation step. For the second option, offhand the only information you'd need is whether a non-rapid move is a ramping operation or not- basically distinguish between 3D surfacing operations and ramping into a pocket.

The other decision I see is how this option is enabled by the user. I was thinking just a checkbox in the UI for "Enable feed correction for arcs" (maybe a separate checkbox for "enable reduced feed for corners"), though I suppose this might also be a "dressup"? Not familiar enough with the distinction to know.


Guidance on both of those two points would be welcome. I'm happy to get an implementation done (albeit likely slowly), but I'd like to do it as in line with the general FreeCAD design/architecture as possible.

Thanks!

[memfis]

Am I wrong, or is this work a stone's throw away from implementing the "S acceleration and deceleration" principle in g-code? I mean the S kind of acceleration graph?
Since FC specifies the feed rate in every line of code, but LinuxCNC (for example) can't do that (S), that would be great.

[GeneFC]

Since FC specifies the feed rate in every line of code, but LinuxCNC (for example) can't do that (S), that would be great.

There is a long-running discussion in LinuxCNC about S-curve acceleration. However that is related to changing the speed within a single line of G-code.

LinuxCNC can certainly perform S-curve acceleration if there are multiple lines of G-code that have accelerating feed rates. That is the only sort of acceleration that FreeCAD could possibly support, since there is no single code that supports acceleration.

Whether this is useful or cumbersome would depend on the user.

Gene

[memfis]

That's what I was thinking - while LCNC is debating, it could probably be implemented here.

[dbtayl]

That's (if I understand right) outside of the scope of what I'm trying to do here- which is just adjusting the feedrate for the edge of the cutter compared to the center. I talked briefly about implementing reduced feeds when (eg) moving into acute corners as well- which would include breaking up some linear moves- but breaking up moves more generally to adapt to acceleration curves isn't something I've had in scope.

Not to say it couldn't/shouldn't be done, just that it's not on my to-do list right now. I'll honestly be happy if I get anything useful finished

[GeneFC]

That's (if I understand right) outside of the scope of what I'm trying to do here- which is just adjusting the feedrate for the edge of the cutter compared to the center.

I think that could be quite useful.

The further step of splitting codes to create sort some of speed ramp seems quite a bit more complex.

Gene