Slic3r prints tilted, raised islands in mid-air

[hyperair]

With a gear (http://www.thingiverse.com/thing:343602) printed at 45°, Slic3r generates G-Code that prints some of the teeth in mid-air. It still turns out somehow or other in the end, but with those teeth deformed.

Here's a screenshot of what it looks like in gcode.ws:

And here's the G-Code: https://gist.github.com/hyperair/7c8595a672df2f40e6e4

[alranel]

Oh wow. How do the supported teeth look like? Do they print well? Do you have a picture?

[alranel]

A rendering of the OP G-code:

[hyperair]

I think I have two gears around printed with bad support -- one with red PLA and one with black ABS. I'll need to look for them. The teeth were kind of loose, but the upper layers printed out fine after the initial mid-air print.

I was watching as they printed -- basically it would just start extruding stuff in mid-air, and the bit of filament would tumble around, eventually harden, maybe latching onto some adjacent material or the print bed itself, and then things would print on top of that.

EDIT: The supported teeth actually turned out pretty good. I raised the support-material-enforce-layers option to 20, and it printed a very nice gear in black ABS. It's in the shredder now, so I'll have to dismantle it later to get a picture. The PLA gear I printed yesterday was bound pretty hard to the support material though. I couldn't get it off cleanly.

[hyperair]

Here you go -- pictures of the red PLA printed with some teeth supported and some not:

I just realized I have a misconfigured extrusion multiplier for this filament, so there might be other errors.

[hyperair]

I just tested with the following OpenSCAD model:

rotate ([45, 0, 0])
union () {
    cube ([10, 10, 20]);

    translate ([20, 0, 10])
    cube ([10, 10, 10]);

    translate ([0, 0, 19.9])
    cube ([30, 10, 10.1]);
}

If the rotation is removed, support material is generated correctly for the raised leg. However, if the model is tilted, Slic3r generates no support material at all.

[whosawhatsis]

This is a common problem. The root cause is that there are no surfaces that exceed the overhang threshold, despite the fact that there are edges with nothing at all below them. It will require some rewriting of the overhang detection to recognize when such an edge borders two faces that don't need support on their own, but the edge itself needs support. In this case, there should be a margin around the edge on either side (not just the one that's up in the air, but the other two bottom edges that are parallel to the platform as well) where support is added to keep the part in place. I'm not sure how such an area would be detected or the size of the margin would be specified, but it would probably share some code with the feature discussed here: #1316

[alranel]

The problem is that very small overhangs are filtered so that support is not generated for very small, insignificant overhanging perimeters. Sometimes there's no benefit in building an entire scaffolding just to support a little pointy extrusion. But sometimes, like here, such filtering should be way less tolerant.

[hyperair]

On Mon, Jun 09, 2014 at 08:05:47AM -0700, Alessandro Ranellucci wrote:

The problem is that very small overhangs are filtered so that support is not
generated for very small, insignificant overhanging perimeters. Sometimes
there's no benefit in building an entire scaffolding just to support a little
pointy extrusion. But sometimes, like here, such filtering should be way less
tolerant.

I tried commenting out this bit from Slic3r/SupportMaterial.pm as a workaround
for the issue, and it seems to work:

                # collapse very tiny spots
                $diff = offset2($diff, -$fw/10, +$fw/10);

I think it'll probably cause more support material to be generated for the tiny
insignificant overhangs, but better than printing islands in mid-air in my
opinion.

I reckon a fix for this issue would be to only do this offset if this region is
thicker than $fw. If I'm understanding this correctly, anything thinner than $fw
should already yield a null $diff if supported by an underlying layer.

Kind regards,
Loong Jin

[hyperair]

On Tue, Jun 10, 2014 at 10:56:36AM +0800, Chow Loong Jin wrote:

On Mon, Jun 09, 2014 at 08:05:47AM -0700, Alessandro Ranellucci wrote:

The problem is that very small overhangs are filtered so that support is not
generated for very small, insignificant overhanging perimeters. Sometimes
there's no benefit in building an entire scaffolding just to support a little
pointy extrusion. But sometimes, like here, such filtering should be way less
tolerant.

I tried commenting out this bit from Slic3r/SupportMaterial.pm as a workaround
for the issue, and it seems to work:

                # collapse very tiny spots
                $diff = offset2($diff, -$fw/10, +$fw/10);

I think it'll probably cause more support material to be generated for the tiny
insignificant overhangs, but better than printing islands in mid-air in my
opinion.

I reckon a fix for this issue would be to only do this offset if this region is
thicker than $fw. If I'm understanding this correctly, anything thinner than $fw
should already yield a null $diff if supported by an underlying layer.

The missing support also happens with $overhold_threshold != 0, but I'm not sure
what goes wrong in that codepath.

Kind regards,
Loong Jin

[whosawhatsis]

The code determining whether a small overhang should have support should also take into account how much of the connected area is not overhanging. A thin overhang attached to a very thin tower needs support more than one that is connected to a large, solid block.