Skip to content

fix: G0 rapids classify as Travel, not Cut (#189) - #260

Merged
sobechestnut-dev merged 2 commits into
devfrom
fix/189-g0-rapid-classification
Jul 30, 2026
Merged

fix: G0 rapids classify as Travel, not Cut (#189)#260
sobechestnut-dev merged 2 commits into
devfrom
fix/189-g0-rapid-classification

Conversation

@sobechestnut-dev

Copy link
Copy Markdown

What

The non-extrusion Cut/Travel classifier keyed only on tool-state (M3/M4 latched), so on a router — where the spindle stays on across rapids — every G0 reposition was counted as a cutting move. On the easel router fixture that meant 742 cut / 0 rapids, which is obviously wrong (it has 5 G0 rapids).

DD-012 D2 §4.2 already specifies rapids stay Travel — this brings the implementation in line: only a feed move (G1/G2/G3) with the tool engaged and no E delta is Cut; a G0 rapid is Travel regardless of tool state (a GRBL-laser also gates the beam off during G0). Not a spec change — a bug fix against the accepted DD.

How it was found

Adds the CNC/laser validation harness (tools/demo/validate.html) — the thing that surfaced this. Load a file you've physically cut, and it lists every claim the software makes (machine class, cut-vs-rapid split, tool-power range, canned cycles, work envelope, skipped commands), each markable ✓ / ✗ / n-a, with a markdown export. Runs entirely in-page: no upload, no worker, no commit of your files. ?sample=easel / ?sample=mach3 for a zero-setup try.

Testing a real GRBL-laser file through it showed cut-count over-reported by exactly the rapid count — the finding that motivated this fix.

Impact

  • Geometry unchanged — only the kind column shifts; the sole golden change is demo-easel (742/0 → 737/5, matching its raw G1=737 / G0=5).
  • FDM byte-identicalCut is never evaluated without a tool-state modal.
  • +1 regression test (G0-engaged → Travel, incl. modal-motion continuation).

Patch changeset on @chestnutlabs/gcode-parser (lockstep).

🤖 Generated with Claude Code

sobechestnut-dev and others added 2 commits July 29, 2026 18:31
The non-extrusion Cut/Travel classifier keyed only on tool-state (M3/M4
latched), so on a router — spindle on across rapids — every G0 reposition
was counted as a cutting move. DD-012 D2 §4.2 already specifies rapids stay
Travel; this aligns the implementation: only a feed move (G1/G2/G3) with the
tool engaged and no E delta is Cut; a G0 rapid is Travel regardless of tool
state (a GRBL-laser also gates the beam off during G0).

Also adds the CNC/laser validation harness (tools/demo/validate.html) that
surfaced this — load a physically-cut file, check each claim (machine class,
cut-vs-rapid split, tool power, envelope, skipped commands) against the real
machine, export a markdown report. Local-only; no upload, no worker.

Geometry unchanged (only the demo-easel kind column shifts: 742/0 → 737/5);
FDM byte-identical. +1 regression test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…189)

The validation harness's Power view drew colored lines with no key, and the
power claim read "200–200" for a single-power job. Fixes from real-file use:

- Power range now measured over CUTTING moves only (a rapid can carry a
  latched S with the beam off — counting it over-reported the engaged tally).
- View legend is mode-aware: cut/rapid swatches, or a cold→hot power scale
  with the real min/max — or a "constant N (no variation)" note when the job
  never modulates power (with the swatch matching the flat tone drawn).
- Power claim phrases constant power as constant, not a degenerate range.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@sobechestnut-dev
sobechestnut-dev merged commit 879b60a into dev Jul 30, 2026
4 checks passed
@sobechestnut-dev
sobechestnut-dev deleted the fix/189-g0-rapid-classification branch July 30, 2026 05:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant