Henrik Muehe f8be0a6b6f AuxPreprocessor: precede each HOOK with M0 so atoms block
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.
2026-05-03 18:39:33 +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 (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 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/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, …)
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%