Bridge settings

[boelle]

looked at https://github.com/daid/LegacyCura/issues/765

i wonder if we will ever see bridge settings in cura again? i have been told it was there when skeinforge was the slice engine

[BagelOrb]

Perhaps in Cura 2.8. Cura 2.7 has some major steps in the right direction as far as the code architecture goes for implementing it.

[boelle]

detection is one thing.... control is another

ie i'm for lettings the user control how much fan etc during bridging

but time will tell :-D

[BagelOrb]

Fan control will most probably not make it into 2.8. We'll be lucky if we can control line width and speed settings of bridges in 2.8.

[boelle]

well you can always dream :-D

[ghost]

I want to put in my vote for this, I find when I have a model where bridging is important I have to use anther slicer :( just been able to set the bridge speed and maybe flow rate for the bridge would be a great step.

[boelle]

i have totally given up on cura.... slic3r prusa edition have made a huge difference

[BagelOrb]

Bridging is more important than variable layer height.

[ghost]

@BagelOrb I was not referring to the variable layer height. as Slic3r PE has bridging settings like bridge speed, Fan speed for bridging etc.

[BagelOrb]

I'm just telling the Cura team that they should start working on bridging before they start working on variable layer height.

[ChrisTerBeke]

Unfortunately it's not entirely in our hands, we have some lovely folks at PM as well ;)

[MoonCactus]

+1 for bridge settings. I find it strange that such a setting that was available in older versions still did not make it to the 2.x. (idem with STL splitting, already posted here https://github.com/Ultimaker/Cura/issues/2052)

[BagelOrb]

Bridging was never in Cura. What has been in Cura since 1.15.x was calculating the direction of bottom skin lines for the best bridging angle

• which is also present in 2.x.

[MoonCactus]

@BagelOrb correct me if I am wrong but at least 13.04 had it the expert setting. See, e.g. https://ultimaker.com/en/community/5686-plug-in-bridging-settings and certainly in 12.08 from my own post http://www.tridimake.com/2012/10/review-settings-for-cura-3d-printing.html I think it was still based on skeinforge at the time (which certainly was a pain until Cura added sugar around it). But bringing technicality (or the past) does no good to a high-level feature request ;)

[BagelOrb]

Oh wow. Yeah it must have been the skeinforge backend.

[Ghostkeeper]

It's in our top 50, about halfway through. There's a few architecture revisions listed before it though which will cause quite some delay. I don't expect this to be implemented before version 3.3.

[hovissimo]

@Ghostkeeper Thanks for sharing the current prioritization of this issue. Just to reinforce the demand, the lack of special bridging support makes Cura a total non-starter for me. It's a shame, because the new interface isn't too bad and I really like some of the other slicing features.

[smartavionics]

Hi @Ghostkeeper , I am happy to progress this if you want. Is it being worked on by anyone else at the moment?

[ChrisTerBeke]

There's not special attention from the Ultimaker team for this at the moment, nor is there anything on the roadmap for the near future. Great that you're offering to help out!

[smartavionics]

OK, thanks Chris. I'll start educating myself as to what needs to be done. If people have concrete suggestions as to what settings should be made bridge aware (speed/width/temp/fan/etc.) please pipe up.

[smartavionics]

Re settings, I don't think temp can be tweaked for a bridge as it wouldn't have time to change so forget that. And the width can't really be changed for walls but the width of skin lines could possibly be changed if it was thought to be beneficial. So that leaves the obvious print speed and fan speed. As both walls and skin can be involved, I would have thought that the speed modifier should either be a percentage which could be applied to both walls and skin or maybe separate absolute values for each. The fan speed modifier would apply to both and would be a percentage (like the other fan speeds are).

[MoonCactus]

Note sure it would make sense to implement more than these 4 parameters, and temp is probably already useless in most cases (it may even prove to be worse unless you add a "pre-delay" to accomodate the thermal inertia of the hot ends... which would really be experimental). Speed and fan really would already make it much better. Weird that UM keeps such a low priority on that one.

[MoonCactus]

oops we crossed our posts! I like how some UI accomodate either percentages or absolute value, just by using "%" postfix sign, but it may not be in accordance to Cura paradigm :/

[fieldOfView]

Flow control for bridges could be useful (as @ChrisRiddell already mentioned).

[smartavionics]

Hi @MoonCactus. Yes, I don't understand UM's priorities either but, hey ho, let's not worry about that here.

Posts crossing again. Yeah, I think you have to have one or other but can't be mixed like slic3r does.

[MoonCactus]

Well, I would favor absolute value, because this is something that is best optimized independently of the actual printing speed, and which produces a sweet spot precisely at some setting (my two cents).

[smartavionics]

OK, now we have people's attention. Here's a question for the team. How should it behave if you have, say, a skin layer that is only partially above a void, i.e. half of the skin is above infill and the other half is above air (holes, slots or whatever). Is the whole skin (and walls, if they are above air) to be printed with bridge settings or should the settings alter as the skin (and walls) cross from supported to non-supported regions?

[smartavionics]

Understood @MoonCactus regarding absolute speeds being easier to set independently from the other print speeds.

[smartavionics]

Answering my own question above, I think that if any of the skin needs to be a bridge, then just print the whole thing with bridge settings. Almost certainly it will get another skin on top so that would seem the easiest to me. Agree? As for walls, I think that you would only use the bridge settings for the portions of the walls that were actually above air (with maybe a little region added each side of the gap) so the region that uses the bridge settings is a little longer than the bridge length.

[MoonCactus]

I would use "bridge settings" only for, well, bridges... Imagine you have a very large skin, with only 1% of it being a bridge. You may get lots of artifacts on subsequent layers and outer walls if you print it all with bridge settings, ipo regular settings -- it may also confuse people. As for walls I was also thinking of the very little extra at start and end, but I suspect it would not be noticeable while it would be harder to implement may be...

[smartavionics]

Hmm, OK @MoonCactus , I think that needs to be explored.

[ghost]

What about having a unsupported threshold setting in square millimeters and apply bridging settings to that unsupported area?

Settings suggestion

1. Flow rate
2. Bridging speed
3. Cooling Fan Speed

[smartavionics]

Progress report - I have done some coding. Here is a screenshot of a part that has a small bridge over a hole. I have deliberately set an overly low flow value so that it makes it obvious where the bridge lines are. You can see that both the skin and wall lines have been flow reduced. At the moment, you can set the speed independently for the skin and the walls and the flow and fan speed for both. I don't think it's worth having separate flow and fan speed for bridge walls/skin.

The detection of skin bridge areas has not changed from the existing code and perhaps that needs to be made smarter.

At the moment if you have, say, a long wall line that passes over air, the whole line will be printed using the bridge speed/flow but I think only the region over the air needs to be printed like that, the rest of the line could be printed using normal values. Segmentation of wall lines so that they just span the bridge zone is yet to be implemented. Early days!

[jackha]

Very cool! Vaguely related is this model, which is more like a "bridge detecting test". I hope you find it useful ^^. bridging-test.zip

[smartavionics]

Hi @jackha , I don't think that model can be printed because the walls around the centre hole and the first layer of skin will be printed on air. When I have models like that, I make the hole stop before the bottom layer of skin so that the whole of that skin can be printed.

[smartavionics]

More coding done... It can now segment wall lines that run across multiple regions of air. If you look closely at this example, the wall lines are thin (flow reduced) in the bridge region but on the pillars they go back to the normal flow (and speed).

[ghost]

@smartavionics Looking good, One question do the skin lines need to go so far back into the model?

[smartavionics]

Hi @ChrisRiddell , well that's just the normal Skin Expand Distance setting so you can adjust it as you wish.

[jackha]

@smartavionics I know it can't be printed like this, that's why it's a test case :-) Yes if I model it myself I also make a small hole stop and open it after the print.

[smartavionics]

More progress, it will now print overhang with bridge speed/flow/fan settings. There is a parameter to specify how much overhang is required to use those settings rather than the normal wall settings:

[MoonCactus]

This is an excellent idea, since the difference is not always obvious!

[smartavionics]

Just asked this question over on the Duet (aka RepRap) forum - how do other slicers behave when both bridging and support is enabled? Does the presence of support inhibit the bridging speed/flow?

[MoonCactus]

@smartavionics imho I would clearly disable any bridging setting, since support is precisely added to avoid overhang and bridging issues in the first place... Say, with a perfect material, you really can get as close as you want to the surface to support (eg. soluble PVA), so there is not even a gap between the support and the deposited material. In this case, any change in the deposition of the actual material would have a negative impact on the outcome (certainly, texture would differ). Now, it is also up to the user not to use incoherent settings, admittedly :)

[fieldOfView]

Can an anti_overhang_mesh be made to "re-enabled" bridging?

[smartavionics]

Hi @MoonCactus , thanks for that input, understood. As there will be on/off setttings for both support (whatever flavour, tree or regular) and the bridging. I am tempted to leave it to the user to enable whichever they want and if they enable both together and it makes a mess well they should consider that a learning exercise!

[fieldOfView]

@smartavionics you can set the "value" of the bridging_enabled setting to "not support_enabled", and that will turn off bridging when support is enabled, but still lets the user control the setting manually.

[MoonCactus]

Yes, this is an advanced mode anyway, so up to the user to create art with weird settings :) I wonder how ultimaker will "officially" incorporate the option (hope they'll do), because you really help everyone of us, hats off!

[MoonCactus]

@fieldOfView yes that would be cool, aka "activate bridge if there is no support below" if I understand

[smartavionics]

Hi @fieldOfView , thanks for that. Perhaps, one day I will understand how the setting logic works. I will do that now.

[NickRimmer]

Any news about support bridges? I think cura may be the best slicer, if there will bridges support (;

[smartavionics]

Hi @NickRimmer. Bridge settings are looking good. I have implemented a whole bunch of settings that let you specify print speed, %flow & fan for the bridge walls and also the the skin. Furthermore, you can specify settings for not just 1 skin but the 3 skins above the unsupported region. I found through experimentation that a single skin over air printed with bridge settings isn't really isn't very good for various reasons. So by having settings for 3 layers, it's possible to achieve reasonably flat bridges that exhibit good layer bonding so they are strong. Having a lot of settings makes it a bit complicated but, (a) the settings have default values which should be fairly OK, and (b) it's an experimental feature so people can experiment to find the settings that work well and then, in the future, some of those settings may not be needed. But until people try them out, we won't really know. The code has not yet been vetted by the Cura devs so I can't say when it will make it into a release but I believe they are interested in getting it merged sooner rather than later. Stay tuned...