Slicing Anomaly: Thin Fill

Having discovering that the chocolate mold positives suffered from sparse top infill, to the extent that silicone rubber would flow right though the surface…

Tux Gradient - PLA positive detail
Tux Gradient – PLA positive detail

… I ran off a few variations of the classic 20 mm calibration “cube” (which is 10 mm tall):

Solid cube - thin top infill - on platform
Solid cube – thin top infill – on platform

Not only were the infilled surfaces porous, I could see right through the block! That’s impossible to photograph, but here’s a laser beam shining through the entire 10 mm stack, showing how precisely the M2 aligns 50 under-filled thread layers:

Solid cube - laser transmission
Solid cube – laser transmission

The yellow spot in the middle marks the overexposed laser beam. There’s a distinct beam passing through the block that, with the proper orientation, can create a spot on the cutting mat atop my desk.

In fact, I can blow air through the blocks; one could use them as (rather coarse) air filters.

Normally, underfill happens when a mechanical problem prevents the printer from feeding enough filament to keep up with demand, but that’s not the case here: the perimeter threads came out exactly 0.4 mm wide for the entire height of the cube, as you can see if you click the picture for more dots. The top and bottom infill, plus all the interior threads, seem to be about half the nominal width and don’t touch their neighbors on the same XY plane at all.

Alex Ustyantsev’s incomparable G-Code Analyzer shows that Slic3r baked the problem right into the G-Code, so the M2 is cranking out exactly the right amount of filament:

Solid cube - Slic3r thin infill
Solid cube – Slic3r thin infill

The colors show the length of extruder filament per millimeter of XY motion, not the usual XY speed, with the two perimeter threads at 0.033 mm/mm and the interior at 0.18 mm/mm. In round numbers, the G-Code starves the infill by a factor of 1.8, which is close enough to the factor of two I’d guessed going into this mess.

Being that type of guy, I set the exact extrusion thickness and width (0.20 x 0.40 mm), rather than let Slic3r pick them. The extruded thread has a fixed cross-section of (roughly) 0.080 mm2 and a millimeter of XY motion thus requires 0.080 mm3 of filament.

The PLA filament measures 1.79 mm diameter, for a cross-section of 2.5 mm2. Getting 0.080 mm3 from the incoming filament requires feeding 0.032 mm into the extruder, which is almost exactly what you see for the perimeter threads.

After restoring Slic3r’s default configuration, the problem Went Away, which suggests that I backed the algorithms into a corner with some perverse combination of settings. Rebuilding my usual configuration from the defaults also worked fine, so it’s obviously not Slic3r’s problem.

Which one is not like the other ones?

Solid cube tests
Solid cube tests

You can see the thin infill on three of those cubes, with the solid one in the lower right showing how it should look.

The solid cube weighs 4.4 g and the thin-fill variations weigh 2.7 to 2.9 g. Assuming PLA density = 1.25 g/cm3 and “cube” volume = 4 cm3, a completely solid cube should weigh 5.0 g. I think 4.4 g is close enough; the top surface came out flat with nice adjacent-thread fusion. Working backwards, the average fill = 88%; the perimeter is fused-glass solid, so the actual infill will be a bit under that.

I generally run Slic3r from my desktop box, with ~/.Slic3r symlinked to the actual config directory and its files on the NFS server downstairs. Perhaps running different versions of Slic3r on two or three different boxes, all using the same config files, wrecked something that didn’t show up in the UI and produced bad slices. I probably ran two different versions of Slic3r at the same time against the same files, although I wasn’t simultaneously typing at both keyboards.

Moral of the story: check the G-Code before assuming a hardware failure!