Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
While doodling about a bike taillight, I figured out the numbers for a 1 mH toroid on a ferrite FT50A-77 core. Even though I’m not going to use it, I may as well write it down so I remember what to do the next time around…
Those mixed units barely make sense and then only in the USA; using cm for the magnetic dimensions gives CGS results. In some parallel universe, this would not be an issue.
The path from KE4ZNU-9 (on my bike in Pleasant Valley) to KB2KUU-13 near Lafayette, NJ, spans a bit over 90 km / 55 miles, which isn’t bad for a 5 W (that’s optimistic) hand-held radio through a dual-band mobile antenna bolted to the seat frame with my head much too close to the base. The topography lay in my favor, though: Pleasant Valley sits near the top of the Wappingers Creek watershed (admittedly, barely 200 feet above sea level) and the valleys run southwest-to-northeast all along this part of the East Coast. The KB2KUU-13 antenna may be only 20 feet above average terrain, but that puts it 600 feet above sea level with a commanding view to the northeast.
Another packet sent a few minutes later took a much longer path to an APRS iGate:
KE4ZNU-9 APRS to WA2GUG-15 – Long Island – 2012-02-01
The first hop covered about 80 km / 50 miles to W2VER-15. That antenna is 320 feet above average terrain, but that’s with a 1400 foot base: a ridge near Hamburg Mountain. The next hop is about 20 miles to WB2FTZ-15, then 60 km / 40 miles across the plains and out to WA2GUG-15 near Hempstead on Long Island.
Normally, of course, a closer digipeater snags packets from my bike; most go through WA2YSM-15 or KC2DAA-2 to K2MHV-6 and probably don’t clog up the entire eastern seaboard. It’s hard to tell, though, because the APRS database records only the first successful capture of a given packet.
The whole bike ride looked like this:
KE4ZNU-9 trip – 2012-02-01
The APRS spots missed the sprint along West Road into Pleasant Valley, but you get the general idea: 22 miles, 15 mph average speed, temperature around 58 °F, a fine day for a ride!
Pondering the Reversal Zittage Bestiary led me to wonder about the formal relationship between pressure and flow in a viscous fluid passing through a nozzle. I’ll cheerfully admit my never-very-puissant fluid dynamics fu has become way rusty and, this being the first time I’ve collected all this stuff in one place, there’s certainly something I’m overlooking (to put it charitably), but here goes…
Assuming that (semi-)molten plastic:
Is an incompressible and highly viscous fluid, which means a very low Reynold’s Number
The hot end contains about 20 mm of molten filament, which is 140 mm3 of 3 mm filament. During filament swaps, the filament pushes back about 2 mm = 14 mm3 without any external force, so there’s about 10% springiness in the hot end. That suggests the plastic really isn’t incompressible. Some of the springiness may come from the PTFE tube expanding against the surrounding metal tube, but the fact that the (solidified) molten zone has a larger diameter than the rest of the filament says the PTFE expansion is not very dynamic: the filament solidified at zero pressure.
Boldly assuming incompressiblity anyway, the always-right-and-never-lies Wikipedia tells us that the equations of state boil down to the Stokes Equations, herewith directly cribbed:
That’s using this symbology, typographically modified to eliminate the need for embedded graphics:
∇2u = Laplacian of velocity (sharpness of pointiness)
μ = dynamic viscosity
f = applied force
Under the breathtakingly aggressive simplifying assumption that we can model slices across the extruder’s nozzle as nearly 2D radially symmetric pipes with a teeny frustum shape, we have a mostly one-dimensional situation:
The first equation says that axial pressure gradient is directly proportional to the applied force, which makes sense, plus a huge term due to the nozzle shape (how abruptly the velocity gradient changes)
The second equation is a generalization of GladOS‘s explanation of the conservation of momentum across Portal transfers: Speedy thing goes in, speedy thing comes out. For slightly conical slices, the axial speed increases as the radial area decreases, but the overall velocity gradient comes out zero.
All the force f comes from a stepper motor ramming filament into the hot end:
To a good first order approximation, stepper motor torque is proportional to winding current.
For a given filament diameter, drive wheel diameter, and speed, a constant-current stepper applies constant force to the filament.
Stepper power being roughly constant for a given current, the available force varies inversely with rotational speed.
Vigorous handwaving
The low Reynolds number says the inertial forces don’t amount to squat, so everything depends on viscous flow. There’s nothing to accelerate; try accelerating a spoon through honey.
Given a desired velocity u (mostly axial, for a particular extruding speed) and a nozzle, the first equation says the required force varies linearly with the pressure gradient ∇p. The gradient runs from atmospheric pressure on one end to the molten pool on the other, with the steepest change in the narrowest part of the nozzle. This suggests a short nozzle aperture is good.
Conversely, a long smooth nozzle reduces ∇2u by reducing abrupt velocity changes. For a given ∇p, the required force varies directly with the second (spatial) derivative of the velocity; lower velocity doesn’t mean lower force, but smoother changes (and their derivatives) certainly do.
During reversal, the extruder must produce a negative ∇p very quickly to inhale the filament and prevent drooling. Assuming ∇p has the same order of magnitude in both directions (thus, different signs), changing the fluid velocity will produce huge changes in ∇2u.
Fluid compressibility means that, during the early part of the reversal operation, moving the filament doesn’t change the pressure by very much at all: the first equation remains pretty much constant.
Caveats
The Stokes equations are time-invariant: the velocity is a constant. So we’re looking at the steady state and making dangerous assumptions about changing conditions.
The force variation seems linear with pressure gradient around a given flow, which is comforting: at least it’s not quadratic or something even more horrible.
Given the low Reynolds number, even moderate flow variations should be roughly linear, as the velocity gradients won’t change much with changing velocity.
This explains why Reversal Zittage gets so much worse at higher speeds: the extruder operates under constant (and, at least in my TOM, low) power that can keep pace with normal extrusion, but doesn’t have an order of magnitude more force in reserve for retraction.
Some years ago I picked up three different magnetic word assortments for the refrigerator, spread them out, and watched insights emerge as my Shop Assistant and I rearranged them. Now that she’s a Larval Engineer, their quantum states have collapsed and I can extract some Subconscious Wisdom…
Shredded flavor modification
For those of you following along through screen readers, the text is:
The thing omits the original’s fancy edge rounding, because I just hit the finger grips with a rat-tail file after it cooled:
HF bar clamp handle – build platform
The solid model uses OpenSCAD’s hull() operation for the beak and straight side of the handle, with a handful of circles chopping out the recesses. The rightmost arc lies tangent to the near side of the beak, so as to join without a stress-raiser bump:
HF Bar Clamp – support – solid model
The little yellow doodad is (a duplicate of) the support structure inside the pivot hole that prevents the middle section from drooping. It’s easier to see from the bottom:
HF Bar Clamp – solid model – bottom
Removing the plug required nothing more than a fat pin punch and a whack from a brass hammer, with the plug centered over a hole in a random chunk of aluminum (with many other holes):
HF bar clamp handle – support plug removed
Much to my delight, the holes & pivot recesses came out exactly the right size on the first version, with HoleWindage = 0.2. What’s new & different: that the first layer height has stabilized at 0.25 mm and the first few layers don’t get squished.
I built three more handles in one setup, just to have some show-n-tell objects, with one prepped and on hot standby should the other Harbor Freight handle break. If these handles break, something aluminum on the Sherline will be in order.
Now that clamp can go back into the collection. Puzzle: which one isn’t like the other ones?
Too many bar clamps
I should’a used Safety Orange filament, eh?
[Update: xylitol designed a much better looking version that should be a drop-in replacement. Perhaps you can print it standing on edge (or end) to eliminate the support structures?]
The OpenSCAD source code:
// Handle for Harbor Freight bar clamp
// Ed Nisley KE4ZNU - Jan 2012
Layout = "Show"; // Build Show
Support = true;
SupportColor = "Yellow";
//- Extrusion parameters must match reality!
// Print with +1 shells and 3 solid layers
// Use infill solidity = 0.5 or more...
ThreadThick = 0.25;
ThreadWidth = 2.0 * ThreadThick;
HoleWindage = 0.2;
Protrusion = 0.1; // make holes end cleanly
CircleSides = 4*8;
$fn = CircleSides;
//-------
// Handle dimensions
OALength = 49;
OAThickness = 6.0;
BodyWidth = 12;
BeakRadius = 12; // hole to tip
BeakEndRadius = 1.0; // roundness of tip
BeakIncludedAngle = 40;
BeakAngle = 55;
BeakAdder = [2.0,1.0]; // additional meat on outer and upper sides
BeakHalfWidth = IntegerMultiple(BeakRadius*sin(BeakIncludedAngle/2),ThreadWidth);
PivotXY = BeakRadius*[cos(BeakAngle),sin(BeakAngle)]; // pivot hole offset from beak tip
PivotShaftDia = 2.6;
PivotRecessDia = 5.0;
PivotRecessDepth = 2.5;
NumScallops = 3;
ScallopRadius = [5,9,9]; // first scallop must be tangent to beak!
ScallopX = [-((ScallopRadius[0] + BeakHalfWidth)*cos(90 - (BeakAngle - BeakIncludedAngle/2))),
-17.5,-31.5];
ScallopY = [-((ScallopRadius[0] + BeakHalfWidth)*sin(90 - (BeakAngle - BeakIncludedAngle/2))),
-12,-12];
echo(str("Scallops R=",ScallopRadius," X=",ScallopX," Y=",ScallopY));
TailOuterRadius = 12;
TailInnerRadius = 22;
//-------
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);
}
module ShowPegGrid(Space = 10.0,Size = 1.0) {
Range = floor(50 / Space);
for (x=[-Range:Range])
for (y=[-Range:Range])
translate([x*Space,y*Space,Size/2])
%cube(Size,center=true);
}
//-------
// Bits and pieces
module Pivot() {
translate([0,0,-Protrusion])
PolyCyl(PivotShaftDia,(OAThickness + 2*Protrusion));
translate([0,0,(OAThickness - PivotRecessDepth)])
PolyCyl(PivotRecessDia,(PivotRecessDepth + Protrusion));
translate([0,0,-Protrusion])
PolyCyl(PivotRecessDia,(PivotRecessDepth + Protrusion));
}
module HandleBlock() {
hull() { // beak
cylinder(r=BeakHalfWidth,h=OAThickness);
translate(BeakAdder)
cylinder(r=BeakHalfWidth,h=OAThickness);
translate([(PivotXY[0] - BeakEndRadius*cos(BeakAngle)),
-(PivotXY[1] - BeakEndRadius*sin(BeakAngle))])
cylinder(r=BeakEndRadius,h=OAThickness);
}
hull() { // straight body edge
translate(BeakAdder)
cylinder(r=BeakHalfWidth,h=OAThickness);
translate([-(OALength - PivotXY[0] - TailOuterRadius),BeakAdder[1]])
cylinder(r=BeakHalfWidth,h=OAThickness);
}
translate([ScallopX[0],0,0]) // scalloped edge tips
rotate(180)
cube([(OALength - PivotXY[0] + ScallopX[0] - TailOuterRadius),
(BodyWidth/2 - ThreadWidth), // small Finagle constant = flat tips
OAThickness],center=false);
translate([-(OALength - PivotXY[0] - TailOuterRadius), // tail
(BeakHalfWidth + BeakAdder[1] - TailOuterRadius)])
rotate(180)
intersection() {
cylinder(r=TailOuterRadius,h=OAThickness);
translate([0,-TailOuterRadius])
cube([TailOuterRadius,2*TailOuterRadius,OAThickness]);
}
}
module SupportPlug() {
color(SupportColor)
union() {
cylinder(r=IntegerMultiple((PivotRecessDia - ThreadWidth),ThreadWidth)/2,
h=2*ThreadThick);
for (Index=[0,1])
rotate(Index*90)
translate([0,0,(PivotRecessDepth - ThreadThick)/2])
cube([(PivotRecessDia - ThreadWidth - 2*Protrusion),
2*ThreadWidth,(PivotRecessDepth - ThreadThick)],
center=true);
}
}
//------
module Handle() {
difference() {
HandleBlock();
translate([-(OALength - PivotXY[0] - TailOuterRadius), // trim tail tip
-(PivotXY[1] - ThreadWidth),
-Protrusion])
rotate(180)
cube([TailOuterRadius,TailOuterRadius,(OAThickness + 2*Protrusion)]);
for (Index=[0:NumScallops-1]) {
translate([ScallopX[Index],ScallopY[Index],-Protrusion])
cylinder(r=ScallopRadius[Index],h=(OAThickness + 2*Protrusion));
}
Pivot();
}
if (Support) // choose support to suit printing orientation
SupportPlug();
}
//-------
ShowPegGrid();
if (Layout == "Show") {
translate([OALength/3,10,0])
Handle();
translate([10,0,0])
SupportPlug();
}
if (Layout == "Build")
translate([OALength/3,0,0])
Handle();
The original doodles, which I started by scanning an unbroken handle and overlaying a grid, then scaling the grid so the end-to-end measurement worked out to the proper number of millimeters:
All of the corresponding Flow rates have the same values, which seems to be the right way to go. In Skeinforge 45, these are all collected in the Speed plugin.
The very slow first layer ensures good adhesion to the Kapton build surface, with the rebuilt HBP now maintaining a very stable 0.25 mm across the whole platform. I’ll try goosing the first layer infill to 20 mm/s and the perimeter to 15 mm/s at some point, but this is entirely tolerable; I’d rather have it Just Work than occasionally come unstuck.
The 20 mm/s perimeter reduces the Extruder Zittage problem, with the 9 mm/s Perimeter on the first layer coming out entirely zit-free. However, the sequential version of Amdahl’s Law applies here: a slow perimeter around a fast infill produces a fairly slow overall layer. Making the infill rather sparse doesn’t help, of course, but overall it’s a win.
This collection of speeds hopelessly confuses Pronterface’s estimated print time calculation; the most amazing prediction reported just under 24 hours for a fairly simple set of objects that took maybe half an hour. A recent gizmo had an estimated time of 4:34 and an actual time of 28:07, off by a factor of 6.2. If Pronterface divides the total filament length by the first speed it finds in the file, it’d be off by a factor of 6.7, so maybe that’s close to what happens under the covers.
Not all CFL bulbs fail after a year. This one seems to have lasted six years, only to burn out a few days after the other one:
Burned-out CFL bulb
I’m sure the date code just over the base means January 2006, not June 2001, simply because I used much larger bulbs a decade ago. Those have long since failed…
These bulbs all operate in nearly the worst possible condition: base-up inside a ceiling downlight can, although without a cover glass. It’s much cooler in there than with the equivalent incandescent bulb, but they still get pretty toasty. The housing discoloration and the brittle bosses around the tube glass looks a bit less saturated in real life, but this will give you an idea:
The Smell of Molten Projects in the Morning 