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.

Author: Ed

Raspberry Pi Shutdown / Start Button

While adding the usual Reset button to a Raspberry Pi destined for a Show-n-Tell with the HP 7475A plotter, I browsed through the latest dtoverlay README and found this welcome surprise:

Name:   gpio-shutdown
Info:   Initiates a shutdown when GPIO pin changes. The given GPIO pin
        is configured as an input key that generates KEY_POWER events.
        This event is handled by systemd-logind by initiating a
        shutdown. Systemd versions older than 225 need an udev rule
        enable listening to the input device:

                ACTION!="REMOVE", SUBSYSTEM=="input", KERNEL=="event*", \
                        SUBSYSTEMS=="platform", DRIVERS=="gpio-keys", \
                        ATTRS{keys}=="116", TAG+="power-switch"

        This overlay only handles shutdown. After shutdown, the system
        can be powered up again by driving GPIO3 low. The default
        configuration uses GPIO3 with a pullup, so if you connect a
        button between GPIO3 and GND (pin 5 and 6 on the 40-pin header),
        you get a shutdown and power-up button.
Load:   dtoverlay=gpio-shutdown,<param>=<val>
Params: gpio_pin                GPIO pin to trigger on (default 3)

        active_low              When this is 1 (active low), a falling
                                edge generates a key down event and a
                                rising edge generates a key up event.
                                When this is 0 (active high), this is
                                reversed. The default is 1 (active low).

        gpio_pull               Desired pull-up/down state (off, down, up)
                                Default is "up".

                                Note that the default pin (GPIO3) has an
                                external pullup.

        debounce                Specify the debounce interval in milliseconds
                                (default 100)

So I added two lines to /boot/config.txt:

dtoverlay=gpio-shutdown
dtparam=act_led_trigger=heartbeat

The fancy “Moster heatsink” case doesn’t leave much room for wiring:

RPi Shutdown Restart Switch - GPIO 3 — RPi Shutdown Restart Switch – GPIO 3

The switch button is slightly shorter than the acrylic sheet, so it’s recessed below the surface and requires a definite push to activate. It’s not as if it’ll get nudged by accident, but ya never know.

I’ll eventually migrate this change to all the RPi boxes around the house, because it just makes more sense than any of the alternatives. Heck, it’ll free up a key on the streaming radio player keypads, although I must move the I²C display to Bus 0 to avoid contention on Pin 3.

For reference, the Raspberry Pi header pinout:

I don’t know if I²C Bus 0 has the same 1.8 kΩ pullups as Bus 1, though; a look at the bus currents will be in order.

2020-01-23

Homage Tek CC Cursor: Pivot Milling
A test to mill the pivot hole in 0.5 mm PETG sheet worked perfectly:

Tek CC – cursor pivot hole milling

The cutter is a 3.175 mm = 1/8 inch router bit, one of a ten-pack that came with the CNC 3018 and to which I have no deep emotional attachment, held in a collet in the Sherline. The hole is 5.5 mm to fit an eyelet. The PETG is taped to a thin plywood scrap.

The hole happened by feeding G-Code manually into LinuxCNC, after touching off XYZ=0 at the center of the pivot and jogging up a bit:
```
g0 y-1.1625
f1000
g0 z0.5
g2 p5 z-1.5 i0 j1.1625
```
Yes, I engraved the hairline using a diamond drag tool on the CNC 3018, cut the cursor outline with a drag knife on the MPCNC, then milled the pivot hole on the Sherline. This seems way over the top, even to me, but that’s just how the tooling worked out right now.

In actual practice, I’d probably mill a stack of cursors and pivot holes on the Sherline in one setup, then engrave the hairlines in a suitable fixture. I think I know enough to fit a spring-loaded diamond drag bit into the Sherline’s 10 mm ID spindle or, worst case, conjure a block for the Z-axis carrier in place of the entire spindle mount.

At least now I can remember what I did to make the hole.
2020-01-22
MPCNC Drag Knife Holder: Lock Screw

While calibrating the MPCNC’s probe camera offset for the drag knife holder, this happened:

Drag Knife – vertical escape

Well, at least it’s centered on the target:

Drag Knife – vertical escape – detail

This happened a few times before, because my fingers don’t fit neatly inside the drag knife holder to tighten the lock ring:

Drag Knife – LM12UU ground shaft – assembled

[Update: The lock ring keeps the holder at a fixed position inside the 12 mm shaft and doesn’t affect the blade directly. When the ring works loose, the threaded holder can rotate to expose more blade and, in this case, stab deeper into the target. ]

So I turned & knurled an aluminum ring, then tapped a 3×0.5 mm hole for a lock screw plucked from the Drawer o’ Random M3 Screws:

Drag Knife – lock screw – side

A view looking along the screw shows a bit more detail around the spring:

Drag Knife – lock screw – front

The general idea is to set the blade extension, then tighten the lock screw to hold it in place, without relying on the original brass lock ring, shown here while cutting a boss for the spring:

Drag Knife – turning spring recess

The lock screw’s knurled handle just barely kisses the NPCNC’s black tool holder ring, so my guesstimated measurements were a bit off. Clamping the knife holder one itsy higher in the tool holder solved the problem.

I cranked on 300 g of spring preload and, squashed like that, the spring’s rate is now 75 g/mm. Cutting at Z=-1 mm should suffice for laminated paper slide rule decks.

The original sizing doodle:

Drag Knife Holder – lock screw ring doodle

The short 18 mm section clears the inside of the LM12UU bearing, although it could be a millimeter shorter. The 19 mm section comes from the 3/4 inch aluminum rod I used, skim-cut to clean it up.

If I ever remake this thing, it needs a major re-think to get all the dimensions flying in formation again.

2020-01-21
Baofeng Bike Helmet Headset Wiring Repair

The audio output wire from the Baofeng UV-5R to my bike helmet headset adapter broke after a year and a half, far longer than I expected:

Baofeng – broken spkr wire

It’s the green one, over on the left, pulled out of the heatstink tubing that should have provided some strain relief, having broken at the solder joint to the resistor.

A quick & easy fix, after which I reapplied even more tape to hold everything in place.

Maybe it’ll last two years this time around …

2020-01-20
Photo Lamp Mount: Moah Plastic!

One of the cold shoe mounts I made for the photo lamps cracked:

$Photo Lamp Mount - fractured$
Photo Lamp Mount – fractured

It’s done in PETG with my more-or-less standard two perimeter threads and 15% 3D honeycomb infill, which is Good Enough™ for most of my parts. In this case, there’s obviously not nearly enough plastic in there!

Redoing it with three perimeters and 50% infill should improve the situation, even though it looks identical on the outside:

Photo Lamp Mount – reinstalled

I didn’t replace the other mount. If it breaks, it’ll get the same 50% infill as this one. If this one breaks, I’ll try 75%.

An easy fix!

2020-01-19
Eyelet Punch Reshaping

The hollow punch included with the 5.5 mm eyelet / grommet set had a rather blunt cutting edge:

Eyelet punch – OEM taper

The rainbow colors along the tapered cut suggested at least token hardening of the edge, so I mounted it in the lathe chuck, deployed a rag over the bed ways to collect the dust, and spun it at a few hundred RPM while freehanding the edge with a Dremel heavy-duty slitting wheel resting on the compound:

Eyelet punch – reshaped

It’s not what you’d call “hollow ground”, but at least the edge doesn’t force the outside of the cut surface quite so far outward.

The Tek Circuit Computer decks get their pivot holes cut with a drag knife on the MPCNC, but I won’t be too embarrassed the next time I deploy this thing.

2020-01-18
HP 7475A Plotter Data Sniffing: socat Serial Port Tee
Some hints and examples provided the socat incantation required to sniff serial data between my Superformula demo program (on the Raspberry Pi) and my HP 7475A plotter:
```
socat /dev/ttyUSB0,raw,echo=0 SYSTEM:'tee /tmp/in.txt | socat - "PTY,link=/tmp/ttyv0,raw,echo=0,wait-slave" | tee /tmp/out.txt'
```
The out.txt file collects data from the program to the plotter, the in.txt file holds data from the plotter to the program, and both files contain exactly and only the serial data, so some interpretation will be required.

With that in hand, tweak the .chiplotle/config.py file to aim Chiplotle at the virtual serial port:
```
serial_port_to_plotter_map = {'/tmp/ttyv0' : 'HP7475A'}
```
This is dramatically easier than wiring a pair of additional hardware serial ports onto the RS-232 connection between the two:

HP 7475A – serial port adapters – hardcore

The adapter stack instantly become a custom cable, although I miss Der Blinkenlights.

The HPGL output to the plotter (out.txt) comes from the Chiplotle driver with no embedded linefeed / carriage return characters, as HPGL uses semicolon command terminators, making it one humongous line impervious to the usual text utilities. In addition, several plotter configuration commands have prefix ESC (0x1b) characters without semicolon separators. Each LB (label) command within the stream ends with a 0x03 ETX character.

While one could fix all those gotchas with a sufficiently complex sed script, I manually separated the few lines I needed after each semicolon, then converted the raw ASCII control characters to displayable Unicode glyphs (␛ and ␃), making it legible for a presentation:
```
head -c 1000 out.txt
␛.B
␛.(;
IN;
OW;OW;OW;OW;
␛.H200:;
SC;
OW;OW;OW;OW;
IP0,0,16640,10365;
OW;OW;
SC-8320,8320,-5182,5182;
SI0.13,0.17;
VS8;
PA5320,-4282;
SP1;
PA5320,-4282;
LBStarted 2020-01-09 18:03:57.494617␃;
SP1;
PA5320,-4382;
LBPen 1: ␃;
SP1;
LBm=1.9 n1=0.71 n2=n3=0.26␃;
SP1;
PU;
PA8320.00,0.00;
PD;
PA8320.00,0.00,
6283.71,24.59,
5980.63,46.81,
5789.79,67.98,
5648.37,88.44,
5535.22,108.34,
5440.50,127.81,
5358.77,146.89,
<<< snippage >>>
```
The corresponding responses from the plotter to the program (in.txt) are separated by carriage return characters (␍) with no linefeeds (␊), so the entire file piles up at the terminal’s left margin when displayed with the usual text tools. Again, manually splitting the output at the end of each line produces something useful:
```
1024
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
0,0,16640,10365
26
18
18
<<< snippage >>>
```
The first number gives the size of the serial FIFO buffer. An inexplicable ten OW; commands from deep in the Chiplotle driver code return the Output Window size in plotter units. No other commands produce any output until the plot finishes, whereupon my code waits for a digitized point from the plotter, with the (decimal) 18 indicating a point isn’t ready.

All that at 9600 bits per second …
2020-01-17