Arcs
-
- Posts: 133
- Joined: 17 Nov 2014, 09:20
Re: Arcs
I could do with arcs because I've only ever used Mach3 for printing.
- Msquare
- Posts: 20
- Joined: 18 Dec 2014, 12:58
- Location: Copenhagen
Re: Arcs
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.
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.
- PenskeGuy
- Posts: 98
- Joined: 08 Nov 2014, 18:04
Re: Arcs
+! (-1?)Msquare wrote:Nahh... vote down.

-
- Posts: 133
- Joined: 17 Nov 2014, 09:20
Re: Arcs
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!
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!