New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jonaskuehling opened this Issue Oct 13, 2014 · 6 comments

Comments

Projects
None yet
2 participants
@jonaskuehling

jonaskuehling commented Oct 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jonaskuehling

jonaskuehling Oct 14, 2014

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!

jonaskuehling commented Oct 14, 2014

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!

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Oct 14, 2014

Member

Aha, will test that!

Member

alexrj commented Oct 14, 2014

Aha, will test that!

@alexrj alexrj added this to the 1.2.1 milestone Oct 14, 2014

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Oct 17, 2014

Member

@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?)

Member

alexrj commented Oct 17, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@jonaskuehling

jonaskuehling Oct 18, 2014

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 commented Oct 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jonaskuehling

jonaskuehling Oct 22, 2014

@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?

jonaskuehling commented Oct 22, 2014

@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?

alexrj added a commit that referenced this issue Nov 7, 2014

alexrj added a commit that referenced this issue Nov 7, 2014

Apply bridge flow and speed to first layer as well, when we have raft…
… layers. This behavior is more consistent when all the other bottom surfaces lying on the void (thus on support material). #2301

alexrj added a commit that referenced this issue Nov 7, 2014

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Nov 7, 2014

Member

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.

Member

alexrj commented Nov 7, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment