15b. Machine time — and the acceleration problem

kerfmaster pin list · Estimator & quoting

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

Contract — Report stage

This contract describes a stage we intend to build — it is NOT a description of the code.

takes gcodemachine-profile

makes delivery

fails if Time computed from cut length alone — acceleration is where naive estimators lose money.

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

1 open question blocks this pin

Q12 M124/M125 corner control and M140/M141 spatter-preventing spray exist on the control and neither shop file uses them. Is that a choice, or does the machine not have the option?
Jordan — Corner control changes cut time, if it is available at all.

⚠ 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.json → cadmaster/KNOWN_DEFECTS.md, not this page — the text below is generated from the register so the two can never disagree.

D8 — Two different crossing counts ship for one program, and neither is delivered
For a single posted program, stats["order"] reports 34 crossings / risk 116.489 while risk.analyse() reports 36 crossings / risk 117.2. They disagree because they sample differently: emit._seg_hits_poly defaults to step=0.05, skip=0.01 and measures from the contour start; risk.py forces step=0.01, skip=0.0 and measures from the pierce point. Neither number reaches any artifact the DXF board hands over.
Cost today: A safety count nobody sees, in two versions.
Verified: 2026-08-03 at 36a55a3. Re-posted novi: stats['order'] == {'crossings': 34, 'risk': 116.489}; risk.analyse == {'rapids_crossing': 36, 'risk': 117.2, 'worst_single': 32.3}.
D9 — Our cut order now costs more travel than the master AND more crossings
Measured at HEAD: our rapid travel is 295.7", the shop's master path 287.3", their older program 245.0" -- 91 boundaries in each. We spend 2.9% more travel than the master and still carry 36 crossings against their 4.
Cost today: Nothing to the cut itself. It removes the argument we would make to Jordan for our ordering.
Verified: 2026-08-03 at 36a55a3, using compare_nc.parse + compare_nc.travel -- the project's own measure -- on a fresh post: 295.7 / 287.3 / 245.0. CONTROL WORTH RECORDING: a rapid-travel parser written from scratch for this check returned 269.5 / 255.3 / 224.5, because it ignored modal moves. The hand-rolled number was the wrong one; the project's tool matched the earlier session exactly. The checker fails before the code does, again.

Cut length ÷ feed rate is the formula everyone uses and it is wrong in a specific, predictable direction.

The problem

A machine only reaches its nominal feed rate on a run long enough to accelerate into it. A part made of long straight cuts gets close. A part made of a hundred small features — letters, small holes, tight radii — spends its life accelerating and decelerating and never reaches feed rate at all. Same cut length, very different time.

The novi sign is exactly this case: 91 boundaries, mostly small lettering, 1,245 in of beam-on (1,233 contour + 12.5 of lead-in). Quoting it at nominal feed rate would be optimistic, and optimistic is the expensive direction.

Why we can model it and others cannot

We have the toolpath broken into its actual primitives, so we know the length of every individual move and the turn angle between consecutive moves. That is precisely the input an acceleration model needs. A conservative first pass: cap the achievable speed on each segment by both its own length and the corner angle at each end, then integrate. No new geometry work — it reads the program we already emit.

But calibrate before trusting it

Do not ship a model in place of a measurement. The route with the least risk of being confidently wrong:

Get real cycle times for a handful of already-cut jobs (15e).
Fit the model to those.
Report the residual honestly — if it predicts within 10% say so, if it is 30% say that instead.

Standing rule applies: run the control first. The shop's own timed jobs are the control here, exactly as their production NC was the control for the cut-path work.

Other real time that gets forgotten

Pierce dominates on hole-heavy parts. 91 pierces at, say, 0.8 s is 73 s — against a cut length that might only be a few minutes. On dense lettering the pierce count can outweigh the cutting.
Rapids are not free. 295.7 in at rapid still takes real seconds, and item 4e will deliberately increase rapid travel to buy down flip risk. (That trade is real but the direction has flipped since it was written: at HEAD we spend 295.7" against the master’s 287.3" — 2.9% more than the shop’s safe path, and still with 36 crossings to their 4. See 4f.) The estimator must price the safe path, not an idealised shortest one.
Gas on/off, focus changes, nozzle changes between operations.

⚑ Build state, 2026-08-21: the conservative first pass is implemented in quote.py accel_cut_min() exactly as sketched above: corner cap v = feed·cos(turn/2) (straight-through keeps feed, a reversal stops, every pierce is a standing start), centripetal cap v = √(accel·r) on arcs, per-segment trapezoid integration. Direction verified with test rates: accel time ≥ naive on both programs, and the novi sign (small lettering) pays a larger penalty than the O0104 kit (large smooth shapes) — 4.7% vs 2.9% at the test numbers. UNCALIBRATED until the shop times a job (15e); the structure is the point, the constants are rows.