Radial slits around the middle let it bend upward over the folded aluminum joint around the pillar:
Angel Food Cake Pan liner – detail
Ours claims to be a 10×4-½ inch pan, roughly the diameter at the top and the overall height. Your pan will surely be different: this one is, as the saying goes, old enough to know better.
Plotting the backlash / calibration target on both the CNC-3018XL and the MPCNC quickly showed, contrary to what I expected, the MPCNC was dead-on accurate, albeit with some wobbulation and a trace of backlash:
MPCNC – Backlash test – detail
Although it looks ug-u-lee, the (lower speed) drag knife cuts come out nice and, because the entry and exit moves match the main cut, the minimal backlash wasn’t a problem.
Turns out only the X axis on the 3018XL had a problem:
Cal Target – 400 step-mm – merged
Apparently the longer leadscrew I installed as part of the “XL” conversion has a small thread pitch error: about 1 mm short in every 250 mm of travel. I don’t have any (definite, non-handwavy) method to measure the pitch directly, other than by running the follower nut and measuring the results, but it’s consistently short.
Quite some time ago (after blowing up the OEM controller board), I set up the Protoneer CNC board in 1:8 microstep mode, making the GRBL $100 setting a nice, round 400 step/mm for a two-start leadscrew with 2 mm pitch and 4 mm pitch:
After a few more measurements suggesting the leadscrew actually traveled 249.2 mm, the correct value will be:
401.28 step/mm = 400 step/mm × 250 mm / 249.2 mm
To verify I understood the problem and solution, I set $100 to a few integer values around the goal:
Cal Target – stacked – 399-402 step-mm
The top image shows the leftmost line at the 10 mm mark on the scale, because it’s easier for me to match the ink line with an engraved line, rather than the non-line at the end of the ruler.
The other images show the results for $100 set to 399, 400, 401, and 402 step/mm, respectively. The results last two results bracket the desired 250 mm outcome, with 401 step/mm being Close Enough™. GRBL accepts a floating point step/mm value, so I set $100 to 401.28, but I was unable to convince myself the result came out consistently different than 401.00.
Plotting both the tick marks (green) and the knife path (red) on the 3018XL, then cutting the bare paper on the MPCNC, showed the two machines now agree on where the knife should fall. The outer end of the tick marks extends 1 mm beyond the cut line to ensure small misalignments do not produce an obvious white gap around the edge of the deck.
The Y axis continues to match:
Tek CC – 2022-02-14 – Y detail
And now the X axis looks just as good:
Tek CC – 2022-02-14 – X detail
The drag knife corners are rounded, as you’d expect. The cut seems slightly offset from a small origin touch-off error, but the scales now match.
But the cut on the X axis edges went too close to the tips:
Tek CC – 2021-11 – X detail
I conjured a calibration target to help measure the two machines:
Cal Target – CNC3018XL
The X- side of the plot gives the general idea:
CNC-3018XL – Backlash Test – 400step-mm
The vertical lines consist of two halves, drawn in order from left to right on the top and right to left on the bottom, meeting in the middle at the Y=0 axis. If they do, in fact, meet in the middle, then there’s no problem with backlash.
The 25 mm distance between adjacent lines verifies the linear calibration; the total distance along the X and Y axes provides more travel for more error accumulation.
The circles provide some reassurance the machine can draw a smooth circle, because they come from GRBL’s (or whatever) G2 G-Code commands, not a linear approximation.
Spoiler: after a considerable amount of drawing, measuring, and muttering, the problem emerged from the CNC-3018XL’s X-axis leadscrew:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A few months of inactivity left the CNC-3018XL table parked in its homed position where the gentle-but-inexorable pressure of the switch lever displaced the foam holding the plastic actuator tab on the X-axis bearing enough that it would no longer operate reliably:
3018 CNC – Y axis endstop
Putting foam tape in a highly leveraged position produces the same poor results as in finance.
The fix requires reorienting the switch so a solid block on the bearing can push directly on the actuator lever:
CNC-3018 X Home Switch – bottom view
The block must curve around the bearing to give the tape enough surface area for a good grip:
CNC-3018 X Home Switch – oblique view
The solid model for the new X-axis mount looks about like you’d expect:
CNC-3018 X Home Switch Mount – solid model
I increased the home switch pulloff to 2 mm, although it’s not clear that will make any difference in the current orientation.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For the first time in a loooong time I (had to) set up remote desktop sharing, starting from an existing SSH login through a single-port pinhole in an immutable router firewall.
The remote PC runs Xubuntu 20.4 LTS and I verified it already had x11vnc installed. If that’s not the case, make it so.
In order to share / control the desktop of a different user (hereinafter known as kay), I must SSH into that PC as kay. My SSH session uses public key authentication and kay has no need for outbound SSH, so just use my PC’s public key in kay‘s authorized_keys file. On the remote PC, where I am signed in as me:
cd ~
sudo mkdir /home/kay/.ssh # kay does not have a public key
sudo cp .ssh/authorized_keys /home/kay/.ssh # so just copy mine
sudo chown -R kay:kay /home/kay/.ssh # transfer ownership
sudo chmod go-rwx /home/kay/.ssh # set proper permissions
A lithium battery management system can (and should!) disable the battery output to prevent damage from overcurrent or undervoltage, after which it must be reset. The inadvertent charge port short may have damaged the BMS PCB, but did not shut down the battery’s motor output, which means the BMS will not should not require resetting. However, because all this will happen remotely, it pays to be prepared.
For this battery, the positive terminal is on the right, as shown by the molded legend and verified by measurement.
A doodle with various dimensions, most of which are pretty close:
Bafang battery – connector dimension doodle
Further doodling produced a BMS reset adapter keyed to fit the battery connector in only one way:
Bafang battery – adapter doodle
Which turned into the rectangular lump at the top of the tool kit, along with the various shell drills and suchlike discussed earlier:
Bafang battery tools
Looking into the solid model from the battery connector shows the notches and projections that prevent it from making incorrect contact:
Battery Reset Adapter – show front
The pin dimensions on the right, along with a mysterious doodle that must have meant something at the time :
Bafang battery – adapter pin doodle
The pins emerged from 3/16 inch brass rod, with pockets for the soldered wires:
Bafang battery – reset tool – pins
The wires go into a coaxial breakout connector that’s hot-melt glued into the recess. The coaxial connectors are rated for 12 V and intended for CCTV cameras, LED strings, and suchlike, but I think they’re good for momentary use at 48 V with minimal current.
I printed the block with the battery connector end on top for the best dimensional accuracy and the other end of the pin holes held in place by a single layer of filament bridging the rectangular opening:
Bafang battery – reset tool – hole support layer
I made a hollow punch to cut the bridge filaments:
Bafang battery – reset tool – pin hole punch
The holes extend along the rectangular cutout for the coaxial connector, so pressing the punch against the notch lines it up neatly with the hole:
Bafang battery – reset tool – hole punching
Whereupon a sharp rap with a hammer clears the hole:
Bafang battery – reset tool – hole cleared
A dollop of urethane adhesive followed the pins into their holes to lock them in place. I plugged the block and pins into the battery to align the pins as the adhesive cured, with the wire ends carefully taped apart.
After curing: unplug the adapter, screw wires into coaxial connector, slobber hot melt glue into the recess, squish into place, align, dribble more glue into all the gaps and over the screw terminals, then declare victory.
It may never be needed, but that’s fine with me.
[Update: A few more doodles with better dimensions and fewer malfeatures appeared from the back of the bench.]
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Amazon sent one of their prescription savings cards, followed a few days later by a note:
We recently mailed you a physical copy of your Amazon Prime Rx savings card, and are writing to inform you that the BIN listed on your Prime Rx card printed incorrectly. The correct BIN is 019363.
So I wrote the corrected number on my card, not that I will ever use it:
Amazon RX – BIN error
Although the BIN (whatever that stands for) is a numeric value, it’s not treated as a number by whoever reads it. I’d lay money down that the source code’s formatting string changed from %6d to %06d or the equivalent in whatever fancy language they use nowadays.
The Social Security Administration sent me an email telling me to check a corrected version of a statement they sent a few months ago. Unfortunately, attempting to do so while writing this post produces a heads-up notice:
We apologize for any inconvenience accessing my Social Security. We are aware of some technical difficulties and are working on them at this time. We appreciate your patience as we work to solve the problems as quickly as possible.
Attempting to sign on seems to proceed normally, until this technical difficulty popped up:
We’re Sorry… There has been an unexpected system error.
Your login session has been terminated. For security reasons, please close all of your internet browser windows.
The first statement put my nearest Social Security office 130 miles away in Wilkes Barre, PA. The corrected statement put it back where it belongs, in the hot urban core of Poughkeepsie.
Perhaps an off-by one error in the database lookup?
As far as I can tell, the world now depends on software nobody can understand or control.