SLIC3R gcode_arcs

USE SLIC3R gcode_arcs,
I would like to use gcode_arc=1 in a currently defined configuration. The gcode_arcs option is not one of the options displayed during settings of selection. But, I do see it at the tail end of the GCODE output (with the gcode_arc =0 which I don't want). I have tried modifying currently exported configurations but they do not seem to take, an edit of the GCODE produced has gcode_arc=o. Is there anyway I can make a simple change and take advantage of Arcs (G2 G3 GCODE commands).

I don't see how that would be possible, because Slic3r uses STL files as input which do not contain any information relating to arcs. An STL file describes the 3D part as a (often very huge) collection of straight-sided triangles, and an arc is therefore represented as a lot of short straight lines. There is no way for Slic3r to know whether the polygon section that results should in fact be an arc. e.g. if I have a circle that is represented in an STL by 6 straight lines, how will Slic3r know that it is meant to be a circle and not a hexagon? How about 8 sides? 10? 20? 100? 1000?

If you are finding that arcs come out pretty rough, blame the application that created the STL, not Slic3r. Many 3D CAD applications model circles internally as multi-sided polygons, (and always have to do so when exporting as an STL), and some do not give enough sides to the polygon to make it appear as a smooth arc. The (free) OpenScad 3D modelling application allows you to specify how smooth to make each round object in the design - the smoother they are, the longer the time needed to render and also the bigger the STL file will be. Give the arcs enough sides and you will see absolutely no difference in the print speed or result than if the arc commands had been used.

Dave

I sorry, I wasn’t clear, Slic3r has a parameter “gcode_arcs=0” with a zero (FALSE) being the default. I would like to try a slice with it set to “1” (TRUE) and see what it can do for me. If it did manage, Slic3r that is, manage to detect any arcs there will be a change in the arcs. Could be better or worse and the only way I know to tell is to try it.

Quote
XR750
I sorry, I wasn’t clear, Slic3r has a parameter “gcode_arcs=0” with a zero (FALSE) being the default. I would like to try a slice with it set to “1” (TRUE) and see what it can do for me. If it did manage, Slic3r that is, manage to detect any arcs there will be a change in the arcs. Could be better or worse and the only way I know to tell is to try it.

No, you were clear, but as I said, I very much doubt that Slic3r could detect what is an arc in order to send such G-codes, which is maybe why that parameter cannot be changed. They would need to be generated by a slicing application that reads a different 3D model file than STL.

Dave

A simple google search "Slic3r arcs" takes you to the developers github with this explanation of why it is not a good idea

Slic3r Github

Edited 2 time(s). Last edit at 02/07/2015 05:39PM by justcurious.

Conversely [blog.freesideatlanta.org] does reflect some success.

Maybe I should rephrase my question-
“Can a Slic3r currently defined configuration be edited, imported and sliced with.

XR750

Quote
XR750
Conversely [blog.freesideatlanta.org] does reflect some success.

Maybe I should rephrase my question-
“Can a Slic3r currently defined configuration be edited, imported and sliced with.

XR750

Yes. Go to "Files" and export the configuration(s) to wherever you want. Edit the exported file with a text editor. Go to "Files" and import the configuration(s).

Dave

Slicer can output to a post processor; convert line segments to arcs

G1toG23

[wiki.linuxcnc.org]

Quote
compton
Slicer can output to a post processor; convert line segments to arcs

G1toG23

[wiki.linuxcnc.org]

It looks promising, but I haven't gotten it to work quite right on my Ultimaker.

It will definitely replace lines with arcs, but strips out the extruder distance calls. I tried modifying "g1tog23.py" to replace all "a" and "A" with "e" and "E".