Cura: [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:

https://github.com/MarlinFirmware/Marlin/issues/17920
https://github.com/MarlinFirmware/Marlin/issues/17342
https://github.com/MarlinFirmware/Marlin/issues/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: https://github.com/MarlinFirmware/Marlin/issues/17920#issuecomment-642276211)

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.

[XDA-Bam]

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.

By decreasing the resolution / increasing the max. deviation, I would bet that you are essentially eliminating those tiny segments Cura otherwise squeezes into curves. Thereby, the junction angles are overall increased and Cura is forced to distribute the angles differently between the segments.

I have calculated that the angles between those tiny segments and the preceding/following longer ones found when using the default Cura settings are incorrect. They do not represent the appropriate curvature of the curves or circles (illustrated explanation here, example file which produces problems in Marlin when usding JD here). As JD relies relies on the curvature to calculate the junction speed (for segments below 1 mm in length), printers running Marlin with JD often stutter on curves with Cura GCode. This may also be influenced by how the STL is sliced and how Cura handles the STL.

The Octoprint thing is different from this geometry/angle problem: In that case, there are just too many of these tiny segments, causing the Marlin buffer to run dry, which causes slowdowns during printing.

Reducing the resolution and increasing the allowed deviation is a solid workaround for most people. But the problem in Cura is still present.

[Ghostkeeper]

I have calculated that the angles between those tiny segments and the preceding/following longer ones found when using the default Cura settings are incorrect. They do not represent the appropriate curvature of the curves or circles (illustrated explanation here, example file which produces problems in Marlin when usding JD here). As JD relies relies on the curvature to calculate the junction speed (for segments below 1 mm in length), printers running Marlin with JD often stutter on curves with Cura GCode. This may also be influenced by how the STL is sliced and how Cura handles the STL.

This could explain why #8321 was not seen with Ultimaker's printers but for many other printers it was. Ultimaker's printers forked off their Marlin version years ago.
We have a fix for #8321 but it turns out that there are still some cases left where it leaves tiny line segments. For the most part it seems to be gone now in our Master branch.

[XDA-Bam]

This could explain why #8321 was not seen with Ultimaker's printers but for many other printers it was. Ultimaker's printers forked off their Marlin version years ago.
We have a fix for #8321 but it turns out that there are still some cases left where it leaves tiny line segments. For the most part it seems to be gone now in our Master branch.

Yes, that sounds plausible. The problematic Junction Deviation code path which relies on the curvature was introduced to Marlin in May '18. You can deactivate it in the current version by commenting out #define JD_HANDLE_SMALL_SEGMENTS in the config.

Very nice that most of those tiny segments are gone in master. Just to clarify: It's not the segment length itself that's critical. It's the curvature [length/sin(theta), with theta in Marlin defined as the angle to the preceding element]. The shorter segments just make the calculation more sensitive to errors in the angle.

[chendo]

The Octoprint thing is different from this geometry/angle problem: In that case, there are just too many of these tiny segments, causing the Marlin buffer to run dry, which causes slowdowns during printing.

Yeah, now that I've read more about it, what I had was more another symptom than the root cause; thought I'd offer what information I've found. I did notice odd segment lengths when I was trying to debug the issue but I'm still very new to 3D printing (3 weeks in) so I wasn't sure what was normal and what wasn't.

I've worked around the issue for the time being by using Klipper, where the gcode that previously had issues now prints correctly, however it looks like the short segments may cause excessive extruder chattering. I've also had good success by enabling arc support and using the Arc Welder Octoprint plugin, which may be a viable workaround for anyone that needs to use 4.7.x for whatever reason still.

I'll be testing with 4.6.2 this weekend as well.

[KimmoHop]

(About JD)

This could explain why #8321 was not seen with Ultimaker's printers but for many other printers it was. Ultimaker's printers forked off their Marlin version years ago.

I'm running Marlin 1.1.9 with jerk, S-curve and linear advance (this is easy to set off for test) and tiny segments cause stutter and blobs. Maybe JD is not only place where small segments are not always treated well?

[qwewer0]

@KimmoHop Could you try the affected gcode without S-Curve?

[XDA-Bam]

(About JD)

This could explain why #8321 was not seen with Ultimaker's printers but for many other printers it was. Ultimaker's printers forked off their Marlin version years ago.

I'm running Marlin 1.1.9 with jerk, S-curve and linear advance (this is easy to set off for test) and tiny segments cause stutter and blobs. Maybe JD is not only place where small segments are not always treated well?

That may be the case, but your Marlin version is quite old (and has a couple of linear advance bugs, IIRC) and running S-curve in combination with linear advance is not recommended and not supported by Marlin. It may work on some gcode, it may fail on others.

You could deactivate LA or S-curve and test again. It may still fail, as you expect. There's also limitations concerning CPU usage, the possibility of the buffer running emtpy and those Octoprint problems mentioned before which could equally be triggered by the tiny segments and cause the artifacts. The problem with JD is the incorrect curvature, the problem in the other cases is likely just too many segments/second to process.

[KimmoHop]

Update - NB! I forgot that I had set maximum resolution and maximum deviation to 0.1mm

This slightly out-of-focus might show it best:

From left: S-curve + LA, S-curve, LA, neither. Same file, same day. PS sliced S+LA on right. PS has two simplifications, one that user can set that affects island shape and another fixed one that is applied to all lines (nozzle print paths) if I understood it correctly.

Another side, same order:

It's a bit difficult to shoot what you see, but S-curve increases and LA decreases bumps :/

Another reference: PS benchy, S-curve + LA on left, LA on right (I need to clean my bed ;) )

Some areas are a bit smoother without S-curve, some worse.

[KimmoHop]

This goes a bit OT, but:

I'm running Marlin 1.1.9 with jerk, S-curve and linear advance (this is easy to set off for test) and tiny segments cause stutter and blobs. Maybe JD is not only place where small segments are not always treated well?

That may be the case, but your Marlin version is quite old (and has a couple of linear advance bugs, IIRC) and running S-curve in combination with linear advance is not recommended and not supported by Marlin. It may work on some gcode, it may fail on others.

How many printers currently in use do have Marlin 2.x? How many will be updated? I think "minority of 8-bitters" to first and "even less" to the second :D
There exists Marlin 2.x branch for AC Mega we have, but I'd have to merge "standard" display handling to it, and I really doubt if print quality would improve (enough or at all) to justify it.

Fortunately issues like #8321 will be (have been) fixed in slicer which is 100x easier to upgrade for majority of printing people.

[brunoosti]

In my experience a benchy will not show as much defects as some other pieces. Try printing a 1/4 of a big thin sphere (like the back of a 2mm shell helmet). Stuttering movements and blobs all over the place. Tried many things on the slicer with the only solution being disabling JD.
I have an anycubic i3 mega-s (8 bit board), with TMC2208s, updated to marling 2.0.5 with s-curve and LA enabled (k=5.5; yes it works fine with the TMC2208s on the extruder). I had to disable junction deviation in the source code to make it print smooth again. So, with no JD, perfect smooth curves and no stuttering movements on the printer axis.
I have to point out that when testing with LA below k=4 I had problems where the extruder would stop extruding. Anyways, around k=6 seams to be the calibrated value for the Ai3m-s.

[flexgrip]

So I am experiencing this exact same issue. I kept having these weird bumpy surfaces on curves. Noticeable on the curved portions of the hull on the benchy, especially.

I was scratching my head when I noticed on one of my older SD cards, I had an older gcode for a benchy (sliced in 4.6.2). I hit print and went to bed. Woke up this morning to a beautifully smooth benchy.

I then looked at the old gcode (4.6.2) vs the new one (4.7.1 and 4.8 beta). Both of the newer ones produced gcode that was more than double the file size of the one I sliced with 4.6.2. Immediately I realized it must have been a resolution thing. Looking at the tool paths in cura, I can see the hull of the 4.6.2 benchy is made up up 1-2mm lines. But like the OP observed... in the > 4.6.2 versions of Cura, it is creating an extremely high number of tiny segments.

I tweaked the maximum resolution to 1mm and they are starting to look similar. But then now the smaller circles on the smoke stack aren't super smooth.

I guess I could go back to 4.6.2. But would these numbers me unrealistic?

• Maximum Resolution: 1mm
• Maximum Deviation: 0.01mm

Would be nice if we could just disable whatever this new part of the slicing engine is. It's just not worth it if you can't increase your processing power/speed on lower end printers like my Ender 3 Pro. Even with the SKR Mini E3 v1.2, it just can't keep up with all of the tiny segments generated from Cura > 4.6.2 :(

[Ghostkeeper]

Both of the newer ones produced gcode that was more than double the file size of the one I sliced with 4.6.2.

Indeed, in Cura 4.6 there was a bug that caused the model to be sliced at way too coarse resolution if the Maximum Resolution was set to be very low. This was fixed in 4.7, leading to much larger g-codes for printers which had their Maximum Resolution setting tweaked very low (depending on the bug to produce g-code that is more manageable for the firmware). See also the discussion over at https://github.com/Ultimaker/Cura/issues/8321. We're duplicating the same discussion here somewhat.

I think a Maximum Resolution of about 0.4mm is good for most printers. Maybe some high-end processors can reduce it somewhat (and no, 32-bit won't help a lot).