Nest-level part sequence — Interactive Sequence, serpentine default, click-in-order at part scale (Jordan 2026-08-28)

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-06 — computed from the item itself, not typed.

Source: Jordan's nesting walkthrough step 3, 2026-08-28 — screenshot Nesting_Step_3_Sequence (incoming/1787937984_645725_Nesting_Step_3_Sequence.JPG), the same live nest as the one-click-spread demo (3 columns x 18 rows of the channel part). MetaCam banner: 'Interactive Sequence: Click on numbered boxes to add/remove from sequence [Shift=Batch]'.

• What the view is: every placed part carries a numbered box showing its position in the cut sequence; clicking boxes adds/removes parts from the sequence (click-in-order), Shift batches. The nest-level twin of the per-feature Manual Sort (metacam-add-toolpath-walkthrough) — Jordan already ruled the click-in-order model 'is exactly what we envisioned for the user interface'; this shows the same paradigm operating at part scale.
• The shown order is serpentine: up column 1 (1-18), down column 2 (19-36), up column 3 (37-54). Consequence: the transition from part N to N+1 is always one row pitch (or one column hop at a column end) — no long rapid from a column top back to the next column's bottom. Minimum travel, and the between-part rapids stay in uncut territory alongside the finished column rather than flying over it.
• True-nesting tie-in (def-true-vs-part-by-part-nesting): what is being sequenced is the duplicated toolpath block per placement, so the sequence is a reorder of the per-placement calls/offsets — cheap to change, which is why an interactive view like this is the right UI.
• Safety rules bind at this scale: outer-last applies within each numbered part; between parts the never-rapid-over-a-cut-held-part rule governs the hops (cut-order safety section). A manual re-sequence that violates them is flagged yellow/red, dismissible — warn never block — and the warning travels into the posted NC (gcode-warning-callouts). MetaCam's own dismissible re-sequence warning is the reference behaviour.
• Reading stated (derive-don't-ask): the serpentine is MetaCam's automatic default sequence; the numbered boxes are the operator's override on top of it. Awaiting Jordan's correction if wrong.
• Open with Jordan: (1) CLOSED 2026-09-06 (Jordan on the 'Process in part-by-part mode' / 'Process only one part of each type' checkbox semantics: 'We don't need this feature from MetaCam.') — the standing question is retired, nothing to build; our own macro-vs-part-by-part choice already lives in the main-program-style toggle. (2) The sequence starts bottom-left — machine-home tie, or shop/operator ergonomics? If a preference, it is an onboarding-wizard candidate next to start_clock.
• Step 2 answers (Jordan, 2026-08-28, with the Layout Settings screenshot): 'we check sequencing and generally it should follow the pattern that you see: starting at the bottom left and fill Y first, unless the operator overrides.' So the serpentine's start corner is the ruled DEFAULT PATTERN (bottom-left, fill Y first — consistent with nest-fill-y-first), operator-overridable as everything is; the onboarding-wizard candidacy is resolved — it is a pattern default, not a shop question. True-nesting implementation on their Mitsubishi lasers: control macros P9997 (nest in Y) and P9996 (nest in X) — the CONTROL arrays one part's toolpath along an axis; the posted program is one part + macro, true nesting made literal at the machine. Part-by-part nests sequence manually the same way part features do — feature-style click-in-order ('Remember we did this with the Novi file'). And the final step, not shown: a one-click generate-G-code button. Auto-increment of the program number lives in pin nest-name-prog-number.
• Ruling — sequence override breaks the macros (Jordan, 2026-08-28): 'should the operator choose to override standard nest sequencing, this will break the nest macros (9996/9997) and the GCode will then be part-by-part. Mitsubishi lasers do not like you to mix nest macros and part-by-part sequences in the same GCode.' Consequences we draw (derive-don't-ask): a true-nest post has exactly TWO shapes — MACRO mode (P9997/P9996, valid only with the standard bottom-left fill-Y-first pattern) and EXPANDED part-by-part mode (duplicated toolpath blocks in any operator order); the control never sees a mix, so even ONE re-sequenced part expands the ENTIRE program. The first click that departs the standard pattern should tell the operator the cost — 'this nest will now post part-by-part (longer program, same cutting)' — informational, never a block, per aid-the-operator. The macro/expanded fork is a POST decision driven by the sequence state, not a separate operator setting.