ScottW514
b51e695fb1
A component pin bump counted as a platform change: the layer content hash in the platform identity covered the recipe carrying the SRCREV, the platform is folded into every acceptance fingerprint, so every image that carried any component update invalidated the whole catalog (dev image 20260816191951: every test domain-changed after a one-line forgectrl bump; the two manifests differ only in platform.layers.meta-forgefirm). The component entry already identifies the pinned source file by file; the pin double-counted it. Component pins now live in <recipe>-pin.inc (SRCREV and the PV that moves with it, nothing else) - forgectrl, grblhal-glowforge and forgefirm-app here, the BSP components in meta-openglow - and forgefirm-image-manifest.bbclass leaves *-pin.inc out of the layer content (FORGEFIRM_MANIFEST_PIN_SUFFIX). Recipe bodies, patches, config fragments, init scripts and third-party pins with no manifest entry stay layer content; a pin written into a recipe body still hashes (the safe direction). manifest-from-tree.py mirrors the rule and reads pins through the recipe's requires; test_tree_manifest.py proves both (pin bump: hash unchanged; recipe body or inline pin: changed). Bitbake resolves the same SRCREV/PV for every pinned recipe. Docs: ACCEPTANCE.md (what layer content is), kas/README.md (the pin files in the push order), BRINGUP.md (the finding and the bench consequence: the first image built with the pin files is itself a platform change, so its campaign is a full one; pin bumps inherit after it). No catalog consequence: nothing in the image's behavior changes; the change is to the acceptance identity computation, proven by the unit tests and the CI lint on the tree manifest.
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.
- Latest Release
- Installation Instructions
- Build Instructions
- Connecting LightBurn
- How the laser safing works
- How a release is accepted
- Community Support
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:
$Hfrom 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.