[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 https://github.com/Ultimaker/CuraEngine/pull/1214 and the related https://github.com/Ultimaker/Cura/pull/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

[hrafnkelle]

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

@nallath I'll test, there is a noticable and repeatable difference in my benchy prints between 4.7.x and 4.6.2. Also G-code is 2x larger with 4.7.

[jakeface1]

I moved back to Cura 4.6.2, oops I messed up the text. Should be 4.6.2!

[tomrush]

I am happy to run some tests if required. Please let me know if I can help.

[kiss81]

I can test as well. (ubuntu)

[CCS86]

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?

Happy to test.

[CCS86]

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

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)

Great comparison. My question is, why are there any segments shorter than the maximum resolution setting?

[rburema]

My question is, why are there any segments shorter than the maximum resolution setting [, even in 4.6]?

(Emphasis and interpretation mine.) Because they also have to be below the maximum deviation to actually be removed.

[CCS86]

My question is, why are there any segments shorter than the maximum resolution setting [, even in 4.6]?

(Emphasis and interpretation mine.) Because they also have to be below the maximum deviation to actually be removed.

Ah, I think you are totally right. I lapsed on maximum deviation being the priority!

[skarasov]

https://github.com/Ultimaker/CuraEngine/blob/788950cefd2af14d9b97ab49ad02d8be6692c688/src/slicer.cpp#L1083

This add in 0.5 um ((num + dx_01/2)/dx_01 == num/dx_01 + 0.5) can lead to generate wrong segment with lenght 1 um (interpolation from one edge + enother edge). Meybe change it to num += num > 0 ? dx_01 / 4 : -dx_01 / 4; to prevent that. Cant check it by myself right now.

[rburema]

@CCS86 Neither of them are really the priority, if it's the resolution that would prevent the change, rather than the deviation, then it doesn't happen either!

@skarasov It can't be that, since (edit conclusion might've been a bit premature, see answer below)

• the error can be way more than that, but more importantly
• that change was already in 4.6.x so it wouldn't explain the difference in behaviour in 4.7

Our best explanation currently is the one @nallath found. Still has to be pored over and reviewed (better) by the rest of us though.

[nallath]

The fix I had did indeed solve this issue, but it also re-introduced another one (which is mostly visible with models that have a mix of long straight lines and then a few very small line segments).

I think I have a fix that does solve this issue while almost solving the re-introduced issue.

As for the proposed solution of @skarasov It might be contributing to this issue. Since the simplify algorithm down the line changed, it could deal different with certain inputs (so sanitising it before hand might impact it).

Since running scripts is cheap, a bit more data: BenchyWithBothFixes (My & skarasov fixes)	Line length	Num segments
1	197111
0.5	79651
0.1	11141
0.05	7598
0.01	4308
0.005	4058
0.001	804

BenchyWithInterpolationFix (My fix)	Line length	Num segments
1	198076
0.5	79659
0.1	11301
0.05	7684
0.01	4375
0.005	4091
0.001	741

BenchyWithRoundingFix (@skarasov 's suggestion)	Line length	Num segments
1	204780
0.5	87840
0.1	13630
0.05	9447
0.01	5623
0.005	5276
0.001	850

BenchyWithoutFix	Line length	Num segments
1	206412
0.5	88439
0.1	13844
0.05	9567
0.01	5752
0.005	5352
0.001	831

[KimmoHop]

Adding to statistics, some Benchy pictures:

Red marks on the outer wall are on line ends (small gaps), if I read www.gcodeanalyser.com viewer right. The scale might be a bit off between slicers, but not that much.

Top: Cura 4.7.0, resolution 0.1 deviation 0.1 Middle: Cura 4.4.1 resolution 0.05 deviation 0.025 Bottom: PrusaSlicer resolution 0 (simplification off)

Is 4.7 splitting lines instead of reducing/merging them? Straight lines behind bow curve (single lines in other slicers) is also splitted to ~25 shorter sections.

[ils15]

+1

[nallath]

Is 4.7 splitting lines instead of reducing/merging them? Straight lines behind bow curve (single lines in other slicers) is also splitted to ~25 shorter sections.

No. The simplify is only removing vertices. That is also the issue here, since in some cases a move / split is actually a better solution.

You can check the pull request on the engine, it provides some images on the cases that we try to prevent / fix. Also feel free to comment in that PR on possible solutions.

[KimmoHop]

You are right - Benchy shows that there are a lot of polygons on straight side. PrusaSlicer might be doing some simplification even when told not to. However, should there be no lines shorter than max deviation (I'm assuming 0.025 or 0.050 was used in the tables above?) after simplification?

I can't comment the math you are using, I'd need to run it (but am unable to compile CuraEngine from source) :/

[Ghostkeeper]

However, should there be no lines shorter than max deviation (I'm assuming 0.025 or 0.050 was used in the tables above?) after simplification?

The expected behaviour is that there are no lines shorter than the Maximum Resolution, unless that causes a deviation from the original shape more than the Maximum Deviation. There are two exceptions for that though:

• Lines shorter than 5 micron should always get removed.
• If removing a vertex causes a very long line segment to shift, it should not be removed.

It seems that the second exception was causing micron-scale line segments to be retained that were previously removed.

[KimmoHop]

Is that second exception why e.g. Douglas-Peucker cannot be used? Sorry for asking so much, but Cura simplification looks fairly complex - both in spec and in implementation ;)

[nallath]

Douglas-Peucker

I've not looked at douglas peucker, but I think that would only work if we subdivided overly long edges.

The implementation that we have right now is fairly complex. It's also how this issue snuck through. We even printed benchies with Ultimaker printers, but the issue simply didn't pop up (which is probably because a different interpretation by the firmware). We don't have any statistical analysis of the g-codes, but due to the clusterfuck of this issue, we are working on a detection system to catch issues like this a bit sooner.

The long segment issue gives the following artifacts: WRONG: Right:

The error that it introduces in this way is pretty small (because it's a very long sliver), but unfortunately for us, it is very noticeable.

[msteele999]

I reported this issue as well - a known, good print in 4.6.1 has distortions on corners in 4.7.x

[Ghostkeeper]

Is that second exception why e.g. Douglas-Peucker cannot be used? Sorry for asking so much, but Cura simplification looks fairly complex - both in spec and in implementation ;)

Ramer-Douglas-Peucker is limited only by the Hausdorff distance (maximum deviation). The main objective of this algorithm is to have a lower limit on the length of line segments (maximum resolution). So this algorithm needs to do both and RDP is not applicable then. There are alternatives we could use. We could make a simple implementation of one of those with some minor adjustments to make it work for our case (e.g. a post-processing step to join colinear line segments even if they are too long). It kind of grew this way due to iterative adding of requirements.

[Liger0]

In 4.6.2 there already were issues with artifacts.

On the top there are 2 triangles that are impressed as a negative, while the 2 vertical lines under that are over the perimeter. I checked the mesh and there is no shape like that (I also created it and it's a plane surface). A gcode online viewer showed those shapes confirming it's something to do with Cura, although the cura viewer doesn't (since wireframe view doesn't exist there). I didn't create a project file but I am going to import the model with the same settings, the result will probably be similar. The gcode is the correct one that presents the issue. All the things I print have artifacts like this.

Artifacts gcode.zip artifacts project.zip

[nallath]

In 4.6.2 there already were issues with artifacts.

These are different artifacts than those described in the rest of the issue. As far as I can see, these are caused by trying to fill thin walled areas. Fixing that is a quite difficult problem, but it is what we are currently working on with LibArachne

[dpreed]

I'm seeing a similar issue with large flat faces. No curves. Fine hairs about 1-2 mm sticking out perpendicular to the surface scattered across the large flat face. The face seems to have some infill behind it. Could short lines be causing this perpendicular hairy stuff?

[Liger0]

In 4.6.2 there already were issues with artifacts.

These are different artifacts than those described in the rest of the issue. As far as I can see, these are caused by trying to fill thin walled areas. Fixing that is a quite difficult problem, but it is what we are currently working on with LibArachne

The triangualr shapes may be caused by the gap filling as it's where it is positioned, altough it's inside another perimeter so not sure how it shows there as a negative rather than a positive, but the 2 perpendicular lines don't seem to have something inside unless I am remembering bad.

[mattaw]

Would you mind pausing cura downloads from your website for a bit until its fixed? Printing benchy is pretty much the first thing people like myself did and I have wasted many days on trying to fix a working printer, and have a fleet of benchy's with artifacts on them. This issue really could spoil folks first introduction to 3d printing, and github is not a good place to find out about it.

[nallath]

Most downloads happen in the first 3 weeks anyway, so that damage has been done already.