Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
After butchering that fancy Tektronix test lead thing for the SMD tweezers, I hung the bitter end in my cable tangle. Turns out I needed a power cord to bring up the brassboard of the Wouxun GPS interface, so I soldered it up, went to plug it in, and … the Tek plugs didn’t fit the plated supply jacks.
Power Supply Banana Jacks
Now, if I had to choose whether Tek plugs are oversized or Made In China jacks are undersized, well, you can probably guess my answer.
Turns out that the jacks should be 4 mm ID, which is actually a 5/32 hard-inch size because banana jacks date back to the days before millimeters became a force to be reckoned with. They were actually 3.8 mm ID, which wouldn’t usually matter except for the fact that the Tek plugs have a nice solid bullet end that’s just about exactly 4 mm OD.
So I chucked up a 5/32 inch drill, perched the power supply on a block of wood (to clear the fuse & cord in on the back panel) on the drill press table, and hand-held it while clearing out the holes with a low spindle speed. You can see the nice, shiny brass inside those jacks in the photo; they used to have lumpy silvery plating inside that was probably responsible for much of the 0.2 mm shrinkage.
The jacks also don’t have the usual crosswise hole near the base to accept a bare wire, which is an occasional nuisance. I was tempted to drill that hole, but decided I’ll leave that project for another time.
Having printed up three of those handles for Show-n-Tell, I preemptively installed one in the hasn’t-failed-yet clamp, and poked the support out of another to show how it works. They’re just the cutest little buttons:
HF bar clamp handle – support plug
The fins are a touch under 4.5 mm end-to-end and 1 mm (2 × 0.5 mm) across, with layer thickness = 0.25 mm. The first layer fill looks a bit lackadaisical, but the bottom of the surrounding handle came out glass-solid with barely visible joints between the threads, so the settings work fine for larger objects.
HF Bar Clamp – support – solid model
The tip of each fin has a scar where the overlying perimeter thread bonded to it. Skeinforge is set to extrude the perimeter first, which would squirt that circle (well, pentagon) into mid-air… which is why this support plug lies in wait below.
Mary made me several presents early this year: a new belt pack, a camera case for the Canon SX230HS, and a touchup for the Zire 71 case:
Belt pack – camera case – PDA case
The belt pack has an interior lining with many side pockets for the stuff I deem essential; it’s also large enough to hold both the camera and the PDA when I’m out biking around. The camera case includes a pocket nestling a battery against the camera’s front side, beside the lens cap. The Zire case, well, at some point I suppose I’ll be forced to get a phone, but, until then, this will suffice.
They’re all made from coated pack cloth, not that I expect to dunk myself in water (or that it’d do any good), but it seems to never wear out.
*hugs*
(And, yes, it probably should be “Therefor”, but …)
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.
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.
The Skeinforge Dimension plugin subsumes the obsolete Reversal plugin’s features. At the end of each thread, if the nozzle will move more than the Minimum Travel distance (1 mm by default, which is what I’m using) to the start of the next thread, the extruder yanks Retraction Distance of filament out of the hot end at the Retraction Speed.
Some experimentation at 30 mm/s showed that 2 mm of filament would eliminate all drooling, 1.5 mm left thin threads, and 1.0 mm wasn’t nearly enough.
Similar experimentation suggested 60 mm/s as the upper limit for Retraction Speed, with the SJFW acceleration limiting parameters set for 250 mm/s2. The usual extrusion speed isn’t much faster than a crawl, so the distance required to reach a backwards 60 mm/s is:
dist = (60 mm/s)2 / (2 * 250 mm/s2) = 7.2 mm
What that means, of course, is that the extruder doesn’t have enough torque to reach the programmed speed in the required distance. Assuming SJFW uses trapezoidal limiting, it will accelerate to some maximum speed at the halfway point and decelerate to a stop at the same rate. Pegging the midpoint at 1 mm, the extruder will reach a peak speed of:
v = √(2 * 250 mm/s2 * 1 mm) = 22 mm/s
In order to hit 60 mm/s in the middle of the retraction, the extruder must accelerate at:
a = (60 mm/s)2 / (2 * 1 mm) = 1800 mm/s2
Which requires way more torque than the piddly little motor I’m using can provide.
While I could swap in that larger motor, crank the current up a bit, and goose the extruder acceleration, the current Reversal Zittage is small enough for my purposes. I’d rather expend that effort on doodling up a direct-drive extruder, but that’s on the back burner until something horrible happens to the current extruder.
One easy alternative: lower the perimeter speed sufficiently far as to reduce the pressure in the hot end enough that the current speeds can suppress the zits. Notice the difference in the pix below; what you can’t see is that the first layer has no zittage whatsoever. Of course, that means the perimeter must trundle along at maybe 10 mm/s…
Herewith, a Reversal Zittage bestiary at various perimeter speeds, with Dimension set as described above and these extrusion settings:
The Smell of Molten Projects in the Morning 