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.
The maple at the far end of the driveway sprouted sapcicles (or maybe sapsicles) after a brief warm spell woke it up in early March:
You can break them off and eat them like Popsicles, but they’re not nearly as sweet as you’d imagine. We’ve boiled sap into syrup and can report from personal experience that the 40:1 boildown ratio is no myth…
Aitch bestowed this gem on me while cleaning out his collection:
It’s a 6C21 triode, originally used as a radar modulator, atop a letter-size sheet of graph paper. The plate terminal is on top, the grid sticks out to the side, and the filament is common with the cathode through the base pins.
It has impressive specs (datasheet and pictures):
The gray film inside the bulb shows that it’s been used, but the filament still has continuity. Ordinarily, you could turn something like this into a night light by running the filament at a voltage somewhat under its rating, but my bench supply maxed out at @ 3 A without even warming it up; a dim orange night light that burns maybe 75 W is Not A Good Idea.
The base has some intriguing holes, originally used for forced-air cooling, that lead directly to the glass envelope:
One could mount discrete LEDs in those holes, maybe a slightly turned-down 10 mm cool-white LED in the middle flanked by red and blue, and run a low-power Arduino-based mood light; by some cosmic coincidence, the hole spacing matches up almost perfectly with those LED strips. Or one could go full analog with three red LEDs driven by the WWVB signal.
I’m thinking a plain black acrylic case, with the tube base sunk into the middle, would be about right. No readouts, no dials, no buttons, just a gently glowing tube.
Maybe a 3D printed socket holding everything in place?
It turns out that dropping a dark-gray USB flash drive on a dark carpet under a table in a dimly lit room doesn’t produce a net increase in happiness. The next time that happens, we’ll be able to find the thing:
Each side has a snippet of retroreflective orange tape; the tenth drive lives with the Token Windows Laptop. Done!
In related news, the Dremel Wrench went missing despite its high-viz tape. I vaguely recalled tucking it into a tool bag for a remote house-call repair jog, but a week later it turned up in the breast pocket of my demin jacket. Maybe it needs a bulky lanyard?
Somewhere along the way, I lost part of the constellation of settings that produce a properly sized first layer. While looking for something else, I discovered that the Z-axis level started at half the expected 0.25 mm:
(<layer> 0.125 ) (<skirt>) G1 X-13.25 Y29.2675 Z0.125 F15000.0
The key turned out to be (re?)enabling the Skeinforge Bottom setting:
Then it comes out right:
(<layer> 0.25 ) (<skirt>) G1 X-13.25 Y29.2675 Z0.25 F15000.0
The excellent illustrations at the bottom of the Official Documentation (which I don’t recall seeing before) show you what’s going on; you really can’t deduce the geometry from the parameter names alone.
The first layers were still within ±0.05 mm of 0.25 mm, which suggests the plastic squooshes out around the nozzle and rebounds to nearly the correct thickness, but they tended toward consistently too thin rather than OK-on-average. The first trial with the proper Bottom setting came out spot on at 0.25 mm around the Skirt thread, so it’s back on track.
The first layer comes out at 20 mm/s and sticks like glue to the Kapton tape. The remaining layers run at 40 mm/s for infill and 20 mm/s for perimeters, producing spot-on dimensions, with 250 mm/s traverses between printed sections. It’d be nice to run faster, but accuracy has its benefits for mechanical parts.
That’s with a 2.95 mm Filament Diameter setting closely matching the average actual diameter and a 0.95 Filament Packing Density. I think the Density is slightly too low, so I’ll bump that to 1.0 for the next object.
That comment suggested scroll ring failures on a Kensington Expert Mouse (it’s a trackball) might occur when the apertures become misaligned from the IR emitter-detector pair, although later results were equivocal. I tore apart a failed unit to see what the alignment looked like for a known-bad scroll ring.
The right side view shows the receiver roughly centered in an aperture:
The left side view shows that the ring is almost flush against the circuit board, with the isolating cutout just in front, and it’s not obvious how to lower it any further:
So I think there’s no way to realign this one, other than to raise the aperture ring a bit, but that doesn’t seem like it would make any difference: the detector already has a good view of the emitter.
If your trackball has a failed scroll ring, tweaking the aperture ring’s alignment certainly can’t hurt: try it and report back.
If you don’t expect a miracle, you probably won’t be disappointed, alas.
The pix come from the Canon pocket camera mounted on the macro lens / illuminator, handheld with manual focus. The dust speck on the detector is just slightly out of focus, but you get the general idea.
Update: 2015-07-29 – A success story from Tom:
Hi, I wanted to leave a comment for your page here: [this url]
I’ve got an expert mouse trackball that was having intermittent scroll ring problems, then finally quit working altogether. Dismantled it easily using the instructions on this site.
Cleaned it and it still wasn’t working. Tried changing the alignment of the IR emitter/detectors and it still wasn’t working. Then we kept on fiddling with the alignment and voilà.
Like others have said, the alignment seems to be SUPER sensitive. So if any others are reading this with the same problem, keep persevering.
Thanks to everyone who has posted to help find solutions!
Another update: Seven years in the future, a real fix appears!
That comment suggested a different solution to the problem of having the display manager start before the NFS mounts complete. When that happens, you can sign in and start programs that won’t have access to their data, producing all manner of heartache and confusion.
One complication: it seems /etc/rc.local starts and runs before the network (among other tidbits) gets connected and becomes ready, which means you can’t just plunk your code in that file like you used to, at least not in Ubuntu. Fixing that requires an upstart script triggered when the network interface finally hauls itself to its feet.
There’s no actual link between the NFS mount commands and the display manager startup, but it seems that if you don’t attempt to mount the NFS shares before the network becomes active (which is what happen with shares automounted through /etc/fstab), but wait for the network to come up and then issue the mounts, the shares mount almost instantly and become ready by the time the display manager presents the login screen. That’s better than the kludge I had figured out and works fine, so I’ll run with it until something else breaks.
The not-quite-deterministic fix has three parts:
noauto in the fstab entries for the NFS sharesupstart script to mount those shares after eth0 lights uplightdm to start up normally (i.e., remove my hackish attempts)A sample line from fstab, with the vital noauto option:
oyster:/mnt/bulkdata /mnt/bulkdata nfs noauto,noatime 0 0
The /etc/init/local.conf script assumes the network interface will be eth0, which does not generalize to wireless networks on laptops and suchlike. You could add some Boolean logic to wait for the first of several interfaces, I suppose:
description "Stuff that should be in /etc/rc.local" author "Ed Nisley - KE4ZNU" start on (local-filesystems and net-device-up IFACE=eth0) stop on shutdown script logger Starting local init... logger Mounting NFS filesystems mount /mnt/bulkdata mount /mnt/userfiles mount /mnt/diskimages mount /mnt/music logger Ending local init end script
The lightdm.conf file reverts to the distribution version, with this starting trigger:
start on ((filesystem
and runlevel [!06]
and started dbus
and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
or stopped udev-fallback-graphics))
or runlevel PREVLEVEL=S)
It’s worth noting that the upstart interpreter hates comment lines embedded within statements: it does not regard them as whitespace and does not ignore them. Just don’t do it. That explains some of the problems I encountered before, but fixing those problems did not eliminate the overall issue.
The end result of all that hocus-pocus makes the box boot the way it used to: the display manager comes up promptly, presents the GUI login screen, and the NFS mounts are ready when you are.
This is not made obvious at the outset, but a video card with a DMS-59 connector that can drive a pair of Single Link DVI monitors cannot drive a single Dual Link DVI monitor: the DMS-59 connector doesn’t have the required signals.
The fact that each of the Single Link DVI connectors on the end of the DMS-59 Y-splitter cable have enough pins (well, holes) to mate with a Dual Link DVI cable doesn’t clarify the situation.
Of course, you can’t combine two separate Single Link outputs into a Dual Link input.
An HDMI 1.4 cable can support a single 2560×1440 monitor, but not from this resolutely low-res video card.
The Smell of Molten Projects in the Morning 