Bed envelope

kerfmaster pin list · Definitions

rulingmixedd1d2closed d17A decision by Aristide or Jordan. True because it was decided; it can be superseded, but it cannot be stale.

Content last changed 2026-08-03 — computed from the item itself, not typed.

Vocabulary — Cross-cutting stage

⚠ Known defects

This item's subject has known defects in the code. Recorded and deliberately NOT fixed — recording a defect is not a licence to fix it. Source: cadmaster/defects.json → cadmaster/KNOWN_DEFECTS.md, not this page — the text below is generated from the register so the two can never disagree.

D1 — The machine profile is silently ignored: the bed size is hardcoded
vec_pipeline.envelope_check reads machine["bed_x"] and machine["bed_y"]. emit.MACHINE_DEFAULT stores the envelope as "bed": (80.0, 160.0) -- one key, holding a pair. Neither key it looks for exists, so both .get() calls fall through to local defaults, which are also 80 x 160. The check passes, the answer is right, and the machine profile had no part in producing it.
Cost today: None. The hardcoded pair is the right pair for the one laser we have.
Verified: 2026-08-03 at 36a55a3. 'bed' in emit.MACHINE_DEFAULT -> True; 'bed_x' -> False. Both source spans read directly rather than taken from the audit.
D2 — The DXF board never checks the envelope at all
build_board.py computes and prints the extents and never compares them to the bed. The only 80 x 160 in the file is inside the unit-detect heuristic (build_board.py:17), which uses the bed as a sanity bound on inch-versus-mm, not as a gate. The vector board does check, D1 notwithstanding; the DXF board does not.
Cost today: None yet -- novi is 41.1 x 47.5", well inside. An oversize DXF would post without a warning.
Verified: 2026-08-03 at 36a55a3. Grepped build_board.py for 80 / 160 / envelope / EXCEEDS: one hit, the unit-heuristic comment.
D17 — The vector front-end's bed check silently ignored the machine profile it was given (CLOSED)
vec_pipeline.envelope_check() read machine.get('bed_x') and machine.get('bed_y'). No machine profile has ever had those keys -- the key is 'bed', an (x, y) pair -- so both reads always missed and the hardcoded 80.0/160.0 answered instead. Every caller that passed an explicit profile had it thrown away.
Cost today: None measurable. Every board we have published used the default profile, whose numbers the fallback happened to match.
Verified: 2026-08-06. Fixed in the same commit that found it: the check now reads tables.bed() as its default and machine['bed'] when a profile is passed.

Bed envelope = the machine's cuttable area: 80" × 160". Anything larger physically cannot be cut on this laser.

⚑ Not checked everywhere, 2026-08-03. This item said we check every file, single part and full nest. What runs today: the vector path checks it (vec_pipeline.envelope_check, called from build_vec_board.py). The DXF board never checks it at all — build_board.py prints the extents and never compares them to the bed; 80×160 appears in that file only inside the unit-detect heuristic. There is no nester, so no nest is checked. And the check that does run silently ignores the machine profile: envelope_check reads machine.get("bed_x") / ("bed_y") while emit.MACHINE_DEFAULT stores "bed": (80.0, 160.0), so the hardcoded 80×160 always wins and a different machine would be ignored without a word. Recorded as a known code defect; deliberately not fixed here.