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
Being that type of guy, I want a visible indication that the firmware continues trudging around the Main Loop. The standard Arduino LED works fine for that (unless you’re using hardware SPI), but the Adafruit 2.8 inch Touch-screen TFT LCD shield covers the entire Arduino board, so I can’t see the glowing chip.
Given a few spare pixels and the Adafruit GFX library, slap a mood light in the corner:
Adafruit TFT – heartbeat spot
The library defines the RGB color as a 16 bit word, so this code produces a dot that changes color every half second around the loop() function:
millis() produces an obvious counting sequence of colors. If that matters, you use random(0x10000).
A square might be slightly faster than a circle. If that matters, you need an actual measurement in place of an opinion.
Not much, but it makes me happy…
There’s an obvious extension for decimal values: five adjacent spots in the resistor color code show you an unsigned number. Use dark gray for black to prevent it from getting lost; light gray and white would be fine. Prefix it with a weird color spot for the negative sign, should you need such a thing.
Hexadecimal values present a challenge. That’s insufficient justification to bring back octal notation.
In this day and age, color-coded numeric readouts should be patentable, as casual searching didn’t turn up anything similar. You saw it here first… [grin]
Now that I think about it, a set of tiny buttons that control various modes might be in order.
Aren’t those just the ugliest buttons you’ve ever seen?
The garish colors identify different functions, the crude shading does a (rather poor) job of identifying the states, and the text & glyphs should be unambiguous in context. Obviously, there’s room for improvement.
The point is that I can begin building the UI code that will slap those bitmaps on the Arduino’s touch-panel LCD while responding to touches, then come back and prettify the buttons as needed. With a bit of attention to detail, I should be able to re-skin the entire UI without building the data into the Arduino sketch, but I’ll start crude.
The mkAll.sh script that defines the button characteristics and calls the generator script:
It turns out, for some reasons that aren’t relevant here, that I’ll be using the Adafruit Arduino LCD panel for the sewing machine control panel, at least to get started. In mulling that over, the notion of putting text on the buttons suggests using getting simple pictures with Unicode characters.
Herewith, some that may prove useful:
Needle stop up: ↥ = U+21A5
Needle stop up: ⤒=U+2912
Needle stop down: ⤓ = U+2913
Needle stop any: ↕ = U+2195
Needle stop any: ⟳ = U+27F3
Needle stop any: ⇅ = U+21C5
Rapid speed: ⛷ = U+26F7 (skier)
Rapid speed: 🐇 = U+1F407 (rabbit)
Slow speed: 🐢 = U+1F422 (turtle)
Dead slow: 🐌 = U+1F40C (snail)
Maximum speed: 🏃 = U+1F3C3 (runner)
Bobbin: ⛀ = U+26C0 (white draughts man)
Bobbin: ⛂ = U+26C2 (black draughts man)
Bobbin winding: 🍥 = U+1F365 (fish cake with swirl)
Of course, displaying those characters require a font with deep Unicode support, which may explain why your browser renders them as gibberish / open blocks / whatever. The speed glyphs look great on the Unicode table, but none of the fonts around here support them; I’m using the Droid font family to no avail.
Back when I started fiddling with 3D printed chain mail, the whole process from model to plastic worked wonderfully well. That continued with the larger sheets, but now, occasionally, the OpenSCAD model would produce weirdly sliced links. Depending on nothing repeatable, some links wouldn’t bridge correctly: the thread paths in the bottom layer across the gap would mysteriously stop just short of one pillar, return to the start, and leave an unsupported shelf that would, of course, fall into the gap.
Shortly before Christmas, I managed to get a consistent failure that manifested differently: upon loading the STL file, Slic3r would quietly perform dozens of automatic corrections that (sometimes!) produced bizarrely distorted results. Feeding a failing model into Meshlab showed an irregular assortment of “self intersecting faces”, highlighted in red:
Chain Mail Square Armor – open – 2×2 – Meshlab self-intersecting faces
Although all four outer links in that image come from the same OpenSCAD module with identical sizes, they don’t all exhibit the same problem in the (nominally identical) faces on each of their four corners. In fact, those faces come from the intersection of two square slabs, carefully sized and positioned to avoid creating coincident planes:
Chain Mail Link – Outer shape
The central opening comes from a similar, slightly smaller, intersected-squares shape, but all four interior corner faces in each link show that they’re self-intersecting.
The STL looked fine in Meshlab, except for the highlit self-intersecting faces, so the geometry seemed OK.
When Slic3r autocorrected the “problems”, it apparently removed one vertex on the bottom surface of each bar, deleted the triangles connected to that vertex, then repaired the mesh to produce a delightfully symmetric pattern:
Chain Mail Square Armor – open – 2×2 – Slic3r corrections
Although the links are resolutely symmetric, Slic3r seemed happy with the identical vertices at the other end of the bar.
Unfortunately, the resulting G-Code won’t produce good links:
Chain Mail Square Armor – open – 2×2 – first layer G-code visualization
So, shortly before Christmas, I filed an issue on OpenSCAD’s Github repository.
The ensuing discussion showed that Meshlab flags faces as “self intersecting” when they have different vertices, even if their values are numerically equal, as well as vertices that differ by teeny amounts. Slic3r applies slightly different criteria to vertices & faces when it automagically corrects “problems” in the STL file, so that Meshlab may:
Highlight faces that don’t bother Slic3r
Apply the same highlight to faces that cause horrible problems
I don’t profess to understand much of that and may have the details wrong, but, apparently, OpenSCAD formerly used quantized coordinates that ensured all vertices within a tiny volume would have the same numeric value. In particular, all three faces that meet at a common point would, in fact, have numerically equal coordinate values for that point. The STL file format consists of a list of separate triangles, each with three coordinates for each of the three axes, and (without quantization) it was entirely possible for each of the three triangles with a common point to have three very slightly different positions for that point.
In theoretic terms, quantized coordinates cause horrible problems during geometric manipulation, because numeric values that aren’t exact can make repeated transformations come out wrong; running an object through a transformation and it’s inverse might not yield an object identical to the original one.
In practical terms, it seems that slicers and STL repair algorithms can reach incorrect conclusions based on minute differences produced by floating-point operations and numeric-to-text conversions. Those differences depend on slight changes in position, rotation, and size, so doing anything to the model produces completely different results.
That notwithstanding, the day after Christmas brought a new OpenSCAD version that uses quantized coordinates. A bit of rummaging in the source shows that the 3D grid (defined in src/grid.h) isn’t all that coarse:
const double GRID_FINE = 0.00000095367431640625;
STL files don’t carry units, so that could be in either millimeters (the Slic3r / RepRap convention) or inches (Sketchup, but we won’t go there). It’s exactly 1/10242, in case you were wondering, which produces a 5% speedup in the geometry engine compared to the more human-readable 1/10002.
With that commit in hand, all the chain mail links slice perfectly again.
I recently exhumed an Iomega 500 GB Home Network Hard Drive (model MDHD-500-N) from the Big Box o’ Drives, with the intent of dumping video files from the Sony HDR-AS30 helmet camera thereupon.
Remember Iomega of ZIP Drive fame? Seems EMC Borged ’em a while back, collided with Lenovo, discarded all the old hardware support, and that’s the end of that story.
Exhuming the setup password from my backup stash wasn’t worth the effort, so I experimentally determined that holding the Reset switch closed while turning the drive on blows away the existing configuration. It woke up, asked for an IP address, got 192.168.1.52 from the DHCP server (you can find that by checking the router’s tables), and popped up the administration console at 192.168.1.52:80 as you’d expect.
The userid will always be admin, but you can change the password from admin to whatever you like; you may safely assume I have done somewhat better than what you see below.
Twiddling the configuration through the IOmega web-based console:
Device name: IOMEGA-500MB (for lack of anything more creative)
Group name: WHATSMYNET
Password: not-admin
Drag the date/time into the current millennium
Time Zone: GMT-5:00
Time Server: 0.us.pool.ntp.org
Static IP: 192.168.1.10 (suitable for my network)
Gateway & DNS as appropriate
Windows File Sharing enabled for the PUBLIC directory
FTP turned off
Sleep time: 10 minutes
Changing either the IP address or the password requires logging in again, of course.
I reformatted the drive, just to be sure.
Then, after a bit of Googling to remember how all this works…
A line in /etc/hosts (left over from the last time I did this) gives the new static IP address:
192.168.1.10 nasty
Install the cifs-utils package to enable mounting the drive.
Create a mount point:
sudo mkdir /mnt/video
Create a file (/root/.nas-id) holding the super-secret credentials used to gain access to the drive:
domain=WHATSMYNET
username=ed
password=not-admin
Then restrict the file to the eyes of the root user:
sudo chmod 700 /root/.nas-id
It’s not clear that the username or domain really make any difference in this situation, but there they are.
Define where and how to mount the network drive with a new line at the bottom of /etc/fstab, which refers to the aforementioned super-secret credentials file:
Mounting it with my userid gives the shared directories & files proper permissions for me (and nobody else, not that anybody else around here cares).
So the manual mounting process looks like this:
sudo mount /mnt/video
Adding the user mount option would eliminate the sudo, but manual mounting won’t be necessary after a normal boot when the automagic startup script does the deed.
The drive must have the noauto attribute to prevent the upstart Pachinko machine from trying to mount the network drives before the network comes up. Actually mounting the drive at the proper time requires an additional line in /etc/init/local.conf:
description "Stuff that should be in /etc/rc.local"
author "Ed Nisley - KE4ZNU"
start on (local-filesystems and net-device-up IFACE=em1)
stop on shutdown
emits nfs-mounted
script
logger Starting local init...
logger Mounting NFS (and CIFS) filesystems
mount /mnt/bulkdata
mount /mnt/userfiles
mount /mnt/diskimages
mount /mnt/music
mount /mnt/video
initctl emit nfs-mounted
logger Ending local init
end script
The reason the drive wound up in the Big Box o’ Hard Drives was its lethargic transfer speed; copying a 4 GB video file from either the MicroSDXC card (via an SD adapter) or the previous 750 GB USB-attached hard drive to the IOmega NAS trundles along at a little over 6 MB/s. The camera stores 25 Mb/s = 3 MB/s of data in 1080p @ 60 fps, so figure 1/2 hour of copying per hour of riding. The USB drive can write data from the aforementioned MicroSDXC card at 18 MB/s, so the card and USB interface aren’t the limiting factors.
I’m not (generally) in a big hurry while copying files from the camera’s SD card, because that’s now automated:
#!/bin/sh
thisdate=$(date --rfc-3339=date)
echo Date is [$thisdate]
# IOmega NASalready mounted as /mnt/video in fstab
mkdir /mnt/video/$thisdate
sudo mount -o uid=ed /dev/sdb1 /mnt/part
rsync -ahu --progress /mnt/part/MP_ROOT/100ANV01/ /mnt/video/$thisdate
if [ $? -eq 0 ] ; then
rm /mnt/part/MP_ROOT/100ANV01/*
sudo umount /mnt/part
fi
I’ve been discarding the oldest month of videos as the USB hard drive fills up, which will happen a bit more often than before: the drive’s 466 GB can hold barely 35 hours of ride video.
The Smell of Molten Projects in the Morning 