Actual motion time is exactly 2x the planner-predicted time on segments that fall into AMASS level 3 (step rate < 2000 Hz)

[ssglag]

Actual motion time is exactly 2x the planner-predicted time on segments that fall into AMASS level 3 (step rate < 2000 Hz)

Environment

• MCU: STM32H743 (custom board)
• Core: grblHAL core (current master as of this report)
• Settings relevant to this report: $110/$111/$112=10000 (max rate), $120/$121/$122=200/200/100 (acceleration, mm/s²), $11=0.050 (junction deviation) — all confirmed via $$ to match the values used in the independent time model below.
• f_step_timer = 120 MHz (240000000*2/STEPPER_TIMER_DIV, STEPPER_TIMER_DIV=4).

Summary

On isolated, single-line G1 moves with no acceleration/cornering ambiguity (entry/exit velocity essentially at rest, single axis or near-single-axis move), the actual elapsed motion time is consistently exactly 2.00x the time predicted by a from-scratch re-implementation of grblHAL's own planner formulas (limit_value_by_axis_maximum, the junction-deviation cornering formula, and the standard trapezoidal velocity profile — all three verified line-for-line against nuts_bolts.c/planner.c in the gnea/grbl reference source and found to match exactly).

The 2x factor appears specifically on moves whose step rate falls in the AMASS level 3 band (step rate < 2000 Hz, i.e. cycles >= amass.level_3). A move at a step rate that falls into AMASS level 2 (2000–4000 Hz) shows no discrepancy (measured time matches the model to within measurement precision).

Reproduction / measurements

Test rig: temporary instrumentation added to the firmware that timestamps (via HAL_GetTick()) the moment plan_get_current_block()->line_number (i.e. the currently executing block) first reaches a given target line, for two adjacent single-line G-code moves, isolated from any lookahead ambiguity by running them from/to rest.

Test line (isolated G1 move)	Feed	Chord length	Step rate (Z axis, 400 steps/mm)	AMASS level (predicted)	Model-predicted time	Measured time	Ratio
G1 Z-1.19 F20 (pure Z, 1.5 mm)	F20	1.5 mm	133 Hz	3	4.500 s	9.0 s	2.00
G1 X4.5 Y25.25 Z0 F102 (mostly Z, 3.6 mm)	F102	3.6 mm	~680 Hz	3	2.122 s	4.2 s	1.98
G1 Z0 F500 (pure Z, 1.5 mm, same move as the F20 case, only F changed)	F500	1.5 mm	3333 Hz	2	0.263 s	0.3 s	1.14 (matches, within measurement precision)

Two wider multi-segment ranges (60–200 G1 lines each, dense/short segments, mixed feed 20–1330 mm/min) from a real finishing pass also showed the same ~2.00x ratio end-to-end, confirming this isn't an artifact of the single-line isolation:

• 207-line range: 50.4 s predicted (model), 100.8 s measured (firmware timestamp) / 102 s measured manually (stopwatch against on-screen G-code text) — ratio ~2.0-2.02
• 60-line range containing exclusively AMASS-level-3-band segments: 20.3 s predicted, 40.7 s measured — ratio 2.005

What's been ruled out

• Settings mismatch (accel/max_rate/junction_deviation confirmed identical to the model's assumptions via $$)
• SPINDLE_LOAD_GUARD_ENABLE — project-specific feature, confirmed disabled at compile time, not linked in this build
• ENABLE_JERK_ACCELERATION — confirmed Off (default)
• Planner buffer starvation — user confirmed via direct observation that plan_get_block_buffer_available() never approaches 0 during these moves; step generation is interrupt/timer-driven and consumes negligible CPU
• Feed override stuck below 100% — confirmed at 100% via on-screen display
• A bug specific to the time-estimation model itself — the identical 2x ratio reproduces on an isolated, single-line, at-rest-to-at-rest move with zero lookahead/cornering complexity, which rules out anything in the multi-block planning math
• ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING set to 0 (tested by editing the definition directly in grbl.h, confirmed via a full Clean+Build that the change was picked up) — the exact same 2.00x ratio persists with AMASS completely disabled. This was surprising and is the main reason for this report — disabling AMASS does not fix it, but the bug's domain (only manifests at very low step rates) still strongly points at the AMASS-adjacent code.

What I found while reading stepper.c

I don't have hardware-level (oscilloscope) confirmation of the mechanism, so take the following as "things I noticed that look suspicious", not a confirmed diagnosis:

1. st_prep_segment() (around what's currently ~line 1397-1407) computes amass_level and does cycles >>= level; n_step <<= level entirely inside #if ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING, with no #else branch. When the symbol is set to 0, prep_segment->amass_level is simply never assigned in that call (relies on whatever was last in that segment ring-buffer slot / its 0 initializer). This alone seems worth a second look independent of my main question below.

2. In block prep (around ~line 929-944), the per-axis Bresenham reference data is scaled unconditionally:

   #if ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
       st_prep_block->steps.value[idx] = pl_block->steps.value[idx] << MAX_AMASS_LEVEL; // <<3
       ...
       st_prep_block->step_event_count = pl_block->step_event_count << MAX_AMASS_LEVEL;
   #else
       st_prep_block->steps.value[idx] = pl_block->steps.value[idx] << 1;               // <<1, unconditional
       ...
       st_prep_block->step_event_count = pl_block->step_event_count << 1;
   #endif

   This scaling is fixed once per block (at MAX_AMASS_LEVEL, i.e. 3, when AMASS is on). But at execution time, st.steps.value[idx] = st.exec_block->steps.value[idx] >> st.amass_level is re-derived per segment, using that segment's own amass_level (which, per point 1, can legitimately differ between segments of the same block as the feed profile ramps through different AMASS bands). Meanwhile st.step_event_count is copied from the block once, unscaled by any per-segment level (st.step_event_count = st.exec_block->step_event_count;, only on block boundary). For a segment landing on level 3, <<3 >>3 cancels exactly against the fixed <<3 denominator. For a segment landing on any level other than MAX_AMASS_LEVEL, it doesn't cancel — I think this could produce a real proportion mismatch between the Bresenham numerator and the fixed-per-block denominator when a block's segments span more than one AMASS level, but I have not been able to fully trace the consequence to a confident conclusion (and it doesn't obviously explain why the disabled case — point 1 — also shows exactly 2x).

Question

Is either of the above expected/compensated somewhere else I'm missing, or does this look like a genuine issue? Any pointers toward where to look next (or what to capture with a logic analyzer) would be very welcome — happy to provide the exact G-code test files, the from-scratch Python re-implementation of the planner math used for the "predicted" column above, or run further isolated single-line tests on request.

[terjeio]

Timing is correct with the MSP432 driver I am currently working on, could be a driver issue? f_step_timer too high causing overflows?

When the symbol is set to 0, prep_segment->amass_level is simply never assigned in that call (relies on whatever was last in that segment ring-buffer slot / its 0 initializer). This alone seems worth a second look independent of my main question below.

amass_level is part of a statically allocated structure which is zeroed at startup, its value is also zeroed in st_reset() and never assigned to when ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING is disabled. So IMO not an issue.

I'll check with a STM32F7 dev board later, the H7 code is derived from that driver.

[terjeio]

The H7 driver caps the max step time to the same value as the F7 driver which has a 27 MHZ f_step_timer. IMO best would be to reduce step timer frequency by increasing STEPPER_TIMER_DIV to a value that brings it down somewhere in the 20-40 MHZ range.
The cap is there to limit long intervals that sometimes occurs on deceleration, and it could be a/the reason for the issue.

Ping @dresco

[ssglag]

You were right — it was a driver clock issue, not the AMASS logic itself. Found it by diffing against the STM32F7xx driver (this H7 driver was ported from it, as you guessed):

STM32F7xx (correct):

STM32H7xx (this project, before fix):

The hardcoded 240000000 is HCLK, not PCLK1. On this clock tree, PCLK1 = 120MHz (HCLK/2 via D2PPRE1), and the APB1 timer kernel clock is PCLK1×2 = 240MHz (confirmed directly in the STM32CubeMX clock diagram: "To APB1 Timer Clocks" = 240MHz). So hal.f_step_timer was computed as 240,000,000×2/4 = 120MHz, exactly double the real post-prescaler counting rate of 240,000,000/4 = 60MHz.

Fix:

I also directly measured this with a hardware cycle counter (DWT->CYCCNT) timestamping actual step pulses in _stepper_step_out(), independent of any planner/AMASS math:

F20 (AMASS level 3): measured 15.00ms/pulse vs 7.4995ms predicted — exactly 2.00x
F500 (AMASS level 2): measured 0.600ms/pulse vs 0.300ms predicted — exactly 2.00x
So it wasn't AMASS-level-specific after all — it affected every feed rate uniformly. My original F500 measurement in the report (which seemed to match) was just too coarse (HAL_GetTick, short interval) to catch it. Sorry for the red herring there.

Both of your points about the AMASS #if/#else and the steps.value/step_event_count scaling were correct too — I traced through the Bresenham math by hand at both AMASS levels and it's self-consistent regardless of level, not the cause.

Fix confirmed on real hardware — motion now runs at the actual commanded feed rate. Thanks for pointing at the driver instead of the core logic, that's exactly where it was.

[dresco]

Hi, thanks for reporting.

I'm not able to replicate this in the upstream H7xx driver, is there a difference in your clock setup?

The step timer is set here from PCLK1, and confirmed as 60MHz on both H723 and H743 boards.

@terjeio I will increase STEPPER_TIMER_DIV from 4 to 6 in the next commit if you feel it's safer to bring it down to 40MHz.

[terjeio]

The hardcoded 240000000 is HCLK, not PCLK1.

This means that it is a new driver? OP did not specify that but it seems so to me.

I will increase STEPPER_TIMER_DIV from 4 to 6 in the next commit if you feel it's safer to bring it down to 40MHz.

At least it will bring it more in line with the max interval cap shared with the F7 so IMO it does not hurt.