Improved Lipstick and Lip Balm Holder With Text

For reasons that aren’t relevant here, Mary asked me to make four sets of improved lipstick / lip balm / sunscreen holders with five smaller tubes plus the central one and an inscription on the bottom. I ran off one with the last of the cyan PETG and the other three in natural PETG:

Improved Lipstick Holder - on platform

Improved Lipstick Holder – on platform

I embossed the text into the bottom three layers. The tiny spots of detached infill for lowercase letters like a didn’t adhere to the platform, mostly because the retraction settings that work well for larger areas don’t push enough plastic out to bond with the platform before retracting and moving away.

The bridging layer over the text shows Slic3r doing the best it can (clicky for more far more dots). Laying a uniform patch over all the letters in one shot would work better, but I don’t know how you’d define an algorithm that specifies when such a situation occurs:

Lip Balm Holder - text bridge layer - Slic3r preview

Lip Balm Holder – text bridge layer – Slic3r preview

The solid infill layer directly over the Hilbert Curve bottom layer came out grossly severely excessively overstuffed, to the extent that the accumulation reduced the flow of molten plastic and caused the filament drive to strip:

Overfilled layer 2

Overfilled layer 2

Previewing the G-Code show nothing out of the ordinary and, after considerable flailing around, I finally set Slic3r to begin the 3D Honeycomb infill directly atop the Hilbert Curve bottom layer. That provided enough open space to complete the mission, but more debugging was in order.

The OpenSCAD source code as a GitHub gist:

Advertisements

,

  1. #1 by solaandjin on 2016-04-12 - 13:03

    Why does Slic3r change the bridging direction right in the middle of letters? Here’s what S3D gives: https://dl.dropboxusercontent.com/u/3845046/bridging.png

    Your use of [0, for …] requires a development snapshot to compile, btw.

    • #2 by Ed on 2016-04-12 - 17:13

      It looks like S3D expects a single (or double?) thread width anchor to work perfectly every time, while Slic3r goes for a broad anchor that flat-out doesn’t work with a zillion close & tiny bridges. In this case, a few failures don’t matter, but I can see how either algorithm could get ugly.

      Running perimeter threads around the infill seems overly fussy. Why not ram the infill up against the bridges and be done with it?

      requires a development snapshot

      Unless there’s a killer problem, like Slic3r’s bridging mess earlier this year, I fetch whatever’s at the head of the master branch for both Slic3r and OpenSCAD whenever I start something new. In general, that works well enough and I get to follow the discussions about whatever the bulging brains come up with …

  1. Lip Balm Holder With Text #3DPrinting #3DThursday « Adafruit Industries – Makers, hackers, artists, designers and engineers!