Skip to content
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

Automatic threshold setting fails to create support when needed #2068

Closed
harriv opened this issue Jun 2, 2014 · 7 comments
Closed

Automatic threshold setting fails to create support when needed #2068

harriv opened this issue Jun 2, 2014 · 7 comments
Labels
Fixed with PR available to merge There is an update to address this issue in an open pull request.
Milestone

Comments

@harriv
Copy link
Contributor

harriv commented Jun 2, 2014

Support is not generated when needed when using automatic settings.

Files:

https://drive.google.com/folderview?id=0Bw1VY8X1WZhdbTNaMVlnWDdlMnM&usp=sharing

Command line: C:\Program Files\Repetier-Host\Slic3r-1.1.3\slic3r.exe --load "C:\Documents and Settings\harriv\Local Settings\Application Data\RepetierHost\slic3r.ini" --print-center 75,74 -o "C:\Documents and Settings\harriv\Local Settings\Application Data\RepetierHost\composition.gcode" "C:\Documents and Settings\harriv\Local Settings\Application Data\RepetierHost\composition.obj"

Using Slic3r 1.1.3 32 bit on Windows XP.

slic3r_support_bug

@harriv
Copy link
Contributor Author

harriv commented Jun 13, 2014

#2072 is similar.

@hyperair
Copy link
Contributor

Have you tried printing it? It might actually print the overhang fine, depending on your perimeter extrusion width to layer height ratio.

I think it's unrelated to #2072, because #2072 is about elevated islands, i.e. where the first layer of that section doesn't start on the layer 0.

@hyperair
Copy link
Contributor

Hmm, this is weird. I just looked at Slic3r 1.1.4's code for automatic overhangs, and it looks like this:

                    $diff = diff(
                        [ map $_->p, @{$layerm->slices} ],
                        offset([ map @$_, @{$lower_layer->slices} ], +$fw*2),
                    );

Shouldn't that be $fw/2 instead of $fw*2?

hyperair added a commit to hyperair/Slic3r that referenced this issue Jun 16, 2014
We should be supporting perimeters that are overhung further than half a
perimeter out, rather than two times the perimeter width.

Fixes: slic3r#2068
@harriv
Copy link
Contributor Author

harriv commented Jun 16, 2014

@hyperair No, I didn't try to print it this way, because it looks so unstable. Center of gravity is so far away from support surface, which is very tiny..

@hyperair
Copy link
Contributor

It's a little far overhung, but if it was a 45° incline, that model would actually print fine with --support-material-enforce-layers=10. Basically enforce support on the first 10 layers to ensure a decently sized footprint on the build platform. It doesn't matter that it looks unstable -- it's meant to stick to the platform for the entire duration of the build.

@harriv
Copy link
Contributor Author

harriv commented Jun 16, 2014

Yes, of course it would print if the support is manually forced. I think this is special case which has not been considered when designing the current automatic support generation.

@hyperair
Copy link
Contributor

But that's what the enforce-layers option is meant for -- if your print isn't capable of getting an appropriate first layer stuck to the bottom. This could be just as easily mitigated with a brim, I think.

hyperair added a commit to hyperair/Slic3r that referenced this issue Aug 6, 2014
We should be supporting perimeters that are overhung further than half a
perimeter out, rather than two times the perimeter width.

Fixes: slic3r#2068
hyperair added a commit to hyperair/Slic3r that referenced this issue Jan 26, 2015
We should be supporting perimeters that are overhung further than half a
perimeter out, rather than two times the perimeter width.

Fixes: slic3r#2068
@lordofhyphens lordofhyphens added the Fixed with PR available to merge There is an update to address this issue in an open pull request. label May 19, 2016
@lordofhyphens lordofhyphens added this to the 1.3.0 milestone May 19, 2016
lordofhyphens pushed a commit to lordofhyphens/Slic3r that referenced this issue Mar 11, 2017
We should be supporting perimeters that are overhung further than half a
perimeter out, rather than two times the perimeter width.

Fixes: slic3r#2068
lordofhyphens added a commit that referenced this issue Mar 11, 2017
* Fix automatic overhang threshold

We should be supporting perimeters that are overhung further than half a
perimeter out, rather than two times the perimeter width.

Fixes: #2068

* Made the overhang detection configurable, up to 200 (the original value, which is still the default)

* Set default to 60% as per https://github.com/alexrj/Slic3r/wiki/Support:-Requirements
Removed some less useful enumerations (0-30%)

* Folded in auto_threshold into support threshold as a % value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed with PR available to merge There is an update to address this issue in an open pull request.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants