slic3r ignores slim slots

[kefir-]

Slic3r ignores slim slots when generating gcode. I constructed a sample to demonstrate and test the issue, where I have created a 20mm cube with 6 slots, of 0.1mm, 0.2mm, 0.3mm, 0.4mm, 0.5mm and 0.6mm width. The two slimmest slots are missing from the gcode, they are simply filled in as if they weren't there. So it appears that I can't make a 0.1mm or 0.2mm slot in my part, but that's what I need to do.

Here's a screenshot of the STL viewed in Blender:

and here's a screenshot of the gcode viewed with tatlin:

I'll share the actual stl and gcode files when my web host is back up after a current outage.

[alranel]

Good test case, thank you.

[kefir-]

Here's the STL:

http://dl.dropbox.com/u/8154223/test-slots.stl

and here's the gcode I got from slic3r 0.9.8:

http://dl.dropbox.com/u/8154223/test-slots-2.gcode

[mesheldrake]

The 0.1 and 0.2 mm wide slots are being lost to the default $safety_offset of 0.1 in Layer::Region::_merge_loops().

$safety_offset there would have to be < 0.05 to preserve the smallest 0.1mm wide gap in this model.

@alexrj - any objection to reducing the default $safety_offset in _merge_loops() from 0.1 to 0.0499? Might that be just about as likely to fix the problem cases the safety offset is supposed to fix?

Then "gap resolution" - minimum gap preserved - could be claimed as 0.1mm, instead of > 0.2mm.

Smallest slots preserved with $safetey_offset = 0.0499:

[kefir-]

Mike, sorry for the late reply, I've somehow missed your comment! And thanks for the workaround.

Are there any drawbacks to reducing $safety_offset for a clean STL? I guess the hard lower bound is XY resolution, or some multiple of that, so it probably shouldn't be set lower than that.

[kefir-]

I can't verify this workaround. When trying to set $safety_offset to less than 0.05, I get core dumps when loading this test cube in slic3r (current git head).

[alranel]

@kefir-, problem is not really about resolution - that outset/inset roundtrip is there because some STL files happen to have very narrow (almost invisible) holes in horizontal surfaces, that are amplified when perimeters and infill are generated. I should find those test cases again and see whether what @mesheldrake proposed is okay.

[kefir-]

Turns out I get core dumps even when I don't change that value with the current git head. Sorry about that, should have tested.

Anyway, thanks for the feedback. I tested SFACT and had the same issue there, but from what I hear, other slicers handle these slots without problems. Would be nice if slic3r also handled it. After all, slic3r is nicer. :)

[dr-mrsthemonarch]

I've been having issues with Slicer ignoring small details aswell, the most recent case seems to be with mr. alligator, where the infill for the entire bottom job is just ignored. (although some infill is added) As noted in the picture.

[kefir-]

I can confirm that setting $safety_offset to 0.04 keeps the smallest detail in the print in my test cube (above), where the smallest slot is 0.1mm wide. I'm testing with current git head.

[Lodran]

kefir's change ( $safety_offset //= scale 0.04; ) also allows Emmet's gear bearing to print correctly (See #1056).

[alranel]

I set the offset to 0.0499 as proposed by @mesheldrake, can you confirm current git works?

[alranel]

No feedback... closing.

[kefir-]

Sorry, I've been away on holiday. I can confirm that setting 0.049 works, I'm currently using that myself with 0.9.9 in git.