ScottW514 05d68ba0a8 docs: BRINGUP describes the present, CAMPAIGN-LOG carries the dated record
BRINGUP had grown to 3,122 lines in which the same subject was answered
differently depending on where the reader stopped: GATE A "stays open, no
live-fire" in the phase text and closed in the campaign record, the catalog
at 24 tests in one section and 35 in another, several "bench validation
pending" headings over bodies that recorded the pass.

Split by kind rather than by age. BRINGUP (907 lines) is the present state
only - status, bench runbook, laser, lid/interlock/button policy, homing,
forgectrl, diagnostics, logging, release acceptance, the measured facts
bank, and a Next work list of the 15 items that are actually open.
CAMPAIGN-LOG (2,657 lines) takes the dated blocks verbatim, in
chronological order, and is append-only: a correction is a later entry, not
an edit. Its two reading rules are stated up front, since moved text keeps
its original "above"/"below" and its pre-split item numbers.

Facts corrected against the tree while rewriting: the liveness probe gates
at p2p 800, not 500, with the real wedge, noise and jolt figures; the panel
has seven tabs including Logs and is built from src/ui/, not ui.c; the
devserver replaced tools/mock.py; /status reports real head presence; the
estop_halts_motion opt-in is gone; core PR #999 is merged, leaving only the
step_us_min commit fork-only; the update system stands at Phase 5, the
uSDHC pads and the 2026-08-08 kernel batch have shipped, and 8 MP camera
capture is tracked here for the first time.

SAFETY and UPDATE-SYSTEM point their drill records at the log. ACCEPTANCE
records that inheritance is local: there is no import of a published
artifact, so a second bench starts from a full campaign - one of the four
open items the retired tool plan held, the rest of which are now in
BRINGUP's acceptance item.

Documentation only, no behavior change and no catalog consequence: docs/
is outside every layer and .md is excluded from the layer content hash.
2026-08-17 11:19:52 -04:00
2026-06-19 13:41:23 -04:00
2020-04-15 17:09:41 -04:00
2022-10-06 10:05:41 -04:00

OpenGlow/ForgeFIRM Firmware for Glowforge

Open-source firmware for Glowforge brand CNC lasers. ForgeFIRM replaces the cloud-dependent factory software on the stock control board — no hardware modification — and gives the machine a local controller, a local web control panel, and a standard Grbl interface.

What it does

Two controller modes, selected in the web panel and switchable while the machine is idle:

  • GRBL mode — grblHAL runs on the machine and speaks Grbl 1.1 over TCP port 23, so LightBurn, UGS, and cncjs drive the laser directly. Motion runs on the board's own hardware step engine (SDMA + EPIT), fed live by the planner. M3/M4 dynamic laser power, coolant-flow verification, over-temp holds, and an operator button press to arm the laser for each job.
  • Cloud mode — the machine presents itself as a stock Glowforge to the Glowforge web service, so the phone and web apps work as they always did. Optional, and off by default. GRBL mode jogs and cuts without it; the one GRBL-mode function that still reaches the Glowforge service is camera-referenced homing (below), until limit-switch homing lands.

Around both modes:

  • A web control panel on port 8080: machine status and position, coolant and fan telemetry, safety-switch states, camera view, machine settings, hardware diagnostics, firmware updates, and boot-slot management.
  • Unified logging: every ForgeFIRM component logs through syslog into its own directory under /data/log/forgefirm, with per-logger levels for the device and for an optional remote syslog server, a live viewer in the panel, and a one-click log bundle — sanitized of identifying details — for attaching to an issue report.
  • Both cameras as MJPEG streams and full-resolution snapshots — the lid camera feeds LightBurn's camera overlay directly.
  • Camera-referenced homing: $H from any sender runs the factory-style camera homing cycle through the Glowforge service (a Glowforge account and a live service session are required for $H; everything else in GRBL mode runs without them), and the machine records where it is.
  • Installs alongside the factory firmware in the unused A/B rootfs slot, archiving every factory version first, so the machine can be switched back to stock at any time without the Glowforge cloud.

Hardware

The control board is common to Glowforge Basic, Plus, and Pro. The 5 MP (OV5648) camera modules are fully supported; the 8 MP (OV8856) modules found in "HD" units bind but do not capture yet — see the camera note in kas/README.md.

Roadmap

  • Limit-switch homing as an alternative to camera-referenced homing.
  • Camera lens calibration and bed alignment for the LightBurn overlay.
  • Capture support for the 8 MP (OV8856) camera modules.
  • Cloud mode: stream jobs into the motion ring during the run, lifting the job-length cap that buffering the whole job imposes.

Safety

This machine contains a Class 4 CO₂ laser: it burns, blinds, and starts fires. Never defeat the lid switches or interlock, always vent the exhaust outdoors, and never cut PVC or other chlorinated plastics. Never leave a running job unattended — keep a fire extinguisher within reach. Read Before you cut — safety before your first job, and the Regulatory and legal section before installing. How the laser safing works describes the hardware safety chain and the software gates ForgeFIRM stacks on it.

A very important warning: this is experimental software. Use of this software could seriously maim or kill you or others, and voids your warranty. It is not affiliated with or endorsed by Glowforge. Use it at your own risk.

S
Description
OpenGlow/ForgeFIRM Firmware for Glowforge
Readme
5.8 MiB
Languages
Python 90.3%
Shell 3.5%
BitBake 2.6%
C 1.2%
JavaScript 1.2%
Other 1.2%