[4.4.0] Cura produces way to many segements/commands and makes printer stutter

[TheAndi]

Application version
Cura 4.4.0

Platform
Windows 10 64 bit

Printer
ANET A8, Sidewinder X1

Reproduction steps
Slicing a cylinder like object

Actual results
The result is in this example a gcode consisting of ~350k lines. This is too much for my ANET running octoprint with a baud of 500k (usually this is not a bottleneck). And it's also too much for the Sidewinder X1 as it also receives its commands via serial (250k baud) from the touch screen.

I noticed that there is a massive stuttering at the outer layer (not the inner one) so I checked the gcode on http://gcode.ws/ :

As you can see there are tiny segments in between the "main" segments, leading to about double the gcode lines as Prusa slicer (see below)

I also altered the resolution (and deviation) which didn't shrink the line count significantly
I already used rather coarse values for the example above:

At some higher values the line count event starts increasing as small bits of infills are generated:

So these values are not the solution.

Expected results
Because I couldn't get this object to print with Cura. I tried it with Prusa Slicer 2.2 and the print worked smooth right out of the box with similar setting. Gcode was just ~170k of lines.
A look at the gcode (same section) reveals that everything is fine here:

The segment count (resolution) in this section is the same as in Cura but without these "extra segments"

Additional information
Something I noticed, which might help to find the bug.
It seems like the outer contour copies all the segment nodes from the inner one:

Is there any option to fix this?

Thanks in advance

[smartavionics]

Yes, please try turning off the wall overlap compensation. That's what's creating those tiny segments in the outer wall. Also, did you try one of my builds (which can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0). They have a partial fix for this issue. If you want to try one of those, please read the README.md there.

[TheAndi]

Thanks a lot, this setting immediately halved the gcode and should print smooth. Why is this feature used? And do I have drawbacks from disabling it?

Some more thing, while turning of this feature solved all these problems in the wall. There are still "to many" segments in the skirt, making it stutter.

(First layer with skirt)

Not as important as the walls, but maybe there's a fix too?

[smartavionics]

Thanks a lot, this setting immediately halved the gcode and should print smooth. Why is this feature used? And do I have drawbacks from disabling it?

This feature (overlap compensation) stops overextrusion when 2 walls won't fit in the gap available. e.g. if the gap is 1.5 walls wide, the first wall will be printed full width and the second at 1/2 width. It often works OK and is definitely beneficial for some models. Unfortunately, the implementation is pretty buggy and badly documented. My Cura builds have some of the bugs fixed but not all.

Some more thing, while turning of this feature solved all these problems in the wall. There are still "to many" segments in the skirt, making it stutter.

AFAIK, there are no settings that will reduce the number of segments in the skirt other than the max resolution and max deviation settings that affect the whole model.

[Ghostkeeper]

As far as I know, the overlap compensation should only kick in when the angle between the lines is less than 90 degrees. When checking for the overlap between two lines, the one line is projected on top of the other. If two subsequent lines have an angle of more than 90 degrees the overlap should become 0 and there will be no overlap compensation. There might be a bug in there somewhere then.

I can't reproduce the problem though when I slice a simple 360-segment cylinder. Every line of the wall has pretty much exactly the same length. No overlap compensation seems to be happening. I tried both the outer wall and the inner walls. Perhaps you could share a project file?

[XDA-Bam]

I think I have the same problem with Cura 4.5. Wall overlap compensation is disabled. Happens only on certain layers of the object and only on certain parts of the curve. Model and settings see project file.

When I slice it, the problem occurs around layer 125 +-10 and looks like this:

A couple of layer above or below, it's totally fine again:

Looks like Cura, as mentioned by the OP, somehow duplicates nodes from the inner wall to the outer.

[Ghostkeeper]

This algorithm is mostly rewritten for Cura 4.7. Hopefully that fixes things for you. This is not in Cura 4.6 yet, mind.

One of the things that was fixed was that there could be an extra vertex or two around the seam. Maybe that's what you're seeing.

[chrisdalke]

I've also experienced this bug, wherever Cura generates a very tiny line segment on curved models it causes the printer to skip. While this is odd slicer behavior, it's also unexpected that a short line segment like that would cause the printer to skip. I've investigated and each "zit" on my print corresponds 1:1 with a short (<1mm) line segment in the gcode.

Some additional context for anyone else who follows on the same path I did -- An explanation why the bug only appears on certain printers could be this Marlin bug (already linked above) which was introduced in more recent firmware:

MarlinFirmware/Marlin#17920
MarlinFirmware/Marlin#17342
MarlinFirmware/Marlin#17146

In those threads, they discuss how the acceleration/jerk algorithm is incorrectly calculating speeds at the vertices for very small line segments in the middle of longer line segments on curved lines (see this comment that has a diagram: MarlinFirmware/Marlin#17920 (comment))

One step to reproduce this may be to test on printers with more recent Marlin firmware (>=1.1.9 seems to be the threshold where this bug appeared). Anecdotally, this happens for me on my printer (Ender 5) ever since I updated from the factory firmware. I am unable to reproduce it on an Ender 3 with 1.1.8 firmware.

[XDA-Bam]

An explanation why the bug only appears on certain printers could be this Marlin bug (already linked above) which was introduced in more recent firmware:

There recently (roughly April to Mid June) were problems in Marlin, which caused excessive stuttering on curves when using "Junction Deviation" instead of "Jerk" for speed limiting. Those are now fixed, but the problems with tiny segments still exist when using Junction Deviation - because it's not really a bug in Marlin.

The problem is, that the slicer (Cura in this case) incorrectly distributes the angles between segments along a curve. This is either a slicer bug, or somehow related to the fact that we are slicing already discretized curves (-> STL files). It's not only present in Cura, but very prominent there. Also, vase mode for example does seem to be affected much less or possibly not at all - which supports the idea that this is a slicing problem.

In those threads, they discuss how the acceleration/jerk algorithm is incorrectly calculating speeds at the vertices for very small line segments in the middle of longer line segments on curved lines.

It may seem that way at first, but the calculated speeds are correct in the mathematical sense. The problem is, that Marlin Junction Deviation calculates the curvature for line segment pairs, in case the second segment is small (< 1 mm) and the angle between the two segments is large (> 135°). And on some of those tiny segments, the curvature the slicer has produced is simply incorrect - along a smooth curve, it is mostly consistent and then increases rapidly on that one tiny segment. Then, it's mostly fine again until the next tiny piece comes along.

This slicer inconsistency / bug leads Marlin to believe, that the curvature is extremely high in some locations, causing the print to slow down at the beginning of the affected segments. This is technically the correct behaviour - but the result still sucks. Therefore, I'm eagerly awaiting the new slicing code in Cura 4.7 and also hope that some Marlin devs got the time and motiviation to improve Junction Deviation further.

[chrisdalke]

Got it, thanks for the detailed explanation!

[brunoosti]

Had no luck with cura 4.7.
Reverted back to classic jerk and have my prints surface smooth as it should be.

[chendo]

Having issues with still with 4.7.1 which I've noticed when printing via Octoprint on my Ender 3 v2. However, same gcode when printed via SD card has no issues for the models I'm testing with, which appears to be an issue with USB buffers not big enough. However, same model sliced with PrusaSlicer prints fine over Octoprint.

Octoprint is running on a desktop-class machine, so it appears to be a combination of complex gcode from Cura and Marlin buffers, at least in my scenario.

[fabioglopes]

I had the same issue printing the benchy hull. I increased the serial buffers on marlin configuration as I am using an external BTT TFT35 and I also increased Maximum resolution and Maximum deviation to 0.25mm on Cura and it solved the problem even with junction deviation enabled.