Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.12k stars 2.07k forks source link

Existing structure proximity restriction #5892

Open Asterchades opened 5 years ago

Asterchades commented 5 years ago

Is your feature request related to a problem? Please describe. Currently, Cura (as of v4.1.0) is, for reasons I cannot fathom, allowing itself to slice layers such that entire sections can be printed over nothing but thin air. Not just a small amount, like what you might expect when it comes to parts designed not to join together (joints, supports, etc), but parts which have no chance of coming into contact with anything else. As is expected in this kind of situation, all it results in is a stream of filament being spewed out and coiling up either on the bed or another part of the model.

Air Printing In this image ("FilHolder_80mm_V1.STL" from "Creality (Ender 3) Filament holder 80mm spools" by "mjoaris"), the completed inner and outer wall of the circle on the left have absolutely nothing below them for at least 80mm, and they're at least 5mm away from the nearest edge. The start of the next wall, where the extruder is currently headed counter-clockwise, is similarly unsupported.

Neither bridging nor overhang settings affect the completely airborne circle, though enabling the experimental bridging settings (with no chances made) will prevent the in-progress wall from starting out in the open.

Describe the solution you'd like In situations like this, it would make sense for the completely un-suspended parts to be printed in an order and style which at least gives them some chance of actually staying in place. In the pictured example, this would mean potentially printing the supported part of the walls first, then lower skin either in a concentric style or perhaps layers parallel to the two "tips" of the previous layer (the far side tip is obscured by the pictured extruder). After the skin layer is completed, the remaining, unsupported walls could be completed.

Potentially this may need some kind of user-alterable options. Defaults may be to ensure prints cannot usually occur further than 1-2 layers from the nearest material vertically, while not allowing printing more than 1 width (wall/infill/nozzle) away from existing material if not supported vertically. The bottom-most layer would naturally be excluded from such checks, due to the solid print bed.

This may not necessarily be the cleanest way to print, but it has a chance of allowing parts like this to be printed without supports, rather than simply spewing filament out for no effect other than wasted filament and loops/tangles which need to be removed.

Describe alternatives you've considered Obviously this situation could be negated entirely by the use of supports. But sometimes you don't turn supports on for pieces you don't think will need them (the "FillerBraceCrealityNut.stl" file from the same project, for example), and other times you just forget about it and use your defaults which don't include them.

I had also considered the possibility of printing the connected inner walls first (which would be the line currently being printed in the picture), albeit very slowly over open air. The outer wall and skin could then be added, at which point the completely suspended wall could be completed. This has the potential to put a large amount of strain on a single-width wall with no support, thus making it more likely to introduce sagging and ultimately defeating the purpose of the feature on larger overhangs. Multiple interior walls at progressively increasing speed may reduce or negate this, however.

Affected users and/or printers Any FDM printer will be affected by this in the same circumstances. It's only through the use of support structures it can be completely avoided.

Ghostkeeper commented 5 years ago

In the pictured example, this would mean potentially printing the supported part of the walls first,

As you pointed out, this is what currently happens when the experimental bridging settings are enabled. I'm advocating for enabling the experimental bridging settings by default and removing the checkbox, but setting the Bridge Skin Support Threshold to 0% so that it uses mostly the same settings. However that code is not considered stable yet.

then lower skin either in a concentric style or perhaps layers parallel to the two "tips" of the previous layer

Concentric works for your case because the overhang is circular. However this comes down to the problem of "how do you fill a plane with lines such that the lines start and end in certain locations" which is not at all a trivial task. A human can recognise that it is circular and that the lines are best aligned in a circular fashion but to a computer this overhang area is an arbitrary shape.

What Cura currently can do is detect that it is a bridging segment and determine the direction in which the polygon is longest. It will draw straight lines in that direction.

I consider this a very hard problem to solve for the general case. Maybe we can reduce the scope of "what infill pattern should we choose for overhang, based on measurable metrics of a polygon"?

Asterchades commented 5 years ago

As you pointed out, this is what currently happens when the experimental bridging settings are enabled. I'm advocating for enabling the experimental bridging settings by default and removing the checkbox, but setting the Bridge Skin Support Threshold to 0% so that it uses mostly the same settings. However that code is not considered stable yet.

This actually gave me an idea of something to check, and unfortunately it didn't yield entirely fruitful results. What it did show, however, is the potential for a change that would require less computation and no guess-work on the part of the slicer.

As I mentioned, enabling the Bridge Settings themselves did remedy the external wall of that layer - the one currently being printed in the picture. It did not, however, affect the internal circle with zero support. Just now I checked as to whether this may have been a conflict between the Bridging Mode setting and Optimize Wall Printing Order. It almost was, in that disabling the latter setting resulted in the inner wall of the external ring (this is awkward terminology so I hope this makes sense) was then printed first, starting from on solid material, but it then went on to print the un-suspended inner wall of the internal circle. The outer walls of both were then printed (as expected), followed by infill which was actually perpendicular to the aforementioned "tips", though this may be coincidental based on how the model is oriented (this would make the infill across the X axis).

So it would seem that it's the rigid adhesion the slicer itself has to its print order that is causing the main problem (ie Attempting to extrude where there's clearly no chance of it adhering to anything), and this layer of this model shows it off fairly clearly. It first prints the infill of the existing solid part, so it clearly knows where the next layer down exists. It then prints the walls. Lastly, it prints the suspended skin. Simply postponing the internal walls (all 3 - inner, outer and infill) until after the skin was in place, then printing it as normal, would actually give it a better chance of working.

Concentric works for your case because the overhang is circular. However this comes down to the problem of "how do you fill a plane with lines such that the lines start and end in certain locations" which is not at all a trivial task. A human can recognise that it is circular and that the lines are best aligned in a circular fashion but to a computer this overhang area is an arbitrary shape.

The existing concentric infill/skin methods are similar to what I meant, rather than the more literal meaning of the word. Rather than relying on a circle being present, these would simply replicate the shape of the existing geometry, moved to extend the "platform" but cropped so as to print in the correct shape. Used in tandem with connected infill lines, this has the potential to create a viable platform; or at least something reasonable.

Incidentally, I did print this exact model off today, using Tree Support (Bridge Settings disabled). Even with the trees in place and an upper interface, this same overhang still printed fairly poorly. However, I may have also found why Tree Support is still considered Experimental - despite having a 0.1mm Support Z Distance, there were 2 layers between the top of the support and the model itself, meaning 0.4mm (0.2mm layer height) of air. In fact, Tree Support seems to not be entirely paying attention to the appropriate distance settings, always adding an extra layer of air gap.

Fixing this (next stop is a bug report, I guess), combined with the bridging mode and the ability to postpone unsupported walls, could result in greatly improved overhang capabilities, both supported and unsupported, without too much additional time in the slicer.

*ed Small correction.

PS This edit "helper" or "history" thing is dreadful.

Ghostkeeper commented 5 years ago

So it would seem that it's the rigid adhesion the slicer itself has to its print order that is causing the main problem (ie Attempting to extrude where there's clearly no chance of it adhering to anything), and this layer of this model shows it off fairly clearly.

Adhering to the print order is crucial (for most printers) to ensure that the flow rate doesn't change too often. Switching between different flow rates is a major cause of overextrusion and underextrusion. When switching from skin to outer wall, you're suddenly going to need to print a thinner line at lower speeds so your flow rate gets cut down by like 50%. We'd prefer to do that only once per part.

However, I may have also found why Tree Support is still considered Experimental - despite having a 0.1mm Support Z Distance, there were 2 layers between the top of the support and the model itself, meaning 0.4mm (0.2mm layer height) of air. In fact, Tree Support seems to not be entirely paying attention to the appropriate distance settings, always adding an extra layer of air gap.

Yeah that issue is known to us. The problem is that the tree branches are too small to print towards their tips. See also: https://github.com/Ultimaker/Cura/issues/5759

Asterchades commented 5 years ago

Adhering to the print order is crucial (for most printers) to ensure that the flow rate doesn't change too often. Switching between different flow rates is a major cause of overextrusion and underextrusion. When switching from skin to outer wall, you're suddenly going to need to print a thinner line at lower speeds so your flow rate gets cut down by like 50%. We'd prefer to do that only once per part.

That being the case, is there at all a possibility of some kind of warning system being implemented? Assuming that an adaptive print order isn't a reasonable option (I'll trust your judgement on this one - I'm still relatively new at this), surely at least alerting the user to a potential excessively/completely unsupported wall is viable. If nothing else it would give a heads-up to the likelihood of material just flowing openly due to the absence of support; either generated or included in the model.

Ghostkeeper commented 5 years ago

Well, it's colouring the surface of your model red if it's going to overhang. It's a bit too sensitive though.

We have a system in place to warn users for model faults, but it only kicks into gear right now if you use ABS with a model more than 10cm wide. The idea was to expand this functionality (the ABS thing was only a pilot) but we never got as far. This sort of thing is a good application of that. However indicating those sort of errors is quite difficult, because ideally you would want to see that before waiting for the slice to complete so you'd want Cura's front-end to do some processing on the 3D geometry, which is always prone to edge cases. Failing that, you'd want Cura to do some processing on the g-code but that could take a long time to calculate with Python vs. 200MB g-code files.

Asterchades commented 5 years ago

Well, it's colouring the surface of your model red if it's going to overhang. It's a bit too sensitive though.

Wait, it does what now?! Red to me always meant "Outer Wall" - never really checked the Prepare screen much before since I didn't really have a lot of use for it.

I see what you mean about it being overly sensitive, though - looks like it's triggering on anything above about 70° (possibly an option I have set somewhere that I can't find right now). Still not a bad feature now that I know it even exists, so perhaps a little more attention might need to be drawn to this (I never even thought to look since it doesn't show from the top).

However indicating those sort of errors is quite difficult, because ideally you would want to see that before waiting for the slice to complete

I agree that would be the ideal, but it's still preferable to get something before hitting the printer. This is especially true in models that would be unaffected until near the end of the print, like the pictured bracket.

As an outsider looking in... surely such a detection could be performed as a combination of the initial layer slicing and the wall preparation, which I imagine is the very next process. A "rolling buffer" of slices (actual number would need to vary by layer height, but minimum two), where prepared walls (whichever is calculated first between inner and outer, based on user preferences) are tested against a stacked view of layers underneath them (binary OR comparison could do this quickly) to see if there's anything within, say, 0.1mm (rounded up to layer height) below them.

Naturally there would be performance implications for the entire slicing process since not everyone has the limited build volume of an Ender-2, or a high-end desktop PC doing the slicing. It also has implications for memory usage depending upon how fine this layer view is (10ppmm? 100ppmm? Scale by model or print bed?), which could affect lower memory systems (how much does a Pi have these days?). So such a system would have to be optional, either in the Print Settings or Cura itself, for both speed and compatibility purposes.

But, that's as an outsider looking in. I'd imagine a similar system is already in use for the purposes of calculating what's skin and what's infill, but wouldn't be surprised if I'm wrong (or at least grossly underestimating the complexity).

Ghostkeeper commented 5 years ago

Layer view is rendering polygon meshes, so it doesn't have any limited resolution other than that the tubes of filament are rendered as square tubes. That has no effect on this; it's just how it's being displayed.

CuraEngine already knows which walls are overhanging. It is applying the bridging settings to those walls, after all. The proposal that you're giving right now is basically to warn the user if the bridging settings are ever used.

Asterchades commented 5 years ago

Very nearly. I mean, that would be nice, since it gives you an indication that there may be a problem. But bridges and some overhangs have a chance of printing successfully - the parts that bother me are the ones which have exactly zero chance of successfully printing in the absence of supports, since all they could ever be doing is spitting out filiment into thin air across their entire track.

Any contained or external "shelf" is a likely candidate for that kind of behaviour. If you can imagine two different flat washers sitting on top of each other. Doesn't matter what size they are, so long as they're different. Assuming you place them concentrically, the one with the smaller interior diameter and the one with the larger exterior diameter have to have those respective walls print at all.

Granted that's a very specific example, but it represents a situation with a 67% possibility (not probability) that at one wall is just going to wind up as a loop on the print bed, no matter which way up you print it. It's also a design feature that could easily show up on someone else's model without the end user noticing anything until it's too later. This isn't necessary a likely model to show up on its own, but it's quite possible that the same design element will show up in larger models (I've already seen it in nut and bolt designs).

Another simple example showing where it would help is actually rather more simple: simply place an object above anything else, separated by a gap. A quick model of two 1cm³ blocks, with one placed 1cm above the other, didn't even detect the floating block's lower surface as a bridge. Yet that entire upper cube has zero chance of printing at all.

OK, so that second one is an extreme example, since no-one (who knows how FDM printers work, anyway) would deliberately make a model with completely detached, floating geometry and expect it to work. But it could happen. And the former definitely shows up with mechanical parts. That neither shows any indication of a guaranteed problem is, at least in my opinion, a problem in and of itself.