Overstuffed First Solid Infill Layer Debugging: FAIL

The first pass at the lip balm holders suffered from a grossly overstuffed first solid infill layer:

Overfilled layer 2

Overfilled layer 2

The skirt measured the usual scant 0.25 mm and was level all around, so the platform alignment and home position were just fine. That’s rarely a problem, but it’s good to verify before proceeding.

Previewing the G-Code didn’t show any problems; all the second-layer threads looked just fine. With that said, I did create an issue for gcode.ws pointing out that the profusion of thread colors wasn’t useful and suggesting some alternative methods.

The first layer requires 15-ish minutes to print, so I decided to reproduce the problem in a solid calibration box sliced with the same settings as the holder:

Calibration boxes - solid

Calibration boxes – solid

That still life represents these tests:

  • Solid 3 mm tall box, 20 mm square
  • 30 mm square
  • 25 mm square, with text in Arial
  • Again, because I can’t believe it hasn’t failed yet
  • With rectilinear first layer
  • Back to Hilbert with text in Zapf Chancery

All of those printed without trouble; every layer came out exactly as it should. In particular, the first solid infill layer atop the Hilbert Curve bottom layer had the precisely filled threads I’m used to seeing, each one butted against its neighbors without any excess plastic.

I modified the OpenSCAD source code to extract a 20x20x3 sample block from the lip balm holder model, including a snippet of the actual text. That worked fine.

Expanding the sample produced the irregular chunk in the front row, also 3 mm tall, including a section of the lilypads surrounding the tubes. Another successful print!

I’ll leave to your imagination a pile of half a dozen first layers topped with small sections of grossly overstuffed solid infill, printed in between the successful blocks and as a result of the variations mentioned below, with identical text and slicer settings. The test blocks work fine, but the actual holder and sections from it do not.

Having eliminated the obvious causes, it was time for more drastic measures.

I build OpenSCAD and Slic3r from the latest source files on GitHub. Nothing in this leads me to suspect the OpenSCAD models and using the most recent stable Slic3r version produced the same results.

Rebuilding the Slic3r configuration files from scratch produced the same results.

That’s where I gave up, set the 3D Honeycomb infill to start with Layer 2, and completed the mission.

Lacking any better ideas, I decided to throw all the balls in the air at once …



  1. #1 by solaandjin on 2016-04-13 - 15:56

    Your model shows some z-fighting on the bottom. Maybe?

    • #2 by Ed on 2016-04-13 - 18:25

      Aye! The cylinders and their holes start at Z=0, then get unioned with the lilypads. In principle, the Z-fighting seen in the preview on the first layer shouldn’t matter in the compiled model on the second layer.

      I’m not sure I believe any of that, but I raised the holes by Protrusion and, should I need more of these things, maybe that will make a difference … [sigh]