Most 3D printers approximate a curve with many short line segments. I was printing a pretty simple part at moderate travel speeds (up to 80 mm/s) and my printer started stuttering on the curves, causing blobs. I knew my printer could handle speeds above this.
After several hours of troubleshooting after a print, I’ve realized that poorly approximated curve profiles caused my printer to stutter. I determined it wasn’t an issue with accelerations, or printing over USB versus SD (speed 10), or poor input file quality, etc.
The single factor that made the printer stutter around curves (with speeds above 60 mm/s) was entirely related to how smoothly the arc was generated. I validated this by creating four rounded rectangle shapes using profiles from 3 popular slicers and one I generated on my own (in Microsoft Excel and used Concatenate to create gcode commands to send to the printer without extrusions). I can get the printer to travel in curves very smoothly with my custom profile. If I offset a point just slightly, the printer really has to decelerate/accelerate for it.
The curves generated from Slic3r, Makerbot, and ReplicatorG all seem to do a poor job of getting a good arc profile. It seems more to do with whether the points lie exactly on the arc rather than density of points in general (once you have enough of course). Does anyone have a recommendation of a slicer or settings on a slicer to improve the profile of an arc? Is there some other resolution?
Sounds like the problem was resolved on your own with a modified gcode and that the underlying problem could lie with the slicer. You could post a test file here and I could slice it for you using Simplify3D if you would like, that should rule out if it is an inherent issue with software in general.
Chris
I finally realized after much troubleshooting what the underlying reason was that allowed my modified gcode to perform better. It actually wasn’t that the arcs were smoother (although they were, slightly); it was that I had fewer points connecting them as well. It seems that having fewer points allows the firmware to plan ahead better (or not have so many short jogs to make). I reduced the slicing resolution from automatic or a very fine slicing to half of the resolution of my model (so around 0.05 mm). This resulted in fewer points that the bot had to travel to, without affecting print quality. I also noticed (after playing with acceleration and jerk) that very low jerk values are not helpful as they just cause blobbing–I thought that lower jerk settings (technically instantaneous change in velocity setting in Slic3r) might help, but it was the slicing resolution after all. Hopefully someone will find this helpful as well, since the resolution setting didn’t have much discussion that I found online.
