Henrik Muehe 0493a4ddc7 Rename W axis -> A axis everywhere (with migration)
Auxiliary axis is the auxcnc-driven stepper exposed to gplan as A,
not W. Half the stack already used A (gcode, DRO row, soft limits,
homing); the other half (settings tab, macros, internal field
names) still said W which was confusing.

Renames:
  - aux.json fields:       min_w/max_w        -> min_mm/max_mm
  - svelte component:      WAxisSettings      -> AAxisSettings
  - settings tab slug:     #w-axis            -> #a-axis
  - js view module:        w-axis-view.js     -> a-axis-view.js
  - pug template:          w-axis-view.pug    -> a-axis-view.pug
  - macros:                w_down.nc/w_up.nc  -> a_down.nc/a_up.nc
                           'W Down'/'W Up'    -> 'A Down'/'A Up'
  - css class & ids:       .w-axis-settings   -> .a-axis-settings,
                           min_w/max_w form ids match field names
  - internal js identifiers and comments

Migration:
  - AuxAxis._migrate_legacy_fields() promotes min_w/max_w in aux.json
    on every load and persists the upgraded form, so existing
    installs come out clean on first restart.
  - Config._upgrade() renames macro file_name and display name in
    every config.json load, so a stale in-memory copy can't
    reintroduce the W names. Ships with a save right after.

The auxcnc ESP wire protocol verbs (WPOS/HOMED) are unchanged - they
are wire-format identifiers, not user-facing labels.
2026-05-03 13:37:16 +02:00
2026-04-30 11:17:03 +02:00
2026-04-30 21:33:48 +02:00
2020-08-27 23:20:27 -04:00
2020-08-27 23:20:27 -04:00
2020-08-27 23:20:27 -04:00
2025-09-21 01:57:17 +05:30
2025-09-21 01:57:17 +05:30
2020-08-27 23:20:27 -04:00
2020-08-27 23:20:27 -04:00

OneFinity CNC Controller Firmware (W-axis fork)

This is the OneFinity / Buildbotics bbctrl firmware with a virtual W axis driven by an auxcnc ESP32 over USB serial. See docs/AUX_W_AXIS.md for the design and config.

Layout

src/avr/        AVR firmware (motion controller, AtxMega)
src/boot/       AVR bootloader
src/bbserial/   Linux kernel module for the bbserial driver
src/py/bbctrl/  Python control daemon (Tornado + websockets)
src/js/         Vue.js UI (legacy)
src/svelte-components/  Newer Svelte UI for dialogs and settings
src/pug/        Pug templates compiled into build/http/index.html
src/resources/  Static assets and config templates
scripts/        Install / update / RPi build helpers
docs/           Architecture, dev setup, W-axis docs

Build & flash (quick path, macOS or Linux)

The full build (make) requires avr-gcc, but the controller and UI only depend on the Python + web parts. If you're shipping a UI/Python change you don't need the AVR toolchain.

Prerequisites

  • Node.js (any recent LTS) with npm
  • Python 3 with setuptools
  • npm install once at the project root (this is wired into the node_modules Make target, but on a fresh checkout it's clearer to do it explicitly)
npm install
(cd src/svelte-components && npm install)

macOS gotcha: esbuild platform pin

The Pi build leaves node_modules/esbuild pinned to linux-arm64, which won't run on Darwin. If npm run build inside src/svelte-components complains about esbuild, reinstall it for the host:

cd src/svelte-components
rm -rf node_modules/esbuild
npm install esbuild@0.14.49 --no-save

(Use the version that matches package-lock.json.)

Build the web UI + Python sdist

# Build the Svelte components
(cd src/svelte-components && npm run build)

# Render pug templates and copy assets into build/http
make all          # AVR step will fail without avr-gcc; safe to ignore
                  # if you didn't change anything under src/avr or src/boot

# Package
./setup.py sdist
ls dist/bbctrl-*.tar.bz2

make pkg is the canonical target but it tries to build AVR first. On hosts without avr-gcc, run the steps above directly.

If bbctrl-*.tar.bz2 is missing src/bbserial/bbserial.ko, copy the prebuilt .ko from a previous official release into src/bbserial/ before running setup.py sdist (the install script on the controller just installs the existing module if a newer one isn't shipped).

Flash to a controller

curl -X PUT -H "Content-Type: multipart/form-data" \
  -F "firmware=@dist/bbctrl-1.6.7.tar.bz2" \
  -F "password=onefinity" \
  http://onefinity.local/api/firmware/update

…or use the Make target:

make update HOST=onefinity.local PASSWORD=onefinity

The controller stops bbctrl, untars the package, runs scripts/install.sh, and brings the service back up. Total downtime is ~30-45s. Watch progress at http://<host>/ (you'll get 404s while bbctrl restarts, then the new UI).

Verify the flash

curl -s http://onefinity.local/ | grep -c "OneFinity"
curl -s http://onefinity.local/api/aux/status   # if W axis is enabled

Build & flash (full path, Debian/Linux)

For AVR + GPlan rebuilds, see docs/development.md. That path uses qemu + chroot to cross-compile gplan for ARM and needs the gcc-avr / avr-libc toolchain.

W axis (auxcnc)

This fork adds a virtual W axis. See docs/AUX_W_AXIS.md for:

  • G-code surface (G28 W0, G1 W25, etc.)
  • The G-code preprocessor and hook architecture
  • aux.json keys
  • REST API (/api/aux/*)
  • UI surface (jog row in Control, settings panel in Settings)
  • Edge cases (ESP reboot mid-job, limit closed at home start, …)
Description
Onefinity CNC controller firmware (fork of OneFinityCNC/onefinity-firmware) with W axis (auxcnc) integration, hooks, build/flash docs, and V09 UX redesign.
Readme GPL-2.0 9.6 MiB
Languages
C 37.4%
JavaScript 22.5%
Python 22.5%
Pug 5.3%
Svelte 4%
Other 8.2%