Sparse Layers: Zhop incorrectly applied to sliced gcode #1548

New Issue

MrUnknownDE · 2026-04-05T18:19:47+02:00

MrUnknownDE commented

2026-04-05 18:19:47 +02:00

Originally created by @lanpartyceo on 11/22/2025

Is there an existing issue for this problem?

I have searched the existing issues

OrcaSlicer Version

2.3.2-dev Build d786aec

Operating System (OS)

Windows

OS Version

Windows 11

Additional system information

Processor: AMD Ryzen Threadripper 2950X 16-Core Processor, 3500 Mhz, 16 Core(s), 32 Logical Processor(s)
RAM: 64.0 GB
Video: AMD Radeon RX 6900 XT

Printer

Any Multicolor Printer using a Wipe Tower with Sparse Layers turned On

How to reproduce

Load any model.
Colorize model with any number of color changes. 2 is enough for demonstration purposes.
In Printer settings, verify a zhop is on and applied (I use 0.2mm Slope w/ 45 degree travel angle).
Verify that Wipe tower is enabled and sparse layers is selected.
Slice model.
With gcode preview turned on (press C), user the vertical slider to navigate to the layer where the sparse layer is printed on the tower.
The bottom slider will be at the end.
Inspect the gcode for the zlift at the end of the sparse layer wipe tower layer and transition to model gcode.
Notice that the printer is commanded to lift Z to the height of the model, then commanded to translate XY AND Z to the model, incorporating the zhop in this move, instead of lifiting the the full zhop height before XY translation leading to the potential for model impart.

Actual results

Here the image shows that the z is commanded to lift to Z35.85 (height of the model layer) then commanded to move XYZ to the model at the Z of Z36.05. While the Y plane motion is short, the X plane motion is over 150mm and so great a travel distance on EITHER X or Y plane effectively invalidates any zhop motion as it has to smooth it out over the motion of the longest axis move.

This means that even if you were to have a strait vertical zhop (same as slope of 90), the printer will perform the exact same motion as if you had a slanted slope.

Expected results

The generated gcode should look as the follow does. I had to manually edit the file and add the zhop to each of the Z axis lift motions that occur after the printing of the wipe tower.

Before editing, the file would not print as the nozzle or material leaking out thereof would continuously impart the model on translation from the wipe tower because the XY motion began at a level lower than i had commanded the slicer to create, knowing that I needed the setting turned on for my use case. This resulted in multiple failures as the model was loosened from it support, then moved around with the nozzle motion.

After editing, the file printed successfully in one go. As the nozzle was raised to the full height the user had programmed (current model layer+ zhop settings) THEN moved tot the XY at the same Z, there was no risk of model impact as the nozzle was always at the users programmed height.

Project file & Debug log uploads

X-Mas Coaster Holder_SL zhop debug files.zip

Contents:
X-Mas Coaster Holder.3mf
T5_X-Max Coaster Holder_PETG_0.2_6h32m.gcode (unmodified slice of 3mf)
T5_X-Max Coaster Holder_MEDIT_PETG_0.2_6h32m.gcode (manual edit of slice of 3mf)

log.zip

Checklist of files to include

Log file
Project file

Anything else?

The bug here is that the zhop is being applied too late. While logically, it is absolutely being applied at the correct time if the nozzle were over the model and in the middle of doing a travel retraction and continuing to print, but when the same logic is applied to sparse layers where xy travel distance is greatly increased it can lead to model impacts and print failures that otherwise would not have occurred if the zhop were simply added to the initial lift of the Z Axis after printing the wipe tower rather than its current application as the long travel XY distance effectively negates the effect of the zhop by smoothing it out over the entire XY motion distance.

In short, when using sparse layers and zhop, the zhop should be applied to the z axis lift from the wipe tower prior to any XY motion.

*Originally created by @lanpartyceo on 11/22/2025* ### Is there an existing issue for this problem? - [x] I have searched the existing issues ### OrcaSlicer Version 2.3.2-dev Build d786aec ### Operating System (OS) Windows ### OS Version Windows 11 ### Additional system information Processor: AMD Ryzen Threadripper 2950X 16-Core Processor, 3500 Mhz, 16 Core(s), 32 Logical Processor(s) RAM: 64.0 GB Video: AMD Radeon RX 6900 XT ### Printer Any Multicolor Printer using a Wipe Tower with Sparse Layers turned On ### How to reproduce 1. Load any model. 2. Colorize model with any number of color changes. 2 is enough for demonstration purposes. 3. In Printer settings, verify a zhop is on and applied (I use 0.2mm Slope w/ 45 degree travel angle). 4. Verify that Wipe tower is enabled and sparse layers is selected. 5. Slice model. 6. With gcode preview turned on (press C), user the vertical slider to navigate to the layer where the sparse layer is printed on the tower. 7. The bottom slider will be at the end. 8. Inspect the gcode for the zlift at the end of the sparse layer wipe tower layer and transition to model gcode. 9. Notice that the printer is commanded to lift Z to the height of the model, then commanded to translate XY AND Z to the model, incorporating the zhop in this move, instead of lifiting the the full zhop height before XY translation leading to the potential for model impart. ### Actual results <img width="481" height="222" alt="Image" src="https://github.com/user-attachments/assets/02a57344-da97-4c12-ba9e-6d49c46c37b9" /> Here the image shows that the z is commanded to lift to Z35.85 (height of the model layer) then commanded to move XYZ to the model at the Z of Z36.05. While the Y plane motion is short, the X plane motion is over 150mm and so great a travel distance on EITHER X or Y plane effectively invalidates any zhop motion as it has to smooth it out over the motion of the longest axis move. This means that even if you were to have a strait vertical zhop (same as slope of 90), the printer will perform the exact same motion as if you had a slanted slope. ### Expected results The generated gcode should look as the follow does. I had to manually edit the file and add the zhop to each of the Z axis lift motions that occur after the printing of the wipe tower. <img width="704" height="176" alt="Image" src="https://github.com/user-attachments/assets/251b6b62-fadf-47e4-881d-1ac5d2448567" /> Before editing, the file would not print as the nozzle or material leaking out thereof would continuously impart the model on translation from the wipe tower because the XY motion began at a level lower than i had commanded the slicer to create, knowing that I needed the setting turned on for my use case. This resulted in multiple failures as the model was loosened from it support, then moved around with the nozzle motion. After editing, the file printed successfully in one go. As the nozzle was raised to the full height the user had programmed (current model layer+ zhop settings) THEN moved tot the XY at the same Z, there was no risk of model impact as the nozzle was always at the users programmed height. ### Project file & Debug log uploads [X-Mas Coaster Holder_SL zhop debug files.zip](https://github.com/user-attachments/files/23690109/X-Mas.Coaster.Holder_SL.zhop.debug.files.zip) Contents: X-Mas Coaster Holder.3mf T5_X-Max Coaster Holder_PETG_0.2_6h32m.gcode (unmodified slice of 3mf) T5_X-Max Coaster Holder_MEDIT_PETG_0.2_6h32m.gcode (manual edit of slice of 3mf) [log.zip](https://github.com/user-attachments/files/23690132/log.zip) ### Checklist of files to include - [x] Log file - [x] Project file ### Anything else? The bug here is that the zhop is being applied too late. While logically, it is absolutely being applied at the correct time if the nozzle were over the model and in the middle of doing a travel retraction and continuing to print, but when the same logic is applied to sparse layers where xy travel distance is greatly increased it can lead to model impacts and print failures that otherwise would not have occurred if the _zhop were simply added to the initial lift of the Z Axis after printing the wipe tower_ rather than its current application as the long travel XY distance effectively negates the effect of the zhop by smoothing it out over the entire XY motion distance. In short, when using sparse layers and zhop, the zhop should be applied to the z axis lift from the wipe tower prior to any XY motion.

MrUnknownDE closed this issue

2026-04-05 18:19:47 +02:00

Sign in to join this conversation.

No Label bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1548