Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
The general idea is to gut an old Dell Optiplex GX270 and stuff the high-voltage parts of the sewing machine controller inside a well constructed and solidly grounded metal shield inside a not-too-ugly plastic box. It’d be nice to reuse the power control button and status LEDs on the front panel…
The few parts on the front of the through-hole board:
Dell Power Button PCB – component
The copper side, with annotations:
Dell Power Button PCB – copper
The red tracer on the ribbon cable goes to Pin 1, which is a blind key on the PCB.
The LEDs do not have ballast resistors, so those must go on a circuit board somewhere else.
It turns out that the clever idea of moving the swap partition to a USB flash drive had no effect whatsoever; the UI continued to freeze up during OpenSCAD compiles and suchlike, with the drive activity light on solid and not much in the way of swap activity. Sooo, I wondered what would happen with the /tmp directory on non-rotating memory.
Then I spotted a sale on a Samsung 840 EVO 120 GB solid state drive, which seemed like it might improve almost everything in one swell foop. That’s a tiny drive, at least by contemporary standards, but all my data files live downstairs on the file server, so the desktop drive holds just the Xubuntu installation.
It’s worth noting that SSDs tend to fail suddenly and catastrophically, so that if the only copy of your data is on that drive, there is no recovery. In this case, I’d lose some configuration that changes with every installation, a few locally installed / compiled-from-source programs, and little else.
The nice thing about transferring a Linux installation: boot a live CD image (I used Ubuntu 14.04LTS, the same as the desktop box), copy the files to the new drive, set up Grub, and you’re back on the air. That recipe worked fine, although I used rsync -au to copy the files and then updated /etc/fstab with the SSD’s new UUID (rather than duplicate a supposedly unique ID).
The Grub recipe does require a bit of delicate surgery, so I removed the OEM hard drive and rebooted the live CD image before doing this. If the SSD fell victim to a finger fumble, I could just start over again:
sudo mount /dev/sda1 /mnt
for f in dev proc sys usr ; do sudo mount --bind /$f /mnt/$f ; done
sudo chroot /mnt
sudo update-grub
sudo grub-install /dev/sda
sudo grub-install --recheck /dev/sda
exit
for f in dev proc sys usr ; do sudo umount /mnt/$f ; done
sudo umount /mnt
Then reboot from the SSD and It Just Worked.
Dropbox and DigiKam noticed the UUID change and asked for advice; there’s no need for re-registration, re-activation, or re-authorization.
The overall time from boot to login isn’t much shorter, because of the tedious delay while the network and the NFS shares get up & running, but the desktop UI startup zips right along.
The same OpenSCAD compile that previously brought the UI to a halt has no effect, so I hereby declare victory. I think the complex solid models that used to take forever will see much the same speedup.
The Dell hard drive (an ordinary 7200 RPM 3.5 inch brick) lies abandoned in place under the fancy black shroud; the Optiplex 980 layout butts the drive’s right-angle SATA connectors hard against the CPU heatsink and offers no spare SATA power connectors. There was just enough room to wedge the SSD above the PCI connectors, where it won’t get into any trouble:
Samsung 840 EVO SSD in Optiplex 980
The hard drive contains the never-used Windows 7 partition and the corresponding recovery / diagnostic partitions; keeping the drive with the Optiplex chassis seems like a Good Idea.
Depending on a solid model’s complexity, OpenSCAD will sometimes chew through system memory, consume the entire swap file, and then fall over dead. In an attempt to work around that situation, I recently jammed a 32 GB USB drive into the back of the box, turned it into a swap device, and then told the kernel to back off its enthusiasm for swapping.
Format the USB drive as a swap device:
sudo mkswap /dev/sd?? #--- unmount it before you do this!
Setting up swapspace version 1, size = 31265292 KiB
no label, UUID=0f559a8c-67b7-4fa3-a709-17aeec3104c4
Add it to /etc/fstab and set swap priorities:
# swap was on /dev/sdb3 during installation
UUID=e8532714-ad80-4aae-bee7-a9b37af63c8c none swap sw,pri=1 0 0
UUID=0f559a8c-67b7-4fa3-a709-17aeec3104c4 none swap sw,pri=5 0 0
Turn it on:
sudo swapon -a
Following those directions, dial back the kernel’s swappiness and limit the file cache growth:
For whatever reason, WordPress turns underscores into blanks, so those obvious typos aren’t, really.
And then it should Just Work.
The box has 4 GB of RAM and, under normal circumstances, doesn’t swap at all, so I expect the USB drive should kick in only for extreme OpenSCAD models. The swappiness tuning should help during ordinary operation with large file operations.
I have no results to report, but if something blows up, I know what changed…
It turns out that the audio-over-HDMI/DisplayPort channel which, for whatever reason, is the only way to get audio out of the Optiplex 980 with the big Dell U2711 monitor starts up AT MAXIMUM VOLUME! regardless of the GUI’s Pulseaudio mixer setting that’s diligently saved-and-restored across sessions. That makes a certain perverse sense, as the digital-to-analog converter & power amp live inside the monitor.
Manually adjusting the GUI mixer by one click, either up or down, forces the new setting out over the digital link to the monitor, after which the audio output corresponds to the mixer; I never remember that until just after some dipshit auto-play video lights up with a fanfare.
Setting the mixer to the same value doesn’t force an update, so the obvious solution (at least to me) of sending a fixed initial value doesn’t work; it’s optimized away. I think that’s why the initial update doesn’t happen: the stored volume is the same as the, ah, stored volume, so there’s no need to tell the monitor.
The automatic solution involves putting two more commands in my ever-growing ~/.config/startup.sh:
That sets a rational level (which might be the same as the existing one from the previous session), then changing it by one tiny click to force the new value out to the monitor.
The Token Windows box (which runs the few programs that don’t get along with Linux) doesn’t get a lot of attention, but a recent update changed their stylin’ graphic CPU meter to something a bit less, mmm, smooth:
For some unknown reason, one of the very rare updates to the Ubuntu 10.04 LTS infrastructure (for LinuxCNC 2.5.3 on my Foxconn D510 box, driving the Sherline mill) stopped supporting the system board’s built-in NIC: networking stopped working. The only symptom was that the NIC didn’t respond and all the usual tricks were unproductive.
After some fruitless searching, I took the easy way out:
NIC added to Foxconn D510 PC
That’s the backside of an ancient NIC using the classic Tulip driver. It used to have a full-size bracket, which I chopped off, bent, and filed to suit, much as with that one in the D525.
Fired it up, the kernel automagically picked the proper driver, and networking Just Worked again.
The backup scripts running on Mary’s folks’ PC kvetched on each backup:
WARNING: Some files and/or directories in /home/ only transferred partially during rsync operation
WARNING: /usr/bin/rsnapshot daily: completed, but with some warnings
Poking around showed that the problem came from the .gvfs “directory” tucked into each home directory, which produced this unenlightening ls -al result:
d????????? ? ? ? ? ? .gvfs
Come to find out that it’s an old problem with mysterious causes that should be fixed by now; evidently I triggered it by installing basic Ubuntu-with-Unity and then installing the Xbubuntu desktop. Or something like that.
Anyhow, the solution workaround involves an rsnapshot configuration entry that bypasses that directory:
The Smell of Molten Projects in the Morning 