Introducing The Experimental Bridging Settings

[burtoogle 514]

Hello @phaedrux, you have rather overloaded me with feedback there, I'll try to answer your questions.

 

9 hours ago, phaedrux said:

Which leads me to my first question, What is the bridging flow parameter a percentage of? Is it a percentage of the flow rate set in material, or is it a percentage based on 100% flow in the material section?

 

It is simply a multiplier that is based on whatever the flow would otherwise be. So 100% simply means use the flow that is normal for the walls/skin (as defined elsewhere) and any other percentage just scales the flow as expected.

 

9 hours ago, phaedrux said:

Next question, The overhang detection and slow down is working well, but it doesn't seem like the bridging fan speed is being applied to these sections? Shouldn't it be?

 

It probably should have it's own fan speed override. I now consider overhangs and bridges as separate problems with separate solutions.

 

9 hours ago, phaedrux said:

First is that bridging was not being applied over the eye slots here on the bottom of the model. It was just exposed to the internal infil. This did not happen with the official cura 4.0. I tried changing settings to see if I could get it to show up but nothing.

 

 

Reducing the skin removal width fixes this.

10 hours ago, phaedrux said:

Next issue is some excessive over extrusion on these curve sections.The extruder is tuned, and the other parts of the print are not over extruded.

 

As you have observed yourself, one of the problems here is that you have set top skins to 2 which tends to break up skin regions into segments (some of the skin has other skin on top and some doesn't) so you are getting narrow skin regions that will not print very well. Personally, I think Cura's top skin feature causes more problems than it solves so I rarely use it.

 

Also, you have set the bridge skin support threshold very high which will make more skin areas be printed using bridging that you probably need. Reducing that value does appear to simplify the print.

10 hours ago, phaedrux said:

Could the small feature detection be expanded to include the entire island if the whole size fits within the feature size?

 

I guess it could but that would then cause slowdown for all small areas of skin which is not ideal.

 

Personally, I think it would be better in this case to make a small change to the model. Just add a two layer thick, 1mm wide brace at the 12 o'clock and 3 o'clock positions to tie the top of the thin feature to the walls near to it. Or maybe just one at 3 o'clock would be sufficient.  I don't think they would stop the hinge operating and would hardly be noticeable. They could be cut out afterwards easily enough I should think.

 

[Babaganoosh 1]

3 hours ago, phaedrux said:

Thanks, i'll look into that. @smartavionics Once I have cura-build setup, how do I build your version?

 

@phaedrux. Follow the build instructions for OS X but you'll have to replace the terminal line command:

git clone git@github.com:Ultimaker/cura-build.git

with smartavionics git repo.

git clone https://github.com/smartavionics/Cura.git

As smartavionics doesn't appear to maintain his builds as releases as Ultimaker does, you'd have to checkout his mb-master branch before building and build based on that branch.

If you need more info, read up on how to use cmake, and git. If you still need further help after that, then open an issue asking for smartavionics to update the git readme to reflect the actual build procedure as the current one linked to the Ultimaker one depends on git releases. Further help on this topic should be restricted to smartavianics git repo as these questions are not relevant to his bridging features in Cura.

 

 

[Babaganoosh 1]

1 hour ago, smartavionics said:

Hello @Babaganoosh, here's an object I have used for testing the bridging. To ensure that the skin areas are aligned in the radial direction, they must not meet in the centre so that each skin area remains separate. Obviously, you can't do the same trick with the object you show above.

 

Note that this is a very old image, the skin in the centre doesn't look right but the other skin areas look OK.

 

 

@smartavionics, interesting, and yes it does look more or less radial, but was this radial pattern intentional or just what happened by default from this design? I'd say in this case, assuming the red walls are fixed, it would actually be better to have a concentric skin as this would result in the shortest bridge skins between these walls. As it stands, the bridge skin lines are of variable length and the shorter ones my work well while longer ones may fail. But it doesn't look like those red walls are supported, but bridge walls , so I'm not sure what would work best there. I could try to incorporate some similar ideas into my design and see if they work better. Thanks!

[burtoogle 514]

Generally, I think the bridge skin lines need to be orientated parallel to the unsupported edge. Of course, the strategy is difficult to achieve if the skin area has multiple unsupported edges in different directions.

[Babaganoosh 1]

@smartavionics, I have one seemingly buggy part of this now that I've paramaterized some elements. I'm now using the latest Windows build from your dropbox link and have a quartered version of the previous part I showed, with a few other minimization things to waste less material/time. See image below, but the paramaterization is done via "per model settings" where I set both the Bridge Wall Speed and Bridge Skin Speed equally in each model and go from 30, 45, 60, 75 mm/s. As you can see in the image, the skin speed is appropriately changed, but the wall speed still seems to follow my general Outer Wall Speed setting of 30 mm/s. I've tried this with a few different Outer Wall Speeds thinking that it may be something weird with the Minimum Layer Time affecting the walls but not the skin for whatever reason, but this doesn't seem to be the case.

 

A few other debugging things I tried:

• I enabled the bridge settings on a default profile (where I haven't messed with other settings) and the same behavior shows.
• I tried deleting the skin per model settings to see if one was working but multiple had issues
• I tried doing the same processes in the Ultimaker 4.0 build.
• I tried just updating the Bridge Wall Speed without any per model settings

None of the above were able to actually modify the Bridge Wall Speed. Am I misunderstanding this term or is this an actual bug?

[burtoogle 514]

Hi @Babaganoosh, can you please attach the project file for your example?

[Babaganoosh 1]

12 minutes ago, smartavionics said:

Generally, I think the bridge skin lines need to be orientated parallel to the unsupported edge. Of course, the strategy is difficult to achieve if the skin area has multiple unsupported edges in different directions.

 

Let me just start by saying that I have no expectation of you to implement this just for my little part, and if its well beyond feasible, no use continuing the conversation, but I am still curious. This is a programmatic issue or printing issue? The skin lines in your image are parallel to one of the unsupported edges, but not the other for each pie piece. It would seem a concentric skin, would result in shorter bridge skin lines, but then you'd have each line only attached to two floating bridge lines rather than one more stable point. So maybe my concentric fill idea would be too unstable and things would just droop. 

[Babaganoosh 1]

2 minutes ago, smartavionics said:

Hi @Babaganoosh, can you please attach the project file for your example?

 

Yep, here.

UM2_arm_base_bridgeTest.3mf

[burtoogle 514]

3 minutes ago, Babaganoosh said:

It would seem a concentric skin, would result in shorter bridge skin lines, but then you'd have each line only attached to two floating bridge lines rather than one more stable point. So maybe my concentric fill idea would be too unstable and things would just droop. 

 

That's what tends to happen, also, in the example I show above if the skin lines go across the regions (at 90 deg to how they are shown above), then the walls curve inwards in the middle due to the tension. You really need the skin lines to anchor on supported areas rather than bridge walls if possible. With my example above, the skin areas are, essentially, triangular so you can't avoid the skin lines terminating on one of the bridge walls but at least they are at quite a shallow angle which will minimise the inward pull.

[Babaganoosh 1]

3 minutes ago, smartavionics said:

 

That's what tends to happen, also, in the example I show above if the skin lines go across the regions (at 90 deg to how they are shown above), then the walls curve inwards in the middle due to the tension. You really need the skin lines to anchor on supported areas rather than bridge walls if possible. With my example above, the skin areas are, essentially, triangular so you can't avoid the skin lines terminating on one of the bridge walls but at least they are at quite a shallow angle which will minimise the inward pull.

 

I see. That's a good explanation, and I would agree. I can't see a better solution than that at the moment. I'll repost if I ever come across anything that works well in my radial-ish type case.

[burtoogle 514]

Hello @Babaganoosh, the reason  the walls are not being recognized as bridges is because the individual lines that make up the curved walls are smaller than the min bridge wall length setting. Reduce that to zero and the walls are recognized as bridges. Now, you could argue that it should add together the lengths of the segments and if the total is > the min bridge wall length all the segments should be treated as bridges. However, given that you can't print a curved bridge wall anyway, it's really not worth doing.

[Babaganoosh 1]

15 hours ago, smartavionics said:

Hello @Babaganoosh, the reason  the walls are not being recognized as bridges is because the individual lines that make up the curved walls are smaller than the min bridge wall length setting. Reduce that to zero and the walls are recognized as bridges. Now, you could argue that it should add together the lengths of the segments and if the total is > the min bridge wall length all the segments should be treated as bridges. However, given that you can't print a curved bridge wall anyway, it's really not worth doing.

 

Ah, yes. Thank you! Actually, I am able to print curved bridge wall with a fair accuracy. I'm heading out of the office for the day, but will post some actual prints showing this tomorrow.

Cheers!

 

Edit: I rushed that comment and after taking a closer look at my prints, I do agree that the actual bridge walls along the curves are not actually curved, but segmented lines. The smaller these segments, the more of a true curve it becomes, but they are still segments. The segments in my print were small enough that I could not visually tell the difference initially. Anyways, you solved what I misunderstood as a bug, so thanks!

Edited April 16, 2019 by Babaganoosh
Incorrect information.

[phaedrux 2]

16 hours ago, smartavionics said:

Hello @phaedrux, you have rather overloaded me with feedback there, I'll try to answer your questions.

Ha ha, Sorry about that. I've been meaning to test your builds for quite some time.

 

16 hours ago, smartavionics said:

 

It is simply a multiplier that is based on whatever the flow would otherwise be. So 100% simply means use the flow that is normal for the walls/skin (as defined elsewhere) and any other percentage just scales the flow as expected.

Perfect. That clears that up.

 

16 hours ago, smartavionics said:

 

It probably should have it's own fan speed override. I now consider overhangs and bridges as separate problems with separate solutions.

That would be nice. 

 

16 hours ago, smartavionics said:

 

 

Reducing the skin removal width fixes this.

That makes sense. I installed your build on my windows machine that had no profiles yet so it was still using the defaults for skin removal. On my Mac with the official 4.0 build I had already reduced skin removal.

 

16 hours ago, smartavionics said:

As you have observed yourself, one of the problems here is that you have set top skins to 2 which tends to break up skin regions into segments (some of the skin has other skin on top and some doesn't) so you are getting narrow skin regions that will not print very well. Personally, I think Cura's top skin feature causes more problems than it solves so I rarely use it.

Right, my point there though was could that be detected and then extend the top fill setting to replace the top/bottom fill to make one larger continuous section.

 

16 hours ago, smartavionics said:

 

Also, you have set the bridge skin support threshold very high which will make more skin areas be printed using bridging that you probably need. Reducing that value does appear to simplify the print.

Yes, I went back yesterday and played around with those values more and reduced them a bit and that did seem to clear it up a bit. I'll have to experiment more.

 

16 hours ago, smartavionics said:

 

I guess it could but that would then cause slowdown for all small areas of skin which is not ideal.

Would it be possible to detect that it's a small island instead of small hole? Seems like two seperate things. One is a small circular perimeter inside of a larger body, the other is a small section entirely separated from other perimeters. Holes don't have infill in the middle of them. Both should be printed with lower speed, either for accuracy or delicacy.

 

 

16 hours ago, smartavionics said:

Personally, I think it would be better in this case to make a small change to the model. Just add a two layer thick, 1mm wide brace at the 12 o'clock and 3 o'clock positions to tie the top of the thin feature to the walls near to it. Or maybe just one at 3 o'clock would be sufficient.  I don't think they would stop the hinge operating and would hardly be noticeable. They could be cut out afterwards easily enough I should think.

It's not my own model, but yes, that modification could work. Though I did print a couple of these models sliced with Slic3r PE and the small pin stayed intact.

 

Thanks your response and all the tweaks in your build.

 

I'll take a look at getting a Mac build working and will let you know.

 

[phaedrux 2]

I was able to retest the original model at 0.15 layer height I posted about earlier using your build with bridging over infill. The results were very good. I still have to tweak the flow rate a bit, but it's going to make bridging when using low layer heights much more reliable.

 

Bottom section is the bridging layer, and to the left side is one solid layer on top of the bridging layer.

 

Another layer

 

And that's after 3 layers of 0.15 on top of the bridging layer.

 

The final top surface was perfect after two more top layers.

[perplex 0]

On 3/28/2018 at 1:17 AM, smartavionics said:

(deleted to save space)

 

Feedback Required From You

 

Please give it a go and share your experiences, all feedback is welcome (good and bad). You can either reply to this topic or for really bad news, please submit a github issue.

 

quick question,

 

when i tick "Enable Bridge Settings" it changes a whole lot of setting (all the ones in the picture below), my question is when its not ticket what are these settings? this way i have a base line to start off with, but since as soon as i tick it they change settings, it makes it hard to work out what it was like to begin with.

 

are you able to tell me the settings they revert back too when you untick it on all the bridge settings? for example "Bridge Wall Speed" i believe the default is whatever the "Print Speed" is set too not 11.25 in this case it should be 45.

 

 

 

Edited May 5, 2019 by perplex

[burtoogle 514]

Hello @perplex, when Enable Bridge Settings is not checked, none of those settings are used. There is some legacy code in Cura that detects unsupported skin regions and modifies their alignment but other than that, there is no special handling of walls, etc.

[perplex 0]

3 minutes ago, smartavionics said:

Hello @perplex, when Enable Bridge Settings is not checked, none of those settings are used. There is some legacy code in Cura that detects unsupported skin regions and modifies their alignment but other than that, there is no special handling of walls, etc.

yes i know when its unchecked it doesnt use the settings but what im asking is, my print speed is 40mm/s, but when i enable the settings it makes it 11.25mm/s, guess im asking what is the default bridge speed with it unticked and im guessing that is whatever your print speed is, so i may of just answered my own question

 

im assuming the defaults are

 

Bridge Wall speed - whatever your print speed is

Bridge wall flow - what ever your flow rate is

Bridge skin density - whatever your line spacing is

 

just trying to work out what the printer does when its unticked. 99% sure i just answered my own question

[burtoogle 514]

Yes, that's right, when the bridge settings are not enabled, it just prints using the normal settings for walls and skin.

[toribios 0]

Hi @smartavionics, this thread is extremely interesting, has helped me a lot improving my bridging. 

I downloaded one of your builds to give a try to the "Bridge Sparse Infill Max Density" setting, I have observed that it doesn't apply to 0% infills, is this on purpose? I have observed that as soon as I put 1% the layer over the infill is treated as a bridge. (See images as example)

 

1% infill

 

0% infill

 

Thanks for your help.

[burtoogle 514]

Hello @toribios, thanks for the feedback. No, that's a bug on my part. I will fix that today and create a new release.

[Dash777 0]

So Im currently using Cura 4.0 and trying to utalise bridge settings and supports on the same model. I have found that this is possible to do but it only applies the Bridge Skin settings. This is done by increasing the Bridge skin threshold to 100%. I would like to be able to use the bridge settings for the walls also but cura doest see these as bridges. So my initial thoughts for a fix would be to have a user defined option to set  maximum unsupported height for bridging. So for an example.  When using a support top distance of 0.2mm, and a maximum unsupported height for bridging of 0.2mm also. Cura would now apply all bridge settings regardless of supports or not. This I think is beneficial for filaments like ABS and PETG that tend to fuse to the supports below them. It would allow for extra part cooling and flow reduction and speed which I think is paramount for these filaments. Thanks

[3blake7 0]

if i want to try out your experimental builds with your bridge settings, where would i get the source? i use ubuntu, i can compile it if need be.

 

also, ive been playing around with the bridge settings. i have attached a picture. the top one is with 0.3 line width, the bottom one is with 0.5 (cura default?) (before i updated retracting and tried 0.35 line width) . i have a 0.4 nozzle (creality cr-10 mini). the 0.35 settings look good for the rest of the print but the skin lines dont connect on a bridge at 0.35 but they do with 0.3 . i have done an extruder test twice and updated my estep. id prefer to keep the 0.35 line width since it reduces print time and the rest of the print looks good.

 

i have tried increasing bridge skin flow to 100% then 150% but it doesnt seem to make a difference? bridge skin density is set to 100% but i was thinking it may help if i could go 120% instead, but cura doesnt let me raise it that high.

 

i have attached picture of current bridge settings. also attached picture of a bad slice. cura tries to do the outer ring of the hole first, when it's not touching anything, instead of working its way out. not sure how to solve that. i tried outer first, infill first, etc but didnt appear to change its order of operations. ended up using supports.

 

thanks!

[3blake7 0]

this is with the settings in the screen shot and 0.35mm line width

[burtoogle 514]

8 hours ago, 3blake7 said:

i have attached picture of current bridge settings. also attached picture of a bad slice. cura tries to do the outer ring of the hole first, when it's not touching anything, instead of working its way out. not sure how to solve that. i tried outer first, infill first, etc but didnt appear to change its order of operations. ended up using supports.

 

Yes, you either have to use supports or do what I often do which is make the smaller hole depth such that it doesn't go all the way through to the large hole. After printing, you then have to drill/clean the hole. This technique of leaving a thin layer of skin over a hole is especially useful for holes for fasteners that are visible, i.e. on a front panel. If you make the hole go all the way through the panel, the top skin has to be printed in segments. But if the hole doesn't reach the top skin layer, the top skin can be printed with fewer (possibly 1) segments so the finish quality is better.

 

As for the bridging settings, this is what I am currently using for PLA on a SV01 printer:

 

 

Some of those settings aren't in the UM cura but most are.

 

[Dash777 0]

Is someone here able to implement a 'Maximum unsupported Height For Bridging'?

I forget ask this with my previous post. Thanks again.

Quote

So Im currently using Cura 4.0 and trying to utalise bridge settings and supports on the same model. I have found that this is possible to do but it only applies the Bridge Skin settings. This is done by increasing the Bridge skin threshold to 100%. I would like to be able to use the bridge settings for the walls also but cura doest see these as bridges. So my initial thoughts for a fix would be to have a user defined option to set  maximum unsupported height for bridging. So for an example.  When using a support top distance of 0.2mm, and a maximum unsupported height for bridging of 0.2mm also. Cura would now apply all bridge settings regardless of supports or not. This I think is beneficial for filaments like ABS and PETG that tend to fuse to the supports below them. It would allow for extra part cooling and flow reduction and speed which I think is paramount for these filaments. Thanks