kerfmaster pin list · UI / workflow decisions
intentWhat we want to build. Never claimed the present, so it cannot be stale — and must never be read as a description of the code.
Content last changed 2026-09-18 — computed from the item itself, not typed.
HIS SKETCH IS THE RIGHT SHAPE and it maps onto the macro structure cleanly: the main program carries TWO array blocks over the SAME grid (same K/Q/I/J pitches, same origins) -- pass 1 arrays a pierce-only sub (per boundary: rapid to the exact planned pierce point, condition select, M98P9011, no comp, no cutting), then M00 with honest comments for the operator (pierce only / grind smooth / cycle start resumes into cutting); pass 2 arrays the full cutting sub, byte-identical to today's except the standard pierce call swaps for the quick pierce (his P9019). Same-grid arraying guarantees the craters land exactly where pass 2 expects them. Part-by-part and single-part posts take the same two-pass shape (pass 1 = every pierce in sequence order). MEASURED SEAMS ALREADY IN CODE: emit.write_gcode_macrob already parameterizes the pierce call (pierce_sub=9011); the corpus runs M98P9011 on every standard pierce (790 calls; 65393.NC also calls M98P9035 once -- unidentified, ask); pierce clear-air is already measured per pierce (_pierce_clear), so the physical trigger 'pierce too close to the contour walls' is a number we already compute -- the standing sub-standoff yellow finding is exactly this defect, and the pre-pierce pass is its shop resolution (finding should then report resolved-by-pre-pierce, staying visible, never nagging). TABLE PROPOSAL: (a) per material x thickness row, a prepierce column (yes/no, Jordan supplies which rows -- thick steel + aluminum) -- table seeds, operator toggles per job on the Post drawer, recorded; (b) the quick-pierce sub number is a MACHINE number (machine.json beside comp_register, provenance recorded), as is the standard 9011. AUDIT: nc_audit learns the two-pass form -- pass-1 pierces sanctioned at pass-2's own points, two tracked sub numbers consumed, M00 + comment hygiene per nc-comment-paren-rule. OPEN QUESTIONS (numbered to Jordan): (1) pass 1 = ALL pierces on the sheet (his 'complete nest') or only the tight ones -- all makes pass 2 uniform quick-pierce and faster, confirm; (2) P9019 on the control: resident like P9011, called M98P9019, any condition line of its own before the call, and does the same number serve both machines; (3) trigger to PROPOSE the pass: prepierce row + at least one pierce under the measured ruled standoff, or the row's Small Threshold class, or row + operator toggle only; (4) M00 operator wording -- shop-standard message; (5) what is 65393.NC's M98P9035. NOTHING BUILT -- awaiting his answers/Go. JORDAN'S ANSWERS (2026-09-18, same day): (a) SCOPE IS THE OPERATOR'S CHOICE at invocation -- 'some pierces (yellow)? / All pierces' -- the yellow set = the measured under-standoff pierces; (b) the quick pierce reads FROM THE TABLE, easily overridable in the interface -- MEASURED: the Rev2 sheet already carries the columns, ingested 2026-08-24 (col S pierce_default = P9011 rows up to 0.25, P9035 rows 0.312-1.0; col T pierce_etch = P9019 every row) -- and NOTHING CONSUMES THEM: every post hardcodes pierce_sub=9011, so 3/8 posts to date (O33338, O33342...) called P9011 where the master table says P9035 -- standing defect, wiring pierce_default/pierce_etch through rev2_tooling into every posting door is part of this build (delivered programs stand per the no-redeliver precedent); (c) the M00 notes '(PAUSE)' and the head PARKS AUTOMATICALLY first -- post a rapid out of the way right before M00 (park position = a machine number, Jordan to say where the operator jogs it today); (d) answered -- P9035 IS a standard pierce, per-row (see b). NEW ASK, his: a POP-UP at post time telling the operator this program is about to get the pre-pierce treatment, operator selects yes or no (then the a-scope choice); optional, recorded. STILL OPEN: park position value; his Go. ARISTIDE'S ANSWERS + GO (2026-09-18): (1) pop-up yes; (2) the pierce-column wiring defect fixed now ('good that we are doing this now then'); (3) PARK POSITION IS COMPUTED PER JOB, never a stored constant -- 'as far as you can on x and y given the sheet size and the x that is consumed for the job, make sure that all pierces clear, so if necessary, add to the x': park at the far corner beyond the job's consumed X and up at max Y, exceeding the sheet edge in X when the nest consumes it, verified clear of every pierce point; (4) program shape confirmed correct. 'go for build' -- BUT first tonight's two setups (pins table-hardcode-audit, table-editor). BUILD PLAN in slices: slice 1 = pierce_default/pierce_etch wired through rev2_tooling into every posting door (the defect fix); slice 2 = the two-pass form (pierce-only sub, park rapid, (PAUSE) M00, quick-pierce cutting sub) + post-time pop-up (no / yes-some-yellow / yes-all, recorded) + audit understanding of the form + resolved-by-pre-pierce warning wording. SLICE 1 BUILT same day: tables.rev2_tooling serves out['pierce'] = {default, etch} from the row's own cols S/T (blank raises MaterialIncomplete like every other miss); emit.write_gcode_macrob pierce_sub=None resolves table > legacy-9011, explicit argument = operator slot, stats['pierce_sub'] records sub + source; cl_post's hand-built common-line pierce line reads the row too; nc_audit's tooling block gains the pierce check -- every in-boundary M98P must call the row's pierce_default (pierce_etch sanctioned, the coming cutting side), off-table calls are anomalies with counts, main-program sub callouts after G52 excluded. NEW test_pierce_sub.py 13 controls (both rows, posted bytes, stats sources, audit flags the defect's exact form and passes the fix, pierce-less tooling dict keeps old callers working); tooling_doc/etch/nc_warn/drag/cl_post/pl_sync suites green; dev engine restarted healthy. SLICE 2 NEXT: the two-pass form + pop-up.