Was about to ask where I can get the plugin to give it a try. 
Printing Face Shields pretty fast (Prusa Research settings for mk3s) and was wondering if it smooths the movement somehow. The printer is not really stuttering but I'm curious to see what happens with gcode optimized by your code.
You may read this thread - ok, maybe the last few ones. 
Just because I didn't reply before he posted a github release?
The thread grows long. Easy to miss a recent post! Glad you found it 
Edit: maybe i should edit the OP to include the link?
1 Like
You should definitely do that.
This has been done!
Oops, sorry - misread the first line...
1 Like
For what it's worth, I've been printing mask parts for the last three days now with an earlier version of this plugin and I use the converted gcode without fear. It produces cleaner, smoother parts for me.
1 Like
I did test the plugin and works like a charm
optimizes gcode well, stutter is gone
using Slic3r, was suprised what garbage it can produce on curves
thank you for your work
1 Like
@FormerLurker You may have answered this already, but I can't find it. Is there any way to convert an already uploaded file, or do I have to download the file and re-upload it?
That feature does not exist yet, but i am working on these missing but obvious features now.
Five-hour print. Beautiful/smooth finish with no signs of interruption (not that I had any problems earlier in that). Toward the end it was really moving quickly, like around 90mm/sec perhaps. I was occasionally watching the Terminal and it was almost all G2/G3 instead of G1 above those triangular shapes at least.
Before: 14,792,916 bytes
After: 4,019,589 bytes
Reduction: 27% of original file size!
1 Like
I am currently printing 3DBenchy using the Anti Stutter plugin and I must say it certainly looks promising!
My printer is a $99,99 TronXY X-1, driven through OctoPrint on a Raspberry Pi2.
Once printing has completed I will upload pictures of the regular print (7.4MB-file) as well as the AS-version (4.1MB-file)... 3 more hours to go...
Seems like the plugin worked well. The new print looks even better than the first one!
Blue = old, Glow-in-the-dark = new
2 Likes
I finally got around to trying this out. I printed the test print for the famous collapsible sword. I felt this was a good test since it prints 3 cylinders, nested in each other. The file size was 2.9mB and became .3mB.
The front part of the cylinders looks like they had a slight improvement. However, the back, where the z seam is located, appears to be much worse. Hopefully the pictures show it, but it almost seems like some kind of under extrusion right before the z seam.
And the strangest thing is that in the before-arc print, the nozzle would just go back and forth in the circle in very smooth motions. However, on the arc-enabled print, it would make a circle, but when it started to approach the z seam it would noticeably start slowing down over the course of about 2 seconds. Because of this, the print took a few minutes longer. Whatever that slowdown was is what caused the poor print quality but I’m not sure what made it do that. Could it be linear advance?
These 2 pictures are the same thing, but one of them, I am blocking the light with my hand to reduce glare. The top ones in each picture are the arc-enabled prints.
You aren't the first person to report this unfortunately. I'm trying to figure out what is going on, but I suspect some firmware issues unfortunately. I think what we need is the smallest possible gcode file necessary to replicate the issue. Maybe you could creat an issue on GitHub, or join in in the existing one, and help me create a test gcode file?
Edit: it could be linear advance (set k=0 to disable), junction deviation, or other firmware settings. It doesn't seem to happen with every printer. Figuring out exactly what the issue is will be the first step to fixing this. I wish it were the gcode itself, but i have seen no evidence of that so far.
Could this be it? If so, it would be extremely easy to swap out 0.0 for seg_length in g2_g3.cpp!
Edit:. The latest code only uses 0 for the final segment length. The commit was quite recent.
I don’t know if that is it. My slow downs and speed ups are no where near that jerky. It’s pretty smooth.
But I can definitely test if you need me to.
Ok. So it looks like those 2 settings you guys were discussing in the firmware might have caused the problem. I just had the defaults for those for marlin 2.0.5.3. I changed the mm one to what you suggested and the other was 24 and I bumped it to 64. Not sure which. But the quality is perfect now.
64 is a bit high for very small circles, so you may see stuttering in other prints. Try 24-36 if yo see any slowdowns cornering tight radiuses.