First model layer on top of raft doesn't use "bridge speed" (1.1.7)

[jonaskuehling]

Hey,

we recently had significant success with current break-away support integration (1.1.7) by massively decreasing the bridge speed, as supported perimeters and infill regions are treated as bridges and - as others also experienced lately - the support adhesion was rather bad due to the minimal contact between support and model when printed too fast.

By using really slow bridge speed (talking about ABS here) like 7-10mm/s we could get the current support working quite satisfying, as the supported regions have more time to securly lay down on the support interface and round perimeters don't get dragged away as the print head moves on.

Now, the first model layer on top of raft doesn't use bridge speed, although it is printed with bridge logic.

I guess that's not intended? :-)

[jonaskuehling]

My apologies - I didn't refer to the dual extruder setup in this regard!

Extruder1 was configured for perimeters and infill
Extruder2 was configured for support/support interface (thus raft, too)

Didn't test with single extruder yet, if the first model layer on top of the raft-support will also print with perimeter speed instead of bridge speed like in my dual extruder case!

[alranel]

Aha, will test that!

[alranel]

@jonaskuehling, I'll write a regression test for this issue.

Anyway, it looks like if you need to decrease the bridge speed for getting good support adhesion, maybe we need a separate setting for this instead of using bridge speed? I'm afraid 7-10mm/s isn't optimal for your actual bridges, is it? (Is this thing mentioned in another issue here?)

[jonaskuehling]

I'm not quite sure about materials like PLA for example since we rather use it. For ABS in particular, as well as PET (Colorfabb XT) and some other more ABS-like plastics a slow bridge speed doesn't introduce trouble with "classic bridging" (between towers, unsupported), especially when using "don't support bridges" option.

But I guess a lot of people using pretty fast PLA printers like Ultimakers and the like won't see the need for slow unsupported bridges just to improve support adhesion..

A dedicated speed parameter for support-adhesion-related bridging doesn't hurt in my oppinion!

Not sure if the specific topic of this issue (bridge speed on top of raft) is already mentioned somewhere else. The support-adhesion problematic actually is - and we are incredibly happy to finally found a configuration that produces easily peelable but adhering support with Slic3r's built-in logic, that just turns out to be amazingly powerful as you always promised @alexrj ;-)

[jonaskuehling]

@alexrj when talking about a dedicated speed setting for supported perimeters, let me make another suggestion:
With our current "workaround" by reducing the bridge speed we achieve good results for low overhang angles like 0 to 40°, since most perimeters in this range will be identified as bridging perimeters due to their clear overhanging characteristic. Now, for higher angles like 40 to 60° Slic3r won't handle the affected perimeters as bridges, althoug there is actually support generated with the intention of supporting those perimeters. In this case, the perimeters are printed with default perimeter speed and little chance for good anchoring onto the destined support. Especially if one finds the need for like 60 or even higher overhang angles like it is at least configurable and potentially also necessary in certain cases depending on the individual printer setup or used print material.

Thus, I'd suggest handling all perimeters where there is support generated for as "supported perimeters" and apply the new "supported perimeters speed" value. This way we have a clear separation between bridges and supported perimeters, while covering the full supported surface area. What do you think?

[alranel]

Okay, I pushed a change that treats first object layer above raft just like any other bottom surface above support material, as per your original report.
For now I prefer not to add more config options unless we get a strong proof that we need them. :)

Regarding your last comment, you're right (and you're a good observer!): overhang detection for perimeters and support material generation use different logic, so they might not catch the same things. The former requires that the overhang is equal or greater to one nozzle diameter (i.e. it's an overhang if nozzle is pushing plastic entirely on the void), while the latter triggers support whenever the loop centerline lies on void. Support material is thus generated more often. This level of sensitivity would be too much for perimeter overhang detection (it was implemented like this, and it produced lots of changes in flow causing bad quality on vases) so I think it would be correct to use the nozzle diameter logic for support material as well.
I'll move these thoughts to another issue.