Infill doesn't attach to curved walls generating gap

[Olifiers]

Application version
Cura v4+. Currently replicating it with Cura 4.8.

Platform
Windows 10 PRO 64bits, GeForce RTX 3090. Problem replicated on Windows 7 64bits, Intel HD 5000.

Printer
Ultimaker Original (happens to other printers too)

Reproduction steps
Extensive thread here:
https://community.ultimaker.com/topic/19312-thin-gap-between-outer-wall-and-inner-wall-only-on-small-circular-insets-but-not-on-the-perimeter-of-the-print/?_fromLogin=1

Screenshot(s)

Actual results
Cura-sliced objects present a gap between the infill and the walls on curved surfaces, particularly exacerbated at around 10-20 degrees curves.

Expected results
Perfect attachment of infill to walls.

Project file
https://community.ultimaker.com/applications/core/interface/file/attachment.php?id=77170

Log file
No log file.

Additional information
Issue disappears when using same printer with similar settings on other slicers, rulling out printer setting problem.

[nallath]

Are you sure it's not a setting problem? If I slice it with the default settings of the Anycubic I get the following result:

When I do the same with the settings that you provided, I get the following result:

[Olifiers]

I'm pretty sure it's not a settings problem for a few reasons: 1. The issue is present with default settings from a fresh install of Cura 4.8 on Ultimaker Original (tested myself) and reported by another user on Ultimaker 2 on defaults. 2. If you check the thread in the report, you'll see all types of settings being tried by multiple users, none seem to resolve the issue. At best we can hide the issue with Ironing and over-extruding. 3. In the first image you've shared, the issue seems to be present already, just check the two gaps formed by yellow filling on the upper right hole. Unlike the lower left hole, where its perimeters are totally covered, the top right hole has gaps around its green walls.

…

On Mon, Dec 14, 2020 at 2:36 PM Jaime van Kessel ***@***.***> wrote: Are you sure it's not a setting problem? If I slice it with the default settings of the Anycubic I get the following result: [image: image] <https://user-images.githubusercontent.com/3922611/102093773-d565e600-3e21-11eb-80fc-a1d09be95f3f.png> When I do the same with the settings that you provided, I get the following result: [image: image] <https://user-images.githubusercontent.com/3922611/102093850-ee6e9700-3e21-11eb-9a6a-b8a71125d8a3.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8933 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUW2SVTY4766UNWU6CZ3CTSUYPIBANCNFSM4UZNWOGQ> .

[konskarm]

Did you try disabling the "Filter Out Tiny Gaps" setting?

I get the following result when I do it in your project file:

And in the standard Draft profile of the Anycubic:

It's not the most desired outcome (because gap filling is filling it with multiple small lines and not a single line), but at least the gap is filled.

[Olifiers]

Hi Konstantinos,

Thanks for the tip, I wasn't aware of this option.

Unfortunately, it didn't solve the problem. In fact, the issue doesn't manifest itself in the Cura visualization, only when printed out -- which makes this a very weird issue indeed.

The object pictured below looks perfect even with the 'Filter Out Tiny Gaps' option enabled. Disabling it doesn't change anything noticeably. Yet, when printed, huge gaps develop both at the left and right intersections of the walls with the top layers and infill. Just to make doubly clear: both the infil (any percentage and shape) and the bottom/top layers fail to properly connect with the walls at the areas marked. One can't see anything wrong or gaps in Cura, but once printed they are severe.

I'm suspecting this could be something to do with a Cura relationship with the current Marlin firmware. Some odd step calculation being rounded the wrong way.

[Ghostkeeper]

The problem here is Horizontal Expansion, in combination with this model. Your Horizontal Expansion is set to 0.2mm. Resetting this to 0mm removes the problem (but then probably makes your dimensions inaccurate, if that was the reason you set it to 0.2mm).

The model is not made very accurately. The facets are linked together with tiny faces, which then make a fairly sharp corner. Through Horizontal Expansion these corners are greatly exaggerated. Normally such things get removed by the Maximum Resolution and Maximum Deviation settings. However Horizontal Expansion is (rightly) executed before the reduction in resolution, and so the sharp corners are expanded to beyond the Maximum Deviation and the simplify() function won't remove them any more.

[Ghostkeeper]

I wouldn't really know how to make it behave correctly here. A few options are:

• Offset the horizontal expansion differently to not make it expand small details. Miter limit? This could introduce extra segments though. And I believe it's already a round offset which has no miter.
• Execute the simplification before the horizontal expansion. But that would make the resolution too low in the final result (or too high if the expansion was negative).

Neither of these are good solutions in my opinion.

[Olifiers]

Hi folks, Ghostkeeper.

Thanks for the feedback on this. I must disagree with your assessment for a couple of reasons:

1. If you check the original forum thread linked in the original issue, you'll see people reporting the problem with printers other than the Ultimaker. You'll see Ultimaker 2 and even other manufacturers reporting the same issue;
2. The problem does not happen with other slicers, such as Slic3r. This does speak to your issue with the model itself. This problem is manifested with different models when sliced on Cura, but the same models perform fine on other slicers.

I've just starter printing a new object today. Below you'll see Cura's first layer, showing the object sliced perfectly. Then you'll see the object actually being printed, with the problem clearly shown. I've also attached the sliced object straight from Cura to this thread.

Note that I've expanded the skin overlap from its original 5% to 30%, expanded the number of walls from 2 to 4, and yet it happens. You don't see any gaps on other geometries such as the straight walls -- it only happens on curves. This is where I believe we should be looking into.

I again stress this: it doesn't seem like a problem with settings. We've tried every setting we could think of. Yet this problem does not happen with other slicers. It's also worth of note this problem is only observed on curved geometries, not straight 90 degrees.

UMO_01b_Baseplate_part2_universal_200x200_v2.zip

[Olifiers]

Worth pointing out: this issue has been persistent for years in forums, with a lot of people putting effort into trying to debug it or find a setting around it. Invariably, people move on and adopt another slicer because no setting seems to fix it, while most expert posters keep ascribing the problem to settings regardless. I hope that by bringing this issue here it might be addressed.

This post, in particular, it's very detailed with several tries -- in the end, they resort to setting a 0.4 extruder to 0.5 setting. Surely this cannot be a proper solution to the problem:
https://community.ultimaker.com/topic/24140-gaps-between-top-layers-and-walls/

https://community.ultimaker.com/topic/23102-looseness-around-holes/

[nallath]

Well, "people have been reporting it" is a bit of an exaggeration. I actually think that there are multiple issues here that look the same and are being piled on a single list because of them appearing to be the same.

In at least a few of the cases, there isn't a slicer issue, but an issue with the printer.

I'm almost convinced that it's caused by slicer settings since I've never had the issue when printing objects myself (even the ones that people claim are a "sure" way to get the issue). Do note that it's entirely possible for certain behavior to not be a problem for one printer and suddenly be a problem for another. As such; switching the slicer can solve the problem, but it doesn't mean that the issue itself is with the slicer (It's only when both the slicer and the printer do the certain thing that you actually see the issue).

Due to covid, I can't actually print any of the models that you use on an Ultimaker Original. But If you'd like I can print it on a UM3 to show that it's not the slicer (since if it was the slicer, it should happen on all printers, right?)

[Olifiers]

I've provided as much information as I could gather with the aim of helping indentify the source of the issue. But if the answer is 'well, works on mine', there's little else I can do.

I'm not familiar with the Cura codebase to be able to be of any further help than providing examples of the issue occurring. If I had to take a guess, this looks like a math rounding issue that is triggered in conjunction with certain firmwares? That would explain why it wouldn't happen on different slicers working on similar settings. It could also explain why certain printers display this behaviour while others don't. But this is just a guess, I'm not an expert nor able to advance the investigation any further than what I've provided, unfortunately.

I'll just set my extruder to 0.5 (despite it being a 0.4) like a few others did to get rid of the issue. Feels wrong, but it works.

[Ghostkeeper]

To be clear, I've been talking about this screenshot taken by Nallath earlier in this thread:

I can see how that introduces gaps. It's a very specific problem which - I'd say - should not be produced by a slicer.

Contrast that to the general problem of skin not adhering to walls which is a generic 3D printing problem akin to underextrusion. Of course there will be many reports about it, but it's not a slicer bug but a print quality issue. There is not one solution to this. It's 99% determined by settings, which means that indeed it won't reproduce on other slicers (since you'll be using other settings there even if most of the common slicers pretty much have feature-parity for common use cases), but those other slicers will also have that problem if you change the wrong settings there. And indeed it won't reproduce on other printers or even with the same printer in a different room. Different printers have different hysteresis in their gantry, or the room temperature is different.

We cannot really help you with skin not adhering to the walls, other than give you advice: Increase the Skin Overlap, use the Stretch post-processing script, reduce wall printing speed, that sort of thing. As long as the g-code output is working as expected this is not a bug. Again, we cannot help you with your print quality issues.

The only thing remaining then is that issue of the jagged wall lines, which is not working as expected and then indeed a bug.

[Pla5ma]

I would really like a "Small Hole Flow" setting as I experience the same on some holes.

[exabrial]

If there is anything one can do to help this along, models, example prints, patches, or $usd, I would gladly contribute. I really like Cura :) Software bugs like this are certainly frustrating as there's a million variables, and I just want to express my thanks for those who have taken a look already.

I'm Ender3, SKR Mini E3 V2.0, latest Cura

[GregValiant]

Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed?

[Olifiers]

Unfortunately I don't know, I moved on from Cura due to the issue at hand and my inability to raise it properly to the community in order to have it looked at.

…

On Wed, 20 Nov 2024 at 02:39, GregValiant ***@***.***> wrote: Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed? — Reply to this email directly, view it on GitHub <#8933 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUW2SQVRAIR4LY3QOFDCWL2BPY7DAVCNFSM6AAAAABSDQODXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBXGIZDEMBSGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[GregValiant]

This problem has come up a couple of times. My own "unofficial" view is that it's a material problem with shrinkage rather than a problem with the code. I have had a couple of prints that have shown this behavior but reprinting the same gcode file with a different roll of filament failed to reproduce the problem.
I'll go ahead and close this. I know the Cura team has looked at this behavior and no determination was made.