I’m working on a pendant for my CNC, running Grbl 1.1f, and wanted to add smooth multiaxis jogging. I’ve already done a single axis implementation for this project: https://github.com/Billiam/cncjs-pendant-keyboardreader

This took me a little bit to find my way through, so I’m documenting it here.

Here’s a good introduction to the feature: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging

Smooth jogging implementation

This implementation uses the GRBL 1.1 modal jogging functionality, but not the \x85 jog cancel feature, which has not yet been added in CNCjs at the time of this writing. cncjs#512

note: Decimal places below are rounded for simplicity

For a single axis

The goal here is to send frequent, small jog commands at the frequency that we expect grbl to execute them. Without jog cancel, there will be some amount of overtravel equal to 0.5 - 1.5x the update frequency (not counting network latency).

My setup includes some wifi usage, so my update frequency is relatively high at 150ms. For direct-only connections (like a touchscreen connected directly to the cncjs server), this could and should be much lower and will feel more responsive to both starting and stopping.

To move one axis at 500 mm/min, divide the total distance to travel in a minute by the update interval to get the total distance to travel for the interval `(500_("mm")) * (150 // 60*1000) = 1.25_("mm")// 150_("ms")`

And then issue the jog command: $J=G91 X1.25 F500, and then continue issuing the same jog command every 150ms until you want motion to stop.

I issue the first delayed jog command with a reduced delay, about 100ms instead of 150ms. This helps to keep grbl’s buffer full, so that it doesn’t try to decelerate each jog step to a stop, which results in jerky movement. This reduced delay should ideally be based on axis acceleration settings and variation in latency.

When (and if) jog cancelling is added in cncjs, the cancel command could also be added at the end of movement. Ideally, this would also allow you to exceed the requested travel distance for smoother jogging, since a jog stop could be issued when needed.

I haven’t come up with a way to do this safely that wouldn’t result in dangerous overshooting if the jog cancel command failed, or when using multi-axis jogging (below) though.

For multiple axes

Multiple axis smooth jogging is a little more complicated. I also want the Z axis to move about 4 times slower than the much larger X and Y axes, meaning I’ll have a ratio of axis speeds like x:y:z -> 1 : 1 : 0.25.

This is also important if using a multi-axis analog controller like a joystick/gamepad, or some wild 3+axis one: Each direction component will have its own speed relative to the others.

When you give grbl a jog command: $J=G91 X5 Y5 Z5 F500, the total distance traveled will be `D^2=x^2+y^2+z^2`, or about 8.66mm, since it moves in a beeline from the starting position to this offset.

To get the desired jog distance for each axis (with different travel speeds), we have to do some math.

First, we can get the diagonal of a rectangular prism with side lengths of of x1, y1, and z1 from our speed ratios, `D = sqrt(x1^2 + y1^2 + z1^2 + "…")`. This represents the relationship of 1 unit of axis speed to the diagonal travel.

For my speeds, that’s `D = sqrt(1^2 + 1^2 + 0.25^2)`, about 1.436.

To get the actual X travel distance, it’s the X speed ratio (1), the X direction(-1 or 1), and the desired travel speed, and the diagonal component: `X_("axis travel") = (500 * -1 * 1)//D` for a total of ~348mm/min, or -0.87mm/150ms.

The slower Z axis can be calculated the same way: `(500 * 1_("direction") * 0.25_("speed"))//1.436`, or 87 mm/min, but we also know its speed is 0.25 × the X axis speed, so 0.25 × 348: 87 mm/min (0.2175/150ms).

This gives us the jog command: $J=G91 X-0.87 Y0.87 Z.218 F500.

Grbl will plan this move so that all axes arrive at the same time, and everything works great.

However, note that $J=G91 Z.218 F500 would not be correct for this feed rate, and will complete much more quickly than our 150ms interval, causing stuttering motion.

Instead, the feed rate needs to be reduced to the maximum speed of all the axes being moved (in this case, just 0.25 × 500): $J=G91 Z.218 F125.

This applies to multi-axis moves as well. If the speeds being used were y:0.6, z:0.25 (with no X component)

`D_("distance")^2 = 0.6^2 + 0.25^2 = 0.65`
`Y_("axis") = (500 * 1 * 0.6)//D = 461.55_("mm/min") (1.15//150_("ms"))`
`Z_("axis") = (500 * 1 * 0.25)//0.65 = 192_("mm/min") (0.48//150_("ms"))`
`F_("feedrate") = max(0.6, 0.25) * 500 = 300`

Result: $J=G91 Y1.15 Z0.48 F300

Note: This is an older (2+ years old) project, and there are now better third party options available (check Millright groups on facebook), even completely replacing both the Z plate and router mount with significantly beefier aluminum parts free of these issues.

There are a couple of problems with the default router mount on this CNC.

The first is that none of its sides are parallel. When mounted to the Z-axis plate, it visibly dives downward in the front toward the spoilboard.

The surfaces that contact the router are also tapered inward, so any adjustment to the router clamping has a tendency to shift the router in one direction or another.

Both of these issues can be shimmed (somewhat), but since the router mount bolts through the Z plate from behind, it takes a lot of work to disassemble the Z axis, loosen the router mount, shim behind it, tighten back up, and reassemble before checking tram again.

The first pass I made at fixing this used a 3d-printed collar, positioned above the router mount with a few adjustable screws to adjust the offset. The idea was that the collar could be tightly fastened to the router, adjusted, and held down firmly while tightening the router mount’s clamp to make fine adjustment more reliable. This helped, but ultimately not enough. I think this could have worked with an aluminum collar, and with holes threaded from the top into the router mount so that manual downward pressure wasn’t required.

In the end, I replaced the stock router mount with this (well machined) OpenBuilds router mount instead. The diameter is slightly oversized for the DWP611 router I’m using, so I 3d-printed a thin (~1-2 mm) straight shim for it.

To mount this to the router, and allow easier tramming in both the X and Y axes, I’ve designed this plate that will bolt to the Z-plate through the front. This allows shimming in the Y axis by just loosening the plate from the front, adding shims, and tightening back down.

For the X axis, I’ve added overside holes to allow the use of eccentric nuts for adjustment.

This did require drilling and tapping 4 new holes in the stock steel Z-plate, but that went fine going slow and careful (and using a drill press to keep the tap straight).

Here’s the first side cut from 3/8” aluminum. As this is a (not yet installed) tramming plate, please excuse the surface finish.

To cut the opposite side to size, and chamfer the edges, I cut a pocket in scrap MDF both for workholding and to position the part. This mostly worked but I did end with a small gouge on one side, when (I think) the part shifted a little bit.

I also cut these two tiny wrenches to help adjust the eccentric nuts.

Overall, this has made a huge improvement in the time required for tramming/squaring and I’d highly recommend it (or replacing the stock Z plate entirely) if you’re having similar issues.

I’ve released a few projects I’m using for managing projects and games on itch.io.

itchpack

The first is itchpack, commandline, preconfigured wrapper around webpack with some extra utilities.

Itchpack provides a local development environment for game, gamejam, and profile pages on itch.io.

It downloads your current page markup and styles, can render templated data from a data file, prefixes custom- in front of your HTML classes, handles sass/scss compilation, and provides live reloading when working locally.

I used it extensively while working on the game page for Deepdwn.

itch_client

itch_client is a ruby library for interacting with itch.io. There are some functions I needed for the next project which are unavailable in the itch API.

itch_client is a screenscraping client and provides authentication, updating and fetching reward information, as well as purchase and reward redemption logs.

itch-rewards

itch-rewards is a commandline application based on itch_client, meant for automating available game page rewards, especially for community copies.

itch-rewards allows a game developer to set a minimum number of copies that are always available, or to have the number update based on sales (for instance: “Every copy of my game sold makes a community copy available!”), or based on tips above the game price (configurable).

itch-rewards can also update the reward content itself, to show the number of copies that have been made available, or progress to the next copy.

I’m using this in concert with the script used for my desk bell notifications to update available rewards after purchases.

An itch.io project of mine has been getting a little attention recently, and I wanted to get alerts for new purchases, instead of obsessively checking the website. I saw this kickstarter alert desk bell project a few years ago, and thought it would work great.

Here’s my finished project:

It runs a web server waiting for a JSON payload, and then rings the bell the appropriate number of times.

Build

Parts list:

• $3 Wemos D1 clone arduino board
• $5 5v mini solenoid. This is perfect for this use case
• 1k resistor
• TIP120 transistor
• 1n4004 diode
• Electrocookie solderable perfboard (really nice)
• USB breakout board from another project.

To mount the solenoid to the bell frame I 3D printed a small mount. The solenoid frame had two M2 threaded hole that made mounting easier. The mount clips onto the frame, but ought to sit a few mm lower. The nice thing about this design is that the bell can still be used normally if needed… Not sure when I’d need that.

I did a bunch of tests on a breadboard since I’m still new to electronics projects, first with just the solenoid to make sure it would ring clearly and later with the arduino. I did most of the design with a NodeMCU but switched to the smaller Wemos D1 when I ran out of space.

One thing I didn’t anticipate when I started is that the clapper (the part of the bell that swings) sits low into the the bottom base in its resting position. This reduced the available space underneath by about half, so I made a paper template and then cut an arc into one side of the (previously square) perfboard with a jewelers saw.

I also 3D printed this simple mount, mostly to keep any of the circuit from contacting the metal frame. The board holds to it nicely, but I haven’t designed a good mount for it, so I just hotglued it in place for now.

There’s more stuff I’d like to do:

• 3D print the whole base for better mounting points and more space
• LEDs (I have an LED ring that fits really nicely in the diameter of the bell, but there isn’t really enough room for it right now)
• Proper outlet mounting instead of just sneaking a thin cable underneath the base

Software

For the firmware, I’m using arduino fsm to handle state changes and delays, since I want the solenoid to activate for about 150ms and then wait a couple of seconds before it can activate again. I need this to be non-blocking, so that I can also respond to web requests and later do some LED animation. The webserver and wifi code is mostly taken from the default ESP8266 examples.

For some reason, the D1 etc. pin constants did not work for me when using the Wemos D1 board profiles, using the correct GPIO pin instead did, so I didn’t investigate further.

It waits for a request with valid basic auth credentials, and a JSON body with a count value, ex:

curl -s -i -u username:password \
  --header "Content-Type: application/json" \
  --request POST \
  --data '{"count": 2}' 

I’ve just launched Sequence8, a PICO-8 music sequencer toy.

Here’s a video:

You can play with it in the browser at https://billiam.itch.io/sequence8, or download prebuilt binaries.

The copy button will save your song to your clipboard so that you can keep and share them.

To import a song, just paste it in.

Shorter songs fit in a tweet, so if you make something you like, please share it with me!

I picked up PICO-8 in the enormous Itch.io bundle recently, and have been having a lot of fun with it. Sequence8 is my first PICO-8 game.

The platform’s built-in limitations help ensure that games stay small and (roughly) within scope. They can’t be too large in code length, or lexical tokens, nor in sprites, sound, or music. Audio is limited to four channels, the screen is 128px square, there are 16 colors.

Sequence8 is based on another project I never finished, built with Ruby and Gosu.

There, I was able to use several full sized audio samples of real instruments, and dynamically pitch them up. Visual effects could be handled with transparencies and complex masks. I used C libraries for fast quadtree performance for mouse events. Can’t really do any of that in PICO-8 (at least, I can’t).

Here’s some of the build process

Getting started

This is the first prototype. It can play sounds. The current beat scrolls by.

Here I’ve started adding the sprites for the background, scrub bar, and selected notes, and one of the only sprite animations.

I found this post invaluable when trying to work with PICO-8’s color palette.

UI

Without the ability to bind a bunch of arbitrary keyboard shortcuts, I actually had to build out the UI for this as well, which took the vast majority of the project’s development time.

Challenges here were:

• Adding mouse support and mapping screen pixels to UI elements,
• having logical controller navigation for an irregular grid,
• switching between mouse and controller input without breaking something
• having a different number of notes for some instruments,
• adding and removing bars of music (which also adds and removes UI elements)

I probably rebuilt the whole UI system 3 or 4 times, and I’m still not happy with it.

I think this didn’t work well because the tab as a UI concept implies nesting content underneath the tab, but I wanted to have more information about the other instrument tracks visible at once.

Here’s the mouse support. It’s mostly built on top of the controller support, so while the mouse has a pixel position, it also maintains a position within the UI grid, identical to controller handling.

Lighting

I went through a few iterations for lighting effects. Originally, the song progress bar was represented by a full column of sprites, as well as some smaller sprites to both sides that would overlay the background to fake a glowing effect.

In this version, the notes light up for a moment after they’re played. This is handled with a palette swap, and redrawing pixels surrounding each note. It’s wildly expensive, but it looks nice, and fixes issues with static overlays on top of animated images.

I’m doing this in a pretty simplistic way. For a much more performant (and technical approach), here’s a really cool article:
https://hackernoon.com/pico-8-lighting-part-1-thin-dark-line-8ea15d21fed7

In the end, I used a simpler approach, using one level of lighting off to the sides of the

Particles

I started on some particle effects to make the visuals a little more engaging, but ran into further performance issues there. I put together a simple profiler to help track down the specifics.

PICO-8, as a virtual console, has it’s own CPU limits distinct from the host system, and applies extra CPU cost to some operations.

The biggest takeaway here for me was: Limit expensive redrawing, limit deeply nested loops, limit overall particle counts (and make sure that count is up to date, and not from the last animation frame. Whoops)

I think these look nice still, but they’re big, slow and floaty, like each note is shaking down snow. Still nice, but I wanted a more explosive feel.

Here’s a less colorful, and more conservative version. Particles have more starting velocity, and fade faster.

Here’s the final version. Notable changes here:

• Notes are always in front of the particles, and have a bit of an opaque outline around them, making them much more visible when a lot is happening on screen.
• Two or three contrast frames at beginning of the particle burst, making it more distinct and poppy.

I recommend looking through (and supporting) this amazing pixel art resource: https://blog.studiominiboss.com/pixelart