Inner walls printing in midair

[OsmosisD]

Cura Version

5.7.2

Operating System

Windows 10

Printer

Creality CR-100

Reproduction steps

Running a bridging test, fails every time despite bridging working on most other prints. I have Wall Ordering set Inside To Outside to improve overhangs on general prints. Using this test for my print: https://www.thingiverse.com/thing:2614805

Scaled down to 60% since I'm testing at layer height of 0.12mm instead of 0.2mm. The issue doesn't happen at 0.2mm at 100% scale. Might be a scaling issue?

This bug appears to be happening regardless of whether or not Enable Bridge Settings is ticked or not. I've also tried varying Line Width from 0.24mm-0.6mm and disabling Optimize Wall Printing Order, and it still happens.

Current workarounds are to set Wall Ordering to Outside To Inside or to set Wall Line Count to 2. Filleting the inner corner may also help; haven't tried as it's not my model.

This bug may be specific to small subset of models with thin layers over interior holes.

Actual results

All prints failing to bridge regardless of bridging settings. Looking at the slicing preview in Cura, it's printing the innermost unsupported wall first.

Expected results

Supported inner wall should print first, then innermost wall, then outer wall.

Add your .zip and screenshots here ⬇️

[GregValiant]

Thanks for the report. Without a project file there can be no investigation. The instructions are on the page you filled out for this report.

[OsmosisD]

I actually tried uploading it before but it wasn't working. Browser issues lol. Fixed now, here's the file. CCR100BRIDGE-_One-layer_bridging_test.zip

[GregValiant]

The problem here is that your settings are not configured for a model like this. You need to print this with the Wall Line Count = 1. The only place that 3 walls can be printed is the overhanging roof, but the lower structure that is supposed to support it is only made up of the two outer walls. So Cura is printing 3 walls at the roof and the inner walls are over air and fail. Set the Wall Line Count to 1 and look at the preview. You can try the print with the "Extra Skin Wall Count = 0" as well. It's a different look and for this model may work well.

I'm going to remove the bug label as this and close it as this is a model and settings issue. The settings need to work for the particular model. A conventional bridge test model would have buttresses at the ends of the bridging area so the roof has something to bond to.

This is with Wall Line Count = 1 and the Extra Skin Wall Count = 1.

Here the Extra Skin Wall Count = 0. This is a bit more of a torture test.

[OsmosisD]

Like I said, setting Wall Line Count to 2 is a workaround, but I feel like this shouldn't be happening in the first place regardless of wall line settings.

[GregValiant]

My take on this is that it is exactly printing with the settings you put in. That's how it works. There is no AI involved. The user must select settings that produce a viable print. That model cannot be printed successfully with the wall count > 1. It cannot be considered a bug when the application is doing exactly what you asked it to do just because what you asked for doesn't work, or because you don't like the results.

This is with the Wall Line Count at 8 and the Extra Skin Walls at 4. This is a guaranteed failure and it is because of the settings combined with the geometry of this particular model.

This is in PrusaSlicer with 3 walls. This will also fail and for the same reason.

[OsmosisD]

Perhaps I should put this as a feature request, then. If one isn't too knowledgeable about 3D printing they might just keep printing it over and over again wondering why bridging never works; and it isn't obvious unless one manually goes through the line print order and not just the layers. As mentioned before, if printed outside-to-inside, this could work, but some people (like myself) have inside-to-outside enabled by default to produce better overhangs, and multiple walls for better shell strength.

It might not be a "bug", but it is undesirable behavior, for the slicer to try to print things mid-air unless you specifically tell it something like "ignore stability and print whatever".

Prusa Slicer at least indicates there are possible stability issues; there's nothing of the sort in Cura (at least for this situation). I don't believe adding a function to detect if a print wall is completely unsupported is impossible. No AI is needed for this, just a few lines of code (though it could be more complex depending on various factors; obviously running it for every print line would be inefficient and slow down slicing). Would be a nice feature to have, either way.

[GregValiant]

Back in the day it was decided that the easiest thing to do with Cura would be to have an "Ambidextrous" front end, and a singular back end that did the actual slicing. That meant that only one front end would need to be maintained rather than one for Windows, one for Mac, one for Linux, one for Chrome, etc.

So Cura uses the interface tools (dialog boxes, textboxes, checkboxes...and MessageBoxes) of QT6/QML. My opinion is that they are exceedingly clumsy to use. Just the change from QT5 to QT6 that was made for Cura 5.0 is still having bugs creep up. I think Cura has outgrown that sort of frontend but nobody will ask me.

You can write up a nice concise feature request detailing exactly what you think is needed and submit it. Remember that you have to convince the UltiMaker Company to spend their money paying their people to do this so people like you and I can get a warning that something isn't right when we slice for our non-Ultimaker printers. I don't know how hard doing this would be, but I know it won't be without cost to the UM company.

Those sorts of test models are often a problem as their entire point is to make it difficult for something to happen. The fact that there is no problem with the "Wall Count = 1" was quite apparent to me, but I am a fairly experienced user. Nevertheless, it is (and should be) the users responsibility to see how their print is going to come out. A print like this is not mission critical, but rather a simple test that will be immediately thrown into the recycle bin. As such it would have a low "wow" factor in a feature request. Another thing is that the designer of that piece erred. I can design all sort of "optical illusions" that can't be printed. That doesn't infer a bug in the slicer, just stupid models I made up. This is a similar model but I made the walls 3mm wide so the bridge would have something to stick to.

PrusaSlicer does have that warning when it notices an unsupported overhang (which is essentially the problem here). Maybe something like that could be added. I write post-processors and I try to keep a user informed if something isn't right, but it's not easy when the actual slicing is occurring in a different app (CuraEngine) rather than the frontend where the settings reside (UMCura). That split between the frontend and the backend was the original decision and is still there.