Stuttering in curved movements due to Wall Overlap Compensation

[Rdog618]

Application version
Cura 4.3, Marlin 2.0.X Bugfix

Platform
Windows 10 64bit

Printer
CR-10 running on an SKR 1.3 Mobo

Reproduction steps
Any .stl file sliced in cura 4.3 causes stuttering, this only happens in Cura, when I use Slic3r the gcode runs just fine and the part turns out great. I dont like having to use Slic3r but am obligated to because Cura cannot slice without causing severe stuttering on curved segments.

It does not matter how you configure marlin, Cura is absolutely the culprit as every other slicer available generates g-code that runs smooth as butter. If you can think of a variable to change in marlin configuration there is a 90% chance I have already tried it. I have spent more than 20 hours trying to get rid of this stutter and nothing seems to phase it at all. Cura is simply not usable and I am meeting more and more people who have had to abandon Cura as a result. I genuinely would prefer to use Cura over Slic3r.

[smartavionics]

Hello @Rdog618 , please save a Cura project that shows this problem (File -> Save) and then either zip or rename the .3mf file and attach to this issue. Thanks.

[smartavionics]

Also, how are you printing? USB, SD card, network?

[Rdog618]

Printing directly from SD card on motherboard.
Circular Spacer.zip

[smartavionics]

Hello @Rdog618 , please attach the project file (.3mf) not the gcode. Thanks.

[Rdog618]

Circular Spacer 3mf.zip

[smartavionics]

Sorry, that .3mf file doesn't contain the settings. Just the model. Please do File -> Save (not Export). Thanks.

[smartavionics]

Anyway, I am currently printing your model on a Kossel delta and it's printing just fine. All motion smooth. So the problem is most likely to be related to the print settings you are using and the capabilities of your printer. Please provide the .3mf file that includes the settings so it can be investigated. Thanks.

[Rdog618]

Circular Spacer Cura RevB.zip

[Rdog618]

Cura is the only slicer that has this problem. Slic3r and matter control both generate files that print beautifully. I am running marlin 2.0.x bugfix on an SKR 1.3 with and updated stepper library.

[smartavionics]

Thanks for the project file. With your settings, Cura is producing some short line segments which may be causing the stuttering. If you increase the Maximum Resolution setting to, say, 0.5. It no longer produces those short segments. You could try doing that and see if the printing is smoother.

When I printed the same part, Cura also created some short line segments but my printer firmware didn't have a problem with them but perhaps Marlin is more sensitive in that regard?

[The-Force]

I'm having the same problem and changing the resolution didnt fix it in my case. The same file sliced in simplify3D printed without these stuttering blobs, I'm not discarting a marlin issue tho

[smartavionics]

Hello @The-Force , please zip up the gcode from Cura and the gcode from S3D and attach to this issue so I can compare them. Thanks.

[The-Force]

There you go: gcodes.zip
I tried cura versions from 4.0 to 4.4.
Edit: I updated the file as I forgot to add the one with 0.5 resolution (cura 4.4.0)

[smartavionics]

Thanks for the files.

So, whereabouts do the cura gcodes stutter? On all walls? Just outer? Just inner? Infill?

For the S3D file, does that print completely without any problems?

[Rdog618]

I changed my resolution to 0.5, and although it is stuttering significantly less in severity, it is still stuttering far in excess of an acceptable amount.

[Rdog618]

I have noticed it will print interior lines of a circle without stuttering but when it moves to the exterior perimeter then it will stutter heavily through.

[Rdog618]

RollerCura05Res.zip
RollerCura05Gcode.zip

RollerSlic3r.zip

[The-Force]

Here are some images:
[cura 4.3 with 0.01resolution], [closer]
[Comparison between slicers]
Left is cura with 0.5 resolution and right is simplify3d with whatever it uses. Right one has some artifacts in the top of the image and thats all. dont mind the first layers (right) as I had some temp issues there.

[smartavionics]

Thanks for the files guys. Well, I don't currently have a good theory for what's going wrong here other than the thought that it could be related to Marlin not being happy with short line segments that vary in length quite a lot. The wall overlap compensation tends to introduce short lines even when the resolution is quite coarse so it could be worth disabling that to see if it makes a difference.

[The-Force]

@smartavionics it did nothing to me.
Can you explain how maximun resolution and deviation works? because I don't understand it. I played with those settings and the preview to see the changes and at first changing only maximun resolution did nothing until I changed deviation. Setting both at 1 did made a great improvement in surface quality but lowered the resolution of the model a lot and some details started to dissapear.

[smartavionics]

max res and max dev are used to control how polygons are simplified in cura. The wall outlines are then created from those polygons. By simplified I mean that the number of points in the polygon are reduced. This speeds up the slicing and also makes gcode files smaller.

max res specifies the lower bound on the length of lines in the simplified polygons. Lines shorter than this will be merged with their preceding neighbour line as long as the resulting line does not introduce too much deviation from the original polygon outline.

max dev specifies the maximum amount of allowed deviation from the original polygon that is allowed when it is simplified.

So if you keep max dev quite small, using a larger value for max res should simplify the polygons without sacrificing too much accuracy. As you have found, using a larger value for max dev leads to inaccurate outlines.

Note that the simplification routine used in the UM cura builds contains some bugs that I have already fixed in my cura builds (which are available at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0, please read the README.md file in there for more info). Unfortunately, I don't think my cura builds will help with your current problem but you could give them a try.

[Rdog618]

@smartavionics Are you an official representative for cura by chance?

[smartavionics]

@smartavionics Are you an official representative for cura by chance?

Not at all. I'm a contributor of new features and bug fixes and I provide some user support like I'm trying to do on this issue but have no official connection with UM whatsoever.

[Rdog618]

I was just curious if you have the capacity to escalate this issue to a higher support level because it's an inhibitory problem, if we have to abandon cura that's going to effect our next 3d printer purchase pretty heavily.

[smartavionics]

The UM Cura devs will read this issue thread so they will be aware of it. However, unless the issue affects all printers and/or UM printers, they will be hard pressed to put much resource into solving the issue. The bottom line is that issues that are specific to a non-UM brand of printer need to be fixed by the community.

[smartavionics]

Just a thought, could you please try enabling Relative Extrusion. That is supported by Marlin and should work on your printers.

Also, do you know what the steps/mm value of your extruder is ?

[eskeyaar]

@smartavionics I also have these stuttering issues when printed from USB Cable. I think i have also noticed same in Ultimaker 2+ when printed from USB cable. am still figuring out is it cura issue or its the host which sending gcode.
Where do i adjust the max dev in cura?
Thanks

[smartavionics]

max dev in the latest release is in the mesh fixes section.

[eskeyaar]

max dev in the latest release is in the mesh fixes section.

ah thanks.

[Rdog618]

Was a cr-10, with the duet 2 wifi its kind of irrelevant.

[Rdog618]

I am running a zesty nimble on the extruder, 2677 steps per unit for the extruder

[Ghostkeeper]

I also find it odd that even though I am specifying 40mm/s, the duet wifi says the requested speed is 30mm/s and is moving at said speed.

It seems to be limiting the speed due to the Minimum Layer Time setting.

[eskeyaar]

@smartavionics I also have these stuttering issues when printed from USB Cable. I think i have also noticed same in Ultimaker 2+ when printed from USB cable. am still figuring out is it cura issue or its the host which sending gcode.

With USB cable printing, the g-code is also limited by the processing speed available on your computer. If you notice that Cura's interface is stuttering while printing via USB, this could be the reason why your printer is stuttering as well. USB printing doesn't normally require a lot of processing power though (it's about 10% CPU on my 6 year old laptop).

Smartavionics gives a good explanation of Maximum Resolution and Maximum Deviation. It should be mentioned also that Maximum Deviation overrides Maximum Resolution (so it should never deviate more than the Maximum Deviation even if line segments become shorter than the Maximum Resolution). My own articles in the Settings Guide about these two settings are here:

* [Maximum Resolution](https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/meshfix_maximum_resolution.md)

* [Maximum Deviation](https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/meshfix_maximum_deviation.md)

Unless the cause of the stuttering can clearly be shown in the g-code, we can't really help you with debugging your printer. If you know of a case where our current algorithm is still producing too many segments we can look into it. But otherwise not.

The stuttering may also be caused by having weird line directions or speeds. That sometimes occurs in the gap filling technique in Cura, which is a known issue. Maybe that is the case?

i have to see how the gcodes are produced and as @Rdog618 forementioned, same for me as well, printing infill , inner walls prints fine without any issues, but when it comes to outerwall it does stuttering on curved parts.
I need to play with max res and max dev yet, thanks for the article. i will keep you posted if i find stuttering issue still.

[Rdog618]

Decreasing the max res produces a pretty terrible surface finish, even more so than the blobs of stuttering. Upon further investigation I've come across numerous instances of people reporting stuttering because cura is producing unreasonably short line segments in curves. https://forum.duet3d.com/topic/7514/movement-is-stuttering-appears-to-slow-printing-down

[smartavionics]

I have sliced and are currently printing the model in Roller3mf.zip. I have sliced for 2 machines, an SOVOL SV01 controlled by a 32 bit Marlin board and a Kossel mini delta controlled by a Duet.

Both were sliced using 0.05 for max res and 0.05 for max dev, layer height 0.2 and overlap compensation and gap filling enabled.

The SV01 used 0.4mm wide lines, the Kossel 0.5mm wide lines (no rational for the difference, that's what the profiles contained).

Both are currently printing smoothly with zero stuttering.

I am using my Cura not, UM's.

[smartavionics]

I should add that the SV01 is printing over USB from a Pi running Octoprint and the Kossel is printing from the SD card.

[smartavionics]

I am sure that the stuttering is caused by the wall overlap compensation creating small line segments. Some time back, I came up with a simple fix that reduces this problem but it's only beneficial when the model's wall thickness is an exact multiple of the wall line width. That simple fix (Ultimaker/CuraEngine#904) was rejected by the UM devs so it's only in my builds anyway.

The bottom line is that if you use the overlap compensation, Cura will create short line segments for models like Roller3mf that have curved walls where the inner walls touch (i.e. there's no skin or infill between the inner walls). YMMV

[Rdog618]

Disabling "compensate wall overlap" finally solved this problem. It is printing as smooth as butter now. I would like to thank everyone who helped. This has been a real head basher of frustration going on for 3 months now. Its spectacular to finally see it running smoothly again. Cheers fellows!

[tablatronix]

I am having stuttering with cylinders, I turned off optimize wall order and it started printing concentric again, I think its a bug

EDIT: nope, I changed the diameter for testing!, so let me create 2 test models, might be on to something

[tablatronix]

So it is really strange, So same model, I export as different diameters(not resized), the large ring does it, the inner one does not.

The large ring only does it on half the circumference and it dithers in and out.. Does not change with layers, same location.

Gonna check seam alignment and see if any change

[tablatronix]

I have disabled or changed everything I can think of, no change

[Ghostkeeper]

The large ring only does it on half the circumference and it dithers in and out.. Does not change with layers, same location.

This effect happens when you have a shape that is designed to be EXACTLY an odd number of lines thick, and then discretise the curve differently on the inside corner than on the outside corner. As a result, the shape will be slightly thinner in some places than in other places. And because the shape was exactly an odd number of lines thick, the line in the centre will fit only in certain places. The middle will then consist of small elongated circles.

CuraEngine will vary the line width by 10 microns in order to make the line width fit better to resolve rounding errors. However if the actual model shape is wrong it's expected to make these circles.

[tablatronix]

A bit over my head, so since this is just a ring is this "then discretise the curve differently on the inside corner than on the outside corner." Coming from fusion ?

Why does the smaller diameter ring not exhibit the same issue and can print 3 concentric walls properly?

[tablatronix]

So I should be able to compensate by adjusting Line width, but then I will have 4 walls instead of 3. Any other way to get 3 walls like the smaller ring?

[Ghostkeeper]

Cura always generates an even number of walls, except by the gap filling technique (the lines appear in yellow then) but that technique is often unreliable to create a good, single, consistent line with curves like this.

To get exactly 3 walls normally I'd give it a line width that's slightly below 1/3rd of the thickness and then enable overlap compensation (precisely the setting that was discussed above and giving problems) and set the Minimum Wall Flow to 50% or so so that the compensated line becomes a travel move instead.

[Ghostkeeper]

A bit over my head, so since this is just a ring is this "then discretise the curve differently on the inside corner than on the outside corner." Coming from fusion ?

Yeah, the CAD tool needs to turn curves into flat triangles (=discretising). If the corners of the curve are not exactly opposite of each other, the ring will be thicker in some places than in others.

[tablatronix]

ahh, I think I see now how fusion is doing this differently at larger diameters, interesting.

You can see the symmetry of the discretising is totally different.

[tablatronix]

I am still having issues with cylinders, I was able to fix the discretizing in fusion by making sure refinement created symmetrical order for 3 walled cylinders. Then I have a new issue and had to disable wall overlap compensation to fix it. The problem I have now is my seams are very weak. Is there no way to stagger alternate or stairstep the seam ? I want them inline but cannot seem to get cura to overlap the seam eg. like a pretzel to make it stronger. It will only stop and reverse on outer AND inner leaving a weak seam. Any ideas?

[tablatronix]

I went back and tried the original suggestion n case I did something wrong last time, and it seems to be working great now, I think I was missing the min wall flow last time. Comes out perfect at 80mm and strong seams, unsnappable.. Going to try a large one now and see how it goes.

To get exactly 3 walls normally I'd give it a line width that's slightly below 1/3rd of the thickness and then enable overlap compensation (precisely the setting that was discussed above and giving problems) and set the Minimum Wall Flow to 50% or so so that the compensated line becomes a travel move instead.

[Ghostkeeper]

The minimum wall flow should in my opinion be set to 40% or so by default but it takes a lot of testing to get that through for Ultimaker so it's not going to happen soon.

The "pretzel" idea doesn't work in the general case where opposite walls are not close to each other. However we do have an open feature request to (not) reverse the print direction for inside polygons: #1867 This would end up more or less at what you're thinking of, if I understand you correctly.

[brgavino]

Is there a plan to fix the generation of filled wall segment, and their subsequent print order? I appreciate @Ghostkeeper explanation of the erratum above, but if this is a defined case, could not a post-process be put in place to correctly chain wall segment construction? (Sorry for bumping an old issue)

[Ghostkeeper]

We have a plan to fix this issue in a completely different way, but it's a big change of 11.000 lines of code. See the pull request here: Ultimaker/CuraEngine#1210

[nallath]

This has been fixed by the fixes for #8321

[TonyK54]

On an Ender 5 Pro running TH3D's firmware (Marlin based) Cura 4.12.1 is showing this issue. I don't even get past printing the skirt before I abandon the print. I'm hoping the suggestions here resolve it as I have a print I believe will benefit from Tree Support which Prusaslicer does not have.