The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Mechanical widgetry
Marco/DIY3D mentioned the LeFabShop Elephant on the Makergear Google Group (defunct, now that MG started their own forum) and I had to print one for an upcoming presentation:
The leg shafts broke free after a bit of struggle and it now prowls my desk in search of handouts:
I like the semi-transparent crystalline effect of natural PLA, even if it’s not appropriate for an elephant…
One of my headband magnifiers has a headlight above the brim, an incandescent flashlight bulb powered by a pair of AAA alkaline cells, that hasn’t worked well since the day I bought it. This being a time of finishing small projects, I finally tore it apart and discovered that the cells and contacts were in fine shape (!), the bulb (remember bulbs?) worked, the wiring was OK, but the switch was bad.
The switch body seems to be firmly anchored in place, so I pried that red base plate off in situ, un-bent the silver-plated (!) spring-contact-actuator, and reassembled it in reverse order. No pictures, as it took less time to do than to tell, but it now works perfectly… most likely, for the first time ever.
Stop squirming! This can be much more painful…
I’m mildly tempted to hotwire the guts of a white LED flashlight into the thing, but that would require either another AA cell or a booster circuit and I’m not ready for that just yet.
My original dimensions for the helmet mirror mount used three sections of the inspection mirror shaft, with a short length of the fattest tube screwed into the azimuth turret:
Each section has a pair of brass leaf springs applying just enough friction to hold the next-smallest tube in place, with a rolled crimp securing the springs and preventing the smaller section from pulling out. My first version used that short length of the largest section and the next (for Mary’s helmet) used only the two smallest tubes; it’s rapid prototyping at its finest, except that I rarely discard a prototype that actually works.
Late last year I managed to pull the shaft out of the base while adjusting the length and watched those two springs flutter to the ground beside me.
After finding both of them amid the usual roadside clutter, I swore a mighty oath that I’d epoxy the base of the middle tube into the larger one, eliminating one non-functional adjustment point:
The heatstink tubing covers most of the evidence, but you can see a fillet of epoxy around the end.
Done!
The Whirlpool water heater anode rod is corroding nicely:
The new GE water heater anode rod seems to be passivating:
There’s some corrosion up near the bolt head, so it’s not entirely asleep:
I hammered the coating off the rod, scuffed the shiny parts with coarse sandpaper, wiped off the dust, and stuck it back in its socket. We’ll see what it looks like next year.
Both tanks flushed nicely without too much sediment.
Searching for “water heater” will turn up other posts…
After replacing the front wheel bearings, I replaced both pairs of brake pads. The rear brakes use holders with slide-in pads, but I’ve never been happy with the dinky little pins that retain the pads, so this time I’m using ordinary cotter pins:
The rear brake pads on a diamond-frame bike sit nearly horizontally on the seat stays, with the pin head pointed upward. On Tour Easy recumbents, the pads stand almost vertically on the chain stays, with the pins sideways:
That photo dates to 2010, when those brakes were new. Nary a pin has worked loose yet and I don’t expect they ever will, but …
If the pins rust before the pads wear out, I’ll go back to those little bitty OEM stainless pins.
The nose bridge of my “computer glasses” snapped in the exact center, thus confirming my dislike of the springy head-clamping design. These never leave my desk, so I filled a small brass tube with epoxy, shimmed the lenses on a surface plate, tweaked the bridge into alignment with a surface gauge scribe, and let it cure overnight:
That layout deliberately reduces the springiness by aligning the lenses to be parallel across the bridge, rather than being a bit side-eyed. They’re an un-bendable alloy that provides no way to tweak the alignment; they emerged just about perfect, but it’s time for a new pair later this year.
FWIW, they’re DIY “computer glasses”: +1 diopter to the far (“infinity”) correction and -1 diopter from the reading adder, producing a pair of glasses with the far point at about 1 meter and an unchanged reading-distance correction. That worked well, but next time I’ll use +0.75 diopter so I can sit back a bit further from those big monitors.
Also: the rust on that lovely surface gauge scribe base came from the previous owner and looks much worse in the picture than in real life. I should run it through an Evaporust bath the next time I have some out. It’s probably a Starrett Model 257, but with absolutely no maker marks whatsoever.
Having discovering that the chocolate mold positives suffered from sparse top infill, to the extent that silicone rubber would flow right though the surface…
… I ran off a few variations of the classic 20 mm calibration “cube” (which is 10 mm tall):
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:
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:
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?
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!
The Smell of Molten Projects in the Morning 