Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
Here’s a howling 1200 Hz mechanical resonance excited by a full-step drive at 290 rpm, with the resonance running at 5 cycles for every 4 full steps.:
1 Step Res 240 Hz
[Update: top trace is voltage from big stepper-as-generator, bottom is small stepper winding current = 1 A/div.]
Switching to 1/2 microstepping at the same rotational speed pretty well tamps it down:
Half Step Res 240 Hz
However, here’s the same resonance excited by 1/2 microstepping at half the rotational speed, oscillating at 9 irregular cycles for every 8 half-steps:
Half res 120 Hz
The resonance was strong enough to back the setscrew completely out of the generator end of the shaft, leaving me wondering why the output was dead when the motor was obviously running. Yes, several times…
Conventional wisdom has it that stepper motor torque decreases as the number of microsteps per full step increases. One reasonably careful measurement trumps a kilo-opinion, so here’s a chart (clicky for bigger) of measurements to mull over:
Microstepping Mode vs Speed – 17PM-J034
Each group of like-colored dots marks the results for full, 1/2, 1/4, 1/8, and 1/16 microstepping with the same load resistance. The caret marks the full-step data point within each group. The load resistances range from a dead short (about 1 Ω due to winding resistance) on the left to 50 Ω on the right.
While I’ll grant the existence of the occasional data-collection error, it’s pretty obvious that:
Torque is reasonably constant regardless of microstepping mode
Full-step mode doesn’t produce more torque and, indeed, produces considerably less under heavy loads
Now, one can argue that the A4988 doesn’t operate in real full-step mode, because it energizes both windings at 1/√2 of the maximum current setting for each full step rather than energizing a single winding at the maximum current. That may be true, but conventional wisdom seems to not bother with such details when opining about torque, either…
As nearly as I can tell, 1/8 microstepping gives as much torque as you’re likely to get from the motor, while having reasonably smooth motion that avoids exciting mechanical resonances.
That chart (or one remarkably like it) will appear in an upcoming Circuit Cellar column. The tonnage of data supporting those dots suggests building an automated dynamometer would be a Good Idea …
Just to see what happened, I reversed the stepper dynamometer and drove the larger (480-ish mN·m) stepper in 1/8 step mode while recording the short-circuit current from the smaller (anonymous) stepper. Slowly cranking the step frequency upward produced this trace when the stepper stalled:
48 mm motor – pullout – 30 rps
The bottom trace shows 30.4 rev/s = 191 rad/s = 1824 rev/min: a pretty good speed for a loaded stepper! The rotor began slowing just before the last sync pulse, but hadn’t lost any appreciable speed.
The current scale is 0.5 A/div (set on the Tek probe amp), which makes the winding current (500 mA/div × 10.4 mVpk / 10 mV/div) = 520 mApk. The scope’s computed rms value includes the waveform after the stall, which isn’t helpful.
The small stepper has a 2.1 Ω winding resistance, so a short-circuit load dissipates (0.52 A)2 × 2.1 Ω = 567 mWpk in each winding. The rms equivalent is half of that, so the total rms power is about half a watt, essentially all internal to the motor.
The pull-out torque depends on the peak torque load, not the rms and not the sum of the two windings, so it’s 0.6 W / (191 rad/s) = 3 mN·m, which doesn’t sound a lot for a 480 mN·m motor until you consider the screaming 6000 full step/s speed: pretty much off-scale high on most of the torque-vs-speed graphs you’ll see. Not much torque left out at that end of the curve, indeed.
In order to stall the motor at lower speeds, the load stepper must generate enough voltage into the load resistor (here, the winding resistance) to push the power/speed ratio (the torque!) above the drive motor’s ability. That implies the load stepper must always be larger than the drive stepper, which means I must conjure up a bracket for that NEMA 23 motor that’s been holding down a stack of papers on my desk…
Incidentally, the voltage required to produce that load current is 0.52 mA × 2.1 Ω = 1.1 V. The 0.58 v/(rev/s) open-circuit generator constant for the smaller motor predicts 0.58 v/rev/s × 30.4 rev/s = 17.7 V. Obviously, you can’t get from the open-circuit unloaded generator constant to the short-circuit loaded voltage… Lenz’s Law gets in the way.
Having acquired a bunch of cheap batteries from the usual eBay suppliers for my new Canon SX230HS pocket camera, it’d be nice to measure their actual (and undoubtedly pathetic) capacity, which implies the need for a holder to make firm contact with the terminals. Sounds like a 3D printer might come in handy for that, doesn’t it?
The first step: measure the dimensions of actual batteries:
NB-5L Battery Dimensions
The terminals lie on what looks to be hard 1/8 inch centers, which must be pure coincidence. They’re recessed anywhere from 0.75 mm to 1.0 mm, depending on who made the thing, into the battery’s endplate.
The Canon charger has three spring-loaded bent-wire contacts, arranged so the (-) terminal touches first as the battery slides into the holder, then (+), and finally the thermistor (T), with about 0.5 mm between each pair. That spring loading provides enough force to hold the battery in the charger.
FWIW, the thermistor is 7.5 kΩ w.r.t. (-) at room temperature.
The plan so far: use three big old gold-plated terminal pins as contacts, with flexible wires to a PowerPole connector that matches the battery tester. Cross-drill the pins to fit music wire lever springs, because the contact spacing is smaller than the smallest coil springs in the Big Box o’ Little Springs. I only need two terminals, so maybe I can force-fit a pair of small coil springs in there, which would be nice.
For Tux pix, one should start with Larry Ewing’s drawings; I used the EPS version to get a scalable vector drawing. Run it through The GIMP, close the outline at the flippers, fill with black, save as PNG. Then import into Inkscape, trace the outline, and something like this pops out:
Tux Outline
The reason for using Inkscape is that OpenSCAD imports a very limited subset of all possible DXF files and, while Inkscape can (with some care) produce a DXF format that OpenSCAD can import, somehow the shape lacked interior fill. Sean took a slightly different approach with the same tools and managed to create a useful DXF file that produced this chunk o’ bits:
Tux Slab – solid model
The DXF import still didn’t work dependably, so I exported the Tux Slab from OpenSCAD to an STL file; if you want to extrude a solid Tux, that’s probably the way to go. Importing the STL in the next steps worked fine.
The Parametric Cookie Cutter by nateoostendorp creates thin cutter walls by subtracting a linear dimension from the X- and Y-axis extents of the shape. Unfortunately, Tux has crazy flipper feet that didn’t respond well to that; the walls developed gaps at the inflection points from self-intersections.
So I started from scratch with a Minkowski sum, which in this case amounts to rubbing a cylinder all over the Tux shape, then intersecting the resulting mega-penguin-post with a slab of the appropriate thickness sitting on the Z=0 plane. The Minkowski enlarges the XY outline by the cylinder’s radius and the Z thickness by twice the cylinder’s height, which I picked to be grossly excessive. Three Minkowskis produce the lip, wall, and tip of the cutter, which then stack up with a Tux-shaped hole subtracted from their midst:
Tux Cookie Cutter – solid model
The thicknesses and heights all derive directly from the extrusion parameters used to print the thing, because there’s not much room for roundoff. The middle section (the wall) is four threads wide, but Skeinforge divides the interior pair of threads into shorter sections with breakpoints at each sharp corner. The cutter section (the lip) is one thread wide, because I couldn’t get a good result with two threads.
The OpenSCAD preview has trouble with the Minkowski result and produces weird rendering glitches, but the CGAL model comes through fine. Note that Tux now has the opposite chirality, a gross oversight that became obvious only after the third cutter emerged from the Basement Laboratory. Here’s the second cutter:
Tux Cutter – reversed
Each cutter takes about 35 minutes to build, so I boiled the highlights down into a thrilling 6 minute movie.
The OpenSCAD source code, into which you can substitute your very own STL shape file:
// Tux cookie cutter using Minkowski sum
// Ed Nisley KE4ZNU - Sept 2011
//- Extrusion parameters - must match reality!
ThreadThick = 0.33;
ThreadWidth = 2.0 * ThreadThick;
function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
MaxSize = 110; // larger than any possible dimension ...
//- Cookie cutter parameters
Size = 100;
TipHeight = IntegerMultiple(8,ThreadThick);
TipThick = 1*ThreadWidth;
WallHeight = IntegerMultiple(7,ThreadThick);
WallThick = 4*ThreadWidth;
LipHeight = IntegerMultiple(1.5,ThreadWidth);
LipThick = IntegerMultiple(5,ThreadWidth);
//- Wrapper for the shape of your choice
module Shape(Size) {
Tux(Size);
}
//- A solid slab of Tux goodness in simple STL format
// Choose magic values to:
// center it in XY
// reversed across Y axis (prints with handle on bottom)
// bottom on Z=0
// make it MaxSize from head to feet
module Tux(Scale) {
STLscale = 250;
scale(Scale/STLscale)
translate([105,-145,0])
scale([-1,1,24])
import_stl(
file = "/mnt/bulkdata/Project Files/Thing-O-Matic/Tux Cookie Cutter/Tux Plate.stl",
convexity=5);
}
//- Given a Shape(), return enlarged slab of given thickness
module EnlargeSlab(Scale, WallThick, SlabThick) {
intersection() {
translate([0,0,SlabThick/2])
cube([MaxSize,MaxSize,SlabThick],center=true);
minkowski() {
Shape(Scale);
cylinder(r=WallThick,h=MaxSize);
}
}
}
//- Put peg grid on build surface
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);
}
//- Build it
ShowPegGrid();
//cube(5);
difference() {
union() {
translate([0,0,(WallHeight + LipHeight)])
EnlargeSlab(Size,TipThick,TipHeight);
translate([0,0,LipHeight])
EnlargeSlab(Size,WallThick,WallHeight);
EnlargeSlab(Size,LipThick,LipHeight);
}
Shape(Size); // punch out cookie hole
}
The wheel fits the shaft with a 4-40 setscrew to hold it in place. The post has 4-40 mounting holes for one of those optical switches, plus a big hole for the wiring. The solid models look about like you’d expect:
Wheel and post solid model
I located the post’s holes on the baseplate with a spindly pair of transfer punches, after transferring the wheel’s centerline by eyeballometric guesstimation:
Locating holes with transfer punches
Then aligned the baseplate on the Sherline, located the holes, and drilled ’em with manual CNC to get the proper spacing:
Drilling opto switch post holes
And then it went together quite smoothly:
Dyno with sync wheel
What’s really nice about 3D printing is you can build stuff like this without too much fuss & bother: figure out the solid model, walk gingerly through the software minefield, and (usually) assemble the parts later that day.
A bit of wiring to power the LED and pull up the phototransistor should do the trick.
The OpenSCAD code, including a few tweaks that rationalize spacings and sizes and suchlike:
I’d waited for a few days for the silicone to cure, then put the clamps back in their home. When I went to use them, the pads were firmly affixed to the plate. Evidently, the copper-loaded silicone gasket compound takes a few days longer than forever to cure, which is not what I gathered from reading the label.
It may well be that adhesive has aged out, because when I went to try it again, the first half-inch inside the tube had turned into solid gum. Yes, it cures inside the tube and not outside.
Other than that, it seems like good stuff; I may pick up another tube and give it a second chance. Who knows? It might be useful in a plastic extruder or something like that.