Feature Request: Convert segments to arcs (G1 to G2 or G3)

[gcanzalo]

I've tried gcodeutils' optimize_arc, but it trashes the g-code. I know some firmwares purport to interpolate arcs, but the real fix would be to do it at the slicer. It makes more compact g-code and should produce a nicer print. Since many models have closed polygons, maybe make a filter permitting the user to define what constitutes an arc, e.g. degrees/chord length. That way models having a large $fn, say >30 (12 degrees/chord), would be treated as arcs and everything less would remain a polygon.

[ChrisTerBeke]

I've seen a lot of printer firmwares that can't handle arc commands, so not sure how helpful this would be in 3D printing. CNC machines support this command a lot better.

[DDDirk]

It's a shame though, that G2 and G3 are so badly supported, because rounded moves are much more suitable for 3D printing. It makes it easier to maintain a constant flow of material, which makes the extrusion more predictable. (Designers should actually be encouraged to make their models more rounded, which will also often make them stronger.) Also, it wil decrease printing times and the gcode is a whole lot easier to read than a long list of steps along an arc.

[Patola]

Besides gcodeutils there's also G-Code Arc Optimiser, https://github.com/manticorp/GCodeArcOptimiser. It's in PHP, but it works, I've tested it a dozen times.

[ChrisTerBeke]

I think converting that to a Python implementation so it can be used as post-processing script is quite doable. Maybe someone will pull request that in to the post processing plugin...

[DDDirk]

Of course this is not ideal. If a design has an arc in it that gets tesselated, producing vertices on that arc, and then a slicer or postprocessor has to fish that arc out of the code. Ideally, the arc would be coded into what the slicer receives.

Another issue, I understand, is that Marlin implements G2/3 as segments with a fixed angle. That means that an arc with a big radius will become too rough. But just last week I programmed a spiral with 200 segment for a complete turn, to make it a smooth movement, but when the spiral got to the inner turns (radius about 3 mm) the nozzle started making staggering moves (dropped lines of gcode?). Then I realised that the program had created about 10 vertices per mm, which is a bit of overkill. :)
So this would have to be resolved first, I'd say. A fixed segment length makes much more sense. Edit: That might be too complicated. Letting the number of segments depend on the radius might be an easier alternative.

[Ghostkeeper]

Loading arcs through our entire slicing process is infeasible. We use ClipperLib polygons everywhere which doesn't support that. We'd have to basically reimplement ClipperLib but then for curves. Offsetting and diffing arbitrary complex polygons which may partially consist of curves is complex.

Also, this issue is a duplicate of Ultimaker/CuraEngine#429