Estimator (#927): model junction blending at corners and chained rapids — the 4 % over-prediction sits in short-segment toolpaths (ball +19 %, chamfer +25 %); parked until after 1.0

Open
  • Is something wrong?
#1,000 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
arduino, typescript
Domain
performance

Research direction

Read ir.ts at estimateCycleSeconds (line 563) and inspect z1.mjs run for the captured junction_deviation setting. The issue is explicitly parked until after 1.0, so wait for it to enter the active queue before starting. Done means the tray-file and short-segment air-run measurements meet the stated tolerances while T1 remains within 1% and the estimator stays conservative.

Written by the indexing model from the issue text.

Description

after-1.0 enhancement fabrication

Filed by the review session at the maintainer's instruction (2026-11-05): parked until after 1.0 ships. Not for the current queue.

1. Stamping fact

Air run of Makera's Tool_Tray_70mm_Top-msfi5w1b.nc on the Z1 (#943 6674098307, 6674272270): the controller's clock gave ≈ 4,350 s of motion; #927 on the same file gives 4,542.5 s, +4.4 %. Per toolpath (estimator vs measured motion): ⌀6 flat 2,112 vs ≈ 2,120 s (−0.4 %); ⌀3.175 flat 1,682 vs ≈ 1,594 (+5.5 %); ⌀6 ball 470 vs ≈ 396 (+19 %); chamfer 294 vs ≈ 235 (+25 %). The error grows with the share of short segments and rapids (ball pocket 19,397 lines / 24 % air; chamfer contours 28 % air) and is absent on long straight feed.

2. Mechanism

ir.ts:563 estimateCycleSeconds accumulates a feed run while the XY direction is continuous and ends it at a direction change, charging a full stop and re-acceleration at accelMmPerS2 (150) for every corner, and times each rapid as its own trapezoid. The Z1 firmware plans through corners with junction deviation, keeping speed through small turns, and chains consecutive rapids. The constants (X/Y 1200, Z 600, acceleration 150, read off the card 2026-10-07) are right: the long-raster toolpath lands on the clock. The over-prediction is the corner-stop model, always on the conservative side.

3. Picture

The per-toolpath table above is the picture; a plot of error against mean segment length per toolpath would show the same.

4. Cost line (§8.9)

Estimator-only change, O(moves), no planning cost. Validation runs: the vendor tray file per toolpath (seconds), the two cards' posted programs (the cycle line moves down a few percent), and one more air run of a short-segment program to pin the junction model's number.

5. The change, named
  • ir.ts estimateCycleSeconds: at a direction change, instead of ending the run, carry the speed the junction allows: v_junction = sqrt(accel × jd / (1 − cos θ/2) … ) in the firmware's own junction-deviation form (read junction_deviation off the card; the capture's config-get sd junction_deviation is already in z1.mjs run), capped by the feed; chain consecutive rapids the same way. One parameter on RapidEstimate (junctionDeviationMm, provenance stated), absent = today's stop-at-every-corner model.
  • Must not change: the long-feed timing (T1 within 1 %); the estimateCycleTerms split (feed / rapid / spin-up); the conservative direction (never under the clock on the tray file).
6. Acceptance, as numbers
  • Vendor tray file: whole-file estimate within 2 % of 4,350 s motion; ball toolpath within 5 % of 396 s; chamfer within 5 % of 235 s; T1 unchanged within 1 %.
  • One air run of a posted program of ours with short segments: estimator within 5 % of the controller's clock, stated on #927.
  • sevenLines/parity pins re-pinned with the new numbers in one commit that says why.
Dominant language
TypeScript
Stars
2
Forks
0
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SlyWombat/CaseMaker

All issues in SlyWombat/CaseMaker

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.