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

  • Tux Cookie Cutter

    Sean asked me to conjure up a Tux cookie cutter for the presentation on DIY 3D Printing and the Makerbot Thing-O-Matic I’m doing at the Mid-Hudson Valley LUG meeting tonight and, as is always the case, it took a bit more conjuring than either of us expected.

    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
    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
    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
    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
    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
    }
    
  • OpenSCAD vs. Skeinforge 40: Bogus G-Code

    My first pass at the NEMA 17 motor mount bracket used additive modeling, glomming together several blocks made from cube primitives:

    • The motor mounting plate, less five holes
    • Two side struts to stiffen the motor plate
    • The baseplate, minus two mounting holes

    Makes perfect sense to me; perhaps I’m an additive kind of guy. That produced an OpenSCAD model with positive surfaces for the various parts and negative surfaces inside the holes:

    NEMA 17 Mount - additive model
    NEMA 17 Mount – additive model

    Compile that through CGAL, export as STL, inhale into RepG 25, and you (well, I) get what looks to be a fine object in the preview pane:

    NEMA 17 RepG preview - additive
    NEMA 17 RepG preview – additive

    Then run it through Skeinforge 40, which emits a flurry of messages along these lines:

    [19:11:08] Warning, the triangle mesh slice intersects itself in getLoopsFromCorrectMesh in triangle_mesh.
    [19:11:08] Something will still be printed, but there is no guarantee that it will be the correct shape.
    [19:11:08] Once the gcode is saved, you should check over the layer with a z of:
    [19:11:09] 0.165
    

    The usual searching suggested that sometimes Skeinforge has problems with coincident surfaces, such as between the motor mount plate and the struts and the base, or coincident edges where two blocks abut. Judging from the messages, the problem ran all the way to the top of the struts. Oddly, Skeinview didn’t show any problems, so the G-Code was (presumably) OK.

    Error messages tend to make me twitchy, though. I modified the OpenSCAD code to extend the struts 0.1 mm inside the base and ran that model through the software stack, which produced not a single complaint about anything, anywhere.

    Success!

    However, painful experience has caused me to review the G-Code for every single object with the Skeinlayer plugin, which, right on cue, revealed this interesting anomaly:

    NEMA 17 Mount - Skeinview - Bad gcode
    NEMA 17 Mount – Skeinview – Bad gcode

    That happened for every layer in the square motor mount plate: the lower right corner is fine, the upper left seems to be the negative of the actual solid model. The holes are filled, the plate is empty. The Skirt outline ignores the smaller holes, goes around the large one, and continues on its merry way.

    I putzed around for a while and discovered that the failure seems acutely sensitive to the side strut thickness. Yeah, like that makes any sense.

    Any variations along those lines that I tried generated either:

    • A flurry of mesh error messages, with seemingly good G-Code
    • No error messages whatsoever, with totally bogus G-Code

    Running the STL files through netfabb Cloud Service produced the same diagnostic for both:

    Number of holes: 3
    Number of shells: 2
    Mesh is not manifold and oriented.
     We unfortunately have not yet enough experience with the occuring server loads, that we can securely enable shell merging at the moment.
    

    However, the repaired STL files produce correct G-Code: evidently OpenSCAD spits out bogus STL data. The fact that RepG/SF treats the two files differently suggests improved diagnostics would be in order, but that’s in the nature of fine tuning.

    So I junked the additive model and went subtractive, chewing the recesses out of one huge block:

    NEMA 17 Stepper Mount - solid model
    NEMA 17 Stepper Mount – solid model

    That worked:

    Number of holes: 0
    Number of shells: 1
    Mesh is manifold and oriented.
    

    I like processes that don’t emit error messages or result in mysterious failures, although it’s not obvious that subtractive modeling will always produce correct results. Heck, I’m not sure I can think in terms of negative volumes all that well.

    The OpenSCAD code for the additive model, with a highlight on the conditional that will trigger the two errors:

    // NEMA 17 stepper motor mount
    // Ed Nisley KE4ZNU August 2011
    
    include </home/ed/Thing-O-Matic/lib/MCAD/units.scad>
    
    //-- Layout Control
    
    Layout = "Build";				// Build Show None
    
    Examine = "None";				// Mount Stand None
    
    //-- Extrusion parameters
    
    ThreadThick = 0.33;
    ThreadWT = 2.0;
    ThreadWidth = ThreadThick * ThreadWT;
    
    HoleWindage = 0.3;			// enlarge hole dia by this amount
    
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    
    //-- Useful sizes
    
    Tap2_56 = 0.070 * inch;
    Clear2_56 = 0.082 * inch;
    Head2_56 = 0.156 * inch;
    Head2_56Thick = 0.055 * inch;
    Nut2_56Dia = 0.204 * inch;
    Nut2_56Thick = 0.065 * inch;
    
    Tap3_48 = 0.079 * inch;
    Clear3_48 = 0.096 * inch;
    Head3_48 = 0.184 * inch;
    Head3_48Thick = 0.058 * inch;
    Nut3_48Dia = 0.201 * inch;
    Nut3_48Thick = 0.073 * inch;
    
    Tap4_40 = 0.089 * inch;
    Clear4_40 = 0.110 * inch;
    Head4_40 = 0.211 * inch;
    Head4_40Thick = 0.065 * inch;
    Nut4_40Dia = 0.228 * inch;
    Nut4_40Thick = 0.086 * inch;
    
    Tap10_32 = 0.159 * inch;
    Clear10_32 = 0.190 * inch;
    Head10_32 = 0.373 * inch;
    Head10_32Thick = 0.110 * inch;
    Nut10_32Dia = 0.433 * inch;
    Nut10_32Thick = 0.130 * inch;
    
    NEMA17_ShaftDia = 5.0;
    NEMA17_ShaftLength = 24.0;
    NEMA17_PilotDia = 0.866 * inch;
    NEMA17_PilotLength = 0.080 * inch;
    NEMA17_BCD = 1.725 * inch;
    NEMA17_BoltDia = 3.5;
    NEMA17_BoltOC = 1.220 * inch;
    
    //-- Mount Sizes
    
    MountSide = IntegerMultiple(NEMA17_BCD,ThreadWidth);
    MountThick = IntegerMultiple(8.0,ThreadThick);
    
    MountBoltDia = 3.0;
    
    StrutThick = IntegerMultiple(5.0,ThreadWidth);
    StrutHeight = MountSide;
    
    StandThick = IntegerMultiple(4.0,ThreadWidth);
    
    UprightLength = IntegerMultiple(MountSide + 2*StrutThick,5);
    
    StandBoltAllowance = IntegerMultiple(Head10_32,5);
    StandBoltOC = UprightLength + 2*StandBoltAllowance;
    
    StandLength = IntegerMultiple(StandBoltOC + 2*StandBoltAllowance,ThreadWidth);
    StandWidth = IntegerMultiple(2*StandBoltAllowance,ThreadThick);
    
    echo(str("Stand Base: ",StandLength," x ",StandWidth));
    echo(str("Stand Bolt OC: ",StandBoltOC));
    
    //-- Convenience values
    
    Protrusion = 0.1;		// make holes look good and joints intersect properly
    
    BuildOffset = 3 * ThreadWidth;
    
    //----------------------
    // 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) {
    
      Range = floor(50 / Space);
    
    	for (x=[-Range:Range])
    	  for (y=[-Range:Range])
    		translate([x*Space,y*Space,Size/2])
    		  %cube(Size,center=true);
    
    }
    
    //----------------------
    // Motor Mount plate
    
    module MotorMount() {
    
      difference() {
    	translate([0,0,MountThick/2])
    	  cube([MountSide,MountSide,MountThick],center=true);
    if (true) {
    	translate([0,0,-Protrusion])
    	  PolyCyl(NEMA17_PilotDia,(MountThick + 2*Protrusion));
    }
    else {
    	translate([0,0,MountThick - NEMA17_PilotLength])
    	  PolyCyl(NEMA17_PilotDia,(NEMA17_PilotLength + Protrusion));
    	translate([0,0,-Protrusion])
    	  PolyCyl(1.5*NEMA17_ShaftDia,(MountThick + 2*Protrusion));
    }
    	for (x=[-1,1])
    	  for (y=[-1,1])
    		translate([x*NEMA17_BoltOC/2,y*NEMA17_BoltOC/2,-Protrusion])
    		  PolyCyl(MountBoltDia,(MountThick + 2*Protrusion));
      }
    
    }
    
    //----------------------
    // Stand to support the plate
    
    module Stand() {
    
      difference() {
    
    	union() {
    	  translate([0,0,StandThick/2])
    		cube([StandLength,StandWidth,StandThick],center=true);
    	  for (x=[-1,1])						// side support struts
    if (true)	// this causes bizarre negative rendering and a diagonal negative section
    		translate([(x*((MountSide + StrutThick)/2)),0,
    				  (StandThick + StrutHeight/2 - Protrusion/2)])
    		  cube([StrutThick,StandWidth,(StrutHeight + Protrusion)],center=true);
    else	// this generates "triangle slice mesh intersects iself"
    		translate([(x*((MountSide + StrutThick)/2)),0,
    				  (StandThick + StrutHeight/2)])
    		  cube([StrutThick,StandWidth,StrutHeight],center=true);
    	}
    
    	for (x=[-1,1])
    	  translate([x*StandBoltOC/2,0,-Protrusion])
    		PolyCyl(Clear10_32,StandThick + 2*Protrusion);
      }
    }
    
    //----------------------
    // Combined for single build
    
    module Combined() {
    
    //  union() {
    	translate([-MountSide/2,0,0])
    	  MotorMount();
    
    	translate([StandThick,0,StandWidth/2])
    	  rotate([90,0,270])
    		Stand();
    
    //  }
    }
    
    //----------------------
    // Lash everything together
    
    ShowPegGrid();
    
    if (Examine == "Mount")
      MotorMount();
    
    if (Examine == "Stand")
      Stand();
    
    if (Layout == "Build" && Examine == "None") {
      translate([MountSide/2,0,0])
    	Combined();
    }
    
    if ((Layout == "Show") && Examine == "None") {
      translate([-StandWidth/2,0,StandThick])
    	rotate([0,90,0])
    	  Combined();
    }
    

    OpenSCAD depends on CGAL for all the 3D heavy lifting, which puts any STL export problems further upstream.  I suppose I could open Yet Another RepG ticket to get better diagnostics, but the others haven’t gotten much attention so far and I suppose it’s not really their problem anyway.

  • Revised OpenSCAD Layout Grid

    Following the suggestions in the comments to my previous attempt at an OpenSCAD layout grid, this pass works better:

    • Leave it turned on all the time
    • Parameterized everything
    • Useful default values
    • Less obtrusive

    It looks about the same as before, only now it’s transparent gray. The 2-unit cube in the middle marks the “your object goes there” spot; the % prefix on the grid cubes causes OpenSCAD to ignore them.

    OpenSCAD Build Surface Grid - revised
    OpenSCAD Build Surface Grid – revised

    The OpenSCAD source code:

    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);
    
    }
    
    ShowPegGrid();
    cube(2,center=true);
    
  • Windows 7 First Boot

    OK, this resembles dynamiting fish, but I can’t help myself. A cute little Lenovo Q150 with a D525 dual-core Atom and nVidia ION graphics just arrived, which, perforce, has Windows 7 preinstalled. The first step is to get Windows activated, updated, and settled down… the second step being, of course, to shrink that partition to a nub and install Linux for actual use.

    After a bit of huffing & puffing, reading (*) & clicking of many EULAs, and the first round of updates:

    Windows 7 - You must restart your computer
    Windows 7 – You must restart your computer

    Every time I see that, I think of the old dialog box joke:

    Mouse motion detected. Windows NT must reboot to apply this change. [OK]

    Then it had to update .NET, which produced this unbelievable body count of changes:

    Windows 7 - Applying update operation
    Windows 7 – Applying update operation

    And then another few rounds of updates, the last of which evidently crashed & burned. The Get help with this error link was, mmm, unhelpful; it simply reported they hadn’t the foggiest idea what went wrong. Rebooting and retrying the automated updates presumably worked:

    Windows 7 - Some updates were not installed
    Windows 7 – Some updates were not installed

    Doing all of that while puttering around with other stuff occupied the better part of a day, after which one owns a PC with an operating system installed. Yeah, you do get a UI that exposes IE 9, but if you want to do something with the PC, well, that requires installing applications.

    I loves me my default Windows desktop background, from a long-ago crash inside a VM:

    BSOD - fatal app exception
    BSOD – fatal app exception

    (*) Yes, I do read them, mostly for comic relief. The general practice of forcing you to scroll through a sheaf of typewriter-formatted pages in a 2×3 inch peephole centered in a huge monitor suggests that they really don’t want you to know what’s going on. Anyone who suggests buying commercial software because it has a reputable company standing behind it has obviously never gone to the trouble of reading the relevant EULA.

  • Thing-O-Matic: Uncommanded Z Motion After Homing

    After printing the Barbie Pistol, I discovered that moving the Z stage to anything less than the absolute maximum was a Bad Idea, so I changed end.gcode to simply home the Z axis to the top. That worked fine in RepG 24, but after printing a few things with RepG 25, I discovered that the Z axis now has uncommanded motion after that homing step: a G0 F4000 X0 causes the Z stage to drop by anywhere from a few millimeters to half the total travel.

    Of course, the uncommanded Z motion depends on something imponderable, but it’s consistent for any given setup. This chunk of G-Code causes about 10 mm of downward Z motion:

    G21        (set units to mm)
    G90        (set positioning to absolute)
    (- coarse home axes -)
    G162 Z F1000    (home Z to get nozzle out of danger zone)
    G161 Y F4000    (retract Y to get X out of front opening)
    G161 X F4000    (now safe to home X)
    M132 X Y Z A B    (fetch home offsets from EEPROM)
    G0 F4000 X0 Y0 Z30        (pause at center to build confidence)
    (- draw square)
    G0 F4000 X-45 Y-45 Z10    (to front left corner)
    G1 Y45 F4000
    G1 X45
    G1 Y-45
    G1 X-45                    (return to front left)
    (- move to eject position)
    G162 Z F1500    (home Z to get nozzle away from object)
    (G0 F4000 Z113) (this would work fine)
    G0 F4000 X0        (center X axis)
    G0 F4000 Y40    (move Y stage forward)

    There’s a RepG ticket for that.

    As nearly as I can tell, homing an axis trashes its coordinate value, so the only thing you can do next is set the axis coordinate value with G92 or M132. Given that those values are now stored in EEPROM, maybe it’s be a good idea to simply use them, without requiring another command after each homing command?

    You’d want home offset values for both the maximum and minimum limits, to accommodate printers with limits on both ends of the axis, rather than the single offset now stored. The two homing commands (G161 and G162) could pick the appropriate offset, if a valid one was stored, and leave the coordinate unchanged (but not trashed!) otherwise.

    There’s a RepG ticket for that.

  • Thing-O-Matic: Broken G91 Relative Motion

    It would be handy, while doing the fast / coarse home stuff, to switch to G91 relative positioning mode and back off the switches by 2 mm by using a simple G0 X2 Y2 Z-2 that doesn’t depend on knowing the exact coordinates of the endpoint, but it seems relative positioning doesn’t work for any but the most trivial cases.

    After some fiddling, this short routine produces a very fast, very long, fully coordinated XY move to some position in the +X +Y direction at the G1 X2 F100 command after the G91 command sets relative motions; it should move 2 mm away from the X switch. When the machine arrives at the new (unexpected) position, it then does the expected slow 2 mm Y and Z moves:

    G21 (set units to mm)
    G90 (set positioning to absolute)
    (- coarse home axes)
    G162 Z F1000 (home Z to get nozzle out of danger zone)
    G161 Y F4000 (retract Y to get X out of front opening)
    G161 X F4000 (now safe to home X)
    (- back off switches)
    G91
    G1 X2 F100
    G1 Y2 F100
    G1 Z-2 F100
    G90

    I gave up and used an absolute move with hardcoded XYZ coordinates that should be pretty close to the stored values.

    There’s a RepG ticket for that.

    Obviously, I’m going where no other Thing-O-Matic operator has gone before. I do that a lot, don’t I?

  • Thing-O-Matic: Revised Homing

    After adding F feed speed parameters to all the G0 commands in my start.gcode (to work around that bug), I decided to use the new-with-firmware-2.8 feature that stores the home offsets in the Thing-O-Matic’s EEPROM. That turned out to be, one might say, a thinly documented feature, so this may be a useful summary…

    The Official Way to set the EEPROM, which you can find in ReplicatorG/scripts/calibration/Thing-O-Matic calibration.gcode, goes a little something like this:

    • Manually position the nozzle dead center on the build plate, just touching the surface
    • Use G92 to set all axes to 0.0
    • Home the axes to the switches
    • Use M131 X Y Z A B to store the current values in EEPROM

    Having already found good values for those offsets as part of the aluminum build plate adventure, I jammed them into EEPROM using RepG’s Machine→Motherboard Onboard Preferences. The values I’m using are:

    • X = -53.0
    • Y = -59.0
    • Z = 116.0

    For some unknown reason that has nothing to do with floating point representation (I mean sheesh even the 32-bit version of IEEE 754 floating point has at least 10 decimal digits of precsion), RepG modifies only the negative values sufficiently to be bothersome:

    • X = -52.964
    • Y = -58.976

    Having stored the offsets, I wondered how to fetch them. That is also, of course, completely undocumented, but I eventually traced down the answer in (deep breath)

    skein_engines/skeinforge-35/skeinforge_application/prefs/SF35-Thingomatic-HBP-Stepstruder/alterations/start.gcode

    That’s not true for all the start.gcode files you might find, though, and there are many such in far more obvious places.

    So, OK, I fetch the EEPROM coordinates using M132 after doing both the coarse home (they’ll be pretty close) and the fine home (they’ll be dead on, modulo the changes), then wipe the nozzle and poke the Z-minimum height switch (which is why I really really care about random changes in the stored values) to find the actual height above the aluminum build surface.

    At exactly this position it would be nice to set only the Z height to the actual switch thickness, but G92 sets all un-mentioned axes to zero, so you can’t set just one axis. I have no idea how M131 and M132 behaves in that regard; none of this stuff is documented anywhere that I can find and this stopped being funny a while ago.

    So, knowing the XYZ coordinates of the switch, I reset the XYZAB axes using G92.

    The current working start.gcode that I devoutly hope will continue to work for a while:

    (---- start.gcode begins ----)
    (MakerBot Thing-O-Matic with aluminum HBP and Z-min platform switch)
    (Tweaked for TOM 286 - Ruttmeister MK5 stepper extruder mod)
    (Ed Nisley - KE4ZNU - July 2011)
    (Hack to work around bad G0 speed)
    (- set initial conditions)
    G21		(set units to mm)
    G90		(set positioning to absolute)
    (- begin heating)
    M104 S210 T0	(extruder head)
    M109 S110 T0	(HBP)
    (- coarse home axes)
    G162 Z F1000	(home Z to get nozzle out of danger zone)
    G161 Y F4000	(retract Y to get X out of front opening)
    G161 X F4000	(now safe to home X)
    M132 X Y Z A B	(fetch home offsets from EEPROM)
    (- fine home axes)
    G0 X-51 Y-55 Z114 F400	(back off switches)
    G161 Y F200
    G161 X F200
    G162 Z F200
    M132 X Y Z A B	(fetch home offsets from EEPROM)
    (- manual nozzle wipe)
    G0 F6000 X0 Y0 Z10	(pause at center to build confidence)
    G4 P500
    G0 X40 Y-57.0 Z10	(move to front, avoid wiper blade)
    G0 X56				(to wipe station)
    G0 Z6.0				(down to wipe level)
    M6 T0				(wait for temperature settling)
    G1 Y-45	F1000		(slowly wipe nozzle)
    (-----------------------------------------------)
    (- Make sure the XY position matches the G92    )
    (- home Z downward to platform switch)
    G0 F6000 X56.4 Y7.6 Z3		(get over build platform switch)
    G161 Z0 F50					(home downward very slowly)
    G92 X56.4 Y7.6 Z1.60		(set Z height)
    G0 F6000 Z6.0				(back off switch to wipe level)
    (-----------------------------------------------)
    (- start extruder and re-wipe)
    G0 X56 Y-45     (set up for wipe from rear)
    G1 Y-57.0 F1000 (wipe to front)
    M108 R2.0		(set stepper extruder speed)
    M101			(Extruder on, forward)
    G4 P4000  	    (take up slack, get pressure)
    M103			(Extruder off)
    G4 P4000  	    (Wait for filament to stop oozing)
    G1 Y-45	F1000	(slowly wipe nozzle again)
    G0 F6000 X0		(get away from wiper blade)
    (- build some pressure)
    M108 R2.0		(set stepper extruder speed)
    M101			(start extruder)
    G4 P100			(run for a bit)
    (---- start.gcode ends ----)
    
    

    For what it’s worth, I put that file in the sf_40_alterations directory, blew away the previous versions in all the profiles, and replaced them with symlinks to that single file. When the next change comes along, I can modify one file and all the profiles will pick up the change at once.