The ATC M-codes are supposed to behave like proper blocking gcode - M100 should not return until the ejector pulse has actually finished, and the next block should not run until M100 has returned. Without that, the drop macro M102 (release) M100 (eject pulse 1) M100 (eject pulse 2) M100 (eject pulse 3) M100 (eject pulse 4) G53 G0 Z0 (lift Z) M103 (clamp) races: gplan emits all the (MSG,HOOK:...) lines and the Z move in quick succession, the AVR queues them, and Z lifts while V2 is still wiggling. The (MSG,...) transport itself is fire-and-forget by gplan's design. The Hooks framework already implements proper blocking via the block_unpause / auto_resume mechanism - but it only takes effect when the program is actually paused. So precede each hook with M0 (program pause) in the rewritten temp file: M0 (MSG,HOOK:release:) M0 (MSG,HOOK:eject:) ... Sequence becomes: M0 -> machine pauses on the AVR side (MSG..) -> hook fires synchronously in a thread hook does ESP RPC, blocks until [eject] done hook completes; auto_resume unpauses next block streams This also fixes the consecutive-comment-line collapse problem naturally: each M0 is its own block, so back-to-back HOOK lines no longer collide. The M0 lives only in the tempfile gplan loads; the operator's macro source still reads as plain M100/M102/M103.
OneFinity CNC Controller Firmware (A-axis fork)
This is the community-fork firmware (V09 UI, FA6, cold-boot work, macOS dev tooling) with a virtual A axis driven by an auxcnc ESP32 over USB serial. See docs/AUX_A_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, A-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 installonce at the project root (this is wired into thenode_modulesMake 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/diag/timing | head
curl -s http://onefinity.local/api/aux/status # if A 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.
A axis (auxcnc)
This fork adds a virtual A axis. See docs/AUX_A_AXIS.md for:
- G-code surface (
G28 A0,G1 A25, 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, …)