Skirt at Z0, that results in the nozzle dragging on the bed

[Thetraktor01]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

OrcaSlicer Version

2.1.1

Operating System (OS)

Windows

OS Version

Windows 11

Additional system information

No response

Printer

Voron 2.4

How to reproduce

When slicing this model with the settings included in the file, it sets a Z0 command during the Skirt

Actual results

Expected results

the skirt should be printed on the same height as the first layer

Project file & Debug log uploads

Spaceman_200x250_PETG_2h59m.zip

Checklist of files to include

• [X] Log file
• [X] Project file

Anything else?

No response

[thejoshuahenry]

I am encountering a similar issue where Orca Slicer is throwing in "Z0" gcode commands. This causes the nozzle to drag on the bed. It also causes the second layer to then print too high off the bed (going from Z0 to Z0.4, instead of Z0.2 to Z0.4). This should never occur, nothing should be attempting to be printed below the initial first layer height!

However, for me a skirt doesn't seem to be the cause of the issue (though the skirt is affected by it), rather, I only encounter the issue if I try to do a multi material/color print. Attempting to print the same file with only a single material/color filament, the "Z0" commands are not generated.

For now, I have been manually fixing this issue using find and replace in a text editor, but this could also be fixed temporarily using a post processing script I would assume - I haven't had the chance to try making one yet, but if someone else has the knowhow replacing any "Z0" with first layer height should do the trick.

EDIT: I have created a very basic post processing script with Python to handle this. Right now I'm manually editing the layer height, but I suppose that might be able to be called using a variable but I haven't gotten that far yet.

import sys
import re

fname = sys.argv[1]
re_search = r"\bZ0 \b"
re_replace = r"Z.2"

with open(fname, 'r') as file:
    gcode = file.read()

gcode = re.sub(re_search, re_replace, gcode)

with open(fname, 'w') as file:
    file.write(gcode)

EDIT2: Here is an updated script that calls the initial layer height from Orca's variables, so if the initial layer height is changed, the script doesn't need to be manually updated. Thanks to @samamorgan for helping me to put this together so quickly. The script is attached here: z0_fix.zip

import os
import sys
from pathlib import Path

initial_layer_height = os.environ["SLIC3R_INITIAL_LAYER_PRINT_HEIGHT"].lstrip("0")
replacement_bytes = f" Z{initial_layer_height} ".encode()

input_gcode = Path(sys.argv[1])
data = input_gcode.read_bytes()

input_gcode.write_bytes(data.replace(b" Z0 ", replacement_bytes))

OrcaSlicer Version 2.1.1

Operating System (OS) Windows

OS Version Windows 10

Printer Mercury One.1 (Ender 5 Plus conversion), Klipper v0.12.0-289 + Happy-Hare v2.7.0-168

How to reproduce When slicing any model with multi materials (using an ERCF) the first layer shows multiple Z0 commands looking at the gcode. It should be calling for the first layer height (Z0.2).

Actual results:

Results when not using multiple color materials:

Additional information can be provided if needed. I'm attaching two project files in a zip, one with a single color without this issue, one with four colors with the issue.

project file examples.zip

[thejoshuahenry]

Quick update to this Z0 issue. Regardless of the cause for Orca putting in Z0 (skirt or MMU stuff, etc), there is a post processing script above that should resolve any Z0 issues with the skirt or otherwise.

If unfamiliar, you would need to have Python installed on your system and then to setup the post processing script settings in Orca.

Post-processing Scripts: "A:\bsolute\path\to\python.exe" "A:\bsolute\path\to\post\processing\script.py";

Example from my slicer: