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

[dpreed]

Indeed, Fedora 32 has already distributed the update to all Fedora users who track Cura via the standard package system. However, it would be nice to make 4.6.3 available and suggest that anyone having problems try 4.6.3 reversion rather than trying to fix their printer.

[kiss81]

Indeed, Fedora 32 has already distributed the update to all Fedora users who track Cura via the standard package system. However, it would be nice to make 4.6.3 available and suggest that anyone having problems try 4.6.3 reversion rather than trying to fix their printer.

I agree with this...

[dpreed]

This "issue" is hard for most ordinary printer users to understand from its title or from the posts. I've shared it with others in a printer user group and they react with confusion. So my advice has turned to "Don't use 4.7.1 at all until a fix is released".
And that's simple enough. I am not trying to say Cura is "crap", and they should switch to Slic3r or Simplify3D or Kisslicer. No, Cura 4.7 has great stuff in it. But a huge problem that wastes users' time.

[mattaw]

[I hesitate to lengthen a technical bug with non-technical "political" matters, please delete if off-topic. In addition, I am unsure how many folks are being affected.]
Can we tastefully escalate guidance like this: https://www.helpscout.com/helpu/outage-status-update/ to the Ultimaker / Cura management and have them do some structured communications around it? I feel Cura would be stronger for clear communications and suggestions like @dpreed . We are 26 days into this bug report, and I imagine the number of affected individuals will only grow and will not have had @dpreed 's positive experience to support them while this issue is being addressed. If we have no communications, how will individuals know to upgrade when the fix is merged short of release notes which I suspect most don't read.

[msteele999]

I have to agree with this suggestion. Currently the lack of communication
has created a vacuum in the social media platforms and that vacuum is being
filled with helpful (just downgrade to 6.4.1 for now, they are working on
it) and deragatory (Ultimaker scks, Cura scks, go use one of the other
slicers, etc.) comments.

Use this as an opportunity to connect with your user base and build
confidence and loyalty.

Best regards,

Mark Steele

On Wed, Sep 30, 2020, 17:22 Dr. Matthew Swabey [e-mail]
wrote:

[I hesitate to lengthen a technical bug with non-technical "political"
matters, please delete if off-topic. In addition, I am unsure how many
folks are being affected.]
Can we tastefully escalate guidance like this:
https://www.helpscout.com/helpu/outage-status-update/ to the Ultimaker /
Cura management and have them do some structured communications around it?
I feel Cura would be stronger for clear communications and suggestions like
@dpreed https://github.com/dpreed . We are 26 days into this bug
report, and I imagine the number of affected individuals will only grow and
will not have had @dpreed https://github.com/dpreed 's positive
experience to support them while this issue is being addressed. If we have
no communications, how will individuals know to upgrade when the fix is
merged short of release notes which I suspect most don't read.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-701653825,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYM7FHTLCZO7BGVCVT3SIOOS7ANCNFSM4QYPYE7A
.

[nallath]

Those derogatory comments will happen regardless. If we release a patch version the same comments happen.

Anyhow, this is also the reason that we are looking for a dedicated (technical) community manager (https://www.linkedin.com/jobs/view/technical-community-manager-at-ultimaker-2021321718).

Last but not least; I don't mind mixing up technical & political matters. They are almost always intertwined, especially in cases like this.

[msteele999]

Those derogatory comments will happen regardless. If we release a patch version the same comments happen.

Anyhow, this is also the reason that we are looking for a dedicated (technical) community manager (https://www.linkedin.com/jobs/view/technical-community-manager-at-ultimaker-2021321718).

Last but not least; I don't mind mixing up technical & political matters. They are almost always intertwined, especially in cases like this.

Understood - so, how can we help?

[KimmoHop]

It would be nice to have nightly or unofficial builds to test how the fix works. I spent ~3 evenings with cura-build-environment, _maybe_ making through it, but then cura-build said "no" ;)

[dpreed]

I'm a beta-test kind of guy. But man, building Cura isn't simple. And figuring out how to attribute bugs on Linux isn't simple, either.

I just found (experimenting) that I can't load 3DBenchy.stl into 4.7.1 - it segfaults reading the mesh somewhere.. Other STL models load fine. The same file loads in the Appimage version of 4..6.2, and used to load fine in the Fedora32 version of 4.6.2.

I'm not sure it is Cura that is hitting this - Fedora32 just updated a bunch of python 3 packages, too. So maybe Cura is fine, but something broke underneath it. So before I do a bug report, I'm experimenting some more.

Being a beta-test kind of guy, I'm used to collaborating with software developers, rather than trashing them.

So this is a complicated way to say I agree with the idea of "unofficial test builds" or "nightlies" as ways I can and would "help".

[konskarm]

Hello everyone. We just merged PR https://github.com/Ultimaker/CuraEngine/pull/1336 into master. Can you check whether it fixes the issue (if you are running Cura from source)?

[nallath]

You just need to build the engine (which is much easier) and ensure that Cura uses that version of the engine (which is a matter of replacing the executable).

I will also check to see what the best way is to expose some nightly builds to you guys (since that is way easier). Do note that these builds will not be signed, as that is a manual and bit of a tedious process.

[nallath]

@dpreed @KimmoHop @msteele999

The nightlies can be found here:
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014539-Darwin.dmg
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014541.AppImage
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002022935.exe

Do note; This is the nightly build from last night. Since our master is considered unstable, it could be that there are other issues with it. As always; it should be possible to install things side by side, but do make a backup of your config folder before using this just to be on the safe side.

[bill-orange]

This isn't authoritative.

I made other changes, such as baking my filament roll, before trying the beta posted by @nallath. That being said, the voids resembling the post by @CCS86 were greatly reduced in the test print made with the beta. I could attribute the very few remaining defects to other causes.

[Skaifer]

Have not tried to print a model sliced with nightly build, cuz, lack of time. But sliced the last problematic model and put in gcode analyzer. I still notice abnormal speed decreases in places it should not happen.

[KimmoHop]

@nallath I sliced benchy (bottommost 10 mm of it) with 4.7.1 and nightly, varying settings. Recently I have used Ender 3 profile, which has low acceleration, modest speeds and very high resolution 0.05mm. Anycubic Mega has higher acceleration and much lower resolution 0.5mm. I printed 3 pairs of benchys based on AC settings with resolutions 0.05mm, 0.1mm and 0.5mm.

In the following I use "high resolution" to short max resolution / more detail / lots of segments and "low resolution" to long max resolution / less detail / less segments, not to confuse, but to make it analogous to e.g. image resolution.

What I found, was that

• getting PS out of the way, it has user definable resolution for island polygons and fixed simplification for print paths so it prints clean. D-P simplification is used in both phases
• 4.4.1 doesn't seem to care much about resolution. It gives small g-code every time, even with 0.001mm resolution, and number of segments does not rise. I guess it's not working correctly, though it prints clean
• 4.7.1 produces files, where size correlates with resolution. High resolutions stutter and blob when printed. 0.5mm printed fine without blobs.
• nightly produces smaller files and less segments for all resolutions. High resolutions stutter and blob when printed. 0.5mm printed fine without blobs, maybe slightly cleaner in some areas, but hard to say with sample size of 1 ;)

The printed parts are not very interesting, so this is how they look in g-code viewer, 2 layers showing at the same time, composition of 3 resolutions for both:

Both versions do some non-printing movements in infill with high resolutions (arrows) that maybe shouldn't be there?

The main finding for me was that max resolution can be _fairly long_ - if we can say so for a length slightly more than nozzle opening. Max deviation keeps contours where they are needed while also keeping SD command buffer fed.
I'm not sure if max resolution "started to work" in some Cura version, or is my 4.4.1 just an oddball. Also I'm not sure if 0.05mm really is default max resolution for Ender 3, and if it deals with it without stuttering. Also I didn't check what value other printers use. Maybe that might be something to go through and evaluate at least for 8-bit printers?

[nallath]

• 4.4.1 doesn't seem to care much about resolution. It gives small g-code every time, even with 0.001mm resolution, and number of segments does not rise. I guess it's not working correctly, though it prints clean

That sounds about right. We've had some issues with the simplify not really doing it's job at all (that's how we even got to this situation)

Both versions do some non-printing movements in infill with high resolutions (arrows) that maybe shouldn't be there?

That is always a hard issue. I _think_ this is another issue (but as always, they could be related).

The main finding for me was that max resolution can be _fairly long_ - if we can say so for a length slightly more than nozzle opening. Max deviation keeps contours where they are needed while also keeping SD command buffer fed.

For Ultimaker printers the max resolution is 0.5mm with a max deviation of 0.025mm

[eoyilmaz]

I had the same problems with 4.7.1. Fixed it by the following settings:

Compensate Wall Overlaps: Off
Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.05 mm
Maximum Deviation: 0.05 mm

And these helped a little bit too:

Z Seam Alignment: Shortest
Print Speed: 75 mm/s
Infill Speed: 75 mm/s
Outer Wall Speed: 12.5 mm/s
Inner Wall Speed: 25 mm/s
Top/Bottom Speed: 37.5 mm/s
Travel Speed: 187.5 mm/s
Initial Layer Speed: 20 mm/s

[msteele999]

I am running a test print now with these settings to see if there is any
difference on my printer / setup.

On Fri, Oct 9, 2020 at 4:28 AM Erkan Ozgur Yilmaz [e-mail]
wrote:

I had the same problems with 4.7.1. Fixed it by the following settings:

Compensate Wall Overlaps: Off
Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.05 mm
Maximum Deviation: 0.05 mm

And these helped a little bit too:

Z Seam Alignment: Shortest
Print Speed: 75 mm/s
Infill Speed: 75 mm/s
Outer Wall Speed: 12.5 mm/s
Inner Wall Speed: 25 mm/s
Top/Bottom Speed: 37.5 mm/s
Travel Speed: 187.5 mm/s
Initial Layer Speed: 20 mm/s

[image: Before]
https://camo.githubusercontent.com/6d3feddd7fd1836e694f2e4b393a70ae53a88fc8/68747470733a2f2f6c68332e676f6f676c6575736572636f6e74656e742e636f6d2f61447064527864527a354b7a3646696550395969344c4668585654684a75316b525a7556766d4d485f50425732536d37754e68713569495f43475353594c766f5577496b4c2d34376b506678705a714245746b326444587237583475762d373051723358494e5236797275574467474850734d32576547514c4e4f45334e4a55634e55594b584a5a7a513d7732343030

[image: After]
https://camo.githubusercontent.com/fa4e51f9dc3a8f87f1c0913b570159f9d88e15c2/68747470733a2f2f6c68332e676f6f676c6575736572636f6e74656e742e636f6d2f5775712d31305f46647273633765564b64376542485f4474704d505271634a444551794b41337648353274345a35753067535f77394e5f6661567a315130717a4b44376b686858354164345249716f61576f556d3758765879396a77726277333333556a636f2d326e75514c447965685276664b6d58462d63664f346439713550595134384e51386e413d7732343030

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-706046715,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYONEC6J3SP6BG2JY3DSJ3CTVANCNFSM4QYPYE7A
.

[CCS86]

Those settings will just hide the issue. Outer walls at 12.5 mm/s is so incredibly slow, that the printer can deal with the discontinuities without significant slow down, because it is already slowed wayyyy down.

[msteele999]

Yeah, I'm finding that it is unacceptably slow - my test print usually
takes about 2 hours to print - with these settings it's over 5 hours.

Back to 4.6.1 :-)

On Fri, Oct 9, 2020 at 8:51 AM CCS86 [e-mail] wrote:

Those settings will just hide the issue. Outer walls at 12.5 mm/s is so
incredibly slow, that the printer can deal with the discontinuities without
significant slow down, because it is already slowed wayyyy down.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-706162038,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYPWP6O4SPJUERI7GODSJ4BMBANCNFSM4QYPYE7A
.

[nallath]

@eoyilmaz Did you also try to print it with the nightly build i posted?

[eoyilmaz]

Guys, those speed settings are not necessary and it is not slow as stated by @CCS86 as I increase the "Print Speed" to 75 mm/s. It prints around them same 2 hours that I normally print a 3DBenchy (by the way Slic3r's G-Code takes like 1.5 hours). Also I printed at normal speed of 50 mm/s and the main settings that mitigates this problem are those:

Compensate Wall Overlaps: Off
Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.05 mm
Maximum Deviation: 0.05 mm

So as I learned, the Compensate Wall Overlaps setting when enabled will disable the Maximum Resolution setting which is the main mitigation for this problem. Doesn't seem to be true. So I checked witth 4.6.2, even with the "Compensate Wall Overlaps" setting is turned on increasing the Maximum Resolution will lower the file size, thus it is working.

@eoyilmaz Did you also try to print it with the nightly build i posted?

@nallath I'll do it so tonight. I'll let you guys now my result.

aand those are the prints that I did while searching for a solution for this problem:

[colatuttorf]

@eoyilmaz Did you also try to print it with the nightly build i posted?

I downloaded and started using the nightly posted above. The issues have been largely cleared. I did run some code through the visualizer, and 4.7.0 definitely shows the slow downs illustrated above, and the code generated with the exact same slicer settings with the nightly build do not show the random wall slow downs.

Is there a date where we expect a 4.7.2 or 4.8.0 to be released including the fix? I really don't want to be doing customer work on a nightly, but 4.6.x and 4.5.x both included show-stopper issues throughout, so I'd have to go pretty far back to find something workable.

[eoyilmaz]

@dpreed @KimmoHop @msteele999

The nightlies can be found here:
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014539-Darwin.dmg
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014541.AppImage
https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002022935.exe

Do note; This is the nightly build from last night. Since our master is considered unstable, it could be that there are other issues with it. As always; it should be possible to install things side by side, but do make a backup of your config folder before using this just to be on the safe side.

Oh snap I should have read your post earlier. I spent like 1 hour to make the master work and then I was trying to figure out why the slicer is not working. It is time to print the 3DBenchy. Will let you know in the morning.

[hrafnkelle]

Just printed a Benchy sliced with the Cura_SteamEngine 4.8.99-master.20201002014518 and Cura_SteamEngine 4.6.2
The front of the hull still shows issues with nightly build that are not visible in the 4.6.2 sliced print.

Attached image shows 3 Benchy, 1st (from left) is sliced with 4.7.1, middle is sliced with the nightly build and the last (on the right) is sliced with 4.6.2. The 4.6.2 and the nigtly build based prints were done just now.

Printed on a Ender 3 in PLA.

Filesize with 4.6.2 is 3945KB, with the nightly build 8902KB.

[eoyilmaz]

I would like to say that, comparing 4.6.2, 4.7.1 and the nightly build, when I use the simulation, on the curvy side of the 3DBenchy model, I still can see the slowing down issue with the nightly and with 4.7.1 where as on 4.6.2 the nozzle flies through those lines, without any hesitation. Now, just because I saw @hrafnkelle 's result. I think I don't want to waste any filaments and any of my time to get the same result.

[smartavionics]

Hello @hrafnkelle , Please try the build at https://github.com/smartavionics/Cura/releases/tag/20200922 and see if it exhibits the same issues. Thanks.

[hrafnkelle]

Here is print using your build @smartavionics
The order from left is
4.8.99-master.20201002014518
mb-master-20200922 (@smartavionics build)
4.6.2

Gcode filesize with your build is 6082KB

There is definetly improvement but still showing issues on the curved front hull.
However, the definition of the #3DBenchy on the back is great, probably best I've had from my printer.

[Skaifer]

I'm getting approximately same results as Hrafnkelle 3-rd benchy with nightly build. Used settings eoyilmaz recommended. Much fewer zits, but they are still there. With 4.7.1 I got completely fuzzy skin, could not even call them zits. Still not smooth. BUT! Can someone tell me, are those zits random on every print? Cuz, my are random and I'm starting to think I have other issue. But at the same time all good in other slicer. That can not be wet filament or retraction settings.

[chendo]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

[hrafnkelle]

I'm printing over USB from octoprint.

[eoyilmaz]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

I thought the same. I'm printing over OctoPrint with USB. But, in Marlin Firmware, I increased the buffer (from 16KB to 32KB) and the baud rate (from 115.2K to 250K) over the default values. It didn't help. The result I shown on my previous post was already with those settings.

[chendo]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

I thought the same. I'm printing over OctoPrint with USB. But, in Marlin Firmware, I increased the buffer (from 16KB to 32KB) and the baud rate (from 115.2K to 250K) over the default values. It didn't help. The result I shown on my previous post was already with those settings.

My understanding of the interaction between Marlin and Octoprint shows that by default, Octoprint waits for an ok from Marlin before sending the next line, which means Marlin's buffers generally remain empty, so this doesn't help. You can verify this by enabling ADVANCED_OK and seeing if the available command buffer indicated by ok P<planner buffer availability> B<command buffer availability> goes to 0.

My experiments show that printing with Octoprint reliably shows B3 for my printer, which has BUFSIZE set to 4.

So currently, increasing buffers and baudrate doesn't address the issue if Octoprint doesn't fill those buffers, however it can help if you're still seeing print quality issues when printing from SD card.

I've done a more detailed write up on my investigation on my blog post, and another one which measures planner buffer underruns (which causes zits) between gcode generated by Cura 4.6.2 and 4.7.1.

Cura 4.6.2:

Cura 4.7.1:

[hrafnkelle]

Just printed a Benchy from SD card, same Gcode file as before sliced with 4.8.99-master.20201002014518
Results are similar as before so I would not say printing over USB is causing this.
Both prints used the same GCode file, gray printed over USB from OctoPrint, orange printed from SD card.

(Filament is same brand, just different color)

[Liger0]

Are you people using stock profiles? No wonders results can be so off if you import the same edited profile with personal resolution and deviation settings on different builds. Stock profiles would be more useful

[hrafnkelle]

My profile is mostly stock but yes I'm using the same profile on all builds. I'm willing to tweak for each build and print if someone wants to guide me what tweaks would make a difference.

[bill-orange]

I am having a odd outer wall problem that may possibly be a symptom of this problem. I am having outer wall defects that change with percent extrusion, layer height and possible wall shape. If I print with a layer height of 0.06mm, find that I get symptoms of over extrusion. The problem resolves if I decrease the percent extrusion to 85%, VERY low. If I print with a layer height of 0.20mm at anything less that 105% extrusion rate, I get symptoms of what appears to be under extrusion (photo attached).

The problem also seem to change with linear vs rounded walls. A very low extrusion rate for highly rounded walls and a much higher extrusion rate for straight walls. It is as if the printing travel speed is not staying well synchronized to the extrusion rate, layer heights and wall shapes. ( in my humble opinion).

Thoughts? Could my issue be an odd consequence of this problem or do I have an issue that I am not analyzing correctly? I have not done regression testing with versions below 4.7.1. I have wasted a lot of filament as it is!

EDIT: I download the latest PrusaSlicer and ran my "straight wall" 0.2mm layer height model. There were no signs of the skipping shown in the photo. One cavate, going from Cura to PrusaSlicer entailed countless other settings changed. Thus, this was clearly a apples-to-oranges test.

Photo of flat 0.20mm layer height flat wall.

[chendo]

As an experiment, I increased BUFSIZE on my printer to 32, and printed a 50% scale Benchy sliced with 4.7.1 from SD card while monitoring buffer underruns. Printing from SD resulted in no planner underruns, however still resulted in overextrusion in the same places around curves. The instructions per second can spike to 200 per second, and considering a print with 4.7.1 is noticeably longer than 4.6.2 as well as the file size being significantly bigger, there are too many instructions for most printers to be able to process.

[gluap]

Independently from any buffer underruns: In the beginning of this issue people were analyzing the g-code and were seeing slowdonws in the g-code that seemed to correspond to the blobs/zits. If the slowdowns are in the g-code they should be independent from any printer buffers. One example where this was shown: https://github.com/Ultimaker/Cura/issues/8321#issuecomment-687835204

Of course the gravity of the zit issue may still depend on printer types, for instance (uneducated guess) bowden printers may produce more zits for the same g-code because they have more lag in slowing extrusion.

Or did I miss something re-reading the thread and the issues with the g-code are already solved?

[nallath]

Bowden style printer actually have this issue less (or well, Ultimaker printers didn't really suffer from it, which is why we didn't see it). I think (but i'm very far from sure) that it has something to do with linear advance on the firmware.

Anyhow, as far as I can see, most, if not all, of the zits in the g-code are gone with the nightly builds I posted.

[hrafnkelle]

I think the prints I posted pictures of show that some of the zits are gone in the nightly build but far from all. Am I misunderstanding your comment @nallath?
I have a bowden style printer and I am not using linear advance.

[nallath]

Hmm. That is odd then. Ultimaker printers are bowden style printers and aren't using linear advance.

What settings do you have for the max resolution?

[hrafnkelle]

I have not touched that setting since I'm not familiar with it
I had

• max resolution 0.05mm
• max travel resolution 0.05mm
• max deviation 0.025mm
  in the profile that was used on the 4.8nightly build

I am willing to print more with changed settings if you suggest other values for this or other parameters.

[nallath]

For the UM3 the settings are:
Maximum resolution: 0.5
Max travel resolution: 0.7
Max deviation: 0.025

Since that's a pretty big difference, I think it might be a good idea to test the max resolution at 0.25 or 0.5 and see what happens.

[ClockeNessMnstr]

The settings were irrelevant weren't they? The g-code was causing slowdowns that shouldn't have been there regardless of the settings? Is that already fixed and people are still having issues?

A separate note to bring back up. I had gone back to Cura 4.3 I think with the version that came with the ender 3 V2. There were still random slowdowns around the forward hull perimeter of a benchy. They were very few and far between but I was hoping when this issue was fixed that we would also see what was causing them before.

[CCS86]

I think the issue has at least two causes:

1. There are actual discontinuities in the curve paths, with segments that should be tangent but angularly separated, also having a translation. These can be seen in gcode visualizers as slow downs because the printer needs almost stop "forward" momentum, to make the sideways shift. I would imagine this is more printer agnostic, since it is a pure motion kinematics issue.

2. The increase in tiny print segments causing motion planner slowdowns. This would vary a bit between controllers because it is more of a calculation bottleneck.

For the record, I am running an Ultimaker Original with a Duet Maestro board; no linear/pressure advance. Fast controller, with a bowden printer.

[nallath]

The settings were irrelevant weren't they? The g-code was causing slowdowns that shouldn't have been there regardless of the settings? Is that already fixed and people are still having issues?

Well, it's a bit more complicated than that. There were very teeny tiny segments that should have been deleted that were not deleted. That issue has been fixed.

That obviously doesn't mean that _all_ issues regarding line segments per second are fixed. It's a complex problem that we've been fighting for a _long_ time. Not every machine has the same number that it can handle and it can result in multiple symptoms that need to be fixed all over the place (Hardware, Firmware, Slicer)

A separate note to bring back up. I had gone back to Cura 4.3 I think with the version that came with the ender 3 V2. There were still random slowdowns around the forward hull perimeter of a benchy. They were very few and far between but I was hoping when this issue was fixed that we would also see what was causing them before.

That's kinda the problem with complicated systems in general. There is no such thing as "changing just one thing". Almost eveyrthing can theoretically impact everything else (this is also why we didn't spot it upon first release, why it's taking so long to really fix it and why we depend on people testing it; We need as much different configurations as possible).

[hrafnkelle]

Here is a picture of two benchys sliced with the 4.8.99-master.20201002014518 build
The one on the left is sliced with max resolution set to 0.05 and the one of the right is sliced with max resolution set to 0.5
The "fuzzyness" and zits are gone on the curved front of the hull when setting max resolution to 0.5. Great!

There is however a discontinuity in the layers where each layer starts/ends (the seam). It is very easy to feel by finger and visual as you can see on the photo.

[rburema]

@hrafnkelle The wrong seam placement is (probably) caused by another bug we're still working on. We hope/'expect' to get that in before 4.8 final as well. (Maybe even before beta?)

(To other devs: Ticket for the misplaced seam is known in our internal system as CURA-7769)

Edit: It is probably related to the initial 'fix' though.

[hrafnkelle]

How should the maximum resolution parameter be tuned? It seems neccecary to adjust it for 4.7 and eventually 4.8.
New defaults need to be created for at least ender 3 for this value.

[hrafnkelle]

@rburema To me the discontinuity isnt just the seam, it seems the whole straight part leading to the seam is higher/further out than the curved part. This doesnt look like a misplaced seam, the whole straight part of the layer is misplaced?

Hope the photo below shows what I mean

[rburema]

@hrafnkelle I think I see what you mean. Odd, as that sort of thing should have been fixed by https://github.com/Ultimaker/CuraEngine/pull/1336 which was merged one or two days before the nightlies you're using. (Though I'm not 100% convinced that it _isn't_ the seam.)

[colatuttorf]

@rburema To me the discontinuity isnt just the seam, it seems the whole straight part leading to the seam is higher/further out than the curved part. This doesnt look like a misplaced seam, the whole straight part of the layer is misplaced?

Hope the photo below shows what I mean

I have this same issue above using in the Nightly posted above. I had thought at first it was a layer shift, but its repeatable across multiple printers and various slicer settings. Going to do a bit more investigating and fiddling with the resolution to resolve, but it appears that the slicer is shifting the model along a boundary of two triangles in the stl file. Its in a straight wall, so might be a different issue altogether.

[bill-orange]

@hrafnkelle Did changing the max resolution from 0.05mm to 0.5mm cause any collateral damage? For instance, was the text on the stern intact?

0.5mm seems pretty course.

[hrafnkelle]

Tried to take as detailed photos as I could. You should be able to zoom in alot since the resolution is high.

The text on the stern is there, not very readable, seems to have some zits but I can't tell if it is just in this print or general.

[nallath]

Well, it doesn't _have_ to be 0.5 of course. It can be lower than that. I do think that the number might need to be higher than what the default creality profiles have now.

[hrafnkelle]

I just did a series of test prints on the bottm 30 layers of a benchy without infill, varying the maximum resolution
I did a "bisection search" between 0.05 (default ender profile) to 0.5 (the UM3 value and value tested yesterday).
This suggested that the lowest acceptable value af max resolution is 0.187

I did print a benchy with that setting with ok results, few minor zits. This suggest perhaps a value around 0.2. Could others try that value using the nightly build as well.

Pictures of the benchy shells and a Benchy attached.

The benchy still shows the discontinuity at the seam. Perhaps nozzle pressure issue because of the slowdown when going beteween perimeters?

My printer is an Ender 3 with stock hotend. Fans and bowden tube have been upgraded but I dont expect that to have an influence on this. Firmware is Marlin 2.0.7, no linear advance

[Ghostkeeper]

How should the maximum resolution parameter be tuned? It seems neccecary to adjust it for 4.7 and eventually 4.8.
New defaults need to be created for at least ender 3 for this value.

Quite a complicated matter, honestly. Consider the amount of line segments the printer can handle. This will be different from printer to printer due to capabilities of firmware and electronics, so let's take the example of about 200seg/s for the Ultimaker 2 (Ultimaker's fastest printer). Then take the fastest print speed into account where you'd like to prevent these underruns from occurring. For instance, maybe you don't find it important during printing infill, so you take the inner wall print speed of 60mm/s. So in 1 second you can print 60mm and 200 segments. That is 0.3mm per segment. This is your theoretical maximum resolution for an ideal curve.

Your print is not an ideal curve though and this is where it gets complex. There is a Maximum Deviation setting too which adds segments. And Wall Overlap Compensation can split parts of the segments off, which is done after the resolution is reduced so this can cause the number of segments per second to rise. So it's good to take some leeway. On the other hand, not all prints are a worst-case so it could be acceptable to have buffer underruns sometimes. This is best done with extensive testing but just from gut feeling I'd put the Maximum Resolution then on 0.4mm or so for the UM2. In actuality it's 0.5mm in the profile, probably because the Maximum Resolution setting was added when the profiles for UM2 were already tuned, so it's just using a sane default.

But yes, 0.05mm is incredibly low. 0.3mm is more realistic as to what your printer can reach.

[Ghostkeeper]

I think what contributes to the confusion here is that the simplification algorithm in 4.6 and before simplified the shapes way too much with very low Maximum Resolution. This is one of the bugs that was fixed, but since the Creality settings set their Maximum Resolution very low, this change greatly increased the resolution for them, resulting in buffer underruns for them.

[Skaifer]

Nightly build - much better than 4.7 but still has some zits, resolution 0.4, travel resolution 0.5, deviation 0.025.

Cura 4.6.2 - Much cleaner, same settings as nightly.

Cura 4.7 - worst case scenario with standard settings.

I hear no poping sounds, and z seam is always on the back. And I've checked gcode with the latest resolution settings nightly build, and there are no more sudden changes in direction resulting in speed drops. So, there's something else going on. I'll try to print with the new filament and change nozzle later on. As those are last resort changes that could possibly affect quality on my end, that I could think of. And prints were made off SD card.

[rburema]

@Skaifer Thanks for the report! Please also take @Ghostkeeper last comment (just above yours') into account.

In other words: We don't expect the 'same' simplification settings to behave exactly the same in 4.6.x versus later, since one of the things we fixed for 4.6.0 was the oversimplification given the settings. That is, if you specified this and that length or angle to be kept as 'maximum allowed' it would sometimes still smooth things over (merge two line-segments into one) even when the settings said not to allow that. Part of that was taken into account in the upgrade scripts, but of course the defaults of printers where tuned to the old (wrong) behaviour.

So, to summarise:

• In 4.6.x: Wrong, but 'papered over' (by the tuned printer settings) behaviour for the simplification.
• In 4.7.x: A (broken) fix which attempts to address the issue above, but instead it under-simplifies, rather than over-simplifying. This can cause problems depending on the printer-model.
• 'Next': The new fix(es) for the upcoming (beta) release(s), which (hopefully) finally fix at least the above problems, but for which simplification parameters might have to be re-tuned, depending on how much the old default parameters for that printer depended on the 4.6.x behaviour.

[nallath]

Can anyone also check if these zits happen in the spot where they see the slowdowns in the g-code (just to confirm it's really the same problem!)?

[Skaifer]

Hey, I found out something. Horizontal expansion has something to do with these speed drops, because when I set expansion to zero those spots become much less noticeable. That setting amplifies the issue, I guess. Here are some screenshots from gcode analyzer.
With positive expansion

With negative expansion

Without expansion but high resolution, 0.05 and deviation 0.05. There are still in some places these weird spots. Because they are small it isn't as noticeable zoomed out.

And with resolution 0.5 deviation 0.05 I can't seem to find these artifacts anymore. But if I increase expansion with lower resolution, those spots appear again. Also, with different combinations of these two settings spots appear on different places.

I'll make a test if these spots actually affect quality later. Had to mention I have CR-10s with original mainboard.

I sliced benchy with expansion and high resolution, strange, but my model has more obvious spots than on benchy, but still, there are slight speed drops and these diagonal inserted moves or something. Here is example.

[Skaifer]

Good day to you, reader!
So did two test prints. One with target to eliminate all zits decreasing resolution quite a bit.
Resolution 0.8, travel res. 0.5, deviation 0.025.

Results in completely smooth surface. Well, at least as it was before.

Then I ran a second test with same resolution settings but negative horizontal expansion.
Horizontal expansion -0.05

Can't see any defects on points where it should be according to gcode analyzer. There should be around 8 spots, but nothing. Although, this print did not turn out as clean as the first one without expansion.

There are some zits on the other side where analyzer showed nothing unusual.

Maybe gcode analyzer misinterprets Cura gcode? Or those spots are so small, that it does not show up on the end result? Anyways resolution gives the most profit on quality. Maybe the only thing expansion does, amplifies resolution defects.

[rburema]

@Skaifer We have a report from an internal user now too, that shows some blobs (_way_ less, but) still show up in actual print. We've got one fix in code review (which originally was for something related but slightly different, that I now think also might already fix the last blobs) and I'm working to see if we need another one after that.

Though, reading your message, I'm glad there is already a workaround for the current level of 'fixedness' for a lot of our 3rd party users then.

Actually, since I'm testing a few things, would you be able to attach the dog model?

[dpreed]

A suggestion from a computer systems hacker viewpoint on this general issue of "zits" is at the end of this comment. But it may also be interesting for some of the other readers of this discussion of the "zit problem" in 4.7.0, which can also appear in other slicers, I am convinced. It's useful to understand how tenuous the connection between g-code description and the actual plastic deposition can be.

From the various reports, I am starting to believe that these "zits" come from a single cause which is only indirectly slicer related. And one which cannot be detected directly in a gcode analyzer. I observed similar zits on a completely flat surface that is preceded by a very complicated surface around the corner from the surface with the zits.

This cause is inside the printer firmware, where the gcode is translated into the input to the motion planner. In my case, the translator is Marlin, and the target is a delta hardware system.

In such a system, there is a buffer between the gcode analysis step and the motion planner. What happens when that buffer holding motions is empty? The mechanism stops moving (very precisely in the case of nozzle position) but the chamber behind the nozzle is at a pressure sufficient to continue pushing out a little bit of filament. A "zit".

Now I think some of this discussion's contributors understand this issue - that a "buffer underrun" can cause a "zit".

But looking at the g-code doesn't show the cause of the underrun. The underrun isn't caused by a particular g-code line. It's not caused by precision of positioning.

And the underrun doesn't directly cause the zit - that's caused by the fact that stopping moving the extruder doesn't stop the pressure-driven emission of molten plastic immediately.

Extrusion is done to manage pressure (not volume directly). To get uniform deposition of plastic, there must never be a stop in the uniform motion of the nozzle along the skin of the print.

Now in a delta this is possible in a "straight line" motion, because the three stepper motors are being accelerated and deceleerated when the nozzle is moving uniformly. This is why the motions of the steppers are broken down into steps by the marlin firmware.

Of course in a cartesian printer, "curves" (actually polygons when emitted as g-code) are broken down into small segments, too.

But the common thing here is that anything that causes an underrun in the motion planner's buffer of segments to be output will likely cause a zit, if the underrun is not very brief.

Unfortunately, firmware doesn't report underruns that occur during a print. And no g-code analyzer can do so, unless it contains an cycle-accurate emulator of the firmware running on the printer.

I've been doing some research on Marlin's design, as have others.

But the key thing here is that to underrun the buffer between g-code interpretation and motion planning involves some very printer-dependent issues.

While it depends partly on always making sure g-code is delivered to the printer, that isn't the only problem to be managed.

Even if g-code is available, if g-code processing can't keep up with all steps of the motion, underruns will occur, sometimes because of segments that are not fully copied into the buffers that directly drive the steppers.

And note also that zit-position is not necessarily at g-code move boundaries. Whereever a buffer underrun happens to occur is where the zit will be.

This suggests that slowing the overall feed rate may be one of the best ways to avoid underruns, but of course that isn't perfect - slowing the feed rate on a layer isn't easily made automatic in the slicer. And remember, feed rate doesn't directly control plastic flow out of the nozzle - because the extruder stepper only indirectly controls it via pressure changes in the chamber. A constant feed rate is far more stable and predictable in its effect.

The user can retune their printing settings for a slower overall feed rate, but what they are tuning for would be a lot easier to tell if the firmware reported on buffer underruns that occur during a print.

I've been thinking that one way to explore this is to avoid a g-code analyzer, and instead use a dry-run of the printer firmware where the stepper outputs are completely disabled at the logic level. Of course this will take as long as the print. The underruns can be detected (ideally logged into a fast log buffer) in the hardware.

Obviously, this is not an end-user friendly feature. For a print, it takes as long to run as the print itself. But this could both be a good quality control test for slicer+firmware combo, and also help figure out how best to tune the slicer in general.

[rburema]

@dpreed Thanks for the write-up, it'll explain some things for the people unknown to this aspect of 3D-printing nicely.

We're familiar with the buffer-underrun problem, and it is one of the reasons why this is so hard to debug (especially from a distance, for printers we don't have here to test with). And it is indeed part of the reason at least the bug _in 4.7.x_ is large for some models of printer, while others hardly notice.

However, when I mentioned that internal report, it specifically investigated that, and was still producing blobs while the buffer should have been OK, given the amount of separate actions/second that where produced. I know you didn't claim so, but it still seems prudent to mention that buffer-underruns can't be the _entire_ story.

[claytono]

@dpreed FWIW, Klipper does actually report underruns for this sort of problem. The field in the log lines is print_stall. It can also print to a simulated AVR processor: https://www.klipper3d.org/Debugging.html

[Zogar89]

What viewer have you used to generate those images?

[Skaifer]

@Zogar89 I guess it's - gcode.ws. There's "Render line slightly transparent", under 2D render options tab.

@rburema It's paid 3D model, I can't share it. I'll find alternative model, that behaves similar and share that tommorow, ok?

[nallath]

For those interested, yet another set of improvements are proposed in this PR: https://github.com/Ultimaker/CuraEngine/pull/1345

[Skaifer]

@rburema Ok, printed French bulldog from Thingiverse and it prints just like mine model. Included profile just in case. Just make sure to lower it by few millimeters on z axis. Printed 5 cm in height.

Standard settings

And 0.8 resolution without expansion.

[Ghostkeeper]

We've released the 4.8 beta today, so there'll be another version with our latest fixes on this matter. As far as we've seen the issue is resolved completely now.

However for Creality users there will be one remaining issue: Your Maximum Resolution is set to a value that your printer just can't handle. We don't know how to tune this for you, so I hope that someone is able to determine better defaults for that printer before the stable version.

[Zogar89]

Compare the size of the files in 4.6 and 4.8 beta to see if the amount of code generated is back to normal.
It can be misleading if we get the same quality as before with more information since this chokes the controllers of the most modest printers.

[Sebazzz]

However for Creality users there will be one remaining issue

Does that also apply to 32-bit boards? I'm also curious what the resolution was in Cura 4.6.x where this issue didn't happen - That that is where the correct number is, isn't it?

[gluap]

@Sebazzz I've been following this issue for some time and I think the gist is that Cura 4.6.x was over-simplifying during simplification steps. The maximum resolution setting for creality printers used in cura 4.6.x profiles was matched to that over-simplifying simplification algorithm. The over-simplification issue is now fixed, so the same setting(s) as 4.6.2 will yield much higher resolution g-code with cura>=4.7. Therefore a new sensible value for maximum resolution needs to be found for creality printer profiles.

32 bit boards may be able to handle a higher resolution thanks to their computing power -- Another factor may be whether the user is printing from SD or via USB (and if he's printing from a computer via USB the exact limits may depend on the software dumping the g-code into the serial connection, for instance octoprint has some limits on how fast it supplies g-code to the printer).

[dpreed]

I'd like to make a small suggestion (based on my experience with a 32-bit delta printer running Marlin on a 72-MHz STM32 processor. Deltas being different in how they manage motion for the same g-codes.

Here's my first-order observation. Printer firmware like Marlin use a pipelined strategy to process g-code. They do not directly map gcode into stepper-rate-segments. Instead, in order to handle varying acceleration, and the delta inverse kinematics dimensional transformation that maps linear motion into non-linear pulse sequences on 4 stepper motors, they queue (into a modest sized buffer) a series of small motion blocks.

This pipelined structure creates an internal, variable depth FIFO buffer of motion blocks whose timing is only loosely coupled to the g-code processing rate.

When g-codes cannot be processed quickly enough by the gcode interpreter and then the motion planner, eventually that internal buffer of motion blocks empties. This may happen at a very different position on the tool path of the nozzle and extruder than the point where the g-coide runs out.

Thus, quality defects may not even show up on curves or highly detailed features, but elsewhere.

This is a worse problem on 32-bit systems, delta systems, etc, because of its "asynchrony" relative to the slicer's view of what is going on.

As a result, users will not be able to correlate quality issues with the cause, and they may not know what settings to change.

As an example from my own experience with 4.7.1, I observed zits on a completely flat "straight" run on a side of a box where the adjacent side had detailed lettering (and only on the vertical position where the lettering occurred, not above or below). The lettering looked GREAT. What I slowly was able to determine was that the straight side wasn't "straight" to the delta motion planner in Marlin - it was a series of small segments because the natural motion of the 3 steppers creates spherical lines, unlike cartesian printers.

So, what we really need, both from the slicer and the firmware, is a way for the user to know what the cause of the problem is, and what they can control in the settings. I suggest two parts to a remedy:

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

2) the slicer needs to be able to be managed by the user (via some kind of settings?) how to control the gcode so that these conditions won't happen subsequent to the gcode in question.

Neither the slicer nor the firmware can manage this problem without user help, and the user cannot manage the problem unless they can "see into the state of the firmware" enough to do something.

What worries me is the assumption that 32-bit processing is enough. It isnt.

[bill-orange]

@Sebazzz Your idea is well worth posting on the Marlin Github site as a feature request.

[chendo]

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

I've opened a PR https://github.com/MarlinFirmware/Marlin/pull/19674 which adds buffer monitoring to Marin that aims to achieve this. It can report command and planner buffer underruns, as well as the max time in milliseconds of each underrun between the report interval. It does not report exactly where the zit occurs in the stream, as for 4.7.1 sliced gcode would easily overwhelm the serial TX buffers which would add more delay when printing over USB unless buffers were filled. I'm still awaiting feedback on the PR however.

I am working on an Octoprint plugin called BufferBuddy (https://github.com/chendo/BufferBuddy) which aims to mitigate print quality issues when printing with Octoprint by keeping the command buffers full. However, the segments generated by 4.7.1 are so small that it cannot eliminate planner underruns entirely.

[Ghostkeeper]

Thus, quality defects may not even show up on curves or highly detailed features, but elsewhere.

True. Only, we are speaking here about line segments on the order of magnitude of 0.2mm, and buffer sizes of 16, so it's normally only one or two millimetres off. It would slow down slightly before the high-resolution curve, as it sees the motion buffer getting almost empty.

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

Ultimaker printers actually do log planner buffer underruns happening. It's not visible in the screen or anything, but it is present in the logs.

2) the slicer needs to be able to be managed by the user (via some kind of settings?) how to control the gcode so that these conditions won't happen subsequent to the gcode in question.

This is what Cura has the Maximum Resolution and Maximum Deviation settings for, really.

[BagelOrb]

I've made a model for testing resolution specifically.
resolution_checker_2.2.stl.zip

The screenshots don't show as much difference as I had hoped.

4.6:

4.7:

4.8 beta:

[Liger0]

Indeed, the circular parts aren't really working as they should on 4.8 beta (cr10s, 0.05 on max deviation and resolution)

[Asterchades]

If you're referring to the yellow extrusions at the top of the circles, that's completely unrelated and should be addressed when Arachne gets implemented. Circles when expressed as polygons rarely have even wall thicknesses which makes filling the middle portion awkward.

Also, 0.05mm maximum resolution is far too small for a CR10s now that the setting is working properly - especially if you're using the stock electronics. At 50mm/s that would allow for up to (though never actually reaching) 1,000 segments/second, which the printer simply cannot handle. You'll want to increase that to at least 0.25mm, if not as high as 0.5mm depending upon your print speed.

[Liger0]

I am referring to them, in the sense the segments are too much long, making it look a low-amount of lines polygon rather than a circle, so the perimeters don't touch and the result is a very weak piece.

I am using a 32-bit board with LPC1768, skr 1.4, and sd card. I tried all of the settings but the internal gap fill is still too much scattered.

[Asterchades]

Different issue, then. Arachne should fix it, but in the meantime you could try a narrower Wall Line Width (drop by 10-20um) or perhaps give SmartAvionics' build a try instead (he uses a different formula for gap fill - https://github.com/smartavionics/Cura/releases). Adjusting the maximum resolution settings won't change that in the slightest as they're not causing it.

Personal experience with an SKR Mini E3 v2.0 has 0.3mm maximum resolution working just fine at 60mm/s. In fact that's specifically being calculated from the speed setting divided by 200. Could probably push it further but I'm yet to notice any visible reason to do so - even printing 32mm miniatures.

[Ghostkeeper]

Indeed the yellow lines in Liger0's cylindrical extrusions on that screenshot are generated by first drawing small line segments to fill the gaps and then combining those small line segments together. The line segments are a simple lines pattern with 50% line width so this is independent of the Maximum Resolution setting.

It would be good if one or two of you could run a few tests with high-resolution parts to see what value for Maximum Resolution works for your printer in the 4.8 beta. Benchy is a good test for this. It doesn't have to be an extensive test, if time is short, but we can make at least some improvements then for the Creality users.

[hrafnkelle]

It would be good if one or two of you could run a few tests with high-resolution parts to see what value for Maximum Resolution works for your printer in the 4.8 beta.

I did a small test max resolution on Benchy like I posted earlier in this thread
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-709235235

Is this similar to what you have in mind @Ghostkeeper?

I can repeat these tests with the 4.8beta on my Ender 3.

[Ghostkeeper]

Yes, that is exactly what I had in mind, @hrafnkelle but then with the 4.8 beta.
With the improvements in the 4.8 beta I'd expect no big changes w.r.t. the motion buffer, only changes that might lead people to believe they had a buffer underrun going, so perhaps you can narrow the binary search somewhat.

[hrafnkelle]

Are we checking for issues because of underruns or because of changed simplifcation algorithm?
If because of underruns then the controller hardware matters I guess. I have upgraded to a 32bit board.
I can put the 8bit stock board back in if that would be more helpful.
Or I can print from SD card to eliminate the influence of printing over serial/usb.

[bill-orange]

@Ghostkeeper In earlier posts you referred to Arachne. What is that?

[rburema]

@bill-orange It's the '''code-name'''* for our variable line width strategy/implementation, which is someday going to be in CuraEngine. We're working on it (at least) a little each sprint now. You can find the big draft PR here if you're interested: https://github.com/Ultimaker/CuraEngine/pull/1210

*] Well... it was originally going to be the name of the separate library before we decided to merge it into CuraEngine. The name stuck when discussing it though!

[Liger0]

I noticed max resolution and standard deviation are not saved in the profiles when exported, is it normal?

[BagelOrb]

Any setting is not saved if it's not changed (or if it's the same as what's already in the default profile).

[c3-eng]

Just downloaded 4.8.0 in replacement of 4.7.x. The "Vase mode zits" problem frustratingly persists as shown, even after endless changes to maximum resolution and deviation.

I am running Modix Big 60 Printer with 32 Bit Duet Wifi board. Printing at 80mm/s.

[hrafnkelle]

Max resolution of 0.25mm with max deviation at 0.025 gives me a very nice Benchy on my Ender 3 with a Skr e3 mini 2.0 board. I printed from SD card.
Before printing I printed a few Benchy hulls (first 28 layers) with no infill, varying the max resolution from 0.05 to 0.25
At 0.15m it was almost acceptable with a smooth surface at 0.25mm

It still suffers from the discontinoutiy at the seam like I reported in https://github.com/Ultimaker/Cura/issues/8321#issuecomment-708487496

[msteele999]

I'm still seeing my original problem which is defects on the edge following
a curve. Changing Max res to 0.25 and max dev to 0.025 I still see the
problem areas. But now, I see them clearly in the slice. It looks like the
layers are not ALL starting at the same point. I have Sharpest Corner /
Smart Hiding turned on so all the layers should start in the same spot. I
am assuming this is no longer an 8321 issue and wonder if I should start a
new issue?

[image: Screenshot_102720_090655_PM.jpg]

On Tue, Oct 27, 2020 at 7:03 PM Hrafnkell Eiríksson <
[email protected]> wrote:

Max resolution of 0.25mm with max deviation at 0.025 gives me a very nice
Benchy on my Ender 3 with a Skr e3 mini 2.0 board. I printed from SD card.
Before printing I printed a few Benchy hulls (first 28 layers) with no
infill, varying the max resolution from 0.05 to 0.25
At 0.15m it was almost acceptable with a smooth surface at 0.25mm

It still suffers from the discontinoutiy at the seam like I reported in #8321
(comment)
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-708487496

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-717591483,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYILIR2E7MO2XXRZVNLSM5GVJANCNFSM4QYPYE7A
.

[bill-orange]

@c3-eng If you print at a lower speed, say, 60 mm/sec, do you see the defects?

[rburema]

@msteele999 The maximum deviation controls how much the shape may differ. Lower values => shape may differ less => less simplification is applied (unless something can be removed without deviation) => less simplified shape is more likely to give blobs and zits for certain reasons. Sorry, I misread the comment.

[Ghostkeeper]

@msteele999 I think it would be best to keep issues with the seam placement to a different thread. There you can upload a project file that will allow us to reproduce the problem and take a look.

[msteele999]

Understood - I created a new issue

On Wed, Oct 28, 2020 at 7:20 AM Ghostkeeper [e-mail]
wrote:

@msteele999 https://github.com/msteele999 I think it would be best to
keep issues with the seam placement to a different thread. There you can
upload a project file that will allow us to reproduce the problem and take
a look.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-717867906,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYNENXC5ETTO2Z2HRXTSM7463ANCNFSM4QYPYE7A
.

[Ghostkeeper]

Hrafnkelle's results give at least a baseline although it's using a modified board with more memory (and probably different CPU characteristics).

It would be good to get results from different people as well. If not, I think it'd be best to use that 0.25/0.025, better than the 0.05mm that we know is wrong. We have a meeting about this in the afternoon as well with the Cura team to decide.

[hrafnkelle]

@Ghostkeeper , could you explain the interaction between Maximum Resolution and Maximum Deviation.
As I understand the tool tips, Maximum Deviation is what ultimately controls the accuracy of the print.
If MaximumResolution tries to simplify the slice result beyond what maximum deviation allows, then that simplification isnt performed.

If thats correct then wouldnt it just make sense to put Maximum Resolution to a high value (1mm? 10mm?) and just tune the accuracy of the print with maximum deviation? If I slice with Max Resolution set to 10mm I still get a good looking benchy in the preview.

[hrafnkelle]

To follow up my question on interaction between Max Resolution and Max Deviation, I tried slicing a benchy with Max Resolution set to 10mm and kept Max Deviation at 0.025mm as it was. The resulting prints were identical except the 10mm Max Resp print had severe stringing issues! See attached photos
Can anyone explain the interaction between Max Res and stringing/retrection?

Both prints had 5mm retraction at 40mm/sec settings.

[Ghostkeeper]

@Ghostkeeper , could you explain the interaction between Maximum Resolution and Maximum Deviation.

I've done my best to explain this in the Settings Guide. Basically: Maximum Deviation wins. Cura should not modify line segments that are longer than Maximum Resolution, but will attempt to modify segments that are shorter. It will not modify shorter segments though if that causes the path to deviate more than Maximum Deviation.
There are a couple of exceptions to this, but that is the gist of it.

If MaximumResolution tries to simplify the slice result beyond what maximum deviation allows, then that simplification isnt performed.

Exactly!

If thats correct then wouldnt it just make sense to put Maximum Resolution to a high value (1mm? 10mm?) and just tune the accuracy of the print with maximum deviation? If I slice with Max Resolution set to 10mm I still get a good looking benchy in the preview.

Bad idea, because this causes long line segments (typically part of flat surfaces) to shift entirely by up to the Maximum Deviation. The Maximum Deviation is technically still held true, but the final result is visible in the print as banding. With Benchy this wouldn't be a problem since it has very little big flat vertical surfaces, but with engineering prints this becomes apparent quickly.

Can anyone explain the interaction between Max Res and stringing/retrection?

I wouldn't really know honestly. One thing that could happen is that all of your lines now shift by 0.025mm, causing them to overlap up to 1/8th of their line width. This could be causing overextrusion, which increases the pressure in the nozzle chamber and could theoretically lead to stringing.

[Liger0]

I did some prints with my cr10s with upgraded 32 bit LPC1868 board but attepts to take photo failed due to the pearl white filament.
So far, the minor issues I noticed were in extremely small points, like in the point where a curve meets a stright line of a perimeter, and in the middle of a long straight perimeter itself. In such cases the previous "tilted" lines were observed.
I used a max resolution of 0.2mm and a maximum deviation of 0.05mm, printing via sd card.
Plus I noticed not perfect seams, by the meaning the seam is "missing", like a cut line. Not sure if it's related at all tbh..

Another thought I had: Is the fuzzy skin still working? I haven't had a chance to test it, but I wonder if the changes in the code affected it in general, even for ultimaker machines.

[Ghostkeeper]

Fuzzy skin seems to still be working fine. Fuzzy skin is applied after the simplification so you might get buffer underruns, but since it's only applied to the outer wall and involves a lot of accelerations anyway, it's probably not really a problem even if you set the point density very high. Fuzzy skin does not get applied to inner walls or skin and such so it won't change the buffer underrun problem there.

[dpreed]

Reading through the wording of the explanation in Max Resolution, I'd suggest a small correction that clarifies things. This sentence is confusing:
"If the g-code contains many tiny line segments, the print head may race through the motion so fast that the processor of the 3D printer is unable to keep up"
The reason is not because the print head does "race", but that it can't do the "racing" the code gcode specifies because the processor of the printer can't keep up. While I decoded that, it left me puzzled why the print head racing kept the processor from keeping up. So one way to fix that is to replace "the print head may race through the motion" with "the motion required of the print head by the gcode may race". Or something like that. Lots of Cura users aren't programmers, so they don't have the idea of a "virtual print head" driven by g-code in an idealized printer.
Hope that helps. (Also the word "Max" in Max Resolution is odd indeed. But it's harder to change. for people used to using it) already expect it to be there, and if the explanation makes it clear, not as big a problem).

[Ghostkeeper]

Note that the Settings Guide is made by me in my spare time. It's not a problem that should be dealt with here. It's not in Cura by default. I can try adjusting the wording a little bit. I think the claims are all correct, as in, the print head exhausts the motion commands very quickly ("racing" through the motions) and is then being slowed down artificially to allow the CPU to keep up. No mention of virtual print heads.
If there are (further) issues with the Settings Guide those should be reported here: https://github.com/Ghostkeeper/SettingsGuide/issues

[dpreed]

Thanks. I was trying to be helpful, because I was confused. I think of the actual printhead as running at the specified rate, defined rigidly in the g-code, but the CPU being too slow to translate highly detailed g-code. The printhead races when it is told to, and doesn't when it isn't told to. Of course the two must cooperate. I appreciate the effort, and the guide is really nice. So, perhaps my words sounded negative - I was just trying to explain why it was confusing to me, in order to contribute. I will be happy to contribute suggestions elsewhere, now that I know where to do so. This one is clear enough.

[Ghostkeeper]

With the 4.8 stable approaching I'll apply the findings so far to the Creality defaults: https://github.com/Ultimaker/Cura/issues/8321#issuecomment-717591483

We can still change it if there are other people who want to try to optimise this setting.

[Zogar89]

Testing the new Beta, it generates many short and small lines. Extrusion is inconsistent on fill layers.
4.6 Left, 4.8 Right

[Zogar89]

Now, I tested again two identical projects.
Print time are icreased 10% due to smal lines created with new algorithm.
4.8 Beta is broken. Please don't release that.

[KimmoHop]

@Zogar89 What are your resolution and deviation settings?

[nallath]

Now, I tested again two identical projects.
Print time are icreased 10% due to smal lines created with new algorithm.
4.8 Beta is broken. Please don't release that.

I understand that you are trying to help here, but if you don't add more information, it's not helping. So what did you slice, what settings did you use? Can you share them with us? What artifacts do you see? With what version did you compare it with?

[Zogar89]

@Zogar89 What are your resolution and deviation settings?

0.5 and 0.25 same results.

[hrafnkelle]

@Zogar89 can you share the model that you are slicing?

[Zogar89]

Now, I tested again two identical projects.
Print time are icreased 10% due to smal lines created with new algorithm.
4.8 Beta is broken. Please don't release that.

I understand that you are trying to help here, but if you don't add more information, it's not helping. So what did you slice, what settings did you use? Can you share them with us? What artifacts do you see? With what version did you compare it with?

For normalization I make a Benchy.
I have also had several crashes while using it.

3h57m102g-_3DBenchy.zip

[hrafnkelle]

I am unable to load your .3mf file @Zogar89. It doesnt seem to be a valid 3mf file. Did you create it by using File->Save Project ? (Archivo->Guardar proyecto?).
Please try that and share.

[Zogar89]

I had to restore the program because I couldn't save the project without a fatal error.
Here is the file with a fresh installation.
CFFFP_3DBenchy.zip

[hrafnkelle]

Thats a huge benchy @Zogar89 :-)

I'm able to load your 3mf now.
I see the same "zits" on the top of the portholes when slicing your model with my profile in cura 4.8beta
These "zits" do not show up when Slicing in cura 4.6.2

[MrEd88]

If I remember right I had the same issue and got rid of it by changing "fill gaps between gaps" to nowere

[Zogar89]

If I remember right I had the same issue and got rid of it by changing "fill gaps between gaps" to nowere

Yeah. That solves it. But I don't know if it's a patch or correct behavior.
Perhaps this has more to do with the implementation of the new library to modify the width of the lines. I don't know if there is any thread where they discuss that.

[rburema]

Perhaps this has more to do with the implementation of the new library to modify the width of the lines.

We haven't merged that in yet, and likely will not for some time. The draft PR is CuraEngine/1210 if you want to have a look.

[konskarm]

If I remember right I had the same issue and got rid of it by changing "fill gaps between gaps" to nowere

Yeah. That solves it. But I don't know if it's a patch or correct behavior.
Perhaps this has more to do with the implementation of the new library to modify the width of the lines. I don't know if there is any thread where they discuss that.

We had an issue where gaps were created unnecessarily, which is unrelated to this discussion. See https://github.com/Ultimaker/Cura/issues/8626. This is currently being fixed in https://github.com/Ultimaker/CuraEngine/pull/1352.

[Nathipha]

If I remember right I had the same issue and got rid of it by changing "fill gaps between gaps" to nowere

Yesterday I printed a benchy with a new nozzle (Cura 7.4.2) and got a bunch of blobs/zits on the outside (photo).

Today I found this issue and printed another one (photo), using the suggestion. Unfortunately it didn't fix it: There are blobs/zits in what looks like the exact same spots on the outside of the benchy and the overall result is even worse because the railing on the higher part of the ship (left side on the image) now has a really spiky finish.

I then sliced the benchy with the exact same settings (with "fill gaps between gaps" set to "everywhere") with Cura 6.4.2 (fresh install) and the main blobs are gone (photo). Now I'm only left with the indents that probably mark the beginning of the layer line.

[hrafnkelle]

@Nathipha, did you use the 4.8.0beta or just the 4.7.2 release? Please try with the 4.8.0beta.
What printer are you using?

[Nathipha]

@hrafnkelle
I tested it with 4.7.2 and 4.6.2. Is there anything I have to be aware of with the beta version (the one released 18 days ago)?
I'm using an Ender 5 Plus with a 0.6mm steel nozzle (was using 0.4mm brass before).

[Asterchades]

The beta of 4.8 did (finally - for realsy this time) fix the simplification algorithm. But it doesn't include the changes to any profiles which are now required (pre-4.7 versions over-simplified), so if you're going to try it than I would recommend changing the Maximum Resolution settings from the Ender 5 default 0.05mm to at least 0.25mm (the upcoming 4.8 release value), if not 0.5mm. Maximum Deviation should probably also be increased to 0.05mm from 0.025mm.

[Ghostkeeper]

In the 4.8 stable release, we've increased the value of Maximum Resolution to 0.25mm for all printers that had it set to 0.05mm: https://github.com/Ultimaker/Cura/commit/ef7cfd846bc0939298b472680de4527ffd9e1ee8
This is based on your calibrations. Thank you, guys, for helping with testing!

Maximum Deviation should probably also be increased to 0.05mm from 0.025mm.

Note that this increases the resolution by halving the deviation allowed from the original path. It would result in more motion commands.
We didn't make any changes to Maximum Deviation for 4.8 as we didn't receive any indication that this needs to be changed.

[Asterchades]

Note that this increases the resolution by halving the deviation allowed from the original path. It would result in more motion commands.

That seems counter-intuitive to me. Why would doubling the maximum deviation halve the allowed deviation?

I would suspect that it may only need to be altered in isolation, since reducing the target segment count globally (ie Maximum Resolution) would allow for some small sections to have more detail without risking a buffer under-run or processor kinematic overload. But just in case it could be worth testing with for someone having problems. Plus I'm fairly confidant there would be no practical benefit - even for engineering purposes - in having a 25um maximum deviation when used with an FDM printer.

[Ghostkeeper]

Ah, sorry, I read your comment wrong. I read it as "from 0.05 to 0.025" but you wrote "to 0.05 from 0.025". You're right, of course. The setting behaves as you'd expect.

At least 0.025mm (and 0.05mm) are in a reasonable order of magnitude for Maximum Deviation. I don't expect it'll be much of a problem, but if you can try out something else we'll be happy to hear your results.
The actual print will of course vary a lot more than the 0.025mm (0.2mm of hysteresis in a printer's gantry isn't unusual) but having a deviation too high can cause visible banding too.

[dpreed]

Remember that the new profiles are "default" profiles. Fixing them doesn't fix people's personal profiles developed in the past when the simplification algorithm tended to hide the issue (4.6.2 apparently covered up the too-fine Max resolution problem, and 4.7 apparently exposed the problem with defaults for some printers, right?)

I don't know how 4.8's release process will address the need for people to perhaps changed their "working" profiles that have been adapted from prior defaults - I'm just a user, and I happen to be rebuilding my own profiles from scratch for 4.8. This issue has raised my awareness that contributed profiles for some printers might be based on tuning for old versions of Cura, and thus should not be viewed as "gospel" anymore.

That's OK, but... I participate actively in a group that supports owners of a particular brand of printers. Most of them aren't software engineers, and most don't understand the STL-Slicer-gcode interpreter pipeline.

Many new users of Cura seem to have been confused by issues like this one, and say "the heck with Cura, it's s**t, I'll use the other famous slicers that are made by cooler people". Not good. Especially not good if it is their own misunderstandings of what is going on. People like to blame stuff for their own misunderstandings, and this does an open source community no good (viz. Linus Torvald's nasty postings that scare away people with potentially useful feedback, though those who end up attacked by Linus are usually more sophisticated than Cura's users). This is a larger culture problem - a mismatch between those who understand how 3d printers work at a deep level and the users who use words like "underextrude" and "stringing" but don't really understand what they are talking about.

I'm not trying to criticize anyone here, but there is a problem that many understand that the default profiles are of uneven quality, and can't be perfect or general, but this isn't so clear, especially for those who don't use Ultimaker printers.

[kiss81]

I tried the beta 4.8 linux appimage on my cr-10v2 with an e3d hemera / 0.9 steppers on all axis, but the curves on my Benchy looked horrible. I only increased the Maximum resolution to 0.1 and Maximum Deviation 0.05 on an existing 0.16mm profile. I am kind of lost how to clear the full config as that might help? I tried deleting the ~/.config/cura/4.7 and 4.8 folder without luck. The 4.6 folder is still there as v4.6.2 is my workhorse for now.

[Nathipha]

I agree with @dpreed . 3d printing has a huge learning curve and in the beginning everything is really overwhelming already. Default profiles simply have to work good (-ish) to give people a good headstart, otherwise there's no point to them. As someone who's still pretty new to 3d printing I can also agree with his point that if it doesn't work (at least with a little bit of tinkering, like temperature, speed or retraction), people are going to get frustrated. If someone's been working on a profile, thinking that they'd finally found the right settings and then a new version completely breaks it, that's going to cause the same type of frustration. I'm not a pro - not even close - and even though I understand the meaning of words like "stringing", I'm not even close to having found the right settings to actually remove it almost completely but I do think that I have a couple of profiles that work .... good with my printer.

Tbh, I have no idea what Asterchades and Ghostkeeper are actually talking about. That's why I really don't see a point of installing the 4.8 beta because I won't know how to actually fix the bigger problems that might come up with my current settings. I'm just going to have to wait for the 4.8 release and hope that it'll fix the problem (and that there's some information on how to fix existing custom profiles too).

If anyone needs any more information or more images, feel free to @ me though.

[Asterchades]

Remember that the new profiles are "default" profiles. Fixing them doesn't fix people's personal profiles developed in the past when the simplification algorithm tended to hide the issue

@dpreed It will correct any print profiles which were made without changing the settings in question. Anything that doesn't deviate from the base printer settings doesn't get saved with the profile, so unless you changed that setting the fix will be automatically applied. And if you did change that setting then hopefully you have the sense to revisit it, since that's not a normally exposed setting.

Just as an example, none of Chuck "CHEP" Hellebuyck's profiles which he provides for download will require any alteration at all - they'll have a more sane value by default under 4.8.

I only increased the Maximum resolution to 0.1

@kiss81 Try higher - especially if you're going faster than normal. Ultimaker's own printers use 0.5mm, for example, and it's safe to say they know a few things about 3D printers. 400-step motors already put extra load onto the controller (assuming still 1/16 microstepping) so you don't also want to have an excessive amount of segments being presented on top of that.

Tbh, I have no idea what Asterchades and Ghostkeeper are actually talking about.

@Nathipha That's probably a good thing. If you've never messed with those settings than you won't have made any profiles which have changed them, meaning you won't need to manually fix them.

[rburema]

@dpreed @Nathipha We're aware of this problem on the one hand, but, on the other hand, limited in our power to address it:

• Ultimaker employees creating/deciding the profiles for what are essentially competitors is not a good look. (Although, as a side note, we have changed one or two values related to this problem when we where certain that value was copied from the old 4.6 default behaviour for 3rd party profiles.)
• Conversely, buying all kinds of 3rd party printers and spending time on optimizing all (and if not _all_ where do we put the limit?) of those profiles is not a really popular idea withing the company. (Though who knows, that might change, although that is _very_ far from likely. And even then, only for a few of the most popular ones.)
• Relatedly, we wouldn't have any time any more for actual features (or bug fixes for that matter).

For context: Around 5 to 10 new profiles are added for new printers with each version, every two months.

Cura is Open Source, the LGPL kind even. As the (main) developer/maintainer of that, Ultimaker and/or the 'core' team of developers have some responsibility to it, but this shouldn't _all_ be on our shoulders. There are literally things so difficult either in time, effort or, yes, even politically, that we basically can't do them. The community as a whole? In a 'many hands make light work' way? Absolutely is able to address the problem if interest is great enough.

And just to be sure, I think this _will_ be addressed by those more experienced users, but it will take some time.

Now you might ask, why don't you only push the solution when everybody is on board then? However, that will only lead to chicken/egg problems. Asynchronous communication with 100s of people is not really plannable. OTOH: 'If you build it, they will come.'

[chrta]

@rburema I do not want to sidetrack this issue, but wouldn't it make sense to put the Cura version that was used to create the profile into the profile itself (at least major and minor version)? At first it would be sufficient to just have it available. Later this could be evaluated to inform the user that maybe the profile needs to be updated because certain internals of Cura changed.

[rburema]

@chrta I can see the merits of that, though putting it in the users face in the UI may not be the way to go. (Also it would be a bit weird for 'base profiles', so we'll probably have to make the field optional.) Let me discuss it with my colleagues sometime this week.

[Nathipha]

@Asterchades
I might have misunderstood then. Does that mean that, unless you actively changed those settings, a 4.7 profile is still going to work the same way in 4.8, minus the glitch?

@rburema
I fully understand that you can't please everyone and the first time I opened Cura I was surprised by how many default profiles there are, even for printers by companies I'd never heard of before.

The thing is, Cura is a favorite in the community because of three things: 1. It's free, 2. It's easy(-ish) to learn, 3. There are already existing profiles for the most common printers (and more). Take even one of these points away and you're inevitably going to lose users - a lot of users. If they wanted that, they/users wouldn't keep adding new profiles, as you said. Same thing though if a version is a mess, which 4.7 seems to be, looking at comments in forums that often say to just use 4.6 in the meantime.

I also fully understand that profiles for 100+ printers can't be changed/tested for every version and if the remaining profiles are provided by the community - great - but with what it looks like where Cura is heading, which is wanting to be a universal slicer, you'd expect there to be at least a bare minimum of well tested profiles for the printers people use most: So basically Ender and Pruse because, let's be honest, not everyone has $2000+ for an Ultimaker printer. Because of all of this the profiles I'd expect to be updated first and maintained the best (which includes this problem) are: 1. Ultimaker (obvious), 2. Ender (biggest community), 3. Prusa (obviously want to be a competitor to PrusaSlicer) and only then the smaller ones like Anet, Anycubic and Geeetech.

At least that's how it usually works in software development from my experience: What devices is the latest e.g. Android version going to be released on first? Of course Samsung's phones/tablets - maybe they're the biggest/most popular, maybe they just pay the most, I don't know.

[Asterchades]

@Nathipha

I might have misunderstood then. Does that mean that, unless you actively changed those settings, a 4.7 profile is still going to work the same way in 4.8, minus the glitch?

Exactly. If you didn't change it then it will take up the printer profile's default value, which would have been updated with 4.8 to be more suitable.

If you're unsure, load up 4.8 and compare the value for Maximum Resolution between your profile and any of the defaults ("Fine" being exactly as the printer is declared). They should match. If they don't, well, take the value from the default profile and whack it into yours, save, and print!

[acwest]

4.8.0 Release is looking much better now. I find that with Maximum Resolution of 0.25 (the new default) sharp corners like the edge of Benchy's door frames are a bit rounded out, I am trying with 0.15 now to see if it makes any difference. This is one of the best Benchys I have ever printed though, so I would call it a success

[msteele999]

What are you using for Maximum Deviation? I am ready to test my specific
model that prints perfectly in 4.6.x and fails terribly under 4.7.x and
4.8.0.

Mark

[acwest]

What are you using for Maximum Deviation? I am ready to test my specific model that prints perfectly in 4.6.x and fails terribly under 4.7.x and 4.8.0. Mark

4.8.0 release or Beta? Some rather critical fixes seem to have made it in between the two. The default deviation is 0.025mm now, I haven't tried changing that yet, I am going to see how the 0.15 resolution works first. What is going wrong with your model, do you have a picture?

[msteele999]

They are shared further up in the thread but I'll repost. 4.8.0 release,
not beta.

[eoyilmaz]

4.8.0 seems to solve my problems with 4.7.1. I still see some little zits here and there, so it is still not as good as 4.6.2. But I can accept that.

My settings are:

Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.5 mm
Maximum Deviation: 0.05 mm

I will also try reducing the Maximum resolution to 0.25 mm and Maximum deviation to 0.025 mm later today.

EDIT: I'm printing with an Ender 3 Pro.

[kiss81]

4.8.0 seems to solve my problems with 4.7.1. I still see some little zits here and there, so it is still not as good as 4.6.2. But I can accept that.

My settings are:

Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.5 mm
Maximum Deviation: 0.05 mm

I will also try reducing the Maximum resolution to 0.25 mm and Maximum deviation to 0.025 mm later today.

EDIT: I'm printing with an Ender 3 Pro.

Thank yu for sharing. This looks back to "normal" with these setings. What was yur layer height?

[msteele999]

Sorry for the repost - images were too large

No joy for me:

Sovol SV01 using Cura built in profile

0.28 resolution
Max Resolution 0.15
Max Deviation 0.05

This print is pristine in 4.6.1

I will retry with Max Res at 0.5 and Max Dev 0.05

https://drive.google.com/file/d/1M_D32vJ1wngkKC5VVdAxnNl8j03ftqxW/view?usp=sharing
https://drive.google.com/file/d/1MRavqPq9hDEf-zYoPH8cWVTeaK7-UPWy/view?usp=sharing
https://drive.google.com/file/d/1MX2N2a1knxx7tBDB5UY_KCZZ9-gK4ECh/view?usp=sharing

On Thu, Nov 12, 2020 at 11:07 AM Mark Steele [e-mail] wrote:

They are shared further up in the thread but I'll repost. 4.8.0 release,
not beta.

On Thu, Nov 12, 2020, 10:40 A. Craig West [e-mail]
wrote:

What are you using for Maximum Deviation? I am ready to test my specific
model that prints perfectly in 4.6.x and fails terribly under 4.7.x and
4.8.0. Mark

4.8.0 release or Beta? Some rather critical fixes seem to have made it in
between the two. The default deviation is 0.025mm now, I haven't tried
changing that yet, I am going to see how the 0.15 resolution works first.
What is going wrong with your model, do you have a picture?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/8321#issuecomment-726156535,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRMUYKABYX42MVRWUEAGRTSPP6V7ANCNFSM4QYPYE7A
.

[msteele999]

Sorry for the repost - images were too large No joy for me: Sovol SV01 using Cura built in profile 0.28 resolution Max Resolution 0.15 Max Deviation 0.05 This print is pristine in 4.6.1 I will retry with Max Res at 0.5 and Max Dev 0.05 https://drive.google.com/file/d/1M_D32vJ1wngkKC5VVdAxnNl8j03ftqxW/view?usp=sharing https://drive.google.com/file/d/1MRavqPq9hDEf-zYoPH8cWVTeaK7-UPWy/view?usp=sharing https://drive.google.com/file/d/1MX2N2a1knxx7tBDB5UY_KCZZ9-gK4ECh/view?usp=sharing
…
On Thu, Nov 12, 2020 at 11:07 AM Mark Steele @.> wrote: They are shared further up in the thread but I'll repost. 4.8.0 release, not beta. On Thu, Nov 12, 2020, 10:40 A. Craig West *@.*> wrote: > What are you using for Maximum Deviation? I am ready to test my specific > model that prints perfectly in 4.6.x and fails terribly under 4.7.x and > 4.8.0. Mark > > 4.8.0 release or Beta? Some rather critical fixes seem to have made it in > between the two. The default deviation is 0.025mm now, I haven't tried > changing that yet, I am going to see how the 0.15 resolution works first. > What is going wrong with your model, do you have a picture? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#8321 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/ABRMUYKABYX42MVRWUEAGRTSPP6V7ANCNFSM4QYPYE7A > . >

0.5 looks slightly better but not good enough for customer work:

https://drive.google.com/file/d/1MvGrCeBt4BA-lt7Z_t8VhfY-kNWciUJm/view?usp=sharing

For reference, same print / material on 4.6.1:

https://drive.google.com/file/d/1MsCuucTUXAyovJ27mcJDmpQeIrAOiIqh/view?usp=sharing
https://drive.google.com/file/d/1Mm3BOxHVUwi4qSPwf-XmHtl3Ux5LiIuQ/view?usp=sharing

[acwest]

It seems like the new default of 0.25 is as good as it gets, going higher seems to have side-effects

[eoyilmaz]

4.8.0 seems to solve my problems with 4.7.1. I still see some little zits here and there, so it is still not as good as 4.6.2. But I can accept that.
My settings are:
Maximum Resolution: 0.5 mm
Maximum Travel Resolution: 0.5 mm
Maximum Deviation: 0.05 mm
I will also try reducing the Maximum resolution to 0.25 mm and Maximum deviation to 0.025 mm later today.
EDIT: I'm printing with an Ender 3 Pro.

Thank yu for sharing. This looks back to "normal" with these setings. What was yur layer height?

0.20 mm

I also checked it with these settings:

Maximum Resolution: 0.25 mm
Maximum Deviation: 0.025 mm

and it is equally good if not a little better.

[msteele999]

I am included the project files and gcode for my tests.

The settings should be identical between the two versions (4.6.1 and 4.8.0) unless of course there is a new setting in 4.8.0 that does not exist in 4.6.1 or a settings was removed.

I have the prints looking MUCH better, but there are still artifacts on the curves (that I do not see in the sliced preview) and they are bad enough that I cannot use them for customer prints.

4.6.1_curves_no-issue_msteele.zip
4.8.0_curves_issue_msteele.zip

[kiss81]

Under linux I deleted all the cura settings / profile information. I started the 4.8 release appimage and I took the 012 super quality as a default and only changed temperatures / retraction to my printer settings. I printed this on a cr-10v2 with 0.9deg stepper motors and a e3d hemera direct drive. The sides look good, but the curve / sharp edge of the hull is still horrible.
I tried the default 0.25mm / 0.025 deviation, but no luck. This print below is even with 1mm resolution / 0.1 deviation. The gcode for a 0.16mm benchy is 4.5Mb then, so small as expected, but the result looks really bad imo.
What am I missing?

below a fast test with 4.6.2, more or less the same settings, but forgot lowering the print temperature, so the overhangs are not clean. But even then it looks much better. I still have another "issue" with my jerk / acceleration I guess as I can "see" the gcode steps. I have to say the used PLA is not forgiving as well, so it shows everything.

[Ghostkeeper]

I find that with Maximum Resolution of 0.25 (the new default) sharp corners like the edge of Benchy's door frames are a bit rounded out, I am trying with 0.15 now to see if it makes any difference. This is one of the best Benchys I have ever printed though, so I would call it a success

If the door frames protrude by more than 0.025mm (a quarter of a width of a human hair) they should not be affected. You could be seeing the effect of increased printing speed here due to the nozzle not slowing down by the buffer underrun?

The pictures I'm seeing here do not really contribute to improving this problem. There are dozens of reasons why you could be seeing ringing or blips. There are two ways in which you can contribute:

• Tell us what is wrong in the g-code. Is it not reducing the resolution in places where you'd expect the resolution to be reduced? If so, please show us a project file and point out where in the project file you are seeing too much detail in the g-code (as in: segments shorter than the Maximum Resolution with less deviation than the Maximum Deviation). If we have such an example, we can work out what the bug is in the simplification algorithm.
• Give us better defaults. If the defaults are currently giving bad results, tell us which defaults work better for your printer. We've now changed it for all Creality printers (since the default was the same for all of them) but perhaps it's different for some of them.

I don't know how 4.8's release process will address the need for people to perhaps changed their "working" profiles that have been adapted from prior defaults - I'm just a user, and I happen to be rebuilding my own profiles from scratch for 4.8.

Normally we have a version upgrade system that would also automatically update profiles that users made. In 4.7 there were multiple bugfixes to the simplification algorithm and one of them was that the Maximum Deviation was essentially handled too strictly such that the allowed deviation in the algorithm was only half of what the setting said. When this was fixed we upgraded all users' profiles to halve the maximum deviation, so that the result would be the same.
We also fixed another issue then where the resolution was decimated too much when using extremely high resolutions, because it was having a sort of chain effect of removing many segments that were individually extremely small but together quite big. This was less cut-and-dry and we didn't think to implement a version upgrade for that. And if we did, it would be very hard to predict what would give the same results on average. We also can't blindly implement a version upgrade for that now since users will already have adjusted their maximum resolution in 4.7 and 4.8. So there really isn't a good solution to adjust users' custom profiles, especially not now.

[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.