Scale emulated spiral Z-hop segments based on slicing resolution #1440

New Issue

MrUnknownDE · 2026-04-05T17:46:55+02:00

MrUnknownDE commented

2026-04-05 17:46:55 +02:00

Originally created by @kisslorand on 12/2/2025

This PR improves the emulated spiral Z-hop (used when arc-fitting is disabled) by scaling the number of linear segments according to the slicing resolution. This produces smoother motion at high resolution and avoids unnecessarily dense G-code at lower resolution.

Why this change is needed

The previous implementation always used 24 segments to approximate the spiral.
For a typical spiral radius (~1–2 mm), this is more resolution than most printers require and can even cause:

unnecessary load on the motion planner
occasional “move queue overflow” on some MCUs

At the same time, users working with very fine slicing resolution (e.g. 0.01 mm) benefit from more precise approximation.

What this PR does

The slicing resolution is now taken into account.
Computes an appropriate number of segments based on it.
Clamps segment count to a safe range [4, 24].
The segmented spiral Z-hop now adapts its smoothness to the resolution.

This keeps the spiral:

smooth enough at high resolution
efficient at lower resolution
safe for printers with limited motion-buffer depth

G2/G3 arc-based spirals are unaffected.

No behavior change

Only the fallback linear spiral approximation is modified.
All other travel logic remains unchanged.

Note

This scaling is intentionally simple because the spiral Z-hop is synthetic motion unrelated to mesh curvature. The goal is to allow coarser or finer motion based on the user’s resolution setting, not to emulate the internal curve simplifier.

*Originally created by @kisslorand on 12/2/2025* This PR improves the emulated spiral Z-hop (used when arc-fitting is disabled) by scaling the number of linear segments according to the slicing resolution. This produces smoother motion at high resolution and avoids unnecessarily dense G-code at lower resolution. #### Why this change is needed The previous implementation always used 24 segments to approximate the spiral. For a typical spiral radius (~1–2 mm), this is more resolution than most printers require and can even cause: - unnecessary load on the motion planner - occasional “move queue overflow” on some MCUs At the same time, users working with very fine slicing resolution (e.g. 0.01 mm) benefit from more precise approximation. #### What this PR does - The slicing resolution is now taken into account. - Computes an appropriate number of segments based on it. - Clamps segment count to a safe range [4, 24]. - The segmented spiral Z-hop now adapts its smoothness to the resolution. This keeps the spiral: - smooth enough at high resolution - efficient at lower resolution - safe for printers with limited motion-buffer depth G2/G3 arc-based spirals are unaffected. #### No behavior change - Only the fallback linear spiral approximation is modified. - All other travel logic remains unchanged. > #### Note > This scaling is intentionally simple because the spiral Z-hop is synthetic motion unrelated to mesh curvature. The goal is to allow coarser or finer motion based on the user’s resolution setting, not to emulate the internal curve simplifier.

MrUnknownDE closed this issue

2026-04-05 17:46:55 +02:00

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1440