I’ve been putting this type of support structure inside screw holes & suchlike for years:
It’s basically a group of small rectangles rotated around the hole’s axis and about one thread thickness shorter than the overhanging interior.
I’ve found that incorporating exactly the right support structure eliminates Slic3r’s weird growths, eases removal, and generally works better all around.
So doing this for the baseplate of the Glass Tile frame came naturally:
This OpenSCAD snippet plunks one of those asterisks in each of four screw holes:
for (i=[-1,1], j=[-1,1])
translate([0,0,(Screw[LENGTH] - ThreadThick)/2])
cube([Screw[OD] - 2*ThreadWidth,2*ThreadWidth,Screw[LENGTH] - ThreadThick],center=true);
The “cubes” overlap in the middle, with no completely coincident faces or common edges, so it’s 2-manifold. Slic3r, however, produces a weird time estimate whenever the model includes those structures:
NaN stands for Not A Number and means something horrible has happened in the G-Code generation. Fortunately, the G-Code worked perfectly and produced the desired result, but I’m always uneasy when Something Seems Wrong.
Messing around with the code produced a slightly different support structure:
The one thread thick square on the bottom helps glue the structure to the platform and four ribs work just as well as eight in the octagonal hole:
Fin = [Screw[OD]/2 - 1.5*ThreadWidth,2*ThreadWidth,ScrewRecess - ThreadThick];
if (Inserts && SupportInserts)
for (i=[-1,1], j=[-1,1])
translate([Fin.x/2 + ThreadWidth/2,0,(ScrewRecess - ThreadThick)/2])
Which changed the NaN time estimates into actual numbers.
One key difference may be the small hole in the middle. The four ribs (not two!) now overlap by one thread width around the hole, so they’re not quite coincident and Slic3r produces a tidy model:
The hole eliminates a smear of infill from the center, which may have something to do with the improvement.
In any event, I have an improved copypasta recipe for the next screw holes in need of support, even if I don’t understand why it’s better.
Which looks like this with the LEDs and brass inserts installed:
The base holds an Arduino Nano with room for wiring under the cell array:
Which looks like this after it’s all wired up:
The weird colors showing through the inserts are from the LEDs. The red thing in the upper left is a silicone insulation snippet. Yes, that’s hot-melt glue holding the Arduino Nano in place and preventing the PCBs from getting frisky.
Soak a handful of glass tiles overnight in paint stripper:
Whereupon the adhesive slides right off with the gentle application of a razor scraper. Rinse carefully, dry thoroughly, and snap into place.
Tighten the four M3 SHCS and it’s all good:
So far, I’ve had two people tell me they don’t know what it is, but they want one:
Although Jason’s comment suggesting carbon-fiber reinforcing rods didn’t prompt me to lay in a stock, ordinary music wire should serve the same purpose:
The pins are 1.6 mm diameter and 20 mm long, chopped off with hardened diagonal cutters. Next time, I must (remember to) grind the ends flat.
The solid model needs holes in appropriate spots:
Yes, I’m going to put round pins in square holes, without drilling the holes to the proper diameter: no epoxy, no adhesive, just 20 mm of pure friction.
The drill press aligns the pins:
And rams them about halfway down:
Close the chuck jaws and shove them flush with the surface:
You can see the pins and their solid plastic shells through the wrench stem:
Early testing shows the reinforced wrench works just as well as the previous version, even on some new valves sporting different handles, with an equally sloppy fit for all. No surprise: I just poked holes in the existing model and left all the other dimensions alone.
Start with a single cell holding a glass tile over a WS2812 RGB LED:
A bit of OpenSCAD tinkering produces a simple 2×2 array with square interiors as a test piece:
The excessive stringing and the booger in the upper-left cell come from absurdly thin infill tucked into the too-thin walls; Slic3r doesn’t (seem to) have a “minimum infill width” setting and it’ll desperately try to fit infill between two nearly adjacent perimeter threads.
The little support spiders under the LED PCB recesses snapped right out, though, so I got that part right:
The perimeter threads around the LED aperture aren’t quite fused, because it was only one layer thick and that’s not enough.
A quick test with two LEDs showed the white PETG let far too much light bleed between the cells, which was no surprise from the single cell test piece.
Fortunately, it’s all parametric, so a bit more tinkering produced a slightly chunkier matrix with a base for an Arduino Nano and M3 threaded brass inserts for the screws holding it together:
Those two parts require about three hours of printing, much faster than I could produce them by milling pockets into aluminum or black acrylic slabs, and came out with minimal stringing.
A little cleanup, some epoxy work, and a few dabs of solder later:
An initial lamp test showed the white-ish glass tiles aren’t all quite the same color:
I thought it was an LED color variation, too, but the slightly blue tint in the lower left corner followed the tile.
The blurred horizontal strip across the middle is adhesive tape holding the tiles in place; I was reluctant to glue them in before being sure this whole thing would work. A peek into the future, though, shows it’s got potential: