Archive for February, 2018
Because the OLED driver came from the
pip package manager, not the Raspberry Pi’s system-level
apt package manager, it (or they, there’s plenty of code under the hood) don’t get updated whenever I do system maintenance. The doc says this should do the trick:
sudo -H pip install --upgrade luma.oled
However, it turns out the new version has a slightly longer list of pre-requisite packages, causing the update to go toes-up at a missing package:
Could not import setuptools which is required to install from a source distribution. Please install setuptools.
So update (or install, for the new ones) the missing pieces:
sudo apt-get install python-dev python-pip libfreetype6-dev libjpeg-dev build-essential
Doing so produced a backwards-compatibility error in my Python code:
... change ... from luma.core.serial import spi ... into ... from luma.core.interface.serial import spi
The motivation for all this fuffing and fawing came from watching some OLEDs wake up completely blank or become garbled in one way or another. Evidently, my slower-speed SPI tweak didn’t quite solve the problem, although it did reduce the frequency of failures. I have decided, as a matter of principle, to not embrace the garble.
Soooo, let’s see how shaking all the dice affects the situation.
The as-built schematic, such as it is:
Yes, the SSR negative output goes to the Protoneer + Power Input.
I should drive the SSR from the
Motor Enable output (in the external motor control header), rather than +5 V, to let GRBL control the motors, with a manual E-Stop override. The A4988 drivers require
-Controlinput (replaces GND)
- +5 V to BRS to SSR
+Controlinput (as before)
The SSR Control input draws 13 mA at 5 V, suggesting I should drive the AC SSR (for the spindle motor) from the DC SSR output, rather than paralleling the two on a single Arduino output pin.
I can attest to its effect on rational thought; a molly-guard may be required.
If ya can’t fix it, feature it!
#font1 = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf',14) font1 = ImageFont.truetype('/home/pi/sga.ttf',14) #font2 = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf',11) font2 = ImageFont.truetype('/home/pi/sga.ttf',11)
It looks surprisingly good on such a low-res display.
The user community seems divided over the update … [grin]
After a year of fairly light use, the lens holder (and “attack ring”) of my J5-V2 flashlight worked loose and began to rattle. The ring holding the lens in place turned out to be finger-loose, but that wasn’t the entire problem, so I removed it and looked inside:
The mysterious alien egg resides on the upper-right side of the LED emitter.
The aluminum ring holding the LED assembly in place was also finger-loose, so I unwound it to take the whole front end apart:
Reassembly with a few dabs of Loctite in appropriate places should prevent future rattles.
NYS DOT’s recent Rt 376 repaving projects improved the road surface, but the infractructure seems to be crumbling apace, as we spotted on a recent walk across the bridge over Wappinger Creek:
The ragged edge of the deck shows other slivers have fallen into the creek.
My arms aren’t long enough to get a closer view:
The concrete roadway is developing potholes in the right hand southbound lane, so the upper surface has begun crumbling, too.
I think the bridge dates to the mid-1990s, based on the aerial photo history from Dutchess GIS, so it’s a bit over twenty years old. Nothing lasts.
Repairing stuff is hard …
So I intended to shrink the Autolevel probe with 1/8 inch drill rod and a tactile membrane switch:
Unfortunately, it didn’t work nearly as well as I expected, because the switch membrane requires slightly less than the 180 g of pressure that pushes the P100 pogo pin entirely into its housing, leaving no overtravel worth mentioning. The membrane switch mechanism itself has much less than 1 mm of overtravel after the dome snaps, which left me with an uncomfortable feeling of impending doom.
I managed to figure that out before completely assembling the thing, saving me a bit of time.
The end of the pogo pin initially sported a dot of epoxy to spread the load over the switch dome:
I dismantled the pogo pin to see
whether I could substitute a more forceful spring how it worked. As expected, a teeny spring drives the probe up against a trio of indentations in the brass housing. I didn’t expect the probe to have such an intricate shape, but it’s obvious in retrospect.
The OpenSCAD code for the housing required minimal tweakage from the larger version, so it’s not worth immortalizing.
The bCNC doc shows a camera mount made from acrylic and aluminum, but the MPCNC tool carrier lacks anywhere to secure such a thing. The camera should be reasonably close to the spindle axis, high enough to clear the work, and stable enough to hold its alignment. There’s a tiny flat spot next to the outer-lower Z-axis bearing supports (along the bottom of the picture), so that’s where it must go:
At least for now, anyway.
The USB camera originally mounted on a spring clip, with a 10 mm ball at the end of a 6 mm OD × 6 mm long stalk. Because we live in the future, building a matching ball socket isn’t particularly difficult:
3D printing FTW!
The stalk opening slants downward by 5°, because the camera PCB isn’t quite aligned with the stalk and I couldn’t get the first version to aim the lens directly downward.
A pair of brass inserts anchor the two M3 SHCS. The clamping force seems barely adequate to the task, but I’ll wait to see what else I don’t like before complexicating the situation.
A square of Genuine 3M sticky foam tape holds the mount to the MPCNC beside the DeWalt DW660 spindle:
The MPCNC bearing bracket doesn’t provide much surface area for the foam and it’s a bit more flexy than I’d like, but good practice probably requires verifying the spindle-to-camera offset before trusting the results, so we’ll see how it works.
The initial camera alignment consists of putting a mirror flat on the (pretty much level) platform:
Then you adjust the camera so its lens looks squarely at itself in the middle of the image:
The picture shows the camera aligned left-to-right (because the ball can rotate around the shaft axis), but the first mount didn’t allow the stalk to have enough downward tilt to center the lens image on the horizontal crosshair, thus the -5° tilt appearing in the second version.
With the camera lens centered on its reflection, you know the optical axis is perpendicular to the mirror. Because the mirror is flat on the bench, the optical axis must be perpendicular to the bench, which is parallel to the XY plane. Because we assume the MPCNC Z-axis moves perpendicular to the bench = XY plane, the distance between the spindle axis and the camera axis will remain constant, regardless of the Z-axis position.
Seems workable to me.
The OpenSCAD program as a GitHub Gist: