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.

Category: Software

General-purpose computers doing something specific

  • Monthly Science: Springtime Ground Temperatures

    The last month’s ground temperatures:

    Temperatures - Garden Patio Water
    Temperatures – Garden Patio Water

    The “Garden” trace comes from a waterproof Hobo datalogger buried a few inches underground, beneath a thick layer of chipped leaf mulch. The “Patio” trace comes from the center of the cramped space below the concrete patio, buried flush with the bare dirt floor. The “Water” trace is the temperature at the incoming water pipe from the town water main, which passes 150 feet under the front yard.

    Calculated eyeballometrically, the temperature rose 7 °F in about a month.

    The datalogger in the garden came from the “cold cellar” veggie storage buckets, so I don’t have a year-long record. On the other paw, it looks like the patio temperature will be a pretty good proxy for the minimum garden temperature.

    I hand-cleaned the Hobo CSV files and fed the results into a Gnuplot script that’s replete with the cruft of ages:

    #!/bin/sh
    #-- overhead
    export GDFONTPATH="/usr/share/fonts/truetype/"
    ofile=Temperatures.png
    echo Output file: ${ofile}
    #-- do it
    gnuplot << EOF
    #set term x11
    set term png font "arialbd.ttf" 18 size 950,600
    set output "${ofile}"
    set title "Ground Temperatures"
    set key noautotitles right center
    unset mouse
    set bmargin 4
    set grid xtics ytics
    set timefmt "%m/%d/%Y %H:%M:%S"
    set xdata time
    set xlabel "Date"
    set format x "%Y-%m-%d"
    set xrange [:"07/15/2014"]
    set xtics font "arial,12"
    #set mxtics 2
    #set logscale y
    #set ytics nomirror autofreq
    set ylabel "Temperature - F"
    #set format y "%4.0f"
    #set yrange [30:90]
    #set mytics 2
    #set y2label "right side variable"
    #set y2tics nomirror autofreq 2
    #set format y2 "%3.0f"
    #set y2range [0:200]
    #set y2tics 32
    #set rmargin 9
    set datafile separator ","
    #set label 1 "Garden"     at "05/31/2014",25 left font "arialbd,10" tc lt 3
    #set arrow from 2.100,110 to 2.105,103 lt 1 lw 2 lc 0
    plot	\
        "Garden.csv" using 2:3 with lines lt 3 lw 1 title "Garden",\
        "Patio.csv"  using 2:3 with lines lt 2 lw 1 title "Patio",\
        "Water.csv"  using 2:5 with lines lt 4 lw 1 title "Water",\
    
    EOF
    
  • Kenmore 158: NEMA 23 Motor Adapter

    After removing the AC motor from the sewing machine, I wondered if a NEMA 23 stepper motor would fit:

    Kenmore 158 - NEMA 23 stepper - trial fit
    Kenmore 158 – NEMA 23 stepper – trial fit

    Huh. Who’d’a thunk it? That’s just too good to pass up…

    Although you wouldn’t use PLA for the real motor mount, this was easy:

    Drive Motor Mount - solid model
    Drive Motor Mount – solid model

    And the whole affair fits pretty much like you’d expect:

    Kenmore 158 - NEMA 23 stepper - on adapter
    Kenmore 158 – NEMA 23 stepper – on adapter

    The NEMA 23 motor doesn’t have the same end profile as the AC motor and the adapter plate gets in the way of the pulley, but flipping the pulley end-for-end perfectly aligned the belt.

    For whatever it’s worth, here’s how I removed the pressed-on gear from the shaft:

    NEMA 23 Stepper - removing gear
    NEMA 23 Stepper – removing gear

    I’m pretty sure I have a little gear puller somewhere, but it’s not where I expected to find it, which means it could be anywhere.

    Much to my astonishment, the shafts on both motors are exactly 1/4″ inch. I filed a flat on the shaft to avoid having the setscrew goober the poor thing.

    A stepper isn’t the right hammer for this job, because it can’t possibly reach 8000 rpm, but it’ll be good enough to explore the parameter space and weed out the truly stupid mistakes. A brushless DC motor from halfway around the planet would fit in the same spot.

    The OpenSCAD source code:

    // NEMA 23 Stepper Mounting Plate
    // Ed Nisley - KE4ZNU - June 2014
    
    Layout = "Build";			// Build Show 
    
    //- Extrusion parameters must match reality!
    //  Print with 4 shells and 3 solid layers
    
    ThreadThick = 0.20;
    ThreadWidth = 0.40;
    
    HoleWindage = 0.2;			// extra clearance
    
    Protrusion = 0.1;			// make holes end cleanly
    
    AlignPinOD = 1.70;			// assembly alignment pins: filament dia
    
    inch = 25.4;
    
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    
    //----------------------
    // Dimensions
    // Origin at bottom front corner of plate as mounted on machine
    //	motor mounted on rear surface, so recess is on that side
    
    PlateThick = 4.0;				// overall plate thickness
    
    SlotOffset = [10.0,13.0,0];		// center nearest origin, motor in X+,Y+ direction
    SlotSize = [8.0,25.0];			// diameter of mounting screw , overall end-to-end length
    
    CutoutOffset = [0.0,40.0,0];	// cutout around machine casting
    CutoutSize = [18.0,18.0];
    
    MotorBase = 58.0;				// square base plate side
    MotorHoleOC = 47.2;				// hole center-to-center spacing
    MotorHoleOffset = MotorHoleOC/2;
    MotorHoleDia = 5.0;
    MotorBaseCornerRadius = (MotorBase - MotorHoleOC)/2;
    
    FlangeWidth = 20.0;				// mounting flange
    
    MotorCenter = [(FlangeWidth + MotorBase/2),(MotorBase/2),0];		// XY of shaft centerline
    
    MotorShaftDia = 7.0;			// allow some clearance
    
    HubDia = 38.5;					// allow some clearance
    HubHeight = 1.8;
    
    //----------------------
    // Useful routines
    
    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) {
    
      RangeX = floor(100 / Space);
      RangeY = floor(125 / Space);
    
    	for (x=[-RangeX:RangeX])
    	  for (y=[-RangeY:RangeY])
    		translate([x*Space,y*Space,Size/2])
    		  %cube(Size,center=true);
    
    }
    
    //----------------------
    // Build it!
    
    module BasePlate() {
    
    	difference() {
    //		cube([(MotorCenter[0] + MotorBase/2),MotorBase,PlateThick],center=false);
    		linear_extrude(height = PlateThick) {
    			hull() {
    				translate([MotorBaseCornerRadius,MotorBaseCornerRadius])
    					circle(r=MotorBaseCornerRadius);
    				translate([MotorBaseCornerRadius,MotorBase - MotorBaseCornerRadius])
    					circle(r=MotorBaseCornerRadius);
    				translate([FlangeWidth + MotorBase - MotorBaseCornerRadius,MotorBase - MotorBaseCornerRadius])
    					circle(r=MotorBaseCornerRadius);
    				translate([FlangeWidth + MotorBase - MotorBaseCornerRadius,MotorBaseCornerRadius])
    					circle(r=MotorBaseCornerRadius);
    			}
    		}
    
    		translate(MotorCenter - [0,0,Protrusion]) {
    			rotate(180/8)
    				PolyCyl(MotorShaftDia,(PlateThick + 2*Protrusion),8);		// shaft hole
    			PolyCyl(HubDia,(HubHeight + Protrusion));						// hub recess
    			for (x=[-1,1] , y=[-1,1]) {
    				translate([x*MotorHoleOffset,y*MotorHoleOffset,0])
    					rotate(180/8)
    						PolyCyl(MotorHoleDia,(PlateThick + 2*Protrusion),8);
    			}
    		}
    
    		translate(SlotOffset - [0,0,Protrusion]) {							// adjustment slot
    			linear_extrude(height = (PlateThick + 2*Protrusion))
    				hull() {
    					circle(d=SlotSize[0]);
    					translate([0,(SlotSize[1] - SlotSize[0])])
    						circle(d=SlotSize[0]);
    
    				}
    		}
    
    		translate(CutoutOffset - [Protrusion,0,Protrusion])
    			linear_extrude(height = (PlateThick + 2*Protrusion))
    				square(CutoutSize + [Protrusion,Protrusion]);
    	}
    }
    
    ShowPegGrid();
    
    if (Layout == "Show") {
    	BasePlate();
    }
    
    if (Layout == "Build") {
    	translate([-(SlotOffset[0] + MotorBase/2),MotorBase/2,PlateThick])
    		rotate([180,0,0])
    			BasePlate();
    }
    
    
  • Kenmore 158: Foot Pedal Foot Bushings

    As you’d expect, the soft feet on the bottom of the Kenmore Model 158 sewing machine’s foot pedal control turn into hard buttons after a few decades. The OEM feet have mushroom tops that push through holes in the case and latch in place; of course, none of the rubber feet in my collection match the hole diameter or case thickness.

    No problem! Design a bushing that fits the case hole and passes a 4-40 screw:

    Speed Control Foot Bushing
    Speed Control Foot Bushing

    Then print up a handful, add screws to fit the rubber feet, and top off with nuts:

    Kenmore 158 - pedal foot bushing - detail
    Kenmore 158 – pedal foot bushing – detail

    Installed, with the screws cropped to a suitable length, they look about like you’d expect:

    Kenmore 158 - pedal foot bushing - interior
    Kenmore 158 – pedal foot bushing – interior

    Turns out that the springs supporting the foot pedal rest in those pockets, so the bushing reduces the spring travel by a few millimeters. The springs aren’t completely compressed with the pedal fully depressed, so it’s all good.

    The OpenSCAD source code:

    // Kenmore Model 158 Sewing Machine Foot Control Bushings
    // Ed Nisley - KE4ZNU - June 2014
    
    //- Extrusion parameters must match reality!
    //  Print with 2 shells and 3 solid layers
    
    ThreadThick = 0.20;
    ThreadWidth = 0.40;
    
    HoleWindage = 0.2;			// extra clearance
    
    Protrusion = 0.1;			// make holes end cleanly
    
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    
    //----------------------
    // Dimensions
    
    Stem = [2.5,5.7];			// through the case hole
    Cap = [3.0,10.0];			// inside the case
    
    LEN = 0;
    DIA = 1;
    
    OAL = Stem[LEN] + Cap[LEN];
    
    ScrewDia = 2.8;				// 4-40 generous clearance
    
    //----------------------
    // Useful routines
    
    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) {
    
      RangeX = floor(100 / Space);
      RangeY = floor(125 / Space);
    
    	for (x=[-RangeX:RangeX])
    	  for (y=[-RangeY:RangeY])
    		translate([x*Space,y*Space,Size/2])
    		  %cube(Size,center=true);
    
    }
    
    //----------------------
    // Build it!
    
    ShowPegGrid();
    
    difference() {
    	union() {
    		cylinder(d=Stem[DIA],h=OAL,$fn=16);
    		cylinder(d=Cap[DIA],h=Cap[LEN],$fm=16);
    	}
    	translate([0,0,-Protrusion])
    		PolyCyl(ScrewDia,OAL + 2*Protrusion,6);
    }
    
  • Subaru Forester: Speed Demon!

    I finally figured out why the Forester feels so slow:

    Subaru Forester - speedometer
    Subaru Forester – speedometer

    Here in the Northeast US, the maximum legal speed anywhere is 65 mph, less than half-scale, and typical around-town speeds hit 40 mph, barely 1/4 of full scale.

    For all practical purposes, that needle barely moves during our usual trips.

    I like analog gauges to represent smoothly varying quantities that you must read at a glance, but a big digital display would actually be more useful than that thing.

    A 150 mph speedometer scale makes no sense in what’s basically a shrunken all-wheel-drive SUV, even with minimal off-road capabilities. Yes, perhaps the Forester could hit 150 mph, but why not have the scale top out around, say, 100 mph? Above that, you shouldn’t be paying much attention to the speedo, anyway.

    The Sienna’s speedo went to 110 and, to the best of my knowledge, that needle never passed 85 mph, tops. However, ordinary (and legal) driving speeds filled the lower half of the scale, with the highest useful speeds in the next quadrant beyond vertical.

    Yes, I know why the speedos sport such absurd numbers. I don’t have to like it.

    There’s a servo motor (or some such) driving the needle; calibration has been a simple matter of software for a long, long time.

    For whatever it’s worth, the Forester and the Sienna have both tachometers and automatic transmissions, a combination that converts shifting into a spectator sport. The Forester’s continuously variable transmission moves the tach needle in smooth glides, rather than abrupt jumps.

  • Fit Test Blocks for 3D Printers: OpenSCAD Version

    During one of my recent presentations, somebody asked about the accuracy of 3D printed parts, which reminded me of another member of Coasterman’s Essential Calibration Set: the perimeter width/thickness test block. Back in the day, calibrating the extruder meant getting the actual ratio of the thread width to its thickness to match the ideal value you told Skeinforge to use; being a bit off meant that the final dimensions weren’t quite right.

    But when I got it right, the Thing-O-Matic printed a test block with considerable success, despite the horrible retraction zittage:

    Perimeter Calibration Block - yellow 1.10 rpm 0.33 0.66 mm
    Perimeter Calibration Block – yellow 1.10 rpm 0.33 0.66 mm

    Alas, feeding the STL to Slic3r showed that it was grossly non-manifold, and none of the automated repair programs produced good results. Turns out it’s an STL created from a Sketchup model, no surprise there, and the newer slicers seem less tolerant of crappy models.

    Sooo, here’s a new version built with OpenSCAD:

    Fit Test Blocks - build view
    Fit Test Blocks – build view

    You get three blocks-and-plugs at once, arranged in all the useful orientations, so you can test all the fits at the same time. They come off the platform about like you’d expect:

    Fit test blocks
    Fit test blocks

    I tweaked the code to make the plugs longer than you see there; the short ones were mighty tough to pry out of those slots.

    I ran the plugs across a fine file to clean the sides, without removing any base material, and the plugs fit into the slots with a firm push. I’d do exactly the same thing for a CNC milled part from the Sherline, plus breaking the edges & corners.

    The plugs doesn’t fit exactly flush in the recesses for the two models on the right side of that first image, because the edges and corners aren’t beveled to match each other. It’s pretty close and, if it had to fit exactly, you could make it work with a few more licks of the file. The left one, printed with the slot on the top surface, fits exactly as flush as the one from the Thing-O-Matic.

    Of course, there’s a cheat: the model allows 0.1 mm of internal clearance on all sides of the plug:

    Fit Test Block - show view
    Fit Test Block – show view

    The outside dimensions of all the blocks and plugs are dead on, within ±0.1 mm of nominal. You’d want to knock off the slight flange at the base and bevel the corners a bit, but unless it must fit inside something else, each object comes off the platform ready to use.

    Feel free to dial that clearance up or down to suit your printer’s tolerances.

    The OpenSCAD source code:

    // Fit test block based on Coasterman's perimeter-wt.stl
    //	http://www.thingiverse.com/thing:5573
    //	http://www.thingiverse.com/download:17277
    // Ed Nisley - KE4ZNU - May 2014
    
    Layout = "Show";
    
    //- Extrusion parameters must match reality!
    //  Print with 2 shells and 3 solid layers
    
    ThreadThick = 0.20;
    ThreadWidth = 0.40;
    
    Protrusion = 0.1;			// make holes end cleanly
    
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    
    //----------------------
    // Dimensions
    
    Clearance = 0.1;
    
    PlugSize = [10.0,10.0,25.0];
    BlockSize = [25.0,13.0,20.0];
    
    PlugOffset = 10.0;
    
    //----------------------
    // Useful routines
    
    module ShowPegGrid(Space = 10.0,Size = 1.0) {
    
      RangeX = floor(100 / Space);
      RangeY = floor(125 / Space);
    
    	for (x=[-RangeX:RangeX])
    	  for (y=[-RangeY:RangeY])
    		translate([x*Space,y*Space,Size/2])
    		  %cube(Size,center=true);
    
    }
    
    module Block() {
    	difference() {
    		translate([0,0,BlockSize[2]/2])
    			cube(BlockSize,center=true);
    		translate([0,PlugSize[1] - PlugSize[1]/2 - BlockSize[1]/2,-PlugOffset])
    			Plug(Clearance);
    	}
    }
    
    module Plug(Clear = 0.0) {
    	minkowski() {
    		translate([0,0,PlugSize[2]/2])
    			cube(PlugSize,center=true);
    		if (Clear > 0.0)
    			cube(Clear,center=true);
    	}
    }
    
    //----------------------
    // Build it
    
    ShowPegGrid();
    
    if (Layout == "Block")
    	Block();
    
    if (Layout == "Plug")
    	Plug();
    
    if (Layout == "Show") {
    	Block();
    	translate([0,PlugSize[1] - PlugSize[1]/2 - BlockSize[1]/2,-PlugOffset])
    		Plug();
    }
    
    if (Layout == "Build") {
    	Block();
    	translate([0,-15,0])
    		Plug();
    
    	translate([-30,0,0]) {
    		translate([0,-BlockSize[1]/2,BlockSize[1]/2])
    			rotate([-90,0,0])
    				Block();
    		translate([-PlugSize[2]/2,-15,PlugSize[0]/2])
    			rotate([0,90,0])
    				Plug();
    	}
    
    	translate([30,0,0]) {
    		translate([0,0,BlockSize[2]])
    			rotate([180,0,180])
    				Block();
    		translate([-PlugSize[2]/2,-15,PlugSize[1]/2])
    			rotate([90,0,90])
    				Plug();
    	}
    
    }
    
  • Boneheads Raven Skull: Extruder Contamination, Continued

    The Boneheads Raven Skull demo came out reasonably well, albeit in a reduced size, on the Squidwrench Frank-o-Squid:

    TOM286 - Raven Skull on platform
    TOM286 – Raven Skull on platform

    So I ran off a full-size version on the M2 for comparison:

    Raven Skull - on M2 platform
    Raven Skull – on M2 platform

    The extruder apparently contained a gobbet of black PLA, left over from the Pink Panther Woman, that managed to hang on inside until the very tip of the beak:

    Raven Skull - beak contamination
    Raven Skull – beak contamination

    Close inspection found two black strands closer to the base of the printed parts:

    Raven Skull - black contamination
    Raven Skull – black contamination

    The rear of the skull joins the front just behind the eye sockets, where the solid bottom layers make a visible contrast with the air behind the perimeter threads elsewhere. Refraction darkens some of the threads, but the two black patches stand out clearly.

    If it weren’t natural PLA, those flaws wouldn’t be nearly so noticeable.

    Were I doing this stuff for a living, I might dedicate a hot end (or an entire extruder) to each color and be done with it.

    All in all, the printed quality is about as good as I could expect from a glorified glue gun.

    The extreme slowdown while printing the tip of the beak pushed Pronterface’s remaining time estimate over the edge:

    Boneheads - Raven - Pronterface time estimate
    Boneheads – Raven – Pronterface time estimate

    I’m not sure what the correct value should be …

  • Poughkeepsie to Rochester Road Trip: The Movie

    With the Sony HDR-AS30V camera Gorilla Taped to the Sienna’s dashboard, we drove it to Rochester with a bank shot off Saratoga:

    Saratoga Rt 50
    Saratoga Rt 50

    I then converted nearly 5000 images into Yet Another Crappy Youtube Movie that is, mercifully, only 00:02:43 long.

    The key steps:

    mkdir /tmp/Video
    cd /tmp/Video
    sn=1 ; for f in /mnt/backup/Video/2014-05-29/* ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; cp -a $f $dn ; done
    avconv -r 30 -i dsc%05d.jpg -q 5 Pok-Saratoga-Rochester.mp4
    

    I tossed out a few images you didn’t need to see, then renumbered the remainder:

    sn=1 ; for f in * ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; mv $f $dn ; done
    

    The point of this exercise was to find out how Youtube treats “HD” movies. The original 1920×1080 MP4 file weighed in at nearly 500 MB with very good quality (due to the -q 5), but the Youtube “HD” result exhibits terrible compression artifacts; the black cloth crawls with huge checkerboard squares. Because the relatively slow-moving sequences at traffic signals and rest stops have excellent quality, I’d say Youtube’s video bit rate just doesn’t support images that change completely from frame to frame. Makes sense; nobody could watch such a thing, so why allocate that many bits?

    Now I have another Youtube movie-making data point