← back to pin list

3b. Slug-retention tab rules — production-validated

kerfmaster pin list · Agreed & queued (build after fidelity)

rulingmixedA decision by Aristide or Jordan. True because it was decided; it can be superseded, but it cannot be stale.

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

Source: a real test production cut of the cadmaster-generated NC, reported by Aristide 2026-07-30. This is the first time our output has been on a machine, and the first hard data behind any of the width tables.

Result

Cut on 1/8" (0.125") steel. All healed geometry was spot on. The tabs are what needed changing.

• Slug under 3/4" — omit the tab entirely. It is small enough to drop clear without a hold, and a tab there is wasted cutting time. It also removes a flip hazard (see item 4e): a slug that drops is gone, a slug held by a tab is still at bed level.
• Small slugs — 0.018", the value already defined. Confirmed correct.
• Large slugs — 0.033". At 0.018" a couple of the larger pieces were not held, and fell through too early, with a risk of damaging the laser head. 0.033" fixed it.

What this tells us about the shape of the table

The physics is leverage, in Aristide's own word: the tab has to resist the moment of the slug's weight about the tab. That moment grows with slug area (weight) and with the distance from the tab to the far edge — which is why a big slug fails at a width a small slug survives, on the same sheet.

Consequence: slug size is a key of the slug-tab table, alongside material and thickness. It is the only one of our width tables that needs a per-feature key rather than a per-job one.

It also retires the ratio guess: 0.018" worked on 0.060 and again on 0.125 for small slugs, so tab width is not a fixed fraction of thickness.

ANSWERED 2026-07-30 (Aristide) — the three bands are complete

The size test is the slug's LONGEST DIMENSION, in Aristide's words: "Small is any item that can fall through that is less than 3/4 in. in its longest dimension. Anything longer than that, we will call large." That settles the longest-dimension-vs-diagonal-vs-area question for the drop-through band.

• Longest dimension < 3/4" → no tab at all. It falls through; a tab there is wasted time and a flip hazard (item 4e).
• The letters → 0.018". Aristide: "all the letters cut out at 18 tau seemed to come out nicer and it was strong enough."
• Everything else that needs a tab → 0.033".

Where we put the small/large line, and why there

"The letters" is a description of this part, not a rule a program can apply, so we measured what the letters actually are. In the novi sign the letter row is an unmistakable cluster: 25 slugs at a cap height of 0.831", longest dimension 0.8312–1.0405", area at most 0.4152 in² (re-measured from the slug table 2026-08-02; the pinned 0.805" lower bound matched nothing in the file and is corrected here — it does not move the 1.10" threshold). The smallest slug that needed 0.033" measures 1.212". So the true boundary lies somewhere in 1.04–1.21" — we cannot know where, but we know it is in there.

We place it at 1.10", the low end of that bracket, because the two errors are not symmetric: too wide a tab leaves a bigger nub to clean up, too narrow a tab drops a slug into the head. Every uncertainty in this table rounds up.

Applied to the file that was cut, the rule reproduces the cut exactly: 20 slugs omitted, 25 at 0.018", 45 at 0.033", with no assumed values left — still exact at HEAD 0ded91a, 2026-08-02. The three bands measure: dropped 0.2819–0.5735" longest, small 0.8312–1.0405", large 1.2121–35.5738".

What the shop's own master NC says about these bands (measured 2026-08-02). The master is hand-built on our geometry, so their tab decisions can be read straight out of it and compared boundary by boundary.

• Which boundaries get a tab at all: we agree on 90 of 91. They leave 21 closed, we omit 20. The single disagreement is a slug 0.906" across — over the 0.75" drop-through, so our rule tabs it and they let it drop.
• Widths: we are wider than the shop on 14 boundaries. They cut 38 narrow and 31 wide; we cut 25 narrow and 45 wide. Every disagreement runs the same way — never narrower than they went, which is the deliberate round-up in this item, but 14 pieces is the price of it in witness marks.
• Their two bands overlap in size, so their split is not a pure size threshold and our 1.10" / 0.45 in² line cannot be derived from this file. Consistent with Jordan's "operator picks, case by case" (item 4b) — and it means the bracket still needs the two slugs either side of it reported from a real cut, exactly as this item asks.

For Jordan: on those 14, was the narrow tab a deliberate call or just what the file inherited? If deliberate, our threshold is too conservative and the nubs are bigger than they need to be.

A second gate: area

Length alone is not enough. A compact 1.0" × 1.0" blob passes a 1.10" length test while weighing 2.4× the heaviest letter that 0.018" was actually proven on. So the small band requires both: longest dimension ≤ 1.10" and area ≤ 0.45 in² (just above the largest proven letter). Either one exceeded → 0.033". Length and weight fail the tab in different ways, so they get separate gates.

The general rule, for future materials

Use the smallest tab that holds. The tab is a defect on the finished part — a nub on the customer's edge and a heat mark — so it always wants to be smaller; the only reason to widen it is that the slug will tear a narrow one. That is exactly why 0.018" "came out nicer": it is a smaller witness mark and less dross, not a different process. Read that way, the shop's two observations are one rule, not two.

What we need after a cut on a new material × thickness — three numbers, not a table:

1. the drop-through size (no tab below this);
2. the small width, and the biggest slug it held;
3. the large width, and the smallest slug that needed it.

The threshold then falls out of 2 and 3 as a bracket, and we place it at the low end as above. Nobody has to decide where "small" ends — they only have to report the two slugs either side of it.

The numbered slug report is built. emit.write_slug_report() (emit.py:683) writes CSV with the columns slug,x,y,longest_in,area_sq_in,tab_in,band,assumed, numbered from 1 in the program's own boundary order. Feedback after a cut is therefore "slug 52 dropped" rather than a description of a shape, and the bracket tightens with every job instead of only after a failure.

One limit worth knowing: the report is written by the two board builders (build_board.py:90, build_vec_board.py:67), not by the post itself — a program posted outside a board build comes with no slug report.

The 3/4" drop-through belongs to the MACHINE — confirmed 2026-07-30

Asked whether 3/4" is really about the bed slat spacing rather than the steel. Aristide: "yes. belongs to the machine."

So it has moved out of the material table and into a machine profile, alongside the 80×160 bed envelope. It stays put when the material changes and it changes when the laser does — which is the whole point, because a job moved to a second machine with different slats would otherwise silently keep the first machine's drop-through size and start dropping slugs that used to be held.

Where the tab is placed — see item 4d

Sizing is only half the tab. The tab can never land at a sharp point of the design (Aristide and Jordan, 2026-07-30): it goes on a flat, or on a circle at the 90° quadrant. Because the tab sits at the contour's start point, that is the same decision as where the cut starts and where the laser pierces — written up under item 4d, with the before/after measurement.

Still open

• One tab per slug — SETTLED for steel, 2026-08-04. This bullet used to propose two or more tabs on a long thin slug. Jordan has ruled the other way: one tab, and widen it if it will not hold. See below.
• Do 0.018 / 0.033 carry to other materials and thicknesses? Aluminium, stainless and copper are all in scope, and thickness changes both the weight and the tab's strength.

Everything here ships as a default, lives in operator Preferences, and stays editable per laser and per location, like every other width table (item 4c).

src — test cut and all three band values, Aristide 2026-07-30. The 1.10" / 0.45 in² thresholds are cadmaster's, measured off the slugs in the file that was cut, and are an engineering default open to correction.

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.

One tab, not two — Jordan, 2026-08-04

Raised off the 65734 file, where a 16.77″ × ~0.4″ sliver on a single tab was the piece under the worst rapid crossing. Asked whether long thin waste strips get more than one tab in the shop:

For steel, we're trying to stick with one tab. If anything, we might go for a thicker slug retention tab if needed, but for testing we'll determine that and we'll add that to the table.

So the lever is width, not count. A slug that will not hold gets a wider tab, never a second one. That keeps the rule we already have — smallest tab that holds, one per boundary at the start point — and it means the table stays two-dimensional (material × thickness → small / large width) instead of growing a tab-count column.

• Scoped to steel. Aluminium, stainless and copper are not covered by this and stay open.
• The width for a long thin slug is not yet a number. It comes from a test cut and then goes in the table, same route as 0.018 / 0.033.
• The code needs no change: emit already places exactly one tab per boundary, so this ruling confirms the present behaviour rather than altering it.
• Consequence for item 4e: because a long sliver on one tab is the worst case and stays that way, a rapid over one is a real hazard and our crossing metric is right to weight it heavily. Jordan confirmed the BND83 reading in the same message.

A third size class: too big to fly over at all — Jordan, 2026-08-04

With the letters we field tested that the tabs were strong enough with the .018″ for the smaller items, and the .033″ for the larger items, except for the really big items which just need to be avoided after cutting. E.g. the hood and roof of the car in the novi file.

Two things in one sentence. First, the 0.018 / 0.033 pair is field-tested and holds for the letters — that is confirmation of the table, not a new number. Second, and it is new: above the large band there is a class where the tab is not the answer at all. The hood and roof of the car are big enough that no tab we would want on a finished edge makes them safe to fly over, so they are avoided outright once cut.

This is a hard constraint, not a weighting, and our metric does not have one. risk.analyse scores every crossing on a continuous moment and lets a big number be traded against a short rapid; Jordan's rule says some pieces are simply not crossable and no trade applies. The threshold is not yet a number — "the hood and roof of the car" is two examples, not a size. Getting it needs either a stated dimension or more examples, the same route the tab widths took.

2026-08-12 — TRAFFIC decides the tab (Jordan, ruling): asked why 33199.NC leaves the three over-drop -61 slugs (0.98/1.26/1.51) untabbed: “Rapids never cross over these, and no other contours get anywhere close so this is a non-issue.” Verified by measurement: in their part-by-part order zero later rapids cross those slugs (nearest other contour 0.849 in); in ours 3 rapids do, so our 0.018/0.033 tabs are right for OUR order. Same rule, opposite conclusions, both programs consistent with it. Consequence: the tab decision is coupled to the cut order, and nc_audit flags an untabbed over-drop slug that later rapids cross. His stray 0.030 tab on one Ø0.51 circle (sub-drop, would fall clear) was his own MetaCam slip — confirmed and removed his end; nc_audit flags that class too.

Under redefinition (Jordan, 2026-08-13): on the 0.187 tube fixture he ruled “Remove the slug tabs on the slots. I need to define slug retention tab rules better. I will brainstorm with Aristide and update you at a later time.” Until that lands, the 0.125-validated bands above stand where a row carries them, the MSO7,0.187 row carries no slug_tab field (asking raises, never guesses), and a job can declare slug_tabs=none at post time (post_nest.py <dxf> <label> <material> <onum> none) — a per-job declaration like G40 on art. The traffic audit still runs: O33212 posted this way and its page lists the two untabbed over-drop slots that later rapids cross, so the declaration ships with its consequence visible.