Archive for category Software
That’s with a 0.1 mm cut depth, sidelit with an LED flashlight.
Feeding those nine digits into the Guilloché pattern generator script should get you the same pattern; set the paper size to 109 mm and use Pen=0 to suppress the legend.
The same pattern at 0.3 mm cut depth looks about the same:
It’s slightly more prominent in real life, but not by enough to make a big difference. I should try a graduated series of tests, of course, which will require harvesting a few more platters from dead drives.
Either side will look great under a 21HB5A tube, although the disks are fingerprint and dust magnets beyond compare.
My old Gen 1 Kindle Fire hasn’t seen much action lately, so I figured maybe it could end its days by becoming a slide show / picture frame. While fiddling around, I tried to fire up the Amazon Shopping app:
Clicking the big orange button fired up Amazon’s Silk browser, which promptly crashed.
Some days, the punch line writes itself …
The adapter for an old Electrolux crevice tool (not the dust brush) snapped at the usual stress concentration after about three years:
The lower adapter is the new version, made from a length of 1 inch PVC pipe (that’s the ID, kinda-sorta) epoxied into a revised Kenmore adapter fitting.
The original OpenSCAD model provided the taper dimensions:
The taper isn’t quite as critical as it seems, because the crevice tool is an ancient molded plastic part, but a smidge over half a degree seemed like a good target.
Start by boring out the pipe ID until it’s Big Enough (or, equally, the walls aren’t Scary Thin) at 28 mm:
Alas, the mini-lathe’s craptastic compound has 2° graduations:
So I set the angle using a somewhat less craptastic protractor and angle gauge:
The little wedge of daylight near the gauge pivot is the difference between the normal perpendicular-to-the-spindle axis setting and half-a-degree-ish.
Turning PVC produces remarkably tenacious swarf:
The gash along the top comes from a utility knife; just pulling the swarf off didn’t work well at all.
The column of figures down the right side of the doodles shows successive approximations to the target angle, mostly achieved by percussive adjustment, eventually converging to about the right taper with the proper dimensions.
Cutting off the finished product with the (newly angled) cutoff bit:
And then It Just Worked™.
The OpenSCAD source code for all the adapters as a GitHub Gist:
The Wzye Pan camera overlooking the bird feeders attracted the attention of a Downy Woodpecker:
The camera sits on a “guest” branch of the house network, fenced off from the rest of the devices, because Pi-Hole showed it relentlessly nattering with its Chinese servers:
In round numbers, the Pan camera tried to reach those (blocked)
iotcplatform domains every 30 seconds around the clock, using a (permitted)
google.com lookup to check Internet connectivity. Pi-Hole supplied the latter from its cache and squelched the former, but enough is enough.
I haven’t tested for traffic to hardcoded dotted-quad IP addresses not requiring DNS lookups through the Pi-Hole. Scuttlebutt suggests the camera firmware includes binary blobs from the baseline Xaiomi/Dafang cameras, so there’s no telling what’s going on in there.
The Xiaomi-Dafang Hacks firmware doesn’t phone home to anybody, but requires router port forwarding and a compatible RTSP client on the remote end. Isolating it from the rest of the LAN must suffice until I can work out that mess; I assume the camera has already made my WiFi passwords public knowledge.
The MPCNC, however, can apply plenty of downforce, so I tinkered up a quick-and-dirty adapter to put the drag knife “pen” body into the MPCNC’s standard DW660 router holder:
That’s using the DW660 adapter upside-down to get the business end of the knife closer to the platform. The solid model descends from the linear-bearing Sakura pen holder by ruthless pruning.
It didn’t work well at all, because you really need a spring for some vertical compliance and control over the downforce pressure.
Back to the Comfy Chair:
A trio of the lightest springs from a 200 piece assortment (in the front left compartment) pushes the upper plate downward against the drag knife’s flange:
There’s a bit more going on than may be obvious at first glance.
The screws slide in brass tubing press-fit into the upper plate, because otherwise their threads hang up on the usual 3D printed layers inside the (drilled-out) holes. Smaller free-floating brass tubing snippets inside the springs keep them away from the screw threads; the gap between the top of the tubing and the screw head limits the vertical compliance to 3 mm. The screws thread into brass inserts epoxied into the bottom disk, with a dab of low-strength Loctite for stay-put adjustment.
I bored the orange PETG disk to a nice slip fit around the knife body:
The upper plate also required fitting:
A few iterations produced reasonably smooth motion over a few millimeters, but it’s definitely not a low-friction / low-stiction drag knife holder. It ought to be good for some proof-of-concept vinyl cutting, though.
The OpenSCAD source code as a GitHub Gist:
The picture also shows a defunct Sandisk Extreme Plus killed by continuous video recording in my Fly6 bike camera. I later replaced the EVO with a video-rated Samsung card which has been running fine ever since, albeit with the occasional crash-and-reformat expected with “action” cameras.
With that as background, a different Samsung EVO card from the same batch has been running the MPCNC’s Raspberry Pi for about a year. Over the course of a few days last week, the RPi went from an occasional stall to a complete lockup, although waiting for minutes to hours would sometimes resolve the problem. As I’ve learned by now, it’s not a software crash, it’s the controller inside the card suffering from write amplification while trying to move data from failing sectors.
f3write to the card shows the problem:
The write speed started out absurdly high as the card’s write cache fills, then slowed to to the flash memory’s ability to absorb data, and eventually ran out of steam during the last few files.
But, as you might not expect,
f3read reported the data was fine:
sudo f3read /mnt/part F3 read 7.0 Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions. SECTORS ok/corrupted/changed/overwritten Validating file 1.h2w ... 2097152/ 0/ 0/ 0 Validating file 2.h2w ... 2097152/ 0/ 0/ 0 Validating file 3.h2w ... 2097152/ 0/ 0/ 0 Validating file 4.h2w ... 2097152/ 0/ 0/ 0 Validating file 5.h2w ... 2097152/ 0/ 0/ 0 Validating file 6.h2w ... 2097152/ 0/ 0/ 0 Validating file 7.h2w ... 2097152/ 0/ 0/ 0 Validating file 8.h2w ... 2097152/ 0/ 0/ 0 Validating file 9.h2w ... 2097152/ 0/ 0/ 0 Validating file 10.h2w ... 2097152/ 0/ 0/ 0 Validating file 11.h2w ... 2097152/ 0/ 0/ 0 Validating file 12.h2w ... 2097152/ 0/ 0/ 0 Validating file 13.h2w ... 2097152/ 0/ 0/ 0 Validating file 14.h2w ... 2097152/ 0/ 0/ 0 Validating file 15.h2w ... 2097152/ 0/ 0/ 0 Validating file 16.h2w ... 2097152/ 0/ 0/ 0 Validating file 17.h2w ... 2097152/ 0/ 0/ 0 Validating file 18.h2w ... 2097152/ 0/ 0/ 0 Validating file 19.h2w ... 2097152/ 0/ 0/ 0 Validating file 20.h2w ... 2097152/ 0/ 0/ 0 Validating file 21.h2w ... 1322894/ 0/ 0/ 0 Data OK: 20.63 GB (43265934 sectors) Data LOST: 0.00 Byte (0 sectors) Corrupted: 0.00 Byte (0 sectors) Slightly changed: 0.00 Byte (0 sectors) Overwritten: 0.00 Byte (0 sectors) Average reading speed: 43.04 MB/s
Obviously, the card’s read speed isn’t affected by the write problems.
Assuming the actual data & programs on the card were still good, I slurped the partitions:
sudo partimage save /dev/sdf1 mpcnc_boot.gz sudo partimage save /dev/sdf2 mpcnc_partition.gz
And wrote them back:
sudo partimage restmbr mpcnc_boot.gz.000 sudo partimage restore /dev/sdf1 mpcnc_boot.gz.000 sudo partimage restore /dev/sdf2 mpcnc_partition.gz.000
Unshown: a finger fumble requiring MBR restoration.
Having forced the card controller to reallocate all the failed sectors, the card works now fine and runs at full speed again. This won’t last long, but it’ll be interesting to see how it plays out.
While I was at it, I wrote the partitions to a new-ish / unused Samsung EVO Plus card, now tucked under the MPCNC’s monitor in case of emergency.
An old SFF Optiplex with an SSD may be a better fallback.
It turns out the Spirograph patterns I’d been using to wring out the MPCNC are also known as Guilloché, perhaps after the guy who invented a lathe-turning machine to engrave them. Sounds pretentious, but they still look nice:
With the ballpoint pen / knife collet holder in mind, I stripped the tool changes out of the Spirograph generator GCMC source code, set the “paper size” to a convenient 100 mm square, and tidied up the code a bit.
As with Spirograph patterns, changing the random number seed produces entirely different results. A collection differing in the last digit, previewed online:
Seed = 213478836:
Seed = 213478837:
Seed = 213478838:
Seed = 213478839:
They’re such unique snowflakes …
The Bash script now accepts a single parameter to force the PRNG seed to a value you presumably want to plot again, rather than just accept whatever the Gods of Cosmic Jest will pick for you.
The GCMC source code and Bash (or whatever) script feeding it as a GitHub Gist: