← back to pin list

4e. Never traverse a piece that is already cut

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

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

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

Contract — Cut order stage

This contract states a decision, not an implementation.

takes boundaries-with-startstopology

makes cut-order

fails if A rapid over a piece already cut and still held, emitted silently; the outer profile cut before anything inside it; a crossing count not reported.

Contract last changed 2026-08-06 — computed, not typed. Dated separately from the text above, so neither date can speak for the other.

⚠ Known defects

This item's subject has known defects in the code. Recorded and deliberately NOT fixed — recording a defect is not a licence to fix it. Source: cadmaster/defects.jsoncadmaster/KNOWN_DEFECTS.md, not this page — the text below is generated from the register so the two can never disagree.

Observed on the test cut, 2026-07-30 (Aristide). After some pieces had been cut, the head travelled back over them. The pressurised nitrogen out of the nozzle, combined with leverage, flipped the already-cut pieces up, and the laser had to be stopped to prevent damage.

The rule

The nozzle must never pass over a piece that has already been cut and is held only by a tab. This binds rapid moves in particular, since that is when the head crosses open ground, but it applies to any motion over the region.

Note what this is not: it is not a keep-out zone on the sheet. It is a time-ordered constraint — a region is perfectly safe to fly over until the moment its boundary is finished, and dangerous from then on. So it is a cut-order problem first and a rapid-routing problem second.

Two levers, in order of preference

  1. Cut order — sequence boundaries so the head progresses away from finished work and rarely needs to come back over it. This is the cheap fix and it improves rapid travel at the same time.
  2. Rapid routing — where a return crossing is unavoidable, detour the rapid around the loose slugs rather than straight-lining over them.

How it interacts with the tab rules (item 3b)

A slug under 3/4" has no tab, so it drops clear the instant it is cut and is not a flip hazard. A slug with a tab stays at bed level and is. Omitting small tabs therefore reduces this risk rather than adding to it — the two rules pull the same way.

Evidence we may already have

The shop’s own production program for the novi sign uses 245" of rapid travel; ours was 781" when this was written and is 295.7" today, with the outer profile cut last in both (re-measured 2026-08-02 at HEAD 0ded91a). Their later master path spends 287.3". Their ordering may already encode this rule by habit. Their file is worth re-reading as a worked example of the sequence, not just of the dialect.

This supersedes nothing, but it changes the priority of item 4: cut order was parked as an optimisation. It is now also a machine-safety requirement.

Slat support is not an input — Jordan, 2026-07-31

Asked for the amplitude, wavelength and phase of the bed's zigzag slats so the unsupported-slug question could be settled numerically, Jordan ruled out the whole branch:

It's impossible to know in advance where the operator will place the design relative to the slats, and since we have no control over that we need to not take that into our equations absolute support points. Therefore the amplitude and wavelength are otherwise irrelevant.

The operator picks the start spot by how the sheet lands; the slag build-up on the tooth tips is a second variable and gets cleaned off periodically. So support is a variable to be robust against, never a fact to lean on.

The machine will not save us — Jordan, 2026-08-04

The M-code glossary showed M199 putting the head into an "evade" state before every rapid, and I read that as the machine carrying its own protection against the hazard this item exists for. Wrong, and Jordan said so directly: "'Evade' in this context is a setting that defines how far Z raises up during rapid travel. We only have around ~5″ of Z travel. It does not 'see' obstacles and therefore it cannot truly evade. We need to keep the rules as you have them now."

So the evade setting is a fixed lift, not a sensor. A tipped slug standing proud of the sheet is not detected and not avoided by anything on the machine. Every bit of the protection is in our cut order.

And he restated the priority, which settles the speed-versus-safety trade for good: "Best practice is to avoid crossing over features that have been cut and have a higher tipping potential. Prevention is more important than speed. Once the head is broken, the downtime is way more costly than a few seconds of extra travel." Our rapid travel is 295.7″ against the master's 287.3″; on this ruling that gap is not a defect to close, and rapid routing — detouring around held slugs, still not built — is worth spending travel on.

Their reordered file, measured — 2026-08-04

Jordan issued a second corrected program for the same part, deliberately reordered, to make the point that a file has more than one good path: "To say that there is only one way to do it would be an untrue statement. What needs to be a true statement, however, is that the way you choose to do it does not create errors." Same 91 boundaries, geometry identical to the previous master (median 0.000 thou), so the only variable is order.

Measured with our own metric (risk.analyse, unchanged and control-tested against the recorded numbers):

rapids crossingriskworst singlerapid travel
previous master42.80.8287.3″
reordered file636.329.5226.1″
ours at HEAD36117.232.3295.7″

The reorder buys 61″ less rapid travel and costs two more crossings. Nearly all of the risk is one move: the rapid leaving BND67 flies back over BND67's own slug, a piece 16.44″ across, for a single exposure of 29.5 against a worst of 0.8 anywhere in the previous file. Four of their six crossings are this same shape — a rapid departing a boundary and passing over the slug it just cut and left tabbed.

Put to Jordan, not asserted: our metric is calibrated on his own rule that prevention beats speed, and on that metric the reordered path is better on speed and worse on prevention. Either the 16″ piece is well enough held that the move is fine — in which case the metric needs a size or tab-strength term it does not have — or it is the kind of error he is asking us to learn to recognise. We do not have the answer and must not guess it. Our own path is still far worse than both of theirs and that is not in question.

Answered — Jordan, 2026-08-04: it was an error

If it did fly over a 16″ piece that was an error. We did not see that, which is why we need you!

So the metric is not missing a tab-strength term at that size. The class of event it flags is real, and a long piece held by one tab is the worst case, exactly as modelled. It also settles what these example files are: not corrected reference paths for us to match, but demonstrations that a part has many valid orders — and our job is to be the thing that catches the errors inside any of them. Note that the error was in a file the shop had already reviewed; the metric found something a human pass did not.

Third file, 65734 — a second reorder, measured 2026-08-04

incoming/1785874809_2669550_65734.NC. Same 91 boundaries, same part size, and the same tabs — 70 boundaries left open, 39 at 0.018″ and 31 at 0.033″, identical to the previous reorder. Order is the only variable.

rapids crossingriskworst singlerapid travel
previous master42.80.8287.3″
reorder 65733636.329.5226.1″
reorder 65734441.721.6244.9″
ours at HEAD36117.232.3295.7″

65734 fixes the crossing Jordan just called an error — that 16.44″ sliver is cut as BND80 here and nothing passes over it — and it introduces two of its own, both the same shape:

The mechanism, which is worth more than the numbers. These are adjacent parallel slivers cut back to back, and the next boundary's start point sits on the far side of the one just cut — so the shortest hop between them has to cross it. The order is not the fault here; the start point is. Alternating the start side on parallel neighbours removes the crossing without touching the sequence, which ties this item to the start-point choice in item 4d.

A principle all three files share. The 18 long pieces (>8″) are cut in the last block in every one of them — BND 78–90 in the previous master, and both reorders keep the block. The previous master crosses none of them and its worst exposure is 0.8; both reorders pull two slivers forward to BND 66–67 and then cross slivers inside the block. Long tip-prone pieces last, and once inside that block never hop back across one is a candidate rule we can state and test, drawn from their own files rather than asserted.

Margin, unanswered: 65734 is back to G52X.2Y.2 where 65733 had G52X.35Y.2, same part size in both. So the .35 was specific to that file, not a change of convention — but whether the X margin belongs in the material table is still open with Jordan.

Confirmed, Jordan 2026-08-04: "Good catch on BND 83 etc.! You are correct with your assessment." The start-point-side reading stands, so the fix belongs to item 4d and not to the ordering search. In the same message he closed the tab-count question this raised: one tab per slug on steel, widened if it will not hold, never two (item 3b). A long thin sliver on a single tab is therefore the permanent worst case, which is what our metric already assumes.

Engraving is outside this metric entirely — Jordan, 2026-08-04. An engrave pass severs nothing, so it produces no loose piece and passing over one costs nothing: "it will have no weight in the decision making in regards to tipping potential." And it is sequenced before everything: all engraving comes first, before any cuts, which is the same reasoning read forwards — engrave while the sheet is still whole. See item 8.

The two levers, ruled and ordered — Jordan, 2026-08-04

We would prefer to optimize the start/stop point, however if there is no safe way around an item then we can add points via G40/G0 to rapid around, keeping in mind that G0 is just like G1 — only straight lines so no arcs.

This authorises rapid routing, which this item has carried as an unbuilt lever since it was written, and it puts the two levers in a fixed order: start/stop point first, detour only where no safe start/stop point exists. It also settles the shape of a detour — a rapid is a straight line like G01, so a route around a slug is a polyline of G0 segments with comp off, never an arc. Recorded in machine_codes.json too, since it is a dialect fact as well as a rule.

How big is the start/stop lever? Measured, 2026-08-04

Jordan's preference turns out to be measurably the right one, and not only for our path. Splitting every crossing by whose slug is flown over — the piece the rapid has just finished cutting (a self-crossing), or some other piece cut earlier:

crossingsself-crossingsshare of risk from the just-cut piece
previous master4249%
reorder 657336496%
reorder 657344390%
ours at HEAD363076%

The dominant failure in every one of the four programs is the same move: finish a boundary, then rapid away across the piece you have just cut and left on a tab. In ours it is 30 of 36 crossings and 76% of the risk; in their own reorders it is 90–96%.

That matters because a self-crossing is not an ordering problem at all. The order could be perfect and the move would still happen, because it is decided by where the boundary ends and where the next one starts — two points, not a sequence. So the lever Jordan named first is also the one carrying most of the damage, and it is the cheaper of the two to build. Detouring is for the remainder.

Method, so this can be re-run: post at HEAD, then risk.detail, counting a rapid as a self-crossing when its from_bnd appears in its own over list. CONTROL: risk.analyse reproduces 36 / 117.2 / 32.3 / 176.3 for our post and the recorded values for all three of their files, unchanged.

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.

The threshold, read back out of their own files — 2026-08-04

Asked for a dimension, Jordan declined and said the files already carry it:

The purpose of us giving you 3 different files was to "teach" you this. This being create a rule around items that are more than likely going to tip. And then we'd rather avoid (which is what we did) vs risk flying over it.
He also framed the division of labour: the calculation and the weighting are ours to do, not his to state.

bigpiece.py derives it two ways. What each program actually flies over — biggest slug crossed:

rapids crossingslugs flown overbiggest crossedits moment
previous master 65733485.31″0.8
reorder 6573361016.44″29.5
reorder 6573441316.77″21.6
07-29 shop file333735.57″228.2

The file the shop calls correct crosses nothing above 5.31″ and no piece ≥10″ at all. The 07-29 file crosses twelve pieces ≥10″ including the 35.57″ giant, and it is the file that measures worst on every metric we have.

The mechanism is ordering, not a keep-out zone — which is this item's own time-ordered point, now visible in their data. Thirteen pieces are ≥13.93″ and the next size down is 8.95″, a real gap in the distribution. All three good files defer every one of those thirteen into the last quarter of the program (earliest cut 72–86% through). The 07-29 file cuts its three largest at 28% through, leaving them live for the following 62–65 rapids. Cut them last and the ban costs nothing to obey.

…and the number stays provisional — Jordan, 2026-08-04

Offered a hard 6″ rule placed at the low end of the bracket, Jordan ruled against freezing it:

Instead of making it a hard 6″ rule, as we encounter "issues" with the chosen path, we will keep fine tuning this over time. Right now, this is the only data we have. We haven't found the "edge" yet. We know 100% right now what doesn't tip, and what does tip from what we've cut thus far. Somewhere between the 1″ items that didn't tip, and the 6″ item that did tip there is a sweet spot, but we're not there yet.

So the threshold is a tunable value carrying its own evidence, not a constant compiled into the ordering pass — the same treatment as the slug-tab widths, which also arrived as a bracket and get tightened by shop feedback keyed to the numbered report. What must be built is the place to put the number and the report line that says which crossings it refused, so a bad call comes back as evidence rather than as a surprise.

Open, and not resolved by guessing: Jordan states the known bracket as 1″ (did not tip) to 6″ (did tip). Our measurement of his own master shows a 5.31″ piece flown over with no incident recorded. Whether his 6″ is a separate tipping event we have not seen, or a reference to the 6″ figure we proposed in the same exchange, is unknown — ask before either number is treated as measured.