kisslicertalk.com

So I know you stopped working on arcs, but right now is a good time to come back to it, because firmwares luke repwtier now fully support arcs, and there are some powerful controllers for repraps now, like ramps-fd, melzi v2, smoothyboard, etc.

I could do with arcs because I've only ever used Mach3 for printing.

Nahh... vote down.

My understanding is that the STL file does not have circular information in it. So when you have made a circle/cylinder, it consists of 8 or 80 or 200 straightline segments (using two triangles each) The slicer would have to recognize the pattern and then fit a circle arc to the points, and lastly generate the arc info. There is a heap of problems : What threshold should it substitute straightline segments with arcs? How large a segment of a circle would it need? If you have made an elliupse, at which point will it incorrectly substitute it for circles ... or several short circular arcs?

Of course if the input format does have arc info ... (I do not know - does AMF?)

The Arc movement is, or rather was, there for people handcoding the Gcode. This is the way it was done back in the 70'ies when you could handcode Gcode for milling machine to do - f.ex - a rectangle with rounded corners. No fun hand calculating and entering 20 points to do a round corner. (I know - that's what I did back then)

The size capacity of the USB/SD cards mean the list of short segments that make a circle is good enough. I cant see polygons at 100+ and my USB/printer does not slowdowe due to large number of Glines.

Msquare wrote:Nahh... vote down.

+! (-1?) IOW, I agree. With the relative "sloppiness" of FDM resolution inherent in the process, a series of small segments cannot be distinguished from an arc. Try it. Set KS's Oversample Resolution to a successive series of increasingly really low numbers on a high resolution mesh and try to see where it stops getting smoother. Once you are past the threshold, it's an arc. You can overkill it, but what's the point?

I found a python script called g1tog23.py that does an arc conversion. http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinesToArcs

It misses some feedrates in the conversion like changing travel move feedrates to the speed of extruder retraction. This caused some stringing. Some other bugs in the conversion as well.

In the parts of the print that were good, there really is no difference in quality compared to a segmented gcode print. It may run on the printer a bit smoother, but I'm not printing anything over 30mm/s

Confirmed G2 and G3 moves, printing with MACH3.

-1!