Category: Software

General-purpose computers doing something specific

Ceiling Lamp Nuts
While cleaning dead bugs out of the ceiling lamps, we discovered the kitchen light was missing one of the three nuts holding its cover in place. While spare nuts might be available, this seemed like a quicker & easier solution:

Ceiling Lamp Nut – bottom view – solid model

The stepped interior fits a brass insert with 8-32 threads (not metric, to my utter astonishment) rammed in place with a heat-set tool:

Ceiling Lamp Nut – insert staking

Using the nominal diameters seems to work fine, although I’m sure some finesse will be needed with smaller inserts.

Printed four just to be sure, rammed three inserts, and they’re ready:

Ceiling Lamp Nuts – as-built

The curved cap matches the original nut through the use of the Chord Equation to get the cap radius as a function of its height (sagitta) & base diameter. Admittedly, it looks kinda grotty with only a dozen layers, but it’s the thought that counts.

The original nuts are heavy knurled steel and the new ones are cheap plastic, but nobody will ever know:

Ceiling Lamp Nut – installed

Bonus: now I have two spare steel nuts for the next time …

The OpenSCAD source code:
```
// Nuts for LED ceiling light fixture
// Ed Nisley KE4ZNU
// 2024-09-27

KnurlLength = 7.4;
KnurlOD = 9.0;

CapOD = 9.0;
CapHeight = 2.0;
CapRadius = (pow(CapHeight,2) + pow(CapOD,2)/4)/(2*CapHeight);
echo(CapRadius=CapRadius);

NumSides = 1*(2*3*4);
$fn = NumSides;

Protrusion = 0.1;

difference() {
    union() {
        intersection() {
            translate([0,0,KnurlLength + CapHeight - CapRadius])
                sphere(r=CapRadius);
            translate([0,0,KnurlLength])
                cylinder(d=2*KnurlOD,h=KnurlLength);
        }

        cylinder(d=KnurlOD,h=KnurlLength);

    }

// Ad-hoc 8-32 brass insert sizes

    cylinder(d=5.5,h=8.0);
    cylinder(d=5.9,h=5.7);
    cylinder(d=6.2,h=2.2);
    translate([0,0,-Protrusion])
        cylinder(d=6.2,h=2.2);

}
```
2024-10-01
Prusa MK4: Cart Coins vs. Extrusion Multiplier

A special request came in for cart coins with a handle:

Overstuffed cart key – 1.0EM

That’s in gray PETG-CF (carbon fiber) with Extrusion Multiplier = 1.0 based on the Pill Tube tests and and slightly lower temperatures based on the temperature tower. It definitely looks overstuffed and so does the Wipe Tower for that set of six coins:

Overstuffed cart key – wipe tower

The orange threads off to the right suggest something went terribly wrong with the top layer, which corresponds to the somewhat recessed cart image in the coin, but there were no other symptoms.

All six of the next set failed completely:

Failed cart key – 1.0EM

Apparently the nozzle hit the clotted gray filament in the Wipe Tower and stalled the X axis motor:

Failed cart key – wipe tower

That suggests the same thing happened to the first set during the last pass over the Wipe Tower, causing a less obvious failure.

Setting the Extrusion Multiplier = 0.65 produced a better result:

Cart key print – blue – 0.65EM

Albeit with a slightly understuffed top layer:

Cart key print – 0.65EM

But not by much:

Cart key print – black – 0.65EM

So the answer depends slightly on the PETG-CF filament color, but not by enough to justify defining three different filament types.

Cart coins are essentially solid plastic layers with no empty infill, so they have nowhere for excess filament to hide. The Wipe Tower should have plenty of room, but even at EM=0.65 the tower looks overstuffed on the side with the carbon fiber purge lines:

Cart key print 0.65EM – wipe towers

The default 110% line spacing in the tower seems too small for PETG-CF, so I’ll increase it to 150% to see if that reduces the clumping.

Judged by the surface finish, a 0.65 Extrusion Multiplier is too low, so I’ll try a set of coins at 0.80.

2024-09-27
Scanning Offset Adjustment: LightBurn vs. RDWorks
A protracted debugging session on the LightBurn forum produced an interest result, which I must yoink over here so I can recall my thoughts:

The test patterns will require power / speed tweakage to properly mark cardboard on other machines. The vector boxes are about 1.5 mm wide: these are small differences in small patterns.

The setup for both LightBurn 1.7 RC-13 and RDWorks 8.01.65:
- The engraved patterns run at 500 mm/s & 20% power
- The lines & letters run at 100 mm/s & 8% Min – 9% Max power
- All on white cardboard, with image contrast blown out
Scanning offset = 0.2 mm = the usual setting for my machine

In LightBurn:

Scanning Offset 0.2 – LightBurn

In RDWorks:

Scanning Offset 0.2 – RDWorks

The slight shift to the left in the LightBurn results shows LB does not shift the uni-directional pattern to line up with the vector shape as RDWorks does, which is what started the forum thread.

Scanning offset = 1.0 mm to accentuate the difference, while shredding the bi-direction pattern as expected.

LightBurn’s uni-directional engraved pattern is still in the same slightly leftward-shifted position relative to the vectors, showing the offset value has not been applied:

Scanning Offset 1.0 – LightBurn

RDWorks definitely applies the offset in both modes:

Scanning Offset 1.0 – RDWorks

I do not know why RDWorks did not output the final “l” over there on the right, but it did so on some (not all) of the patterns while setting things up. The jank is strong with it.

So having LightBurn apply the same offset value for both uni- and bi-directional engravings would fix the (slight) offset in my machine. I think it will also fix the much larger misalignment in [the other] machine in that forum discussion.

The whole problem seems to arise from the response time of the HV power supply / laser tube: the position of the left & right edges of the scanned output line depend critically on the rising and falling edges of the current applied to the tube and its power output.

Being me, of course, makes me want a different offset value applied to the uni-directional case, just for fine tuning. Which would require a duplicate offset-per-speed table and that looks like a UX disaster comin’ on strong.
2024-09-24
MMU3 vs. Cart Coin Calibrators
The last time around, I used Cart Coins to verify platform alignment (a.k.a. “leveling”) on the Makergear M2. The Prusa MK4 does mesh probing to ensure accurate alignment, so these new Cart Coins exercised the MMU3 and gave me some giveaways for a recent dinner:

Cart Coin – assortment

The design, such as it is, mashes a PNG found on the InterWebs with a few go-fast stripes added in LightBurn to balance the layout inside a circle:

Cart Coin layout

The motivations for LightBurn:
- It’s convenient
- TroCraft Eco is within 0.1 mm of the proper thickness
- Laser-cut coins proceed with great speed
Normally you’d export the finished layout as an SVG, but OpenSCAD ignores “holes” within shapes, so I exported it as a PNG to serve as a binary height map:
- Import the PNG into OpenSCAD using surface()
- Resize it to 20 mm wide and 1.7 mm tall
- Knock it out of a 24 mm OD × 1.6 mm tall cylinder (which is why the extra 0.1 mm)
- Add the PNG again as a separate 1.6 mm object to refill the hole
Whereupon out pops a solid model:

Cart Coin – solid model

Export that as a 3mf file to keep the two objects aligned, import it into PrusaSlicer, then get multi-material on it:

Cart Coin – PrusaSlicer layout

There’s a fourth group with different colors in hiding. I printed 12 identical coins at a time, mostly so I could keep track of what was happening, and it ended well enough.

The black coins with the translucent retina-burn orange cart look surprisingly good.

But this is way faster:

They’re the size of a US quarter, because that’s what unlocks shopping carts around here. Feel free to tweak the parameters for your locale.

The OpenSCAD source code is almost a one-liner:
```
difference() {
    cylinder(d=24.0,h=1.6);

    resize([20.0,0,1.7],auto=true)
        linear_extrude(height=1,convexity=10)
           projection(cut=true)
            surface("/mnt/bulkdata/Project Files/Prusa Mk4/Models/Cart Coin/Cart Coin layout.png",
                    center=true,invert=true);
}

    color("Black")
        resize([20.0,0,1.6],auto=true)
            linear_extrude(height=1,convexity=10)
               projection(cut=true)
                surface("/mnt/bulkdata/Project Files/Prusa Mk4/Models/Cart Coin/Cart Coin layout.png",
                        center=true,invert=true);
```
Use them responsibly, OK?
2024-09-03

Cutting Board Shim

The kitchen counter has only two useful places for the cutting board and the spot Mary favors puts a distinct swale under one corner. A bit of measuring and solid modeling produced a simple shim to make the answer come out right:

The basic shape is union() of a trio of hull() operations forming the three sides, with the text label as a separate object to verify I understood how to build a multi-material object.

Export it as a 3mf file, open it in PrusaSlicer, slice, print:

Cutting Board shim - label — Cutting Board shim – label

Putting the label on the bottom surface takes advantage of the nubbly finish on the Textured Steel Sheet to make it look like it just grew in there.

The label is just barely visible from the top, despite extending only 1/4 of the way through the 1.6 mm bottom slab:

Cutting Board shim - top — Cutting Board shim – top

So white PETG needs more than 1.2 mm of thickness to hid a black feature. Today I Learned, etc.

Multi-material printing produces a Wipe Tower to hold all the extruded junk during color changes:

Cutting Board shim - wipe tower — Cutting Board shim – wipe tower

The curl under the nozzle comes from the final ramming used to shape the end of the filament into a point for reliable material / color changing.

Although a shim is something of a nuisance, it works perfectly:

Cutting Board shim - in use — Cutting Board shim – in use

Much easier than installing an L-shaped Corian slab with a sink cutout!

The faded engraving dates back to the early days of the laser …

The OpenSCAD source code as a GitHub Gist:

	// Cutting Board alignment shim
	// Ed Nisley KE4ZNU – 2024-08-20

	//—–
	// Dimensions

	ShimThick = 1.6; // thickness of shim under board

	/* [Hidden] */

	ShimOA = [25.0,25.0,15.0]; // overall size of shim

	WallThick = 4.0;

	ShimRadius = WallThick/2;

	LabelThick = ShimThick/4;

	NumSides = 3*4;

	//—–
	// Build it

	union() {
	hull()
	for (i=[0,1])
	translate([i*(ShimOA.x – ShimRadius),0,0])
	cylinder(r=ShimRadius,h=ShimOA.z,$fn=NumSides);
	hull()
	for (j=[0,1])
	translate([0,j*(ShimOA.y – ShimRadius),0])
	cylinder(r=ShimRadius,h=ShimOA.z,$fn=NumSides);

	hull() {
	for (i=[0,1])
	translate([i*(ShimOA.x – ShimRadius),0,0])
	cylinder(r=ShimRadius,h=ShimThick,$fn=NumSides);
	translate([0,1*(ShimOA.y – ShimRadius),0])
	cylinder(r=ShimRadius,h=ShimThick,$fn=NumSides);
	}

	}

	color("Black")
	translate([ShimOA.x/3,ShimOA.y/3,LabelThick])
	rotate([180,0,90 + 45])
	linear_extrude(height=LabelThick,convexity=20)
	text(text=str(ShimThick),size=6,spacing=1.00,
	font="Arial:style:Bold",halign="center",valign="center");

view raw Cutting Board shim.scad hosted with ❤ by GitHub

2024-08-27

Prusa MK4 Y Motor Shim
Having been viciously nerd-sniped by The Great Dragorn of Kismet, I’m in the process of building a Prusa MK4 3D printer with an MMU3. This has been a generally pleasant experience, although I am beginning to loathe Genuine Haribo Goldbären.

Anyhow, the Y axis motor position puts the belt too close to one side of the pulley, with no further adjustment possible:

Prusa MK4 Y axis motor mount – as-built

The stepper motor stator laminations are the striped gray area on the far left, the 3D printed motor mount is the striped black area on the right, and the belt pulley is snugged up against the motor as far as it can go on the shaft.

Pushing the motor a little more to the left requires a shim:

Prusa MK4 Y axis motor mount – shim

Rather than fiddle with scanning the motor mount, I imported its STL model from the Prusa MK4 files:

Prusa MK4 Y Axis Motor mount – solid model

Importing the STL into OpenSCAD and converting the motor face into an SVG file is basically a one-liner:
```
projection(cut=true)
translate([0,0,-5.0])
import("/mnt/bulkdata/Project Files/Prusa Mk4/Calibration/y_motor_holder_R3.stl");
```
Import the SVG into LightBurn, round the corners a little, set it up for 1.5 mm Trocraft Eco, Fire. The. Laser. and it fits perfectly and stands out nicely:

Prusa MK4 Y axis motor mount – shimmed

Having the right tools for a job makes it easy …
2024-08-21

Glass-top Patio Table Leg Brackets: Hardfought

A glass-top patio table came with our house and, similar to one of the patio chairs, required some repair. The arched steel legs fit into plastic brackets / sockets around the steel table rim under the glass top:

Glass patio table - new brackets installed — Glass patio table – new brackets installed

The four glaringly obvious white blocks are the new brackets.

The original brackets had, over uncounted years, deteriorated:

Glass patio table - failed OEM bracket — Glass patio table – failed OEM bracket

Perhaps disintegrated would be a better description:

Glass patio table - crumbled OEM bracket — Glass patio table – crumbled OEM bracket

Each leg has a pair of rusted 1-½ inch ¼-20 screws holding it to the central ring. As expected, seven of the eight screws came out easily enough, with the last one requiring an overnight soak in Kroil penetrating oil plus percussive persuasion:

Glass patio table - jammed screw — Glass patio table – jammed screw

The four legs had three different screws holding them to the brackets, so I drilled out the holes and squished M5 rivnuts in place:

Glass patio table - M5 rivnut installed — Glass patio table – M5 rivnut installed

Although it’s not obvious, the end of that tube is beveled with respect to the centerline to put both the top and bottom edges on the table rim inside the bracket. In addition, the tube angles about 10° downward from horizontal, which I did not realize amid the wrecked fittings, so the first bracket model failed instantly as I inserted the leg:

Glass patio table - first bracket test — Glass patio table – first bracket test

The top & bottom walls of that poor thing were breathtakingly thin (to match the original bracket) and cracked when confronted with the angled tube. I could not measure all the sizes & angles without assembling the table on trial brackets, so getting it right required considerable rapid prototyping:

Glass patio table - failed brackets — Glass patio table – failed brackets

Some trigonometry produced a solid model with features rebuilding themselves around the various sizes / angles / offsets:

Glass Top Table - leg bracket - solid model — Glass Top Table – leg bracket – solid model

A sectioned view shows the angled tube position and end chamfer:

Glass Top Table - leg bracket - section view — Glass Top Table – leg bracket – section view

The OpenSCAD code can produce a sectioned midline slice useful for laser-cut MDF pieces to check the angle:

Glass patio table - chunky bracket installed - bottom — Glass patio table – chunky bracket installed – bottom

That eliminated several bad ideas & misconceptions, although trying to balance the leg on a 3 mm MDF snippet was trickier than I expected. In retrospect, gluing a few snippets together would be easier and still faster than trying to print a similar section from the model.

The slightly elongated slot for the M5 screw shows that the original screw holes were not precisely placed or that the tubes were not precisely cut, neither of which come as a surprise. I finally built some slop into the design to eliminate the need for four different blocks keyed to four different legs.

The outer rim, the notch on the bottom, and the tab on the top curve to match the four foot OD glass tabletop, with the inward side & ends remaining flat:

Glass patio table - chunky bracket installed - top — Glass patio table – chunky bracket installed – top

The sector’s difference from a straight line amounts to half a millimeter and improved the fit enough to justify the geometric exercise. The bracket snaps into position with the notch over the table rim and the tab locked in the gap between the glass disk & the rim, although I suspect the weight of the tabletop would keep everything aligned anyway.

The walls are now at least 4 mm thick and, printed in PETG, came out strong enough to survive assembly and some gentle testing. They’re arranged to print on their side to eliminate support under those slight curves and to align the layers for best strength vertically in the finished bracket:

Glass Top Table - leg bracket - slicer preview — Glass Top Table – leg bracket – slicer preview

The leg cavity and screw hole built well enough without internal support.

They’re relentlessly rectangular and I’m not going to apologize one little bit.

Now to see how they survive out there on the screened porch.

The OpenSCAD source code as a GitHub Gist:

	// Glass patio table leg brackets
	// Ed Nisley – KE4ZNU
	// 2024-08

	/* [Layout] */

	Layout = "Show"; // [Section,Projection,Show,Build]

	Part = "Leg"; // [Leg, RimPlate, Block, Bracket]


	/* [Hidden] */

	ThreadWidth = 0.40;
	ThreadThick = 0.25;

	HoleWindage = 0.2;

	Protrusion = 0.1;

	//—–
	// Dimensions

	/* [Hidden] */

	GlassOD = 1230.0; // inner edge of upper tab
	GlassThick = 5.0;

	WallThick = 4.0;

	TOP = 0;
	BOT = 1;

	TabWidth = [3.0,3.0]; // locking tabs, top & bottom
	TabHeight = [0.5,3.0]; // … height

	LegOA = [16.0,36.5,23.0]; // X insertion, Y around glass, Z upward
	LegAngle = 10;

	ScrewOffset = [8.0,10.0]; // from socket bottom
	ScrewOD = 6.0; // clearance hole

	Plate = [1.0 + 2*max(TabWidth[TOP],TabWidth[BOT]),
	LegOA.y + 2*WallThick,
	25.5
	];
	echo(Plate=Plate);

	BlockOA = [LegOA.xcos(LegAngle) + (LegOA.z/2)sin(LegAngle) + WallThick,
	Plate.y,
	LegOA.z/cos(LegAngle) + 2LegOA.xsin(LegAngle) + 2*WallThick
	];
	echo(BlockOA=BlockOA);

	//—–
	// Useful routines

	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(r=(FixDia + HoleWindage)/2,
	h=Height,
	$fn=Sides);
	}


	//—–
	// Table Leg
	// Including screw slot
	// Additional length to allow use as difference

	module Leg() {

	union() {
	difference() {
	rotate([0,90,0])
	translate([0,0,-LegOA.x])
	linear_extrude(height=4*LegOA.x,convexity=5)
	hull()
	for (j=[-1,1])
	translate([0,j*(LegOA.y – LegOA.z)/2])
	circle(d=LegOA.z);
	rotate([0,-LegAngle,0])
	translate([-2*LegOA.x,0,0])
	cube(4*LegOA,center=true);
	}

	hull()
	for (c = ScrewOffset)
	translate([each c + (LegOA.z/2)*sin(LegAngle),0,-LegOA.z])
	//rotate(180/6)
	PolyCyl(ScrewOD,LegOA.z,6);
	}

	}

	// Rim Plate

	module RimPlate() {

	n = 1643;

	render(convexity=5)
	translate([-Plate.x,0,0])
	difference() {
	intersection() { // shape outer side to match table rim curve
	translate([0,-Plate.y/2,0])
	cube(Plate,center=false);
	translate([GlassOD/2 + TabWidth[TOP],0,0])
	cylinder(d=GlassOD + 2*TabWidth[TOP],h=Plate.z,center=false,$fn=n);
	}

	translate([GlassOD/2 + TabWidth[TOP],0,Plate.z – TabHeight[TOP]])
	cylinder(d=GlassOD,h=Plate.z,center=false,$fn=n);

	translate([GlassOD/2 + TabWidth[BOT],0,-(Plate.z – TabHeight[BOT])])
	difference() {
	cylinder(d=GlassOD,h=Plate.z,center=false,$fn=n);
	cylinder(d=GlassOD – 2*TabWidth[BOT],h=Plate.z,center=false,$fn=n);
	}
	}
	}

	// Block surrounding leg

	module Block() {

	intersection() {
	translate([BlockOA.x/2,0,0])
	cube(BlockOA,center=true);
	translate([0,0,BlockOA.x*sin(LegAngle) – BlockOA.z/2])
	rotate([0,LegAngle,0])
	translate([-2BlockOA.x,-2BlockOA.y,0])
	cube(4*BlockOA,center=false);
	}

	}

	// Complete bracket

	module Bracket() {

	difference() {
	union() {
	RimPlate();
	translate([0,0,Plate.z – BlockOA.z/2 – TabHeight[TOP] – 0*WallThick])
	Block();
	}
	translate([0,0,1Plate.z/2 – 1WallThick])
	rotate([0,LegAngle,0])
	translate([WallThick,0,0])
	Leg();
	}

	}

	//—–
	// Build things

	// Layouts for design & tweaking

	if (Layout == "Section")
	intersection() {
	Bracket();
	translate([0,BlockOA.y/2,0])
	cube([4BlockOA.x,BlockOA.y,3BlockOA.z],center=true);
	}

	if (Layout == "Projection")
	for (j = [1])
	translate([0,j2BlockOA.z])
	projection(cut=true)
	translate([0,0,j*5.0])
	rotate([90,0,0])
	Bracket();


	if (Layout == "Show")

	if (Part == "Leg")
	Leg();

	else if (Part == "RimPlate")
	RimPlate();

	else if (Part == "Bracket")
	Bracket();

	else if (Part == "Block")
	Block();


	// Build layouts for top-level parts

	if (Layout == "Build") {

	translate([0,0,Plate.y/2])
	rotate([90,0,0])
	Bracket();


	}