Undersized circles - Has this been solved yet?

The slic3r --gcode-arcs option (the post-processor you mentioned) is the only arc option in open source slicers available today or?
I'm curious how it can increase the dimensional accuracy of holes.

[www.reddit.com]

The 3D printer firmware has to convert any (part of a) circle into small linear movements anyway, if those arc codes are used. The circle is split into a number of linear parts, and with increasing this number, the closer the result will be at the real circle. Having all the extruded filament exactly on this circle would need infinitive parts, which is not possible. The more parts/segments, the closer you get to the circle.

If the printer firmware has to do this, the GCode will be way smaller, but the firmware has to do lots of trigonometric calculations. And those typically used processors like ATMega something are no really good choice for doing maths. I haven't checked this out completely, but for a quick glance, if the printer sets a point to print in an arc, there has to be done at least one sinus and one cosinus calculation, and I know these are heavy duty crunching numbers operations. It would be interesting how many sin/cos calculations per second an ATMega can do at 16 or 20 MHz.

On the other side, if the slicer does the work and approximates "perfect" circles by increasing the line count, this massively increases GCode size. The data transfer rate from the SD card will probably be high enough, and (I assume) the high BAUD rate of the USB connection is still high enough to compensate this. But anyway some more numbers and tests would be interesting. If my time allows me to do, I'll do some trigonometric performace testing with Arduino Mega boards.

Circles don't live in STL files, that's a fact (as far as I know). In a resume I do see two problems: If there is a circle or cylinder in a 3D object, the 3D designing software needs a way to tell the slicer "Hey, this is a circle, so treat it as a circle!"

If the slicer recognises a circle, it has to decide to either approximate the circle by linear movement on it's own, or let the printer firmare do the job. In this case I'd rely on the slicer more than on the printer firmware, but we have to make the slicers know about arcs.

If you Google for Bresenham's ellipse drawing algorithm, you'll see its possible to do these operations without any trig or even FP calculations.

Most 3D printer firmware already supports the G2 & G3 arc drawing commands. I'm not sure how well they do this -- IIRC some software just turns these into G1 commands of about a mm each, rather than into steps or microsteps.

However, slicers (mostly) don't generate G2/G3 commands, because they (mostly) work from .STL files which represent meshes of straight lines. A slicer would have to somehow figure out whether a series of straight lines represent a curve or not, and what that curve ought to be. The information about the curve has already been lost. So a different file format is needed which represents arcs as well as straight lines.

Hey, this Bresenham's algorithm is indeed a very nice piece of work, I didn't knew this before. This would speed up the calculation of ellipse or circle parts on weak 8 bit processors a lot.
So the main problem remains: In the 3D models there are circles. This information needs to reach the 3D printer, but this will not work with STL files.

Edited 1 time(s). Last edit at 02/02/2017 09:09AM by Inhumierer.

.stl should be abandoned in favor of .amf
G2/G3 only makes sense based on the .amf format