I'll post the pictures later, but as I'm looking at them, I don't see a difference between Octoprint (original) and SD card print. But I've had to use different filament, so there actually are differences, but I think those are caused by the filament itself.
I'll let you decide, if there is anything to see on these pictures 
(a bit more here: https://imgur.com/a/hsGfKWL
EDIT: I've added some more pictures to imgur, comparing anti-stutter and original with octoprint, now I see that some small rounded corners are actually "cut", cam be visible in the front part of the ship and on the top view.
1 Like
Yes, I believe this can be traced back to the MM_PER_ARC_SEGMENT setting (or an equivalent). I see the exact same thing in exactly the same places. The length of those arcs are similar to the default MM_PER_ARC_SEGMENT setting (around 1mm). I haven't gotten around to re-compiling my firmware with a lower setting, but I believe 0.1mm would be adequate. I'm not sure what an optimal value is.
Interesting idea. I was thinking about making a post-processor myself. It would be quite easy to modify the source to take an input path and and output path as parameters. Can you let me know more about what you are planning?
Also, FYI, the algorithm needs a bit more work before it is production ready. I'm still in the tinkering phase.
1 Like
I like the idea of a Cura plugin (post processing script?). If the code could be split into a core, input, and output then input and output could be OctoPrint specific, Cura specific, or TBD specific while the meat of it resided in the core.
1 Like
I dunno. If this is a Cura post-processing script then it's not part of the core Cura functionality. It feels to me like this needs to have its own area within the Experimental section of the Settings and at least one variable which the user can tweak (resolution).
@fieldOfView is the author / maintainer of the Cura OctoPrint Connection so I trust that he can properly interface this with Cura including any variables that need to be set.
2 Likes
By the way, thank you SO MUCH for posting all of those images. That must have been a lot of work, and I appreciate it. That's exactly what I wanted to see when I created this post!
1 Like
Once I get things ironed out, I'll build a console app that will hopefully be usable as a post processor for various slicers. I actually started testing it this way with arguments for source-path, target-path, resolution, and g90/91 influences extruder, which are the only settings it requires ATM.
1 Like
No problem, I've at least tested and seen some other issues I have with my printer 
And btw. I don't know if it was mentioned here before, or if you already have it in feature requests, would it be possible for finale version to have option to set the upper limit of the arc length? My concern is that, with arcs, on Prusa i3, mesh bed levelling doesn't work, it can't compensate for Z during arc move. So I think, if it could be limited for 1-2cm or something like that, it should work fine.
would it be possible for finale version to have option to set the upper limit of the arc length
Yes, in fact, I've made a note of that in the about page (added since the version you installed). I'm considering also adding a minimum length to get around that default minimum segment length setting. I hate adding more settings though. I started with two and it was glorious.
1 Like
@FormerLurker I am very much interested in testing this, both console and octoprint version.
I am currently tweaking curve printing quality, and gone way too far into extremely fine resolution (segments of ~0.1mm in gcode with 5um deviation...). This scratches many limits in the slicers and firmware.
I wonder if Bezier would offer even more compression/lower error in the future (G5). Surely it is currently supported on even fewer hardware, but it will change in the future if benefits are clear.
Although true, Bezier curves add to the complexity of the required math. I'm pretty sure that FL has a tip jar and he likely has to pay rent this month methinks...
@FormerLurker I've tested the plugin, installation went flawlessly, thanks for your work!
Size reduction is enormous on my test part, which contains mainly curves.
From 1.7Mb->0.15Mb. So 10x improvement. 
Unfortunately, I had to use absolute extrusion mode, as it's how Cura generates the code. But total length of extruded filament was not changed.
During printing I noticed significant slowdowns between arc moves, which caused blobs on the surface of the part.
On the image:
On the bottom: Line-based Gcode.
Middle: test1, 0.01mm resolution for anti-stutter, coasting, stock parameters for arc configuration.
Top: test2, 0.01mm resolution, no coasting, 0.1mm arc segment, 49 segments per arc.
I also tested it with Vase-mode gcode. Unfortunately, as arcs could not handle linear changes of Z, it is much less helpful. Update: Incorrect information on Bezier removed. They also do not support Z axis moves.
So while far from perfect, I can confirm that changes of arc parameters in firmware visibly improve surface quality. 1mm segments definitely not enough, and 25 segments per arc are also not enough for large radius arcs.
pack.zip (1.7 MB)
1 Like
Wow, fantastic testing! It is looking like even more extensive testing will need to be done to nail down the proper firmware settings necessary to achieve parity with line segment based prints. Can you send me your test STL? It looks like a great shape to test arcs in general. I would normally write a novel in response, as such a post deserves, but am cooking Nashville fried chicken. Expect a lot more from me tomorrow, and many many thanks for your testing and results.
Before I go, perhaps you could measure the parts for dimensional accuracy? My goal is to preserve the tool paths within the resolution of the printer.
Also, what did you think of the progress indicator? Does it show enough/too much info?
Duty calls. Ttyl, and tganks again!!
@FormerLurker STL is included in the archive. I typically scale it down to 50mm width.
On the dimensions - I do not see any size issues, but it would be hard to notice on single-wall parts. I believe best way to verify size accuracy is via gcode simulators.
Unfortunately, I was unable to test progress indicator yet, as Octoprint is not completely integrated into printer. I run it standalone on RPi3, and printed via SD-card.
Didn't notice the archive, got it now, thanks! Looking forward to experimenting with the firmware settings. That will be new for me. Thanks again!
I'm interested. I still have ramps 1.4 on one printer so I can test old hardware with gyroid infill and stuff.
@BarsMonster, there is actually a setting in Cura for Relative Extrusion. You have to go looking for it in settings since it is hidden normally.
1 Like