Posts Tagged Improvements
Drilling a pair of holes into a length of ground steel shaft turned it into a holder for a Sakura Micron pen:
The aluminum ring epoxied to the top keeps it from falling completely through the linear bearing.
The hole sizes are the nearest inch drills matching the pen’s hard metric sizes:
While I was at the lathe, I turned another layer of epoxy on the printed holder down to a consistent 11.95+ OD. It fits the bearing nearly as well as the steel shaft, although it’s not quite as smooth.
The steel version weighs about 20 g with the pen, so it applies about the same downforce on the pen nib as the HP 7475A plotter. The force varies from about 19 g as the Z axis moves upward to 23 g as it move downward, so the stiction amounts to less than 10% of the weight:
However, the more I ponder this setup, the less I like it.
When the Z-axis moves downward and the nib hits the paper, it must decelerate the weight of the pen + holder + ballast within a fraction of a millimeter, without crushing the nib. If the pen moves downward at 3000 mm/min = 50 mm/s, stopping in 0.3 mm requires an acceleration of 4.2 m/s² and a 20 g = 2/3 oz mass will apply 0.08 N = 0.3 oz to the nib. Seems survivable, but smashing the tip a few hundred times while drawing the legends can’t possibly be good for it.
Also, the tool length probe switch trips at 60 (-ish) g, which means the pen can’t activate the switch. Adding a manual latch seems absurd, but you can get used to anything if you do it enough.
Smoking bacon during the winter months brought the third tank into play, requiring the POL-to-QD adapter I’d had in the drawer for just such an occasion. Not much to my surprise, the old PLA fitting adapter snapped along the layers near the outside end of the triangular snout:
So I ran off the two orange ones in PETG with six perimeter layers and 50% infill density:
Those should last roughly forever …
The OpenSCAD source code as a GitHub Gist:
Adding delays around the SPI control signal changes reduced the OLED glitch rate from maybe a few a week to once a week, but didn’t completely solve the problem.
However, (nearly) all the remaining glitches seem to occur while writing a single row of pixels, which trashes the rest of the display and resolves on the next track update. That suggests slowing the timing during the initial hardware setup did change the results.
Another look at the Luma code showed I missed the Chip Enable (a.k.a. Chip Select in the SH1106 doc) change in
def _write_bytes(self, data): gpio = self._gpio if self._CE: time.sleep(1.0e-3) gpio.output(self._CE, gpio.LOW) # Active low time.sleep(1.0e-3) for byte in data: for _ in range(8): gpio.output(self._SDA, byte & 0x80) gpio.output(self._SCLK, gpio.HIGH) byte <<= 1 gpio.output(self._SCLK, gpio.LOW) if self._CE: time.sleep(1.0e-3) gpio.output(self._CE, gpio.HIGH)
What remains unclear (to me, anyway) is how the code in Luma's
bitbang class interacts with the hardware-based SPI code in Python’s underlying
spidev library. I think what I just changed shouldn’t make any difference, because the code should be using the hardware driver, but the failure rate is now low enough I can’t be sure for another few weeks (and maybe not even then).
All this boils down to the Pi’s SPI hardware interface, which changes the CS output with setup / hold times measured in a few “core clock cycles”, which is way too fast for the SH1106. It seems there’s no control over CS timing, other than by changing the kernel’s bcm2708 driver code, which ain’t happening.
The Python library includes a
no_cs option, with the caveat it will “disable use of the chip select (although the driver may still own the CS pin)”.
Forcibly insisting on using Luma’s bitbang routine may be the only way to make this work, but I don’t yet know how to do that.
Obviously, I should code up a testcase to hammer the OLED and peer at the results on the oscilloscope: one careful observation outweighs a thousand opinions.
As usual, several shoplights didn’t survive the winter, so I gutted and rebuilt them with LED tubes. Even the fancy shoplights with genuine electronic ballasts survive less than nine years, as two of those eight “new” lamps have failed so far.
The dead ballast looks the same as it did before:
Some deft work with a cold chisel and my Designated Prydriver popped the top to reveal a plastic-wrapped circuit board:
Perhaps the flexy gunk reduces the sound level:
The black gunk smells more like plastic and less like old-school tar. It’s definitely not a peel-able conformal coating.
One the other paw, the two magnetic ballasts in another lamp sported actual metal-film capacitors, which I harvested and tossed into the Big Box o’ Film Caps:
If a dying ballast didn’t also kill its fluorescent tube(s), I’d be less annoyed. I’m running the remaining tubes through the surviving fixtures, but the end is nigh for both.
The new LED tubes produce more light than the old fluorescents, although I still don’t like their 6500 K “daylight glow” color.
A crude shelf bandsawed from a plank moves the Sena PS410 serial server and an old Ethernet switch off the bench:
The brackets holding it to the studs came from a 2×4 inch scrap:
Obviously, the Basement Laboratory lacks stylin’ home decor.
None of which would be worth mentioning, except for some Shop Calculations scrawled on the 2×4:
It’s in my handwriting, although whatever it related to is long gone.
After three years, the bracket locking the snowblower’s muffler bolts broke, but this time I saw the bolt pop out of the muffler, fall to the driveway, and lie there sizzling in the slush. I tightened the remaining bolt and completed the mission.
The OEM bracket was thin sheet metal and broke across one bolt hole under the head. I sawed a rectangle out of a defunct PC case, then drilled clearance holes:
Bending two corners upward locks the bolt heads in position. I started the bends by clamping the bracket in the bench vise and whacking the corners, then finishing the job with a drift punch after installing it:
Of course, I renewed the Never-Seez on the bolt threads; they obviously weren’t corroded in place!
For whatever it’s worth, the many spot welds joining the top bracket to the muffler are doing just fine.
The simplest way to push a pen (or similar thing) downward with constant force may be to hold it in a linear bearing with a weight on it, so I gimmicked up a proof-of-concept. The general idea is to mount the pen so its axis coincides with the DW660 spindle, so as to have the nib trace the same path:
The puck mimics the shape of the DW660 snout closely enough to satisfy the MPCNC’s tool holder:
The pen holder suffers from thin walls constrained by the 10 mm (-ish) pen OD and the 12 mm linear bearing ID, to the extent the slight infill variations produced by the tapered pen outline change the OD. A flock of 16 mm bearings, en route around the planet even as I type, should provide more meat.
In any event, 3D printing isn’t noted for its perfect surface finish, so I applied an epoxy layer and rotated the holder as it cured:
After letting it cure overnight, I ran a lathe tool along the length to knock down the high spots and set the OD to 11.9+ mm. Although the result turns out to be a surprisingly nice fit in the bearing, there’s no way epoxy can sustain the surface load required for the usual precision steel-on-steel fit.
A plastic pen in a plastic holder weighs 8.3 g, which isn’t quite enough to put any force on the paper. Copper weighs 9 g/cm³ = 9 mg/mm³ and 10 AWG wire is 2.54 mm OD = 5 mm², so it’s 45 mg/mm: to get 20 g, chop off 450 mm of wire.
I chopped off a bit more than that, straightened it, annealed it, and wound it around a random contestant from the Bucket o’ Sticks with an OD just over the pen OD:
The helix is 13.5 mm down the middle of the turns and 14 turns long (trimmed of the tail going into the chuck and fudging the tail sticking out as a partial turn), so it’s 593 mm long and should weigh 26.7 g. It actually weighs 27.6 g: close enough.
Which is enough to overcome stiction due to the holder’s surface roughness, but the mediocre epoxy-on-balls fit allows the pen point to wander a bit too much for good results.
The prospect of poking precise holes into 16 mm drill rod seems daunting, but, based on what I see here, it will produce much better results: rapid prototyping FTW!
The OpenSCAD source code as a GitHub Gist: