I’ve shared this project in a few places, but like many other projects, I’ve neglected to add it to this blog.

I’m currently using CNCjs with my GRBL-based CNC, and while there are some really nice pendants out there for 32-bit grblHAL boards, the options for physical devices and interfaces for older 8 bit boards like mine, with CNCjs, are very limited.

Previous to this, I was using another pendant I put together, cncjs-pendant-keyboardreader, using a wireless keyboard.

This supported smooth jogging, and a handful of macros and preset actions, but with no visual feedback, it was difficult to remember all of the commands and shortcuts.

I found that if I hadn’t used the machine in a while, I completely forgot which keys did what. Was it control or alt for faster jogging? How do you dismiss notifications or unpause a job? And so on.

I set out to create a more usable web interface for touch devices, with the intention of also supporting a physical Streamdeck.

The Streamdeck is interesting. At its heart, it’s a single, self-contained LCD touchscreen, with a clever approach to physical buttons. The buttons themselves are transparent, with a membrane that runs along the outside edge of the button to activate the screen when pressed, giving the illusion of multiple discrete displays.

Being self contained, you can send images in jpeg format to the device to populate the display, instead of treating it as an external monitor. This is great for my use, since I can continue to use a headless Raspberry Pi for performance.

The result is the (creatively named) cncjs-pendant-streamdeck, an obsessively configurable frontend for CNCjs with these goals in mind. The included configuration is for a 3x5 Streamdeck, but it supports both the mini (2x3) and XL (4x8). I have not tested it with newer devices with secondary display areas, since I don’t own one.

Out of the box, it supports:

• Multi-axis smooth or incremental jogging. The web interface supports multitouch, so two (or more) jog direction buttons can be used at the same time.
• Multiple pages
• Templated text to display CNC state, like current position
• Conditional button display/disabling
• Custom images/colors
• Execute macros (ex: for probing) and cncjs custom commands
• Execute actions on press, release, or button hold
• Display and manage alarms, holds, and pause events
• Job selection from the CNCjs watch folder
• Numeric input
• (Animated) gcode rendering and thumbnails

It can be used with or without a physical Streamdeck, with nice, large buttons for use on a phone or tablet.

From a development perspective, the project is built as a Vue application, with a separate nodejs renderering pipeline for the Streamdeck output, and a handful of adapters to abstract the differences between the Node and Web display. This allows all of the business logic (and configuration) to be shared between the two display types.

Ideally, I’d love to build a visual configurator to generate the config file, but honestly there hasn’t really been enough interest to warrant the effort.

That said, the project is extensively documented, and I’ve published the cncjs-pendant-streamdeck-validator package, which can be used from the commandline, in a javascript project, or you can use the schema directly, so there should be enough there for somebody to build that tool if desired.

I installed Home Assistant with Dokku. It was very easy, but there were a couple of gotchas that slowed it down a bit.

Setup

Create a new homeassistant app in Dokku

dokku apps:create homeassistant

Set the timezone

dokku config:set homeassistant TZ=America/Chicago

Create a folder that will be used for Home Assistant configuration

mkdir /path/to/my-config
dokku storage:mount homeassistant /path/to/my-config:/config

Home Assistant uses its own init procedure, and we need to disable automatic init

dokku scheduler-docker-local:set homeassistant init-process false

Initialize Home Assistant app from its docker image

dokku git:from-image homeassistant ghcr.io/home-assistant/home-assistant:stable

Dokku didn’t correctly configure the correct port for the container, so:

Remove the default proxy port if needed:

dokku proxy:ports-remove homeassistant http:80:5000

Add the correct proxy port:

dokku proxy:ports-add homeassistant http:80:8123

To enable autodiscovery, Home Assistant needs to be connected to the host network. Other than autodiscovery, I had no issues using the default network and normal port mapping.

You can enable this option in dokku with

dokku docker-options:add homeassistant deploy,run "--network=host"

Once Home Assistant is on the host network, dokku’s zero-downtime restarts will fail when updating or restarting the service, because the bound port will already be in use.

Zero downtime restarting can be disabled with

dokku checks:disable homeassistant

Updating Home Assistant

To update Home Assistant, use git:from-image again, pointing to the newest SHA digest for your architecture (instead of using the :stable tag)

dokku git:from-image homeassistant ghcr.io/home-assistant/home-assistant@sha256:<shadigest>

You can get this digest from docker hub for your architecture: docker hub, or you can pull the image locally and use:

docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/home-assistant/home-assistant:stable

My favorite automations (so far) turn my printer’s light off automatically after a print completes, and lets me know to open windows when the weather is cooler and less humid outside, and air quality is ok.

I do a lot of multicolor 3d printing, where more than one color is printed on the same layer using manual filament swapping, and I wanted to share some tips that I haven’t seen collected everywhere.

Some of this applies to layer/height-based color swapping, but this is directed specifically at the above, AKA the poor-man’s MMU.

This is pretty easy to set up in PrusaSlicer, and probably other slicers as well, but I don’t have as much experience with them.

Setup

First, create a new printer with two (or more) configured extruders, one extruder for each color you’d like to use in your print.

In the Custom G-code tab, set the Tool change G-code value to m600.

This triggers a manual filament change when changing extruders.

Lastly, import your multipart object, select it and press the “Split To Parts” button in the toolbar.

Next, assign the appropriate extruder to each part in the part list.

Extruder 1 will be used first, so use that one for the background color, and use extruder 2 for your inlay. Otherwise you’ll end up doing an extra color swap.

Tip 1: Minimizing filament swaps

Without an automatic filament changer, you’ll may want to minimize the number of manual filament swaps.

For top or bottom-layer inlays, I usually stick to a total of two colors, two layers thick. This allows two-color prints with a total of two filament changes.

Additional colors add one more swap per color per layer.

number_of_swaps = layer_count * (colors - 1)

Tip 2: Filament opacity

For text inlays and similar small details, you’ll want to use a filament that is as opaque as possible. Transparent colors, especially over dark “background” colors, will appear dim and muddy.

When using a less opaque filament, a white or light colored filament for the background will be more forgiving.

A small test print is recommended to make sure your colors will look OK at the layer thicknesses you’re using, especially if your prints are large or complex.

Tip 3: Use a wipe tower

This actually serves two purposes. Obviously, it allows a reliable color change with configurable purge volumes without as much baby sitting while changing filament, but it also has another side effect.

Without a wipe tower, the m600 filament change event will take place when the extruder has completed the last object of that color for a layer, and when that’s complete, the extruder will return to the last location, before moving on to the next object location.

This can cause a small, circular dot of the new filament color in the last object location, which can be pretty noticeable with certain colors, or when printing on the top layer.

With a wipe tower, the extruder will first be moved to the wipe tower area, then initiate swap filament, and then will return to the wipe tower for purging, which prevents the wrong-color-spot.

The tower is still very efficient for prints where the bottom layer(s) have a color change, since the wipe “tower” will only be two layers thick.

Tip 4: Z-hop

On layers where there will be filament swapping, add a small Z-hop. This prevents any small blobs from getting dragged across the printed surface. This is not usually noticeable with single color prints, but can stand out more with contrasting colors. The z-hop setting prevents this by raising the extruder up a little bit for travel moves.

In PrusaSlicer, this is configured per extruder (so you’ll need to set it more than once) under Printer Settings -> Extruder x, under “Lift Z”. You’ll need to enable retraction if you don’t already, or the setting will be disabled. You can limit the range where Lift Z is enabled in the setting below it.

I’ve been using CascadeStudio recently for parametric modeling (like this) and needed a way to center some dynamic text, which isn’t implemented currently.

Fortunately, a user on github documented a way to get the boundary box of a solid shape here: this discussion post, which makes centered (or right-aligned) text easy.

// https://github.com/zalo/CascadeStudio/discussions/86#discussioncomment-506883
const getBounds = shape => {
    const bmin = { x: Infinity, y: Infinity, z: Infinity },
        bmax = { x: -Infinity, y: -Infinity, z: -Infinity };

    ForEachFace(shape, (index, face) => {
        ForEachVertex(face, (vertex) => {
            const pnt = oc.BRep_Tool.prototype.Pnt(vertex);
            const x = pnt.X(), y = pnt.Y(), z = pnt.Z();

            if (x < bmin.x) bmin.x = x;
            if (y < bmin.y) bmin.y = y;
            if (z < bmin.z) bmin.z = z;

            if (x > bmax.x) bmax.x = x;
            if (y > bmax.y) bmax.y = y;
            if (z > bmax.z) bmax.z = z;
        });
    });
    return [bmin, bmax];
}

// create the text shape
const textShape = Text3D("hello!", 10, 0.1);

// get the minimum and maximum bounds for the text
const [min, max] = getBounds(textShape);
const width = max.x - min.x;
const height = max.z - min.z;

// translate the text by half the width and height
Translate(
    [-width / 2, 0, -height / 2],
    textShape,
    false);

Demo link

I built this last year, but completely forgot to post about it. As such, it’s a bit detail-light.

Reasoning

I was looking for a small keyboard that I could use to sound out musical phrases or chords, while learning other instruments.

Notably, I wanted:

• 1.5 to 2 octaves of notes
• Standard piano layout
• Small enough to fit in my desk drawer, around 10.5” wide by 9” deep
• Two or more note polyphony
• Buttons for keys (rather than a stylophone)
• Close enough to accurate tuning

There are some midi controllers that meet these requirements, but I was looking for something standalone, with it’s own speaker.

I couldn’t find any commercial keyboards that did those things, but I did eventually stumble on the (delightful) Oskitone site.

They have a number of fun noise makers, including the poly555, an analog keyboard based on twenty 555 timers, and the scout, a hackable microcontroller-based synth.

A number of these also have 3d models available for 3d printing:

https://www.thingiverse.com/oskitone/designs

I settled on the Okay2 synth, as it had the dimensions I was looking for (around 9.25” wide by 4.25” deep), two octaves of keys, and it looks cute.

Build

Instead of using Oskitone’s components, I chose to build out the internals myself. Initially, my goal for this was just to allow more notes to be played simultaneously, but the features got away from me a little as the project went on.

It currently supports the following:

• full polyphony
• eight sampled instruments, pulled from Microsoft’s sound fonts
• selectable octave
• volume control
• headphone jack (as soon as I hook it up. I may never)

Components

For the controller, I settled on the Teensy 4.1, a high powered ARM development board, and their audio adapter board.

I chose a 2.5w class D amplifier and a 4ohm 3w speaker from Adafruit, as well as some 8 way rotary selector switches, and a potentiometer.

I purchased the PCBs for the keyboard itself from the designer. While it acts as a resistor ladder by default, I had enough open pins on the Teensy to allow one input per key, so I didn’t bother to wire up a matrix.

Ideally, I’d have had a couple of custom PCBs made that would have simplified the wiring and build a lot, but at the time I had not done so before.

I made a handful of tiny changes to the case to accommodate my parts, mostly adding board standoffs in the right location, moving and adding potentiometer/switch holes in the lid, and resizing the hole for the speaker to match the one I used.

I soldered everything together on a protoboard.

For power, I’m using 4 rechargeable AAA batteries.

Software

The project code is available here: https://github.com/Billiam/okay-teensy

All together now

Initial breadboard testing

Done!