TinyG edge-next: 126 fixes from a long-overdue bug hunt

TinyG has been quiet for a while. Its last firmware branch, edge-0.97, dates from 2016, and the forum archive is full of reports that never got a fix: a homing cycle that "worked" with a broken switch wire, a stray character that turned a 5 mm move into a 545 mm one, a spindle that kept running after an alarm. We went back and hunted them down.

The result is a new firmware branch, edge-next. It builds on edge-0.97, keeps its settings defaults, and fixes 126 bugs. Every fix comes with a test that reproduces the bug on a real TinyG v8 board and then passes once the fix is in.

Safety first: the fixes that matter most

A motion controller has one job above all others: never move when it shouldn't. These fixes close gaps where TinyG could move unexpectedly or keep going when it should have stopped:

However good the firmware gets, software is not an emergency stop. Every machine needs a hardware E-stop that cuts motor power, within reach of the operator.

Stopping sooner at a limit switch

When a limit switch tripped, TinyG used to start a gentle feedhold from its main loop, using the normal deceleration. Now the switch interrupt requests a stop directly, using the much steeper homing jerk, and the board keeps track of its position through the stop. We measured both versions on the bench with a logic analyzer on the step line, hitting the switch at 10 mm/s:

Before (edge-0.97)After (edge-next)
0 2 4 6 8 10 12 -0.4 -0.2 0 0.2 0.4 0.6 Time from limit switch trip (s) Speed (mm/s) switch trips
Axis speed from the step pulses recorded at 12 MHz, in 5 ms bins. After the fix, travel past the switch drops from 3.34 mm to 1.17 mm and the stop takes 0.21 s instead of 0.54 s. Measured at 10 mm/s; faster moves travel further. (E031)

Smoother starts

From idle, TinyG used to start the first move before it had seen the second one, so it planned a full stop between them even when the path was straight. Now the planner waits a few milliseconds for the next move before starting. Two back-to-back moves now flow into each other instead of stopping in between:

Before (edge-0.97)After (edge-next)
0 2 4 6 8 10 12 0 0.5 1 1.5 2 2.5 3 Time from first step (s) Speed (mm/s)
The same two moves, sent together from idle. Before, the axis stopped completely between them; after, it holds cruise speed through the junction and finishes 0.6 s sooner. A single command sent from idle can now start up to about 50 ms later. (E089)

Where the bugs were

G-code parser
28
Serial input
24
Settings
19
Motion and feedhold
17
Status reports
15
Homing, limits, probing
15
Spindle and PWM
4
Build and tooling
4
The 126 fixes, grouped by the part of the firmware they touch.

A few more worth knowing about:

New features

How it was tested

Every bug started as a failing test. A test harness drives a real TinyG v8 over USB, and each known bug is recorded as a test that's expected to fail. A fix only counts when its test passes on the board, and when the whole suite still passes with it. The harness won't move a motor unless motion is explicitly allowed, and it snapshots the board's settings before each session and restores them afterwards.

Timing fixes like the two above are measured with a logic analyzer on the step, direction and switch lines, sampling at 12 MHz. The raw captures and the scripts that turn them into numbers are kept with the firmware, so anyone can check the results.

Run 1
124
Run 2
100
Run 3
95
Run 4
51
Run 5
27
Run 6
15
Known bugs still reproducing on the bench at each full regression run, from 124 down to 15. The rest were fixed in the final round and verified individually.

Before you upgrade

Most machines will just work better, but a few changes can affect existing setups:

Known issues

A bug hunt this size finds more than it can fix in one go. Still open, and tracked: a suspected race between feedhold and homing (E114), and requests that read alarm, shutd or me actually triggering them (E138), which matters if you write host software. Speed overrides (M48–M51) were never implemented and now return an error instead of being silently ignored.

How to get it

The source is on the edge-next branch of synthetos/TinyG on GitHub, along with the full change log and the test results. It reports firmware build 450.01 ($fb), so you and your sender can tell it apart from the older edge-0.97 (449.01). Back up your settings before flashing, test with an E-stop within reach, and if something doesn't behave, tell us on the community forum.

A browser-based firmware updater is on the way, so you won't need a toolchain to install it. More on that soon.