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.

Tag: Improvements

Making the world a better place, one piece at a time

  • Quilting Ruler Pivot Pin Sharpening

    Mary mentioned the pivot pin supplied with a quilting ruler tended to hang up on the layers of fabric and batting in the quilt squares she’s been making. A quick look showed the pin bore a remarkable resemblance to an ordinary thumb tack:

    Ruler Quilting Pivot Pin - as delivered
    Ruler Quilting Pivot Pin – as delivered

    I reset the pin shaft perpendicular to the head, grabbed a small brass tube in the lathe tailstock, inserted pin in tube, grabbed the head in the chuck, ignored a slight radial offset, and attacked the pin with fine files and sandpaper:

    Ruler Quilting Pivot Pin - sharpened
    Ruler Quilting Pivot Pin – sharpened

    The lathe chuck seemed the easiest way to firmly hold the head; I rotated the chuck by hand while filing.

    Most of the remaining scratches go mostly parallel to the pin, but it really didn’t work much better than before. We decided polishing the pin wouldn’t improve the situation enough to make it worthwhile.

    That’s the difference between sharp and keen, which cropped up with the cheap ceramic knife from a while ago. The point may penetrate the fabric, but the shaft can’t get through the tight weave.

    She’s now using a scary thin and pointy embroidery pin, having successfully rebuffed my offer to mount it in a suitable base.

  • Kinesis Freestyle2 Keyboard: Linux Fix

    Someone who found my original post about the Freestyle2’s dysfunctional media keys came up with a fix: https://github.com/whereswaldon/kfreestyle2d.

    Kinesis Freestyle2 Media Keys
    Kinesis Freestyle2 Media Keys

    Some notes for the next time this comes up:

    After doing sudo modprobe uinput, lsmod | grep uinp returns nothing at all (Xubuntu 16.04), but evtest seems perfectly happy:

    sudo evtest /dev/input/event17
    Input driver version is 1.0.1
    Input device ID: bus 0x3 vendor 0x58f product 0x9410 version 0x0
    Input device name: "KB800 Kinesis Freestyle"
    Supported events:
      Event type 0 (EV_SYN)
      Event type 1 (EV_KEY)
        Event code 113 (KEY_MUTE)
        Event code 114 (KEY_VOLUMEDOWN)
        Event code 115 (KEY_VOLUMEUP)
        Event code 140 (KEY_CALC)
    Properties:
    Testing ... (interrupt to exit)
    Event: time 1518199358.454619, type 1 (EV_KEY), code 113 (KEY_MUTE), value 1
    Event: time 1518199358.454619, -------------- SYN_REPORT ------------
    Event: time 1518199358.454638, type 1 (EV_KEY), code 113 (KEY_MUTE), value 0
    Event: time 1518199358.454638, -------------- SYN_REPORT ------------
    Event: time 1518199361.014681, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
    Event: time 1518199361.014681, -------------- SYN_REPORT ------------
    Event: time 1518199361.014699, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
    Event: time 1518199361.014699, -------------- SYN_REPORT ------------
    Event: time 1518199361.654701, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
    Event: time 1518199361.654701, -------------- SYN_REPORT ------------
    Event: time 1518199361.654721, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
    Event: time 1518199361.654721, -------------- SYN_REPORT ------------
    Event: time 1518199362.294715, type 1 (EV_KEY), code 140 (KEY_CALC), value 1
    Event: time 1518199362.294715, -------------- SYN_REPORT ------------
    Event: time 1518199362.294733, type 1 (EV_KEY), code 140 (KEY_CALC), value 0
    Event: time 1518199362.294733, -------------- SYN_REPORT ------------
    

    And the keys work without any special configuration on my part. Apparently they’re already built into XFCE, despite the sound keys not showing up in the Keyboard Shortcuts control panel where you assign programs to keys.

    This is wonderful work!

    I’ve never seen so many calculators before! Oops.

    There should be some udev-rule-ish way to automagically figure out which /dev/hidraw? device to use and symlink to a suitable alias, so the program could use it without knowing the actual device. A casual search turns up:

    https://unix.stackexchange.com/questions/105144/udev-rule-for-assigning-known-symlinks-for-identical-usb-serial-devices#105218

    With which I’d produce /dev/input/kinesis0 and kinesis1, then use:

    /home/ed/bin/kinesis/kfreestyle2d /dev/input/kinesis1
    

    If only the Kinesis Fn key was momentary, rather than a push-on / push-off toggle. Le sigh. I can cope.

  • M2 Platform Alignment and Nozzle Height Check: Z Offset Confusion

    A set of five calibration boxes will check both platform alignment and extruder settings:

    Calibration Squares - rectified
    Calibration Squares – rectified

    Those boxes have three threads in their walls and stand 3.0 mm tall:

    Calibration Boxes - alignment layout - corner detail - Slic3r preview
    Calibration Boxes – alignment layout – corner detail – Slic3r preview

    The first pass measurements:

    Calibration Boxes - initial measurements - 2018-02-07
    Calibration Boxes – initial measurements – 2018-02-07

    The skirt is scant at 0.20 mm, the boxes are 0.15 mm short at 2.85 mm, and the walls are 0.03 mm too thin. Some Z offset adjustment seems in order, as the first few layers (on the left) came out grossly squished:

    Calibration box - 2.85 - detail
    Calibration box – 2.85 – detail

    However, the box heights came out sufficiently uniform to show the platform alignment remains just fine.

    Long ago, I moved the Z endstop switch to the X axis gantry, where it can directly sense the platform position:

    M2 - V4 hot end - Z endstop switch
    M2 – V4 hot end – Z endstop switch

    Putting it there replaces all the mechanical putzing and adjusting cute little screws / bolts / nuts / spacers / suchlike with a simple offset in the startup G-Code:

    G28 Z-2.15				; home Z to platform switch, with measured offset
    

    So I changed the startup G-Code in Slic3r to use G28 Z-2.30, sliced a single box in the middle of the platform, printed it, and … it came out exactly the same height: 2.85 mm.

    Huh.

    To make a very long story short, it turns out Marlin 1.1 ignores the numeric parameter in G28. When I updated the firmware to that version, I had changed the Configuration.h file to include the homing offsets:

      #define MANUAL_X_HOME_POS -100
      #define MANUAL_Y_HOME_POS -127
      #define MANUAL_Z_HOME_POS -2.15
    

    So, with the same offset burned into the firmware, it looked like the startup G-Code was Doing The Right Thing. I never deleted the offset from the startup G-Code and, at some point, Marlin stopped supporting the numeric parameter.

    Huh.

    However, the X and Y homing offsets must be hardcoded, because I want the XY origin in the middle of the platform to match my original OpenSCAD part designs. Everybody else prefers the XY origin in the front-left corner. FWIW, in Marlin 1.1-RC5 (two years old by now), the #define BED_CENTER_AT_0_0 constant appears only in that line and nowhere else in the source code. Maybe it was a change in progress back then?

    Anyhow, rather than hardcode the Z offset again, I set it to 0.00:

      #define MANUAL_X_HOME_POS -100
      #define MANUAL_Y_HOME_POS -127
      #define MANUAL_Z_HOME_POS  0.0
    

    Recompile and reload the firmware, then change the startup G-Code to use G28 Z without the offset.

    Doing so means I can measure and adjust the actual Z offset with M206, then store the value in EEPROM with M500:

    M206 Z-2.25
    M500
    

    I went a little short at -2.25, for reasons I cannot explain now.

    Measuring the offset goes like this:

    • Zero the offset: M206 Z0
    • Move the extruder off to the right: G0 X135
    • Home Z: G28 Z
    • Get some air under the nozzle: G0 Z4.0
    • Measure the actual clearance, perhaps using your taper gauge, at (let’s say) 1.7 mm
    • Set (1.7 – 4.0) as the offset: M206 Z-2.3
    • Print a box and adjust the offset accordingly

    Using my actual measurement, not the for-instance example, I resliced the box, printed it, and it came out at 2.94 mm, just slightly short, so I re-tweaked the offset to Z-3.28 and re-stored it.

    Embiggening the wall thickness turned out to be a matter of updating the filament diameter. I measured the start of the current spool of orange PETG at 1.75 mm, the same as the previous natural PETG spool, but the current section is 1.70 mm. Plugging that into Slic3r, reslicing, and reprinting produced a dead-on square: 3.00 mm tall with 1.20 mm walls:

    Calibration Square series
    Calibration Square series

    The skirt now comes out at 0.25 mm, the way it should, too. The difference between the original 0.20 mm skirt and 0.25 mm suggests the squashed center thread (of the three in the skirt around the first set of five boxes) forced the two adjacent threads to become a bit taller, for lack of somewhere for the excess plastic to go on one side of each thread, and the nozzle rode higher than you’d (well, I’d) expect from the bare numbers.

    The picture is missing a few squares in the middle, because I couldn’t believe changing the G28 Z-2.15 offset had no effect. It was easier to believe I’d inadvertently loaded the wrong file than the software / firmware was doing something wrong.

    However, during the course of the adventure, I established M851 does exactly nothing in this context, perhaps because it applies to some different type of homing / probing / mesh leveling / whatever. You can set the Z offset with several other G-Code and M-Code commands, but the documentation isn’t always forthcoming about how the various methods interact and different firmware uses identical codes for completely different functions, so proceed with Exceedingly Great Caution.

    In any event, it’s much easier and faster to adjust the printer & slicing parameters by measuring test boxes than by puzzling over actual prints, so …

    The OpenSCAD source code as a GitHub Gist:

    // Simple calibration boxes
    // Thin wall open box – verify Extrusion Multiplier
    // Solid box – verify infill settings
    // Ed Nisley – KE4ZNU
    // https://softsolder.com/
    Layout = "Open"; // Open Solid
    Texting = ""; // text message on solid box or empty string to suppress
    //——-
    //- Extrusion parameters must match reality!
    ThreadThick = 0.25;
    ThreadWidth = 0.40;
    Protrusion = 0.1; // make holes end cleanly
    function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);
    //——-
    // Dimensions
    WallThick = 3.0 * ThreadWidth;
    echo(str("Wall thickness: ",WallThick));
    BoxSize = 40.0;
    echo(str("Overall size: ",BoxSize));
    NominalHeight = 3.0;
    echo(str("Nominal height: ",NominalHeight));
    Height = IntegerMultiple(NominalHeight,ThreadThick);
    echo(str("Actual height: ",Height));
    Rotation = 0; // 45 to exercise X and Y axis motors at same time
    CornerRadius = max(2.0, 2.0 + WallThick);
    CornerSides = 8*4;
    //——–
    module Solid() {
    difference() {
    hull()
    for (i=[-1,1], j=[-1,1])
    translate([i*(BoxSize – 2*CornerRadius)/2,j*(BoxSize – 2*CornerRadius)/2,0])
    cylinder(r=CornerRadius,h=Height,$fn=CornerSides);
    if (len(Texting))
    translate([0,0,-Protrusion/2])
    linear_extrude(height=3*ThreadThick + Protrusion)
    mirror([1,0,0])
    text(text=Texting,size=6,spacing=1.05,font="ITC Zapf Chancery:style=Italic",halign="center",valign="center");
    }
    }
    module Thinwall() {
    difference() {
    Solid();
    hull()
    for (i=[-1,1], j=[-1,1])
    translate([i*(BoxSize – 2*CornerRadius)/2,j*(BoxSize – 2*CornerRadius)/2,-Protrusion])
    cylinder(r=(CornerRadius – WallThick),h=(Height + 2*Protrusion),$fn=CornerSides);
    }
    }
    //——-
    rotate(Rotation)
    if (Layout == "Open")
    Thinwall();
    else
    Solid();
  • MPCNC: Bar Clamp Mounts, Redux

    With the new thermistor installed and the nozzle at (pretty nearly) the right height, the final set of bar clamp mounts came out perfectly:

    MPCNC - reprinted bar clamp mounts
    MPCNC – reprinted bar clamp mounts

    They’re supporting the snippets produced by trimming the clamp extrusions to fit across the bench under the MPCNC; I figure they ought to come in handy for something.

    Both extrusions carry a warning sticker giving the bar’s serial number:

    Harbor Freight Bar Clamp Labels
    Harbor Freight Bar Clamp Labels

    Huh.

    I could be persuaded the number applies to a given production batch, although I’d be unsurprised to learn it’s a batch of labels, not clamps.

    They don’t look much different than the previous versions:

    MPCNC - bar clamp mount
    MPCNC – bar clamp mount

    The main change was to raise the bars by another 2 mm to give one of the clamp shoes more clearance. As you might expect, the top and bottom halves of the clamp castings aren’t quite symmetric.

    The plastic mounts come in mirror-image sets due to that off-center bolt hole.

    Yes, the threaded casting is slightly angled from the screw clamping force.

    All in all, the mounts look pretty good, in a bright-orange sort of way.

  • VFAT Time Zone Offset Correction

    An SJCAM M20 action camera includes the date and time in its file names, but the directory entries appear with the wrong timestamp:

    sudo mount -o uid=ed /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
    

    I’m in the Eastern US time zone, -5 hr from UTC.

    By definition, FAT directory entries contain the “local time” when the file was created / changed. Because it cannot know which “local time” applies, the Linux VFAT filesystem treats the timestamp as UTC and adjusts it by -5 hr.

    So the camera writes the directory timestamps properly. When mounted, Linux correctly (for a reasonable definition of correctly) regards them as UTC, knocks off five hours to match this time zone, and displays the result.

    Alas, disabling the VFAT timestamp conversion has no effect:

    sudo mount -o uid=ed,tz=UTC /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*
    

    I’m not sure why that doesn’t do anything; it doesn’t generate any error messages.

    Although it seems like a reasonable thing, one cannot force a specific time zone with, say, tz=EST or tz=EDT or tz=UTC8 or whatever.

    You can specify an offset in minutes:

    sudo mount -o uid=ed,time_offset=$((-5*60)) /dev/sdc1 /mnt/part
    ll -tr /mnt/part/DCIM/Photo/ | head
    total 4.8G
    drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
    drwxr-xr-x 2 ed root 144K Jan 25 23:52 ./
    -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100825_001.JPG*
    -rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100830_002.JPG*
    

    The time_offset value is subtracted from the directory timestamp, which means you’re feeding in the actual time offset from UTC, including whatever Daylight Saving Time offset may be in order.

    So Linux takes the FAT timestamp, adds (subtracts a negative) 5 hr, and displays the result as my (now correct) local time.

    I suppose I could set the camera to UTC, but then the camera’s on-screen and in-video timestamps would be off by four or five hours, depending on the season. So it goes.

  • MPCNC: Reinforced Z-axis Motor Mount

    PLA isn’t particularly strong, especially in small sections under high stress:

    MPCNC - Cracked Z Motor Mount
    MPCNC – Cracked Z Motor Mount

    I tried solvent-bonding + clamping the break, didn’t expect much, and wasn’t disappointed.

    Stronger versions exist:

    Z Upper Motor Mount
    Z Upper Motor Mount

    It adds a festive touch when done up in orange PETG:

    MPCNC - Reinforced Z Motor Mount
    MPCNC – Reinforced Z Motor Mount

    The attentive reader will note the missing head of the screw anchoring the mount to the left Z rail. Apparently a #32 drill was a bit too small to let the randomly chosen self-tapping screws thread themselves into EMT; they probably anchored a PCB to the plastic case of a long-forgotten lump of consumer electronics.

    It should last long enough for something else to let go …

  • Umbrella Strut Splinting, Round Two

    Two more umbrella struts snapped and required the same repair, but, having drained all the suitable snippets from the Box o’ Brass Cutoffs, some lathe work was in order:

    Umbrella strut splint - cutting
    Umbrella strut splint – cutting

    I used the carbide insert in the mistaken belief it’d be less grabby, then applied the cutoff tool.

    Break the edges, slide splints over the ribs, slobber epoxy on the struts, slide splints into place, apply masking tape for a bit of compression & alignment, and let it cure:

    Umbrella strut splint - curing
    Umbrella strut splint – curing

    Three down, five to go …