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
Given that you really don’t care about the absolute dimensions, you can generate a positive mold from a height map image and avoid the entire solid modeling process. Having already solved the cookie press problem, this was a quick-and-easy feasibility study…
Start by selecting the logo, growing the selection by a few pixels, and feathering the edges to produce the mold draft. Then apply a square gradient behind the Squidwrench logo to produce the height map for the edge of the mold. This one is scaled at 3.0 pixel/mm and is 100×100 pixel, thus producing a 33 mm square mold:
One could, of course, produce a non-square mold with a different gradient outline shape.
Hand the image to a slightly modified version of the cookie press script (see below) to get an STL file of the mold:
SqWr solid model – oblique view
Feed the STL into Slic3r, hand the G-Code to Pronterface, fire the M2!, and you get a positive mold that looks enough like black chocolate to seem ready-to-eat:
SqWr – mold positive
I have no idea whether that will work as a mold, but I suspect flexy silicone putty won’t reproduce much of the fine plastic filament detail, so the negative mold won’t grab the chocolate. The logo is six threads deep with a little bit of draft, if that makes any difference.
The backing plate is 1 mm thick and the height map is 5 mm stacked atop that. A few iterations suggested using about 0.75 gray for the logo; working backwards says 5 mm = 25 layers @ 0.20 mm/layer, so a depth of 0.25 * 25 is about six threads.
For production use, I’d be tempted to import maybe a dozen copies of the STL into OpenSCAD, mount them on a platform with a gutter and a lip on the outside, and then print the whole positive multi-cavity mold in one shot.
The Bash script that produces the mold strongly resembles my cookie cutter script and contains about as much cruft as you’d expect. Because we need a positive mold, not a negative press, the script doesn’t invert the colors or flop the image left-to-right, nor does it generate the cookie cutter STL around the outside of the press:
The avconv (formerly ffmpeg) image-to-video programs expect sequentially numbered files, with the numbers in a fixed-width part of the file name, thusly: dsc00001.jpg.
ll | head
total 286576
-rwxr-xr-x 1 ed ed 595708 Jan 23 19:14 dsc00940.jpg
-rwxr-xr-x 1 ed ed 515561 Jan 23 19:14 dsc00941.jpg
-rwxr-xr-x 1 ed ed 580190 Jan 23 19:14 dsc00942.jpg
-rwxr-xr-x 1 ed ed 571387 Jan 23 19:14 dsc00943.jpg
-rwxr-xr-x 1 ed ed 573207 Jan 23 19:14 dsc00944.jpg
-rwxr-xr-x 1 ed ed 571086 Jan 23 19:14 dsc00945.jpg
-rwxr-xr-x 1 ed ed 571600 Jan 23 19:14 dsc00946.jpg
-rwxr-xr-x 1 ed ed 571547 Jan 23 19:14 dsc00947.jpg
-rwxr-xr-x 1 ed ed 565706 Jan 23 19:15 dsc00948.jpg
A Bash one-liner loop does the renumbering:
sn=1 ; for f in *jpg ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; mv $f $dn ; done
The results look pretty much like you’d expect:
ll | head
total 286556
-rwxr-xr-x 1 ed ed 595708 Jan 23 19:14 dsc00001.jpg
-rwxr-xr-x 1 ed ed 515561 Jan 23 19:14 dsc00002.jpg
-rwxr-xr-x 1 ed ed 580190 Jan 23 19:14 dsc00003.jpg
-rwxr-xr-x 1 ed ed 571387 Jan 23 19:14 dsc00004.jpg
-rwxr-xr-x 1 ed ed 573207 Jan 23 19:14 dsc00005.jpg
-rwxr-xr-x 1 ed ed 571086 Jan 23 19:14 dsc00006.jpg
-rwxr-xr-x 1 ed ed 571600 Jan 23 19:14 dsc00007.jpg
-rwxr-xr-x 1 ed ed 571547 Jan 23 19:14 dsc00008.jpg
-rwxr-xr-x 1 ed ed 565706 Jan 23 19:15 dsc00009.jpg
Because you’re renaming the files anyway, don’t bother to normalize ’em:
sn=1 ; for f in *JPG ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; mv $f $dn ; done
And, of course, you can fetch ’em from the camera while doing that:
sn=1 ; for f in /mnt/part/DCIM/100MSDCF/*JPG ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; cp -a $f $dn ; done
That leaves the DSC*JPG original files on the camera, where you can delete all of them in one operation when you’re happy with the results.
If you don’t need the full resolution, reserialize and resize each picture on the fly:
sn=1 ; for f in /mnt/part/DCIM/100MSDCF/*JPG ; do printf -v dn 'dsc%05d.jpg' "$(( sn++ ))" ; convert $f -resize 50% $dn ; done
That’s based on combining several hints turned up by the usual Google search.
To assemble a quick-and-simple movie from the images:
avconv -r 30 -i dsc%05d.jpg -q 5 movie.mp4
The image quality certainly isn’t up to what you (well, I) would expect from a 1920×1080 “HD” file, but the Sony HDR-AS30V Zeiss camera lens seems to be a fisheye pinhole (170° view angle, 2.5 mm f/2.8) backed with relentless image compression:
Sony HDR-AS30V Action Camera
Memo to Self: It’s not worth creating and remembering Yet Another Script.
While converting a stop-action series of images from the HDR-AS30V into a movie, I wanted change all the image files on a USB Flash drive from DSC00008.JPG to dsc00008.jpg, so as to simplify typing their names.
Alas, because the camera’s exFAT filesystem cares not one whit about case, the obvious command doesn’t work:
rename 's/JPG/jpg/' /mnt/part/*
/mnt/part/DSC00008.JPG not renamed: /mnt/part/DSC00008.jpg already exists
The Sony HDR-AS30V “action camera” uses NP-BX1 lithium batteries (3.7 V @ 1.24 A·h = 4.6 W·h) that are, of course, a completely different size and shape than any other lithium battery on the planet.
So.
Tweaking a few dimensions in the Canon NB-6L source code, tinkering with the layout of the contact pins, and shazam Yet Another 3D Printed Battery Test Fixture:
NP-BX1 Holder – show layout
It builds nicely, although the contact pin tunnels are a bit too close to the top of the case:
Sony NP-BX1 Holder – on platform
After reaming out the contact pin holes to the proper diameters & depths, then gluing the plugs in place, it works just as you’d expect:
Sony NP-BX1 battery holder
It’s worth noting that the Wasabi charger accepts the batteries upside-down, with the conspicuous chevron against the charger body. It’s definitely not the way all the other chargers work. The keying recesses on the battery (corresponding to the blocks in the solid model) lie along the bottom edge of the contact surface, so flipping the battery over means they’ll hold it in place, but … oh, well.
That grotty Powerpole connector last saw use in some random benchtop lashup. At some point I’ll be forced to start making more of those.
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.
A discussion on the OpenSCAD mailing list about making a rectangular solid with rounded edges having different radii eventually produced this delightful result:
Basic Rounded Cube
Those guys make me feel dumb, because they’re generally solving problems I can’t even imagine, but I know what to do with this solution. One could slice it in half horizontally, emboss a height map defining a logo / picture into the top surface, print it out on your favorite 3D printer, maybe smooth / seal the surface a bit, define it to be a positive mold pattern, cast / pour flexible silicone around it, and get a negative mold for a pourable precious material such as, oh, chocolate.
You could make half a dozen of them, arrange them inside a suitable printed frame, pour the silicone, and get a multi-cavity mold for better manufacturing productivity.
The overall block lacks draft, because the problem it solves presumes you need a block of specific outside dimensions: it overlays three full-size rectangular blocks that define the dimensions. OpenSCAD constructs spheres such that they may be slightly smaller than the defined radius at the poles and, depending on their alignment, a face at the equator may reduce the outer dimension of a surrounding hull.
Given a sufficiently bendy silicone mold, you might not need any draft at all. If you do need draft and you don’t care about a very slightly undersized pattern, remove the internal blocks and increase the XY spacing of the lower four spheres by enough to make the draft come out right.
The grayscale logo / image should have nice smooth transitions that produce suitable draft for the fine details; a bare black-and-white image might not work well. Shallow is good, but that conflicts with 3D printing’s crappy resolution: 1 mm = 10 layers, tops. That might not matter in practice.
You’re supposed to temper the chocolate, but that’s probably more relevant for Fine Art molds.
The Smell of Molten Projects in the Morning 