← back to pin list4c. Table data format — agree once, use everywhere
kerfmaster pin list · Big capabilities
questionclosed d17closed d18Unresolved, waiting on Aristide or Jordan.
Content last changed 2026-08-06 — computed from the item itself, not typed.
Contract — Cross-cutting stage
This contract is unresolved — the gate below is the thing waiting on an answer.
takes —
makes —
fails if A number that lives in prose instead of a table; two tables with two shapes; a value an operator cannot override; a lookup that answers with a neighbouring thickness instead of refusing.
Contract last changed 2026-08-06 — computed, not typed. Dated separately from the text above, so neither date can speak for the other.
3 open questions block this pin
- Q7 What are the shop codes for copper, aluminium and stainless? Every file we hold says MSO7.
Jordan — One of the three questions this pin is still open for. - Q8 May a material row ever match a RANGE of thicknesses rather than one exact value?
Jordan, Aristide — Second of the three open questions on the pin. - Q9 Can a per-location override be locked, so a per-job value cannot silently overrule it?
Aristide — Third of the three open questions on the pin.
⚠ Known defects
This item's subject has known defects 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.
- 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. - D18 — The post declared one thickness in its header and cut with the lead length of another (CLOSED)
write_gcode_macrob's signature carried material='MSO7,0.250' and lead_len=0.15 side by side. Any caller that left the defaults alone -- which is every _post.nc on every comparison board -- printed 1/4 in steel into (MATERIAL) and M100[] and then pierced with a lead sized for 1/8 in.
Cost today: The geometry _post.nc on published boards is an inspection artifact, not a program that was sent to a machine, and the production posts were unaffected. No part was cut wrong.
Verified: 2026-08-06. Fixed in the same commit: kerf, lead_len, standoff and margin default to None, meaning resolve from the declared material through tables.py; an explicit argument still wins.
Status: three questions open. Jordan, 2026-07-29, on settling one format for all of them: "Agreed." The format now exists — machine.json, materials.json and tables.py, described in item 4g — so what remains here is only what a lookup cannot decide for itself.
These are all table-defined and there is no reason for them to have different shapes: bridge widths (2b), tab widths and count rules (3a), slug-retention tab widths, lead-in defaults (4d), materials / conditions (the M100 strings and the #-variables), offsets (kerf and D-numbers), and pierce subprograms.
Decided, and built — see 4g
- The key.
<shop code>,<thickness>, written exactly as the shop writes it in the NC: MSO7,0.125, the same string that goes into (MATERIAL) and M100[]. Nothing is translated, so a row can be checked against a program by eye. - Matching. Exact. No interpolation and no nearest row: a miss raises
MaterialUnknown, and a row asked for a field it has never been given raises MaterialIncomplete naming the field. Inventing a tab width for an untested thickness is the failure the table exists to stop. - Derived, not typed. Lead length is a RULE in the file (thickness, floor 0.150), not four copies of a number — because Jordan stated it as a rule.
- Format and home. JSON, one file per scope, in the repo as the shipped default. Operator overrides live outside git so an operator edit never looks like a code change.
- Order. Repo default → per laser → per location → per job, later wins, deep-merged per key.
Still open — needs Aristide or Jordan
- The code list. Every file we hold says
MSO7. Copper, aluminium and stainless have codes we have never seen, and we cannot invent them. - Bands. May a row ever match a RANGE of thicknesses rather than one value? Today it may not. The lead rule already scales; slug-tab widths do not, and there is no evidence yet that they should.
- Locking. Can a location override be locked against the machine and job levels above it? The mechanism resolves; it does not yet refuse.
Getting this right once means a new material is a row someone types, not a code change. That part is now true.