4a. Post dialect — match the shop's G-code exactly

kerfmaster pin list · Big capabilities

recordclosed d13States what the code does today. Auditable against the code — this is the only type that can go stale.

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

Contract — Post stage

This contract describes the code as it runs today.

takes cut-ordermachine-profile

makes gcode

fails if A condition var outside #102–#111/#121/#122; the G52 margin missing; a difference from the shop's dialect that is not written down.

Contract last changed 2026-08-06 — computed, not typed. Dated separately from the text above, so neither date can speak for the other.

2 open questions block this pin

Q10 Which pierce subprogram does a job call for a given material and thickness? We hardcode 9011 and there are at least 9008 and 9035 as well.
Jordan — Every program we post calls the same subprogram.
Q11 Are the M1xx condition-select codes and the #1xx condition variables the same table?
Jordan — We emit ten condition variables while selecting condition set 1, and cannot say whether that is consistent.

⚠ Known defects

This item's subject has a known defect in the code. 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.

D13 — The end-of-boundary M-code is keyed on cutter comp; Jordan has confirmed it must not be (CLOSED)
emit.py:1443 picks the end code as `end_mcode_comp if on else end_mcode_g40` -- M121 when a boundary is cut-critical (comp on), M87 when it is not. The control's own glossary says M87 is 'Beam off' and M121 is 'Process end'. Neither is a compensation code. The correlation we built the rule on is 90 comp-off boundaries ending M87 and 1 comp-on boundary ending M121 in the master NC -- and that one boundary is also the LAST boundary in the program, at line 1730 of 1734, which fits 'process end' at least as well as it fits 'comp on'.
Cost today: None. Fixed 2026-08-04 before any file with two top-level profiles was posted.
Verified: 2026-08-03. Code census of the master NC, the 07-29 shop file and a fresh post: all three carry exactly 90 M87 + 1 M121 + 91 M199, and M121 sits 4 lines from M30. Glossary transcribed from machine_codes.json. CONFIRMED by Jordan 2026-08-04, in his own words: "To be clear, M121 & M87 don't have anything to do with cutter comp." The defect is no longer an inference. The replacement rule is now DEFINED too: Jordan defined "subprogram" on 2026-08-04 as one part's G-code, authored from one DXF and called once per instance across a nest. So M121 ends a PART and M87 ends a FEATURE -- which is exactly the 90-to-1 split in the master. The correct rule is `M121 on the last boundary of the subprogram, M87 on every other`, with no reference to comp. Stays OPEN because the fix has not been made: it is a code change and nobody has authorised one. Output is unaffected for a single part whose outer profile is cut last, which is every job shipped so far. Jordan confirmed 2026-08-04 that the inline structure stays for now ("keep it this way for now, and we'll learn more about subprograms and nesting later"), so the fix is the small one: the subprogram is the program, M121 on the last boundary, M87 on every other. No restructuring rides along. FIXED 2026-08-04 on Jordan's go. emit.py now reads `end_mcode_last if bi == len(cons) else end_mcode_feature`, with no reference to comp state, and the kwargs are renamed from end_mcode_comp/end_mcode_g40 so the old idea cannot be re-read out of the signature. Output on the novi part is unchanged -- 90 M87, 1 M121 on the last boundary -- which is the expected result, since the part that exposed the bug does not trigger it.

Jordan sent the shop's real production program for the novi sign on 2026-07-29. It is an answer key for the post, and it splits our output cleanly into two halves.

Geometry — already correct

Measured with compare_nc.py against this file (the 2026-07-29 program, not the later master): 91 boundaries in both, worst deviation 0.777 thou, median 0.055 thou, 89 of 91 inside half a thou — re-measured 2026-08-02 at HEAD 0ded91a; the pinned 0.441/0.11/91-of-91 is from the July post and no longer reproduces. Against the master NC the same tool reports 0.776 worst, 0.068 median, 89 of 91. The two outliers are the same boundaries in both comparisons. The healer is producing the shop's geometry. (A whole-part offset of X-0.4461 Y-0.0122 is reported separately — it is exactly the source DXF's $EXTMIN, i.e. true part coords vs an origin-shifted program, not a fit error.)

Settled — read off their file, now implemented or queued

Number format. 4 decimals max; positive sub-1 values drop the leading zero (.039); negative sub-1 values keep it (-0.7165); exact zero is bare (J0). Consistent across all 3298 values in their file. DONE — both our posts now match this exactly.
Cutter comp side — NOT a geometry decision. Their file runs G40 on the 90 interior boundaries and G41 on the outer profile. The first reading — "interiors get G40" — is wrong. Jordan, 2026-07-29: comp is dropped here because this job is art/text. Those features are non-critical, gain nothing from a .007 offset, and tiny lines and radii below the offset value throw interference alarms, so the offset is removed for the whole class.
Tested against their file before accepting it: of the 90 comp-off boundaries, the smallest arc radius anywhere is 0.0579" — eight times the offset — and only 7 of 90 contain anything under .007 at all (10 under .014, 14 under .021). So 76–83 of the 90 had ample room and would never have alarmed. Comp-off was a blanket call on the feature class, not a per-boundary geometric one.
Consequence for us — and the pin had this the wrong way round until 2026-08-02: the side is derivable and is derived, in emit._comp_side() (emit.py:1044-1058), always toward the scrap. What cannot be measured is comp ON vs G40: cadmaster has to be told which geometry is cut-critical profile and which is non-critical art/text. That is the same classification input as items 6 (layering) and 8 (cut vs engrave), and it is the natural home for the .ai stroke-colour convention. OPEN: how does the operator mark it — layer, colour, or a pick in the UI?
End-of-boundary M-code. M87 on interiors, M121 on the outer. DONE — the current post emits M87 on 90 and M121 on 1, counted out of the file, matching theirs exactly.
Slug-retention tabs. Left uncut at the close of interior boundaries; outer closes exactly. BUILT — and measured against the master 2026-08-02: we and the shop agree on which boundaries get a tab in 90 of 91 cases (their 69 open + 21 closed against our 70 + 20). The one disagreement is our BND 32, a slug 0.906" across: over the 0.75" drop-through, so our rule tabs it; they left it to drop. Widths are where we differ: they use the narrow tab on 38 and the wide one on 31; we use narrow on 25 and wide on 45 — on 14 boundaries they cut the narrow tab where we cut the wide one. Their own two bands overlap in size, so their split is not a pure size threshold and our table cannot be derived from this file. See item 3b.
Cut order. Their outer profile is the last boundary. Ours is now 91 of 91 too, and rapid travel is 295.7" against their 245" — re-measured 2026-08-02; the pinned "89 of 91" and "808"" predate the safety cut order and no longer describe the post. Tracked in items 4e and 4f.
Lead-in. Theirs 0.150 nominal, shortened to fit down to 0.019; ours is no longer a fixed 0.250 — measured out of the current post: min 0.0962, median 0.1499, max 0.1501. Jordan: defaults will come from the tables.
Header (of the 2026-07-29 file this item was written from — the master settled all of it the other way, see the section below). G90 and G92X0Y0 on separate lines, no G52, no #2007 line, O-number carries the part name, M100[MSO7,0.060]. Jordan: M100 material/condition table and the offset values come from the tables.
Our inspection post. The _healed.nc file carried M03/M05 around each contour as beam on/off. Those are milling spindle codes and have no business in a laser file; removed. That file is now labelled INSPECTION ONLY. DONE.

Coming from the tables (Jordan, 2026-07-29)

Confirmed as table-defined, so these are no longer open questions — they are a data format we need to agree and then read: the #-variable values per material (#102–#111, and what #501=#107 selects), the M100 material/condition strings, the offset values (D-numbers and kerf), the pierce subprograms (P9011 and friends), the lead-in defaults, and the slug-retention tab widths by thickness. Same pattern as the bridge and tab tables: shipped defaults, overridable in Preferences, per laser and per location.

Answered — the operator decides, case by case (Jordan, 2026-07-29)

Three separate questions came back with the same answer, which is a design decision, not three of them:

Feature classification (comp side) — operator picks in the UI, case-by-case until there is enough data to see patterns. Not a layer, not a colour, not inferred from geometry.
Slug-tab placement — widths from the table, but which boundaries get one and how many is operator-defined per job, and needs to be a UI feature.
Lead geometry — lengths from the table, but the shortening rule, minimum lead, pierce point and angle need an agreed interface for the operator to define them.

All three are per-boundary overrides made by a human looking at the part. They are one feature, not three — see item 4b.

Still outstanding

M-code glossary — RECEIVED 2026-08-03. Aristide photographed the control's own G and M list off the machine; transcribed to cadmaster/machine_codes.json and rendered by build_codes.py into cadmaster/MACHINE_CODES.md. It names every code this item was guessing at: M87 Beam off, M121 Process end, M101 cond data 1 select, M199 Height control off, M66 Emission on, M100 cond search, M98 Sub-program calling, M99 Sub-program return. A code census of the master, the 07-29 file and a fresh post confirms every word all three emit is in the documented vocabulary. It also answered the pairing question against us: neither M87 nor M121 is a compensation code, so keying the end-code on comp state (emit.py:1443) is very unlikely to be right — the master's single M121 sits four lines above M30. Logged as defect D13, not fixed, and Jordan should still confirm. Detail in the reminder item.
Cut sequence — parked at Jordan's call. Outer profile last is known; what orders the interiors is not.
More NC + DXF pairs — another day. Still the highest-value input: pairs let us verify against a real answer instead of asking, and they are what turns case-by-case operator picks into defaults worth shipping.

THE MASTER NC SETTLED THE DIALECT — and this item predates it

Everything above was read off the shop's 2026-07-29 program. On 2026-07-31 Aristide and Jordan issued incoming/1785523984_296697_65733.NC, hand-built on our own healed geometry, and it answered the open questions in the opposite direction. Item 4f says "the master file also settled the dialect, see item 4a" — until now this item did not mention the master at all. Re-counted from both files, 2026-08-02:

	2026-07-29 file	MASTER	our post at HEAD
work shift	none	`G52X.2Y.2`	`G52X.2Y.2`
beam comp macro	none	`#2007=.007(D07)`	`#2007=.007(D07)`
material	`M100[MSO7,0.060]`	`M100[MSO7,0.125]`	`M100[MSO7,0.125]`
comp words	182 G40 / 1 G41	182 G40 / 1 G41	182 G40 / 1 G41
end codes	90 M87 / 1 M121	90 M87 / 1 M121	90 M87 / 1 M121
M99	present	absent	absent
condition vars	#102–#111 + #121/#122, plus #107×92 and #501×91 (no #112–#120 in either file; both files carry exactly one `#3002=0 (TIMER)`, and so does our post at `emit.py:1497` — this item said until 2026-08-03 that the master did not, which a grep of both files disproves)		identical to the master
D words	D7×91	D7×91 + D07 once (in the #2007 comment)	D7×91 + D07 once
retract	`G0G28Z0`		identical

Our post at HEAD is dialect-identical to the master on every one of those counts. A line-by-line diff of the two files leaves only the free-text part-name comments in the header and the outer profile's start point — which is a start-point disagreement, not a dialect one, and is tracked in 4f. The dialect half of this item is closed; what is still open below is about the shop's decisions, not its format.

Tool: cadmaster/compare_nc.py <reference.nc> <ours.nc> reports geometry deviation and the convention diff, and refuses to compare across post dialects.

Not being answered — Jordan, 2026-08-04

Asked directly whether the 14 were a deliberate call: "Not sure, and don't want to spend time on going back. Moving forward on the next move. Hold for more files."

This retires the question rather than answering it, and the distinction matters. Our table cannot be derived from the novi file and now will not be; it gets derived from future NC + DXF pairs or not at all. Until then the round-up stands and those 14 pieces carry a wider tab than the shop would have cut — a known, accepted cost, not an open defect. Nobody should re-open this from the numbers alone.

Record — 2026-08-14, the D word is a REGISTER, not kerf-in-thou: 33215.NC (the shop's own 1/2" program for the O100 job) writes #2007=.020(D07) — register 7 loaded with a .020 value. The whole corpus runs D7 at every thickness (14ga .007, 1/8 .007, 1/4 no-assignment, 1/2 .020), so D7 is a machine constant (machine.json comp_register, read via tables.comp_register) and the kerf value rides in #(2000+register). Our post derived D from kerf — matched by luck at .007 and wrote D20/#2020 on the first 1/2" post; fixed same day, O100 re-posted. Same file measured MSO7,0.500 kerf .020 (replacing a failed .007 bracket — thick plate does not share the thin-plate offset, so the 0.990 row's bracketless .007 deserves re-measuring too).