Angel Food Cake Pan Liner

Laser cut from parchment paper, no less:

Angel Food Cake Pan liner
Angel Food Cake Pan liner

Radial slits around the middle let it bend upward over the folded aluminum joint around the pillar:

Angel Food Cake Pan liner - detail
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.

The SVG image as a GitHub Gist:

Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

Made in anticipation of the next time Mary bakes a special carrot cake with cream cheese frosting for my birthday …

CNC-3018XL X-Axis Recalibration

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
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
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:

400 step/mm = (200 step/rev * 8 µstep/step) / 4 mm 

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
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
Tek CC – 2022-02-14 – Y detail

And now the X axis looks just as good:

Tek CC - 2022-02-14 - X detail
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.

GCMC XY Axis Calibration Target

The CNC-3018XL drawing the scales on a Tek Circuit Computer disagreed with the MPCNC cutting the perimeter. The Y axis edges looked OK:

Tek CC - 2021-11 - Y detail
Tek CC – 2021-11 – Y detail

But the cut on the X axis edges went too close to the tips:

Tek CC - 2021-11 - X detail
Tek CC – 2021-11 – X detail

I conjured a calibration target to help measure the two machines:

Cal Target - CNC3018XL
Cal Target – CNC3018XL

The X- side of the plot gives the general idea:

CNC-3018XL - Backlash Test - 400step-mm
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:

Cal Target - 400 step-mm - merged
Cal Target – 400 step-mm – merged

It’s half a millimeter short on each end!

More on this tomorrow …

The GCMC source code as a GitHub Gist:

(epilog begins)
(bCNC may regard plot as done before this returns)
(epilog ends)
view raw epilog.gcmc hosted with ❤ by GitHub
(prolog begins)
G17 (XY plane)
G21 (mm)
G40 (no cutter comp)
G49 (no tool length comp)
G80 (no motion mode)
G90 (abs distance)
G94 (units per minute)
(prolog ends)
view raw prolog.gcmc hosted with ❤ by GitHub
// Grid pattern to check XY scaling
// Ed Nisley KE4ZNU - 2021-11
// gcmc -P 4 --pedantic --prolog prolog.gcmc --epilog epilog.gcmc --output 'Scale Grid.ngc' 'Scale Grid.gcmc'
FALSE = 0;
// Define useful constants
SafeZ = [-,-,10.0mm]; // above all obstructions
TravelZ = [-,-,2.0mm]; // within engraving / milling area
PenZ = [-,-,-1.0mm]; // depth for good inking
PenSpeed = 2000mm;
// Overall values
PlotSize = [250mm,200mm,-];
comment("PlotSize: ",PlotSize);
GridSize = [25mm,25mm,-];
Margins = [5mm,5mm,-];
CenterOD = 5.0mm;
TextFont = FONT_HSANS_1_RS; // single stroke stick font
TextSize = 3.0 * [1.0mm,1.0mm];
// Draw it
comment("Draw title info");
tp = scale(typeset("Scale & Backlash Test Pattern",TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2,PlotSize.y/2 - GridSize.y/2,-];
tp = scale(typeset("Grid " + GridSize,TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2,PlotSize.y/2 - GridSize.y/2 - 1.5*TextSize.y,-];
tp = scale(typeset("F " + PenSpeed + "/min",TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2,PlotSize.y/2 - GridSize.y/2 - 3.0*TextSize.y,-];
tp = scale(typeset("Ed Nisley - KE4ZNU",TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2,-(PlotSize.y/2 - GridSize.y/2),-];
tp = scale(typeset("",TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2,-(PlotSize.y/2 - GridSize.y/2 + 1.5*TextSize.y),-];
comment("Mark center point");
comment("Label axes");
tp = scale(typeset("X+",TextFont),TextSize);
tp += [GridSize.x + 0.5*TextSize.x,-TextSize.y/2,-];
tp = scale(typeset("Y+",TextFont),TextSize);
tp += [-TextSize.x/2,GridSize.y + 0.5*TextSize.y,-];
comment("Draw left-to-right");
tp = scale(typeset("L to R →",TextFont),TextSize);
tp += [-PlotSize.x/2 + GridSize.x/2 - tp[-1].x/2,GridSize.y/2,-];
goto([-(PlotSize.x/2 + Margins.x),GridSize.y,-]);
for (p=[-PlotSize.x/2,GridSize.y,-] ; p.x <= PlotSize.x/2 ; p.x += GridSize.x ) {
comment(" p: ",p);
comment("Draw right-to-left");
tp = scale(typeset("R to L ←",TextFont),TextSize);
tp += [PlotSize.x/2 - GridSize.x/2 - tp[-1].x/2,-GridSize.y/2,-];
goto([(PlotSize.x/2 + Margins.x),-GridSize.y,-]);
for (p=[PlotSize.x/2,-GridSize.y,-] ; p.x >= -PlotSize.x/2 ; p.x -= GridSize.x ) {
comment(" p: ",p);
comment("Draw bottom-to-top");
tp = scale(typeset("B to T ↑",TextFont),TextSize);
tp += [-GridSize.x/2 - tp[-1].x/2,-(PlotSize.y/2 - TextSize.y),-];
goto([-GridSize.x,-(PlotSize.y/2 + Margins.y),-]);
for (p=[-GridSize.x,-PlotSize.y/2,-] ; p.y <= PlotSize.y/2 ; p.y += GridSize.y ) {
comment(" p: ",p);
comment("Draw top-to-bottom");
tp = scale(typeset("T to B ↓",TextFont),TextSize);
tp += [GridSize.x/2 - tp[-1].x/2,(PlotSize.y/2 - 1.5*TextSize.y),-];
goto([GridSize.x,(PlotSize.y/2 + Margins.y),-]);
for (p=[GridSize.x,PlotSize.y/2,-] ; p.y >= -PlotSize.y/2 ; p.y -= GridSize.y ) {
comment(" p: ",p);
comment("Draw circles");
maxr = (PlotSize.x < PlotSize.y) ? PlotSize.x/2 : PlotSize.y/2;
for (r=GridSize.x/2 ; r <= maxr ; r += GridSize.x) {
comment(" r: ",r);
view raw Scale Grid.gcmc hosted with ❤ by GitHub

CNC-3018XL: Improved X-Axis Home Switch Mount

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
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
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
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
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.

The OpenSCAD source code as a GitHub Gist:

// 3018-Pro Mount for Makerbot Endstop PCB
// Ed Nisley KE4ZNU - 2019-07 (using OEM machine axes)
// 2022-02-02 rotate X block (after renaming axes to match new layout)
/* [Build Options] */
Layout = "Show"; // [Build, Show]
/* [Hidden] */
ThreadThick = 0.25; // [0.20, 0.25]
ThreadWidth = 0.40; // [0.40]
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
Protrusion = 0.01; // [0.01, 0.1]
HoleWindage = 0.2;
ID = 0;
OD = 1;
//- Shapes
// Basic PCB with hole for switch pins
// origin at switch actuator corner, as seen looking at component side
SwitchClear = [15.0,5.0,2.0]; // clearance around switch pins
SwitchOffset = [12.5,9.0,0.0]; // center of switch pins from actuator corner
PCB = [26.0,16.4,2*SwitchClear.z]; // switch PCB beyond connector, pin height
//XBlock = [PCB.x + 10.0,PCB.y,20.0];
XBlock = [PCB.x,PCB.y,10.0];
XBearing = [10.0,26.5,28.5];
XPin = [10.0,20.0,10.0];
module XMount() {
if (false) // side-push switch tended to slip
difference() {
cube(XBlock + [0,2*Protrusion,0],center=false);
translate(SwitchOffset + [0,0,10.0 - SwitchClear.z/2])
cube(SwitchClear + [0,0,Protrusion],center=true);
else {
difference() {
translate(SwitchOffset + [0,0,XBlock.z - SwitchClear.z/2])
cube(SwitchClear + [0,0,Protrusion],center=true);
difference() {
cube(XPin + [0,0,XBearing[OD]/4],center=false);
translate([-Protrusion,XPin.y/2,XPin.z + XBearing[OD]/2])
cylinder(d=XBearing[OD],h=XPin.x + 2*Protrusion,center=false);
cube(XPin + [2*Protrusion,0,0],center=false);
YBlock = [PCB.x,PCB.y,5.0];
module YMount() {
difference() {
translate(SwitchOffset + [0,0,YBlock.z - SwitchClear.z/2])
cube(SwitchClear + [0,0,Protrusion],center=true);
ZBlock = [PCB.x,PCB.y,6.0];
ZPin = [20.0,10.0,5.5];
module ZMount() {
difference() {
translate(SwitchOffset + [0,0,ZBlock.z - SwitchClear.z/2])
cube(SwitchClear + [0,0,Protrusion],center=true);
difference() {
cube(ZPin + [0,2*Protrusion,0],center=false);
//- Build things
if (Layout == "Show") {
translate([0,-(ZBlock.y + XBlock.y)])

XFCE: Remote Desktop via X11vnc Through an SSH Tunnel

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

From my local PC, I can now SSH into the remote PC as kay and start x11vnc through the SSH tunnel:

ssh -v kay@remote.address -L 5900:localhost:5900 "x11vnc -display :0 -noxdamage -ncache 10 -ncache_cr -nopw"

Still on my PC, aim a VNC client at the local end of the tunnel:

novnc localhost:5900

Using novnc presents the remote desktop as a web page in a browser, although you may prefer something more traditional.

Somewhat to my surprise, It Just Worked™.

Bafang Battery Charge Port: Battery Reset Tool

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.

A description of how to reset the BMS in a similar battery involves poking bare hot wires into the battery terminals, which IMO is akin to Tickling The Dragon’s Tail. The alert reader will note that the “Shark” battery shown on that page has its terminal polarity exactly opposite of the “Ultra Slim Shark” battery on our bikes. Given the energies involved, eliminating any possible errors makes plenty of sense.

The battery connector looks like this:

Bafang battery - Ultra-Slim Shark connector
Bafang battery – Ultra-Slim Shark connector

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
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
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
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
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
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
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
Bafang battery – reset tool – hole support layer

I made a hollow punch to cut the bridge filaments:

Bafang battery - reset tool - pin hole punch
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
Bafang battery – reset tool – hole punching

Whereupon a sharp rap with a hammer clears the hole:

Bafang battery - reset tool - hole cleared
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.]

Bafang battery - adapter better doodle
Bafang battery – adapter better doodle
Bafang battery - adapter dimension doodle
Bafang battery – adapter dimension doodle
Bafang battery - connector key doodle
Bafang battery – connector key doodle

The OpenSCAD source code as a GitHub Gist:

// Adapter to reset Bafang battery management system
// Ed Nisley KE4ZNU Dec 2021
Layout = "Block"; // [Show, Build, Pins, Block, CoaxAdapter, Key]
Gap = 4.0;
/* [Hidden] */
ThreadThick = 0.25;
ThreadWidth = 0.40;
HoleWindage = 0.2;
Protrusion = 0.1; // make holes end cleanly
inch = 25.4;
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
module PolyCyl(Dia,Height,ForceSides=0) { // based on nophead's polyholes
Sides = (ForceSides != 0) ? ForceSides : (ceil(Dia) + 2);
FixDia = Dia / cos(180/Sides);
cylinder(d=(FixDia + HoleWindage),h=Height,$fn=Sides);
ID = 0;
OD = 1;
// Dimensions
WallThick = 3.0;
PinSize = [3.5,4.75,9.0 + WallThick]; // LENGTH = exposed + wall
PinFerrule = [3.5,4.75,10.0]; // larger section for soldering
PinOC = 18.0;
PinOffset = [-9.0,0,9.0];
Keybase = 4.0; // key bottom plate thickness
KeyBlockSize = [15.0,50.0,15.0];
CoaxSize = [35.0,15.0,11.0];
CoaxGlue = [0,2*2,1];
// without key X section
BlockSize = [CoaxSize.x + WallThick + PinFerrule[LENGTH],KeyBlockSize.y,KeyBlockSize.z + WallThick];
// Battery connection pin
// Used to carve out space for real brass pin
// Long enough to slide ferrule through block
module Pins() {
for (j=[-1,1])
translate(PinOffset + [0,j*PinOC/2,0])
rotate(180/6) {
// Coaxial socket adapter nest
// X=0 at left end of block, Z=0 at bottom
// includes glue, extends rightward to ensure clearance
module CoaxAdapter() {
cube(CoaxSize + CoaxGlue + [CoaxSize.x,0,CoaxSize.z],center=true);
// Block without key
// X=0 at connector face, Z=0 at bottom of block
module BareBlock() {
difference() {
translate([BlockSize.x - CoaxSize.x,0,BlockSize.z/2]) // bridging layer
// Complete block
module Block() {
// Battery connector key shape
// Chock full of magic sizes
// Polygons start at upper left corner
module BatteryKey() {
// base outline
kb = [[-15,KeyBlockSize.y/2],[0,KeyBlockSize.y/2],[0,-KeyBlockSize.y/2],[-15,-KeyBlockSize.y/2]];
// flange cutout
kf = [[kb[0].x,20],[-3,20],[-3,15],[-8,15],[-8,-15],[-3,-15],[-3,-20],[kb[0].x,-20]];
// sidewalls
kw = [[-15,KeyBlockSize.y/2],[0,KeyBlockSize.y/2],[0,20],kf[0]];
difference() {
linear_extrude(height=BlockSize.z - KeyBlockSize.z)
// Build it
if (Layout == "Block") {
if (Layout == "Pins") {
if (Layout == "Key") {
if (Layout == "CoaxAdapter") {
if (Layout == "Show") {
if (Layout == "Build") {

The Machine Stops

As foretold by E. M. Forster in 1909, we have two exhibits of the machine grinding to a halt.

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
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.