[Request] Fix and enable Arc feature

[CReimer]

There's already some code in Slic3r to generate Arc commands (G2, G3). Either it was never finished in the first place or it got broken over time.

I was able to reenable it by adapting it to some more recent changes in Slic3r, but the generated GCode is completely wrong.

[bubnikv]

I would rather remove it. With the current state of the firmwares, I don't see much benefit of it. On the contrary, this feature could do more harm than good as you already found out.

[CReimer]

Well. That would at least be a clear signal where the development is headed.

But what do you mean by current state of the firmwares. As far as I know Marlin and Repetier are capable of G2 and G3 commands. But I don't know if the print actually benefits from arc commands.

AFAIK Marlin converts G2 and G3 back to G0/G1 commands. The only real benefit I see there is, that the firmware knows more about steps per mm and might be able to generate mechanically better fitting lines.

[bubnikv]

AFAIK Marlin converts G2 and G3 back to G0/G1 commands. The only real benefit I see there is, that the firmware knows more about steps per mm and might be able to generate mechanically better fitting lines.

Exactly. AFAIK the print will most likely not be better if you use G2/G3 with Marlin. It may be worse due to the heuristics finding the arcs and circles though.

[Sebastianv650]

I'm also no friend of G2 and G3. First, the Slicer has to find an approximation to fit arcs into the model. Second, the already quite overloaded 16MHz Marlin board has to approximate the circle further by breaking it up into small G0/1 moves at a resolution that has to be defined by the user in the config file first. So you are not flexible for choosing a resolution as you can do it in Slic3r, and you transfer the calculations to the weaker CPU.

[CReimer]

Under the assumption everyone uses these outdated CPUs on their printers: Yes. But it could be an optional feature.

But I think we have already determined that there's either way no real benefit in print quality or print speed or whatever.

[manticorp]

I know this is an old issue, and that it has been closed, but I would like to add that one great benefit of G2 and G3 arc commands is that one command can replace 100's of G0 and G1 commands.

When printing over USB using, e.g. Octoprint, this greatly reduces the amount of instructions that need to be sent to and cleared by the USB buffer on the printer.

For some printed models, especially curvy ones with high polygon counts, sending so many G0 and G1 commands can stall the printer, making blobs and zits. Some printers cannot keep up with the high level of G0 and G1 commands in these prints.

Sending single G2 and G3 arc commands produces nice smooth extrusions when printing from USB.

I have done some work on this as a gcode post-processing solution and the results are promising:

https://github.com/manticorp/GCodeArcOptimiser/

[haarp]

@manticorp Funny you mention that. Just now I've run (again) into situations where the spam of G1 commands stalls the printer (prusa3d/Prusa-Firmware#1406) which I strongly suspect to be related.

[mdealer]

Well, fast forward to 2019, this would be a definitive feature to try on my Duet 2 powered CoreXY. I'm running into a problem where the CPU gets bogged down reading many short successive commands for a print consisting out of curves only. If Arcs would be used, then the reading from SD-card part could get skipped completely and it might free up enough CPU to print at an acceptable speed. The CPU is not the fastest, but, in any case, I wouldn't write off this feature. This should be an experimental, optional feature that can be switched per printer.

We shouldn't ignore the fact that the GCodes are currently highly inefficient. Plus, we can't try new ways of path computation if all we have are straight segments only, but it's a different discussion.

[darthscsi]

An intermediate option would be to allow enabling arcs for Gyroid infill. No reconstructing of curved surfaces in the slicer would then be necessary.

[OldCurmudgeon3DP]

Klipper bogs down more on arcs than I ever saw in Marlin firmware. Maybe it's the 100mm/s speed, but i used that base rate in Marlin and 80% on perimeters same as now. Using the virtual SD card fixes the problem, but defeats the purpose of having octoprint almost entirely. Beats me whether a G2/G3 would help, but seems if Octo sends that one command to Klipper it reduces the bottleneck of Octo sending dozens of little line segments via whatever method is involved.

[Nandox7]

Than it doesn't seem to be a Klipper problem but a Octoprint problem, that is well know for the serial communication problems.

[mdealer]

Duet works better with arcs than segments in my tests.