Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

sim: the cycle estimate assumes 3000 mm/min rapids — the controller's own config caps X/Y at 1200

Open
  • Is something wrong?
#281 13 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, performance

Research direction

Start with src/engine/cnc/cam/ir.ts and the config record in docs/bench/2026-10-07-config-sweep.json; compare the estimator's rapid-rate and acceleration assumptions with the recorded machine settings. The issue proposes no fix and says #208 D3 must first time an air run to verify planner behavior and rapid feed overrides. Treat that measurement, then updating the constant and model together, as the completion criterion.

Written by the indexing model from the issue text.

Description

bench-test fabrication triaged

Split out of the bench sweep (B9, 2026-10-07). The estimator's one assumption now has a measured
number to be checked against, and it does not agree.

What the estimator does

estimateCycleSeconds (src/engine/cnc/cam/ir.ts) times a feed at its own f, a rapid at
ASSUMED_RAPID_MM_MIN = 3000, and ignores acceleration entirely — every move is assumed to reach
its rate instantly. The constant carries its own warning:

PROVISIONAL — this is the display constant, not a measurement of the machine. #208 D3 times an
air run and replaces it.

It is the single source for the panel's row, the run sheet's estimatedTime and the ;@MKR|TIME
header, so all three are wrong together.

What the machine says

Read off /sd/config.txt with config-get sd <key>, 2026-10-07 — full record in
docs/bench/2026-10-07-config-sweep.json:

Key Value What it is
default_seek_rate 2000.0 the rate a G0 with no F is planned at
alpha_max_rate / beta_max_rate 1200.0 X / Y axis ceiling — the planner clamps to it
gamma_max_rate 600.0 Z ceiling
acceleration 150 mm/s², which the estimator does not model at all
default_feed_rate 1000

So a rapid is planned at min(seek, axis ceiling) = 1200 mm/min on X and Y, 600 on Z, against an
assumption of 3000. Two independent errors, both in the same direction: the rapid rate is 2.5× too
high, and accel/decel is free. Both make the printed estimate optimistic — the real run should
take longer than the sheet says.

(maxCutFeed: 1200 in the profile happens to equal alpha_max_rate exactly, so the cutting ceiling
and the X/Y rapid cap are the same number on this machine.)

What this is not

This is a read of the config, not a measurement. Two things are unestablished:

  • whether Smoothieware's planner clamps a G0 to the axis max_rate the way this assumes, and
  • whether the vendor's post or Studio puts an F on rapids, overriding the seek rate.

#208 D3 — time an air run — settles both, and is still the thing that closes this. This issue is
the evidence to check D3's answer against, and the reason to expect the estimate to come in low.

Also unverified

maxRpm: 13000 in MillProfile still has no read behind it. The file's spindle.* group carries
only default_rpm = 10000 and control_smoothing = 2.5 — a default is not a maximum, so this is
neither confirmed nor contradicted, just unsourced.

No fix proposed here: D3 first, then the constant and the model together.

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.