Has anyone tried the --gcode-arcs option in Slic3r lately? I’m trying to see what kind of (approximately) curved surface I need in a .stl to trigger it, but haven’t had any luck finding G2 or G3 codes yet…
I would avoid it, at least until the firmware actually supports arcs. Currently it just breaks them into segments, meaning it saves you a bit on communication at the cost of model fidelity (the segmentation of the arcs will be different, and you can’t avoid affecting the diameter in this process).
The fine segments seem to overwhelm my usb connection to my arduino sometimes, and even worse are the little ripples that appear at every corner. I’d thought that maybe Marlin could smooth out the extrusion rate better than Slic3r seems to. Perhaps it’s just my settings.
@Michael_Hohensee you might actually just be experiencing lag in the host software if you’re using pronterface and you’re using something underpowered like a netbook.
Try, instead of running pronterface, run pronsole (console version) and starting your print from there. “help” will give you what you need to get a print started. If it runs fine from the console, then the problem is the gcode live view causing your machine to lag.
Also, have a look here: http://blog.lincomatic.com/?p=773 – Look at “acceleration and jerk” - that should be enough to get rid of your waviness on 90 degree corners.
As I explain in my post about hand crafted G codes, I think that slicing software trying to figure out arcs from .stl is doomed to failure:
Derrick Oswald: Probably true for .stl, since that format cannot represent curved surfaces. I mainly want to see whether the print quality can be improved if I could actually access Marlin’s arc codes. Maybe for .amfs. Bezier curves would be ok, but to do it right, you’d have to design your piece with the bezier’s that the hardware can support. This isn’t necessarily a bad thing.
Anthony Morris: You’re probably right about cutting my jerk settings down. But wow, I have to lower them a lot to make a difference. I’m using a MM1.5 with 8mm rods, and I still get rippling (a bit less) when I cut the xyjerk to 8 mm/s^2.
No, apparently not .amf either…
“The format maintains the triangle-mesh geometry representation used in the STL format in order to take advantage of existing optimized slicing algorithm and code infrastructure already in existence.”
The code in the mentioned post emits G2 and G3 codes directly.
AMF does use STL-like geometry, but has (optional) support for curves rather than straight lines connecting the vertices.