← back to pin listInterface intent — nest spacing prompt: table default, operator shrink OR spread-out, both layouts shown (Jordan 2026-08-27)
kerfmaster pin list · The spec — what we build to
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-08-28 — computed from the item itself, not typed.
Intent (from Jordan's 2026-08-27 margin ruling — see pin nest-margin-from-min-gap for the ruling itself): 'As the operator I might opt to make the decision to slightly shrink that gap on a case by case basis, and this should be easy to do in the interface. For the sake of material preservation, I would love for you to recognize that if you would have picked .23 instead of .25 (only a .020" difference) we saved over 5" in X. You should give the operator both options and they can pick.'
- Default: the nesting tab seeds gap AND sheet-edge margin from the Rev2 min_gap for the job's material row (one value, margin derived). The seeded value is displayed as the current value, per the 2026-08-24 per-contour override ruling ('display the current value').
- Override: a per-job spacing input, one edit, no digging — shrinking the gap moves the margin with it unless the margin is overridden separately (nest_rules.resolve_spacing already behaves this way, so the UI is a thin skin over it).
- Show the trade, don't just take a number: the interface computes the ruled layout AND tightened alternative(s) and shows what each buys — rows per column, columns, right-edge X, material saved — the way builds 148/149 delivered it as two board builds. The operator picks; the pick is recorded beside the ruled value (stats.spacing_rule pattern), so an override is visible, never silent.
- Spread it out (added same day, Jordan): 'In addition to shrinking, we should also have the option to "spread it out" in one command. In cases where we have large parts, a small margin between them, and plenty of scrap at the top of the columns, it's better to even out all of the gaps which will help reduce the effects of thermal expansion during the laser cutting process and will therefore reduce errors.' One command, the mirror of shrink: part count and column structure unchanged, the top-of-column scrap distributed evenly into the row gaps. Engine is in code (nest_rules.fill_y_first spread_y=True): the gap only ever GROWS from the resolved value, pitch stays uniform across columns (pattern/macro uniformity), edge margins stay put, and the X remnant stays one clean full-height vertical slab per fill-y-first — spreading is a Y operation. Verified: LS at ruled 0.25 spreads to a 0.2815 row gap, columns running to the top margin; two 20in parts in a 48in column turn 7.25in of top scrap into one even 7.5in gap.
- Manual X spacing (added same day, Jordan, with a MetaCam screenshot): '(4.) You are correct. X remnant stays one clean full height slab, however in the software, the operator (not you) should be able to have the option to increase the X spacing manually with little increments. Add this as an interface rule.' His demo: the LS array in MetaCam's Layout Array dialog (12 columns x 32 rows, Y spacing 0.23), X spacing raised from 0.23 to 1.03 in the spacing box — all elements move in X only. So: automatic spreading stays Y-only and the remnant slab stays clean BY DEFAULT; consuming it in X is an operator decision made in small increments, never something the software does on its own. Engine slot is in code: fill_y_first(gap_x=...) — defaults to the resolved gap, uniform column pitch. MetaCam's Layout Array dialog (common-line-cutting options, columns/rows + per-axis spacing, pitch-instead-of-spacing, fill-entire-sheet) joins EDIT_TOOLING as reference feature set. The 5.104 inference CORRECTED by Jordan (second screenshot, array back at 0.23/0.23): 'that 5.104 was pierce to pierce before we spread everything out for the example. MetaCam is giving us the bounding box of the toolpath, not the geometry.' So MetaCam's array spacing runs on the TOOLPATH bounding box (leads included) — no between-column geometry meshing in their array tool; our true-geometry gap ruling stands as OUR improvement, and toolpath-vs-geometry bbox is a real distinction to keep (a lead-in widens the toolpath bbox past the part).
- Not a floor (Jordan, same thread): "'never tighten below the table' not true, operator should be able to override it, just your starting point." The table-resolved value seeds the dialog; the operator may go BELOW it (the 0.23-under-0.25 pick was exactly that), in gap, margin, or per-axis spacing. Guardrails are visibility (override recorded beside the ruled value) — never a hard block.
- One modal: for LS1156258 the same dialog offers: (a) go to 0.23 — Y maxed AND the X remnant maximized, or (b) spread it out, whenever the operator deems it beneficial for any reason. Shrink, spread, and per-axis manual increments are all reachable from that single modal, MetaCam Layout Array-style.
- Zoomed confirmation (Jordan's third screenshot, tight nest at 0.23): the 0.23 dimension spans between adjacent columns' TOOLPATHS — the outer-profile lead arrow of one column to the next column's envelope, pierce marks visible at every hole center. So in X his 0.23 rides pierce-to-pierce and the true steel-to-steel distance where the lead sits is larger (~0.37+ with a 0.15 lead); in Y no lead extends the envelope, so 0.23 spacing is near-geometry. Squares with his NC 28585 sheet: 12 columns in 61.42 = 5.12 pitch = 4.72 part + lead + 0.23, while our build 149 packs geometry-to-geometry at 0.23 (right edge 59.45 — tighter in X than the shop runs). Consequence, already ruled but now measured: when leads ride into our nest, the gap must hold the lead AND pierce clear-air, or the lead must aim along Y / into scrap — the nest-tooling feedback loop is not optional at tight spacing. Demo also shows adjacent columns 180 to each other (his array demo; his production NC 28585 sheet stays all-one-orientation as measured).
- Flip every other column (added same day, Jordan, two tight-nest screenshots): 'When we're tight on space and we need to squeeze in that extra column, one trick that us humans do that no nesting software does, and we want you to do it, is flipping every other column so that the pierce points are aligned in Y. The X spacing remains the same otherwise (.23). As you can see in the zoomed out version, we were able to add a whole other column because we did this, which we otherwise would not be able to add with standard spacing and configuration.' The 180d columns pair the lead/pierce channels so aligned pierce points share clear-air, buying back roughly a lead length per column pair once leads are in the envelope. This DELIBERATELY overrules the lower-right pierce-side default: 'that was a bias not a hard rule, and now you know why. Operator can always make these decisions.' Engine slot in code: fill_y_first(alt_flip=True) — odd columns at 180, placements carry (x, y, rot); the width gain is to be verified in our own posts once leads ride into nests (our current nest DXFs carry no leads). Same modal as shrink/spread.
- Placement: the nesting tab, next to the free-rotation prompt and feeding the nest-tooling feedback loop (both recorded as intents in CLAUDE.md's nesting section, 2026-08-26).
- Phase rule: this is recorded intent — nothing here is built as UI today; the data (ruled value, override slot, both-layouts computation) already exists in code, which is exactly the build rule (data/generator/presentation split).
- Answers (Jordan, 2026-08-27) to the two open questions on this thread: (1) the head-to-tail 180-pair in his tight-nest demo was 'Just a demo to teach you the concept' — production 28585 runs one orientation; the flip trick is the squeeze move, not a standing pairing practice. (2) 'Shortening lead-ins and moving pierce points will have to manually be done by the operator' — no automatic lead-shorten or pierce-move default in tight nests; the pipeline flags the conflict, the operator resolves it in the tooling loop (recorded as a ruling in CLAUDE.md's pierce-standoff section). Same message ruled true vs part-by-part nesting (pin def-true-vs-part-by-part-nesting): this modal's array behaviour is the TRUE-nesting face — the arrayed element is a finished toolpath.
- Placement CONFIRMED in the modal itself (Jordan, 2026-08-28, screenshot Nesting_Tab_Step_1 — MetaCam's full Layout Array dialog): 'The functionality we described yesterday about being able to manipulate the spacing in between the parts should be right here.' So shrink / spread-out / per-axis increments / flip-every-other-column all live IN the layout-array dialog at the nesting step, in the slot MetaCam gives to its Columns/Rows + Spacing fields. Full option list recorded for reference: Columns/Rows counts with X/Y Spacing (0.2/0.2 in his shot), 'Use pitch instead of spacing' toggle, 'Process in part-by-part mode' checkbox (MetaCam uses our very term), 'Fill Entire Sheet' button, 'Save as default', and the common-line-cutting block → common-line-cutting.
- One-click spreads + reset, evening includes the edges (Jordan, 2026-08-28, live-nest screenshot — 3 columns x 18 rows of the channel part, X spacing 0.2, Y spacing 0.32): 'What I did here was manipulate the spacing in Y to give an even gap: top, bottom, and in between parts to minimize thermal expansion errors. A computer program will do a better job than me as a human "eyeballing it" and guessing. This should fall in line with what we talked about yesterday, only difference is we expect you to automate it. Question: is it possible to have a one click option for "spread Y", "spread X", or go back to table values?' Three refinements recorded: (1) the spread evening includes the TOP AND BOTTOM (and left/right) edge gaps, not just the between-part gaps — supersedes the edge-margins-stay-put form of the 2026-08-27 spread; with the margin derived from the same min_gap the even value can only grow from the resolved gap. (2) The modal carries three ONE-CLICK actions: spread Y; spread X — the same evening across the columns, which deliberately SPENDS the clean full-height remnant slab, so it is only ever an operator's click, never automatic (consistent with X-is-the-operator's); and back-to-table-values — reseed gap and margin from the Rev2 min_gap with spreads off, restoring the slab. (3) Engine updated in the same commit: nest_rules.fill_y_first(spread_y=True / spread_x=True); calling with defaults IS the reset (verified: uniform gap incl. edges in both axes, part count and column structure unchanged, reset placements identical to default).