The Smell of Molten Projects in the Morning
Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
If you measure something often enough, it becomes science
Mary found the wrench I made five years ago in the bottom of her tool bucket:
Having moved away from the garden with all the valves that wrench turned, it can now go into the 3D Printed Sample Box for use in the unlikely event I ever give another talk on the subject.
I’d design it differently these days, what with BOSL2 in my sails, but it got the job done.
Some things last long enough!
A critter made off with our battered plastic rain gauge, so I set up an Ambient Weather WS-5000 station to tell Mary how much rain her garden was getting. I added the Official Bird Spike Ring around the rain gauge to keep birds off, but robins began perching atop the anemometer while surveying the yard and crapping on the insolation photocell.
After a few false starts, the anemometer now has its own spikes:
It’s a snugly fitting TPU ring:
The spikes are Chromel A themocouple wire, because a spool of the stuff didn’t scamper out of the way when I opened the Big Box o’ Specialty Wire. As you can tell from the picture, it’s very stiff (which is good for spikes) and hard to straighten (which is bad for looking cool).
The shape in the middle is a hole diameter test piece. Next time around, I’ll use thicker 14 AWG copper wire:
The test piece showed I lack good control over the TPU extrusion parameters on the Makergear M2, as holes smaller than about 2 mm vanish, even though the block’s outside dimensions are spot on. This application wasn’t too critical, so I sharpened the wire ends and stabbed them into the middle of the perimeter threads encircling the hole.
Now we’ll discover how TPU survives weather.
The OpenSCAD source code as a GitHub Gist:
| // Ambient Weather – Ambient Weather WS-5000 anemometer bird spike ring | |
| // Ed Nisley – KE4ZNU | |
| // 2025-06-09 | |
| include <BOSL2/std.scad> | |
| Layout = "Show"; // [Show,Build,Slice] | |
| /* [Hidden] */ | |
| HoleWindage = 0.2; | |
| Protrusion = 0.1; | |
| ID = 0; | |
| OD = 1; | |
| LENGTH = 2; | |
| SpikeOC = 30.0; // straight-line distance between spikes, OEM = 35 | |
| WallThick = 4.0; | |
| BandID = 3.5*INCH – 0.5; // = OD of weather station | |
| BandOD = BandID + 2*WallThick; | |
| BandHeight = 8.0; | |
| SpikeOD = 1.7 + HoleWindage; // wire diameter | |
| SpikeWall = 2.0; // around wires | |
| SpikeBCD = BandOD; | |
| MountOD = SpikeOD + 2*SpikeWall; | |
| NumSpikes = ceil(PI*BandOD/SpikeOC); // need integral number of spikes | |
| SpikeAngle = 360/NumSpikes; | |
| NumSides = 3*NumSpikes; | |
| echo(SpikeAngle=SpikeAngle); | |
| echo(NumSpikes=NumSpikes); | |
| //———- | |
| // Define Shapes | |
| module Slice() { | |
| difference() { | |
| hull() { | |
| pie_slice(h=BandHeight,d=BandOD,$fn=NumSides,ang=SpikeAngle,spin=-SpikeAngle/2,anchor=BOTTOM); | |
| right(SpikeBCD/2 – MountOD/2) | |
| cyl(h=BandHeight,d=MountOD,realign=true,anchor=LEFT+BOTTOM,$fn=2*6); | |
| } | |
| down(Protrusion) { | |
| cyl(h=BandHeight + 2*Protrusion,d=BandID,$fn=NumSides,circum=true,realign=true,anchor=BOTTOM); | |
| right(SpikeBCD/2) | |
| cyl(h=BandHeight + 2*Protrusion,d=SpikeOD,$fn=6,circum=true,realign=true,anchor=BOTTOM); | |
| } | |
| } | |
| } | |
| module SpikeRing() { | |
| for (i=[0:NumSpikes-1]) | |
| zrot(i*SpikeAngle) | |
| Slice(); | |
| } | |
| //———- | |
| // Build things | |
| if (Layout == "Slice") { | |
| Slice(); | |
| } | |
| if (Layout == "Show") { | |
| left(SpikeBCD/2) | |
| Slice(); | |
| SpikeRing(); | |
| } | |
| if (Layout == "Build") { | |
| SpikeRing(); | |
| } |
With the humidity inside the PolyDryer boxes being roughly proportional to the amount of filament on the spool, I printed a slightly modified airlock plate and a TPU seal ring, then stuck a tiny fan on it:
It just barely clears the curved air guide inside:
The tea bags full of desiccant allow some wind between them and the filament in the spool, but I obviously must re-think that setup. There’s enough clearance for what should be reasonable circulation, so i defined it to be good enough for now.
The box of TPU started at 25 %RH, dropped to 22 %RH overnight, then returned to 25 %RH the next day:
Now that I’m watching more often, I’ve seen the meter glitch to 10% for a few seconds:
A humidity indicator card suggests the air is under 20 %RH:
It may be the filament can outgas water vapor as rapidly as the desiccant can remove it, but I expected the fan to make at least a little difference.
I have no idea what’s going on in those boxes.
The Basement Shop has 50±5% relative humidity, with the top held down by a hulking dehumidifier (plus a box fan stirring the air) and the bottom supported by being a basement. As a result, the 3D printer filament stabilized at about 50% RH, which seemed to work well enough for PETG.
Adding TPU to the stable called for better humidity control, so I set up a bunch of PolyMaker PolyDryer boxes with Auto-rewind spindles.
After a few weeks, though, I didn’t expect this:
That’s activated alumina desiccant, mostly because it’s reputed to have more capacity and a lower ultimate humidity than silica gel, but it likely doesn’t make much difference.
In addition to 25 g of desiccant in the PolyDryer meter case, I dropped five teabags holding 10 g each in the bottom of the box for more capacity. I measure the desiccant by putting 75.0 g into a cup, putting 25.0 g in the PolyDryer meter box (aided by a Polydryer Desiccant Funnel), 10.0 g into four teabags, and whatever’s left into the fifth teabag, thus eliminating rounding errors in the smaller quantities.
The stabilized humidity inside the boxes seems to depend on the amount of filament on the spool:
I think the humidity level comes from the filament outgassing water vapor through its (limited) surface area on the outer layer around the spool. The difference between that rate and the desiccant’s ability to remove water vapor from the (unmoving) air in the box sets the stable humidity: more surface area → more water vapor → higher humidity.
After the filament eventually dries out, the humidity should decrease, but diffusion is a slow process. More likely, the humidity will remain stable as the printer pulls filament from the outer layer and exposes the somewhat wetter plastic within.
The heater and fan inside the PolyDryer base unit circulates hot air through the box around the spool, but depends on the desiccant to remove water vapor. Running the base unit for 6 or 12 hours makes little difference in the stabilized humidity, so I think the desiccant is doing the best it can as the filament outgasses more water vapor.
Using Air Exchanger vents seems to make no difference, likely because the desiccant must then pull more water vapor out of the incoming 50% RH basement air. A psychrometric chart says 50% RH air at 60 °F becomes 10% RH air at 120 °F, but moisture in the filament wrapped around the spool can’t escape any faster.
So, for example, a full spool of TPU starting at 25% RH:
Six hours of drying pulls it down to 22%:
After sitting overnight it’s back at 25%:
Admittedly, that was with the vents in place, but the closed box started at 25% RH after sitting around for a week or so following a similar drying cycle.
The desiccant had absorbed 4 g of water since I put it in, so it hasn’t been entirely idle.
Which suggests 75 g of activated alumina desiccant is workin’ hard and doin’ swell in there, with the filament acting as an essentially infinite reservoir of water vapor.
I haven’t noticed any particular difference in PETG print quality and the TPU hasn’t gotten enough mileage to notice much trouble, but reducing the MMU3 buffer clutter was totally worth the effort.
After about 7.5 years (!) the 64 GB card in my Sony HDR-AS30V helmet camera breathed its last:
Over the course of several rides I noticed many video files ended prematurely or would not play. I gave up attempting to reformat the card in overwrite mode using the Official SD Card formatter after four hours, which says the wear leveler in the card has no spare capacity.
In round numbers, I ride 1700 miles a year at 12 mph, so the card recorded 1000 hours of 1920×1080 video at 60 frame/s, storing one 4.3 GB file every 22.75 minutes for a grand total of 12 TB of data.
Although that’s 188 times the capacity of the card, it rarely held more than an hour or two of data at any one time, because I copy the camera video files to a 3 TB USB hard drive after each ride. I don’t know how the exFAT file system interacts with the card’s wear leveling, but overall it’s much better than the non-high-endurance cards I’d been using way back when.
A new Sandisk 128 GB High Endurance card cost a third of what the 64 GB card did and, after setting the partition label to AS30V, it’s off to a good start:
That’s the street lamp pole installed on the replaced base at the corner of Rt 376 and Rombout House Lane, with the barrels gradually being pushed closer and closer to the pole by turning traffic on the newly paved lane.
That pole is not going to see the end of this year.
Update: The barrels vanished this morning:
Definitely the triumph of hope over experience.
Continuing the experiments on Y axis wobbling produced this shaky engraving:
The rectangle is 30×10 mm, with lines spaced 0.25 mm apart to simplify estimating distances (although I also have a measuring magnifier) and run at 100 mm/s to simplify converting distance to time. The lines alternate in direction, beginning with a left-to-right line at the bottom (which is bar-straight from the initial positioning move). The wobbles occur at the start of each line.
A closer look with blown contrast:
The maximum error in the Y axis direction looks like 0.12 mm and damps out after 3 cycles. Each cycle covers 2.8 mm = 28 ms = 35 Hz.
The LightBurn Preview shows a 1.5 mm overscan distance and extrapolating the wobbulations leftward suggests the gantry starts the scan line with an overshoot due to the Y axis motion. The cycle-to-cycle damping is about 50%, so the initial overshoot (invisible in the overscan region) might be 0.25 mm, agreeing reasonably well with the 0.2 mm seen while cutting small squares.
The results above come from these settings:
I then made single-variable changes to the Engraving Parameters settings:
Line shift speed
Y Acceleration
Y start speed
Today I Learned: The Y Start Speed (in mm/s) for engraving is capped by the Y Axis Jumpoff Speed (in mm/s², so perhaps the maximum change in speed), which is, in turn, capped at 80 mm/s.
Each of the variations produced a result visually indistinguishable from the image you see above: the error magnitude and oscillation frequency were identical.
One possible reason: None of those settings have any effect, because LightBurn doesn’t do whatever the Ruida controller defines as Engraving. However, changing both the Y start speed and the Jumpoff speed should have made at least a little change to the results and did not.
Another possible reason: Each 0.25 mm Y axis change requires 20.8 motor steps (either 20 or 21 at 12 µm/step), so the fancy tweaks lack space to take effect, the motor thumps 20-ish steps, and the gantry shakes the same way every time.
The closer you look, the worse it gets …
Experimenting with little squares showed the Y axis has a definite wobble:
Which suggested a simple test:
I adjusted the laser power to compensate for the speed, with the result being a line burned into white cardboard. The lines are a bit under 0.2 mm wide, roughly the width of the focused spot.
The controller settings for the X and Y axes:
The acceleration values may be affected by the limits in this section:
Assuming the Y axis acceleration is 3000 mm/s², the RepRap calculator shows the Y axis speeds within the 30 mm distance along the vertical sides:
Extracting the useful bits and lining them up for comparison:
The first column in the test results shows perfectly square corners have no problem at any speed, because the controller decelerates to nearly a stop before changing direction.
Rounding the corner to 0.5 mm introduces a distinct wobble in the Y axis that doesn’t change much, probably because the controller still decelerates as it approaches the corner.
The 1 mm radius corners show a distinct overshoot at all speeds. The peak overshoot doesn’t change much between 250 and 500 mm/s, because the RepRap calculator shows the machine barely reaches 250 mm/s by the middle of the side, so 500 mm/s isn’t any faster.
The first overshoot is about 0.2 mm, the first undershoot is a little over 0.1 mm, and the rest are barely visible.
The 2 and 4 mm radius corners have barely visible wobbles. Whether that is due to the head not flexing as much due to the lower acceleration around the larger radius I cannot say.
The machine may not follow the simple RepRap acceleration profile when approaching a corner, let alone a rounded corner.
I think attempting to reduce the overshoot by fiddling with the belt tension / hardware fasteners / whatever will be unavailing. The laser head runs on a linear rail along the gantry with plenty of unbalanced mass hanging off the bottom:
Moving the beam 0.2 mm on the platform by pivoting around the rail 6 inch = 150 mm above amounts to only 0.08°, far less than anything I can measure while adjusting the mechanics.
Slowing down doesn’t help nearly as much as I expected and rounding the corners makes it worse.
Word has it that much spendier machines behave better, which is both comforting and unhelpful.
The Smell of Molten Projects in the Morning 