Suet Feeder Temporary Fix

The neighborhood raccoons made off with our steel-cage suet feeder, leaving a dangling chain, several puzzled woodpeckers, and a potential gap in Mary’s FeederWatch data. A quick Thingiverse search turned up a likely candidate and a few hours of 3D printing produced a replacement:

3D printed suet feeder

3D printed suet feeder

The cheerful party colors just sort of happened after I realized orange wasn’t the new steel.

I bandsawed the top plate from an acrylic sheet, rather than devote several hours to printing a simple disk with two slots. Said slots came from a bit of freehand work with the drill press, a step drill bit, and a nasty carbide milling bur(r).

The loops holding the chains won’t last for long, as hairy and red-bellied woodpeckers land with thump.

It hangs from the stub of a former ski pole, loosely secured to the bracket holding the former feeder, and extending another two feet over the abyss beyond the patio. I doubt the raccoons will remain daunted for long, but maybe they’ll catch a heart attack when it collapses.


, ,


Kinesis Freestyle2 Keyboard: Linux Fix

Someone who found my original post about the Freestyle2’s dysfunctional media keys came up with a fix:

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)
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:

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.

Leave a comment

Monthly Image: Red Sky in the Morning

You can tell the day’s weather won’t be good when you see this:

Red Sky in the Morning - 2018-02-07

Red Sky in the Morning – 2018-02-07

Taken just before the snow started …

I wish I could run the snowblower up and down the driveway to preemptively level it at -5 inches, so the snowfall would end with almost bare asphalt.

Long ago, they promised me heated driveways and sidewalks to eliminate snow shoveling, but it hasn’t worked out that way, either.


Stepper Motor Current Measurement Setup

As part of installing the bar clamps, I packed away the Tek Hall effect current probes measuring the stepper winding currents:

MPCNC Z Axis AB current probe - overview

MPCNC Z Axis AB current probe – overview

The hulking pistol is a Tektronix A6203 100 A probe, the little black pencil is a Tek A6302 20 A probe:

MPCNC Z Axis AB current probe - detail

MPCNC Z Axis AB current probe – detail

The absurdity of measuring a 600 mA (peak!) current with a 100 A probe isn’t lost on me, but those things have become genuine eBay collectibles over the last few years.

For low-frequency signals, you could probably get by with a Fluke i410 Hall effect current clamp.

Yo, Eks, babes, remember me in your will … [grin]

Leave a comment

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.


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.


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

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:

, ,


Wouxun KG-UV3D: Enemy Action

Once is happenstance, twice is coincidence, three times is enemy action:

Wouxun KG-UV3D - failure 3

Wouxun KG-UV3D – failure 3

All of the (surviving) battery packs produce 9.0 to 9.2 V, a bit hotter than the pair of fully charged lithium cells the radio expects to see, but the first two radios lasted for six years under that abuse.

This one failed after a few hours. It’s a new radio, but I’m willing to assume I killed the thing and will just eat the cost.

I have no theories about what’s going on, but I must tweak my APRS interface to work with a Baofeng radio I have on the shelf.

From now on, though, both radios will run from their stock battery packs.

Maybe I’m just a slow learner.


Furiosa’s Home Away From Home

You never know who or what you’ll meet on the road:

Mad Max - Home Away From Home

Mad Max – Home Away From Home

A bit more detail:

Mad Max - Home Away From Home - detail

Mad Max – Home Away From Home – detail

Maybe she’s on vacation?

Spotted on one of our walks around the block.

Leave a comment