Z Hop speed is not limited by machine_max_speed_z #970

Activity

1. highpowerxh

   added

   bugSomething isn't workingSomething isn't working

   on Oct 8, 2026
2. highpowerxh commented on Oct 8, 2026

   

   highpowerxh

   on Oct 8, 2026

   Author

   More actions

   I actually reported this to the forum 1.5 years ago
   https://forum.snapmaker.com/t/snapmaker-orca-v1-1-0-beta-issues-report-discussions/38235/28
3. highpowerxh commented on Oct 11, 2026

   

   highpowerxh

   on Oct 11, 2026

   Author

   More actions

   Investigation update: Z acceleration appears to be the main cause of the physical height loss

   Further testing on my A350 Dual + Quick Swap + Bracing Kit suggests two separate problems: generated Z travel feedrates are not capped, and the printer profile overwrites the firmware's much lower default Z acceleration limit.

   Physical observations and controlled changes

   • With the default settings and 0.4 mm Z-hop, the reported Z position can reach 7 mm while the actual mechanical height is only 5.x mm. This is consistent with lost motion (missed steps or slipping), rather than merely an incorrect displayed coordinate.
   • Single-head printing works with Z-hop disabled, but dual-head printing still has problems with Z-hop disabled. Disabling Z-hop does not eliminate layer changes or tool-change-related motion.
   • With dual-head printing, the first layer was normal, but both tools were mechanically too low on the second layer.
   • Setting the hidden process-preset option "travel_speed_z": "10" successfully changed the print-generated vertical moves to F600 (10 mm/s), but did not resolve the problem.
   • The next comparison kept that Z speed and 0.4 mm Z-hop unchanged and changed only machine_max_acceleration_z from 3000 to 100. This is now the leading explanation for the lost Z height based on the printing observations. Further repeatability testing is still needed; I am not claiming every configuration is validated.

   Important firmware/profile mismatch

   The generated Orca G-code originally starts with:

   M201 X3500 Y3500 Z3000 E3000
   M203 X150 Y150 Z40 E45

   These are automatically emitted machine-limit commands before the custom start G-code. A subsequent M503 reported M201 ... Z3000.00, showing that the controller accepted that setting. M503 reports current settings, not an independent factory baseline: running a slicer's G-code can change what it reports.

   In contrast, Snapmaker's official controller configuration defines:

   • Z maximum acceleration: 100 mm/s² in the normal 3DP and fast-print L8/L20 configurations.
   • Z maximum feedrate: 40 mm/s.
   • Junction deviation enabled, default 0.02 mm.

   The v4.7.2 configuration also has a default Z maximum acceleration of 100. This is verified firmware source, not a complete factory M503 dump matched to my installed firmware version.

   Thus Orca's profile raises the Z axis acceleration limit to 30× the official default. Actual acceleration also depends on M204 and firmware planning, but limiting feedrate alone does not restore the original axis acceleration constraint. Short Z-hop moves can be dominated by acceleration/deceleration without reaching their requested maximum speed.

   The newly generated comparison file correctly contains:

   M201 X3500 Y3500 Z100 E3000

   G-code comparison and local code fixes

   • The working Cura file mainly uses F600 for layer/tool-change Z moves, does not emit M201/M205, and raises Z by 1 mm before tool changes. Orca changes tools at the current first-layer Z of 0.3 mm. These are additional differences, not proof of a second root cause. Cura also contains some short 0.1 mm Z moves at higher inherited feedrates, so maximum feedrate alone is not a sufficient explanation. Cura can also inherit motion limits left by an earlier Orca print.
   • A local fix now caps pure-Z travel and the Z component of combined XYZ travel. Investigation also found that GCode::change_layer() silently updated the writer's Z before emitting the layer-change move, making the new cap see zero Z displacement. The local fix preserves the actual position until the move is emitted and preserves the requested hop height above the new layer.
   • One exported combined move was objectively excessive: from X167.804 Y167.985 Z0.3 to X167.921 Y167.804 Z0.5 F6000 has a Z component of approximately 68.02 mm/s, despite a 40 mm/s limit. The corrected writer emits F3528.285 for that segment.
   • The patched arm64 macOS application builds successfully. The full native FFF test executable passed 844 assertions across 38 test cases, including an end-to-end exported layer-change regression that failed before the fix. These tests verify generated code, not physical printer reliability. No PR has been published yet.

   Suggested maintainer action: review the A350-family preset's Z maximum acceleration, not only Z travel speed. Restoring the verified firmware default of 100 mm/s² is the key parameter change to investigate alongside the feedrate-generation fixes. The speed-limit bug is real, but may not be the principal cause of the mechanical height loss described in this report.
4. highpowerxh commented on Oct 11, 2026

   

   highpowerxh

   on Oct 11, 2026

   Author

   More actions

   The preset acceleration findings are now tracked separately in #989: #989 . That issue includes official firmware defaults, the 0.4 mm rest-to-rest motion calculations, and the proposed acceleration-only preset fix. It is the higher-priority candidate explanation for the reported physical Z height loss; the feedrate-generation defect in this issue remains independently valid. The preset fix can have its own PR without bundling the pending writer/position-tracking changes.
5. highpowerxh commented on Oct 11, 2026

   

   highpowerxh

   on Oct 11, 2026

   Author

   More actions

   Upstream comparison: OrcaSlicer#13308 has a related but distinct confirmed fix

   I read the upstream report and all its comments: OrcaSlicer#13308 . Its original report closely matches this issue: a Snapmaker A350T, pure-Z hop F7200 with travel speed 120 mm/s and Z limit 40 mm/s, and progressively declining mechanical Z height because upward motion loses more steps than downward motion.

   However, the later confirmed fix addresses a UI/configuration indexing defect, not general Z feedrate clamping:

   • On multi-nozzle printers, editing Motion ability settings could store the new value in a later variant slot while consumers read slot 0. Consequently the UI value and emitted machine-limit command disagreed.
   • OrcaSlicer/OrcaSlicer#14253, merged June 17, 2026, fixes the page-name check used to select that index (Speed limitation → Motion ability). The reporter confirmed that edits landed in slot 0 and resolved the problems they were testing.
   • That PR changes one GUI condition; it does not introduce a general cap on pure-Z/combined-XYZ F values. Its confirmation does not establish that every symptom in the original report had the same cause.

   In our acceleration comparisons, the actual exported commands matched the edited values (M201 Z100 / Z500) and the earlier M503 matched Z3000. Thus the evidence so far does not show the same indexing defect in our tested configurations. The separate excessive preset acceleration is tracked in #989, with a successful dual-head Body1 test at 500 mm/s² and Z speed 10 mm/s.

   There are therefore three distinct mechanisms to keep separate: wrong UI array slot, uncapped generated travel feedrate, and an excessive machine-acceleration limit explicitly emitted by the preset. The common physical symptom does not prove a single shared root cause. We should verify exported JSON and emitted commands when testing UI changes, not infer the effective limits from the UI alone.