[4.7.0] Glitch Causing Slowdowns in Circular Perimeters

[CCS86]

4.7.0
Win 10

The slicing engine seems to be struggling with circular perimeters. 99% of the code is fine, but there are random slowdowns during printing at 70 mm/s on a Duet Maestro, which should have plenty of horsepower.

I first noticed these random artifacts (typical slow down bulges) in a print. So, I ran the gcode through gcodeanalyzer and it is actually showing these areas:

I saved the project file: Slowdown.3mf.txt

Then I loaded that project into 4.6.2, saved the gcode, and ran through the analyzer. It also shows some of these slowdown areas (and some oddly long ones), but scanning through all the code, there are FAR fewer of them. Here is the same layer in 4.6.2:

I tried many combinations of 'maximum resolution' and 'maximum deviation', and interestingly with 4.6.2, bringing maximum resolution down to 0.1mm eliminated most of these spots. The behavior in 4.7.0 is not the same, and it saw no improvement.

Here are the gcode files:
4.6.2.gcode.txt
4.7.0.gcode.txt

[CCS86]

[swademc95]

I have this issue as well. Only noticed after upgrading to 4.7.0. Even in places where the curve appears smooth, the printer jitters around the contours causing a significant reduction in speed and a lot of vibration. Only the inner walls seem to be affected.

[CCS86]

Wow, those are some big discontinuities!

[CCS86]

I know this is off-topic from the original issue here, but if you guys are rewriting this portion of the code, is there anything that can be done about this tendancy?

When the model has small holes, and you use a relatively large number of perimeters, each perimeter becomes progressively lower resolution. I can see that it it simply doing offsets on the inner perimeter, and it may be much more complicated to maintain the same segment length, while moving outwards.

Let me know if I should make this request via a new issue.

[dominik59]

I have got the same problem.
I have reflashed firmware, change junction deviation to jerk and so on and have not noticed improvement. When i tried IdeaMaker problem has dissapeared.

Green tickc are pointing model printed with previous cura version (4.6.2), red arrows are pointing models printed with newest software.

P.S. Cura 4.7.0 stable, Linux Mint 20

[ClockeNessMnstr]

Yep, CURA can't slice curves? I thought I was going crazy.

Here it is at 30mm/s target (print speed = 30, speed setting = 60...)

Here it is at 60mm/s target.

actual print. I forget the settings for this but the speed was at least 60mm/s, possibly set higher.
There could be two issues here. The lines you see running up the bow primarily in the z-axis do not show up based on infill, rather appear differently based on speed? looks like some sort of ghosting of the front of the bow but you can see the printer changing speed and causing the pattern.
The rough texture looks to match the gcode issues in different layers of the shell.

[louisferreira]

So I installed 4.7.0 along side 4.6.2 and set both instances to be exactly the same on all settings using CHEPS 0.2 profile, and I noticed a big difference in the prints. Firstly the GCode for 4.7 was twice the size of 4.6. And the print quality was distinctly different as shown - 4.6 on the left (2hr 2min), 4.7 on the right (2hrs 35min). There was also a noticeable difference in the sound the steppers made... 4.7 seemed to jitter a lot more round curves, whilst 4.6 seemed to be smoother in the same places.
So for now, I'm sticking to 4.6.2 until 4.7.x can do at least the same output as 4.6.2
I'd be interested to see if anyone else can do the same test and get similar results on their printer.
Hardware:
Ender 5+
Stock board + firmware
Capri bowden
metal extruder
Luke's hot end fix
Octoprint
Filament:
YOYI Silk PLA 1.75

[rburema]

Possibly caused by Ultimaker/CuraEngine#1214 and the related #7385

Depending on whether you're using stock profiles or external ones, please try 4.7.0 with the 'Maximum Deviation' set to half that of 4.6.x -- If this happens with stock profiles that come with Cura, there's something quite wrong. Otherwise the setting should be changed.

[swademc95]

Deviation settings was the first place I went after noticing the stuttering and slowdown. Thoroughly testing those settings through a range of values did not improve results once I was looking in the right place (at the plotted g-code)

[jellespijker]

@rburema #7385 is in my mind the likely cull-print compared to the simplify function executed on a circle

[rburema]

@swademc95 Thanks for the reply. This is bad news :-/

@jellespijker Yes, that's the second PR I mention in my comment (because they are related, and from the same JIRA ticket: CURA-7282). So I'm a bit confused: Are you agreeing or did you mean another PR?

[jellespijker]

@rburema I should have done more then hoover over the link. Once again I agree with you completely. I meant an other ticket but I can't remember the number and title anymore. I gonna look into it tomorrow.

Curious why it wasn't caught with the statistics that we run on the build server over certain models, especially the increase in file size as @louisferreira mentioned.

Time to double the effort for in GHermeneus toolbox ;-)

[swademc95]

Top surface layers also seem to be affected. Here is a comparison of the same part, same settings in 4.6.2 vs 4.7.0. In 4.7.0 there are strange pointy artifacts.

[Ghostkeeper]

When the model has small holes, and you use a relatively large number of perimeters, each perimeter becomes progressively lower resolution. I can see that it it simply doing offsets on the inner perimeter, and it may be much more complicated to maintain the same segment length, while moving outwards.

Even if the original circle was higher resolution, you wouldn't want it to do anything about it, because that would cause the vertices of the approximated circle to misalign, causing the surrounding wall to overlap the lower-resolution wall in some places, and to leave gaps in other places.

[Ghostkeeper]

Does anyone have a project file that reproduces the pointy corners? I'm not seeing them.

I do see the problems when slicing Benchy though. It's not caused by the Wall Overlap Compensation. Looks like it's creating micron-length line segments:

G1 X135.471 Y100.024 E904.85643
G1 X135.863 Y100.367 E904.85888
G1 X135.864 Y100.366 E904.85889  ; 1.4um line segment!
G1 X136.229 Y100.7 E904.86122
G1 X136.228 Y100.701 E904.86122
G1 X136.601 Y101.055 E904.86364
G1 X136.602 Y101.054 E904.86365  ; 1.4um line segment!
G1 X136.961 Y101.408 E904.86602

[nallath]

@swademc95 Could you share the project file that causes those issues for you? It would help us a lot to debug / fix this issue.

[KalCorp]

Note: I have same issue with 4.7/4.7.1 and 4.6.2 is ok. New Ender 5 Plus

[Zogar89]

I also experienced freeze issues with the new version. I have solved it by putting the following settings in the resolution:
Maximum Resolution 0.5mm, Maximum Travel Resolution 1.6mm, Maximum Deviation 0.3.
Much higher values than in version 4.6 but now I can print the circles much faster without stopping and the curves are still smooth!
Artillery x1, 8 bit board Mks Gen L clone. 50mm/s exterior perimeters. Host by Repetier Server.

[dominik59]

@Zogar89 Unfortunately your suggestion solves one problem but unfortunately introduce another one. I have printed benchy model using 4.7.1 cura with your settings, but details are now gone. I have also noticed that 4.7.1 cura do something strange with the seam. On the first picture i marked side of doors which looks scattered, but 4.6.2 version of cura have printed that without problems. P.S. I have set manual seam position to (0x,0y - Left front) in both models. I have also noticed that with your settings some small cracks appeared at front bottom side of benchy (hull). Anyway thanks for your advice.

[skarasov]

With CompensateWallOverlap - little gaps appears.

stl2.zip

[jakeface1]

I'm having the exact same issue, benchy's all have artifacts on the front of the print, any straight line is fine. I spent about 2 days trying to fix this problem. Luckily I found this linked from reddit.

[nallath]

I've wrote a quick script to check the number of line segments that are below a certain length.

As per the g-codes provided by @CCS86

4.7.0

Line length	Num segments
1	92578
0.5	33291
0.1	5472
0.05	2219
0.01	727
0.005	611
0.001	32

4.6.2

Line length	Num segments
1	56244
0.5	5669
0.1	685
0.05	32
0.01	32
0.005	32
0.001	32

4.7 with overlap compensation

Line length	Num segments
1	105925
0.5	45219
0.1	12877
0.05	8717
0.01	768
0.005	616
0.001	33

So there is quite a lot going on in the much smaller lines. 4.6.2 only had 32 line segments below 0.05, whereas 4.7.0 has 2219 line segments below 0.05.

The overlap compensation is making the problem a slight bit worse, but I think it should be considered a seperate issue (it could very well be that it's just amplifying the original issue)

[nallath]

Okay, I think I've found the solution here. It's still pending what the other developers think of it, but it fixes it for the cases that I've tested it.

Could we interest some people in testing this fix once it's reviewed?

[dominik59]

@nallath Sure

[bill-orange]

I was concerned about loss of detail with version 4.8 with the Mesh Fixes settings that appear to be commonly used. It appears I have nothing to fear. This test print has 3 mm threads. It was printed with a Tronxy X3A fitted with an generic Ender3 hot end (0.4 mm nozzle). Layer height was 0.06mm at 40 mm/sec. Max. resolution was 0.25 mm. Max Deviation was 0.025. These setting appear pretty good for "Ender3-like" machines.

[Ghostkeeper]

We currently consider this to be fixed. We've heard good things from Creality users on here and Reddit. I think if there are new issues (and not just "I'm getting blips, Cura must be wrong") then we're better off analysing those with clear reproduction steps in a new issue. The original problems in this issue have been resolved.

[tablatronix]

related #6676 ?

[Ghostkeeper]

Somewhat related because they are both buffer underruns. The symptom is the same and the fix for this can cause the problem to disappear there.

[swademc95]

Fusion 360 slicer vs Cura 4.8 with similar settings derived from default profiles. At this point I give up on Cura altogether. This problem is still not fixed.

[nallath]

@swademc95 Well, you never did share that project file where you had this issue, so we've been unable to check what is causing it in your case. Since all other users did report that the issue was resolved, we closed it.

If you could share the project file we can have a look at it and figure out what is different about your case.

Also note that it's almost impossible to have "similar" settings between slicers. The underlying algorithms are simply too different for there to be any meaningful way to have the same settings.

[swademc95]

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.

Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.

I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.

This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.

[colatuttorf]

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.

Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.

I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.

This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

[swademc95]

@nallath Think I might have found what triggers the behavior. It may be related to the ratio between part thickness and extrusion width, where if an even number of walls cannot fit fully inside the model boundary, then it makes erratic inner wall paths instead of smoothly filling the remaining volume. Relates to "Slicing Tolerance - Exclusive" because I suppose that effectively changes the position of the model boundaries, and on this particular model and my extrusion width settings, it reduced the model thickness below 4xExtrusionWidth.
Printing a model where the part thickness is less than 4xExtrusion width while in Exclusive mode seems to be the trigger. See the screenshot where you can see that the inner wall is not extruding continuously/smoothly.
I would expect that a sophisticated slicer should fill a thin volume of any thickness down to a minimum of 2x extrusion width fairly well? Not sure what the limiting factor would be. The part thickness range between 1-2x extusion width might be asking too much, but I am convinced that around 3x extrusion width should not be an issue for reliable and smooth filling of the volume.
This may be a slightly different issue to the one originally posted in 2020 but it shows up in a very similar way.

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

I have been advised that the Cura Arachne engine beta is meant to resolve this issue. I will test that soon.

[nallath]

I’ve seen this issue as well on my smaller parts, but I didn’t really give it much consideration, and I just thickened my design to avoid the thin wall weirdness. I know that’s not always a practical solution.

I’d call this a different issue though, should we open a new ticket with details on this odd path planning?

It is a different issue and one that is also very hard to solve. We actually had to re-write large parts of the slicing algorithm to fix it, which resulted in the Arachne Beta that is currently available. It's not completely done just yet, but we can always use more people testing it!

[CCS86]

This issue is much improved, but still not solved, unfortunately. I have repeated it in both 4.8 and 4.9 beta

https://www.gcodeanalyser.com/ does a great job of predicting these discontinuities:

I went hunting for these areas in Cura's own preview, and found them. They are indeed print moves, which are an order of magnitude smaller than the normal moves. They also appear to be non-continuous with the rest of the path. Even Cura preview shows a significant direction change induced by these moves, which explains why they cause the printer to slow down:

Cura-Discontinuity.mp4

Cura-Discontinuity2.mp4

O-ring coupler.3mf.zip
O-ring coupler 4.8.gcode.zip

[tablatronix]

I export from fusion and have to make sure any discretized cylinder polys are symmetrical or else I have this issue. Seems to be hit or miss how 3 walls get sliced, but its not random.

[CCS86]

I export from fusion and have to make sure any discretized cylinder polys are symmetrical or else I have this issue. Seems to be hit or miss how 3 walls get sliced, but its not random.

I don't doubt that STL composition plays into this, at least sometimes. It's such a messy format, with a lot of variance between how different software translates them in and out.

In some cases, I see these slowdowns appear to start on an exterior surface, and get propagated inwards. But other times, the outer wall looks fine, and slowdowns only occur on deeper inner walls.

[Ghostkeeper]

Even if the STL contains tiny triangles (or just normal triangles but with a sharp tip), Cura is expected to filter out such tiny movements as long as it's allowed by the Maximum Resolution and Maximum Deviation settings. That is, it should filter out segments smaller than the Maximum Resolution, unless that causes the path to deviate further than the Maximum Deviation.

[kiler129]

I don't think this issue should be solved - the newest version of Cura as of today (v4.11.0) still suffers from these artifacts. I tried to slice the standard dual-color benchy and I've got this:

Project file attached.
TLD_3DBenchy_-Dualprint-Hull_Box_Bridge_walls_Rod-holder_Chimney_v02-_3DBenchy.com.3mf.gz

[nallath]

@kiler129 Try setting your "merged meshes overlap" to 0

[Ghostkeeper]

To quote myself from earlier:

I think if there are new issues [...] then we're better off analysing those with clear reproduction steps in a new issue. The original problems in this issue have been resolved.

[lfrlucas]

This issue is much improved, but still not solved, unfortunately. I have repeated it in both 4.8 and 4.9 beta

https://www.gcodeanalyser.com/ does a great job of predicting these discontinuities:

I went hunting for these areas in Cura's own preview, and found them. They are indeed print moves, which are an order of magnitude smaller than the normal moves. They also appear to be non-continuous with the rest of the path. Even Cura preview shows a significant direction change induced by these moves, which explains why they cause the printer to slow down:
Cura-Discontinuity.mp4
Cura-Discontinuity2.mp4

O-ring coupler.3mf.zip O-ring coupler 4.8.gcode.zip

I'm using cura 4.13.1 and I'm experiencing exactly the same issue show in these videos. Took me hours to understand the cause of the defects in the curved walls. After finding this github issue, I confirmed the root case through the G-code analyser and I could see the exact same change of direction in cura preview mode. Is there any setting that can be tuned to avoid this behaviour? I'm wondering why don't we have more people complaining about this issue. At least with klipper the consequence on the printed objects is well visible.

[richfelker]

I think this issue should be fixed in Cura 5 as a result of Ultimaker/CuraEngine#1677

[lfrlucas]

Unfortunately the last version available on Ubuntu app store is still 4.13. I can't test yet. I hope version 5 will solve.