My guess is the filament length tracker doesn't understand G2/G3, so the E values weren't included.
2 Likes
Ah, that makes sense. Sounds like something that needs fixing then.
1 Like
Yes, the aside of the bottom layers, it only consists of circles.
As I remember, the left was the original one, the right is converted. They look quite the same. The seam on the left is the layer change.
Shh... the plugin means that your parts cost less now.
1 Like
For anyone who would like to try the STL file I have been using, here is the link:
1 Like
So, I just finished up a version of Prusa firmware that (hopefully) fixes arcs. I was getting lots of stuttering when adjusting MM_PER_ARC_SEGMENT, so I implemented MIN_ARC_SEGMENTS, which exists in a similar form within Marlin 2.0, and will do a pull request once it's completely tested. For anyone interested, check out this issue. The results (both before and after) were quite surprising and encouraging. Be sure to thumbs up if you'd like to see the feature included in an upcoming firmware release.
So does this mean we won’t need to recompile firmware after this feature is added to your plugin?
If your firmware can't print small arcs accurately like mine, it will need to be fixed and flashed unfortunately. Mileage may vary, but for me I have issues only for small curves with a small radius. Marlin 2 seems OK from the reports I have seen here, but my printer (MK2) needs a firmware fix. I will submit a pull request probably soon with my fix. This could be applied to most firmware based on marlin 1.x i believe, if they are using a similar mc_arc function in motion_control.cpp. I would be happy to help anyone with the desire to get their firmware patched.
Im not sure about other firmware, and I think those of us with this issue are in the minority. It is possible that this was fixed in a later build of marlin 1, but i would have to go down the firmware release rabbit hole to figure that out
Nice! It looks like your firmware also has MM_PER_ARC_SEGMENT set to 1mm, which is why the corners on the roof are straight, and the front of the bow is slightly off. But other than that, it looks like a quality boost!
I see it, ignorance was bliss. 
1 Like
I think most people will have this issue. I’m on nearly the latest Marlin and it is set to 1mm. It’s not a big deal for me to recompile but I just wanted to confirm that I needed to.
please , please, please send me the DM I will check it, my octoprint needs this badly, sttutering like mad.. Many thanks for the hard work!
LS
So here are the results of the AntiStutter Challange:
Used: Prusa MK2.5S MMU2S, layer height 0.2 mm and standard AntiStutter settings
3 Likes
Hi man, thanks a lot, done my first test:
- I need to artivate arc support in my firmware.
- In a relatively not complex piece the size moved down from 6.4 mb to 6.2 with the standard resolution of 0.05 in the setup. Cannot print it till the firmware is being changed
- Interesting finding.. changing the resolution and saving the setup, from 0.05 to 0.5 mm did not produce any change on size.. did a bit by bit comparison and files are 100% identical, so seems that the setup is not storing the resolution change or stucking with a hard coded value?
Other than that I need to upload new firmware with the arc support activated. Stay tuned!
Tx
note: ist 4.53 am here, need to take some rest, so my test will take a while 
EDIT 1: Changed firmware of my Artillery X1 to 2.0.2 with bltouch support. It accepts arc gcodes on first try. Printing now... ETA prediction is more or less the same, but I can perceive a much smoother operation than with the normal gcode, not so... jerky I would say. Cura stting are the same, on both cases with deviation and resolution to 0.2 ( cura 4.5). Long print will take a while to see both results. will keep u posted.
When you activate arc set MIN_ARC_SEGMENTS to 32. The default of 1 for MM_PER_ARC_SEGMENT should be OK then. You'll get large segments for larger arcs, and small ones from smaller arcs.
That is a very small reduction. If your gcode is printed using vase mode, anti-stutter won't be able to create many Arcs. Some firmware allows arcs with changing Z heights, but not many. Additionally, there are checks in AntiStutter that explicitly prevent these kinds of arcs from being drawn. I'll work on that limitation at some point, but for now it won't work.
Id be interested in testing this as well
agree the reduction is very small, but it the default one on the plugin... moreover, changed it to something way bigger (my initial intention), is no producing any change on the gcode, no matter which setting I choose in your plugin all generated gcodes files are identical... not sure if you can reproduce the problem or is just me... weird anyhow, any idea? I mean... if I choose 0.05 resolution (plugin default) the file generated is identical o the file generated with a 0.4 resolution, and in my understanding the 0.4 one should produce a way smaller file, not the same. I am not using vase modefor the printing. thanks man!