wrong MAXZ in the gcode file

[bellzw]

Cura Version

5.11.0

Operating System

Windows 11 Pro V25H2 on a Lenovo P1 Gen7

Printer

BIBO Dual (I used my own definition to get around bugs in the official definition)

Reproduction steps

Load an stl into Cura 5.11.0
slice
Cura shows correct dimensions (excluding brim) and slices correctly
Save file
Open the gcode file with a text editor

Actual results

Gcode file says:
;MINX:-84.83
;MINY:-84.83
;MINZ:0.3
;MAXX:84.83
;MAXY:84.805
;MAXZ:20.001

Expected results

Actual last Z move in the code is G0 F120 X-64.852 Y-76.731 Z3.15

Cura screen shows 158.1 x158.1 x 3.2 mm. Actual CAD model is 1/8" = 3.175 mm.

Add your .zip and screenshots here ⬇️

test.txt - This is the gcode file

Large Stick80.zip - This contains the stl

[HellAholic]

The Z 20 is the initial travel to a safe height before the printing starts and that is the value you see in the gcode as a result.

There are some safeguards in place in the engine so to ensure we don't scratch the build plate when starting a print.

Is this causing an issue or is it just the inconsistency between UI and Gcode that raises a question?

[GregValiant]

It might be a concern for a post processor if the MAXZ was used for something. (but I don't actually recall any PP's using it.)

HellAholic I don't see any move to Z20 in the posted Gcode.
When I slice that model with any other non-UM printer (single or dual extruder) the MAXZ is the model height of 3.2.

When slicing with an UltiMaker S5 or with the BIBO active - the MAXZ becomes 20.001.

In the Gcode generated by the UM S5 there is indeed a move to Z20.001.
G0 Z20.001
G1 F2700 E-6.5
;LAYER_COUNT:16
G0 F9000 X330 Y237
;LAYER:0

My first thought was that the Z20 was coming from a Definition or Extruder file but I didn't find it.
(The MAXZ in the posters Gcode is actually 4.65 after the Ending Gcode runs. I don't recall the Ending Gcode being used for the footprint or height calculations.)

[HellAholic]

GregValiant (@GregValiant)
The gcode export has a baseline value:

GCodeExport::GCodeExport()
    : current_position_(0, 0, MM2INT(20))

So if there is no override on that, the value remains at 20.
When there is a prime blob for example, then the value for extruder_prime_pos_z is used.
Otherwise I believe extruder_prime_pos_z (2mm from F4+ for example) is never actually used here because prime_blob_enable is off, and the G0 Z20.001 is a leftover/uninitialized value from GCodeExport's constructor, not a configured setting.

But without proper testing and figuring out all the edge cases that the initial value of 20mm would resolve, it's a big risk to change it (which would also require going through the different definitions to ensure they don't set an incorrect value).

So would need a justification for going on the adventure, if there is a side-effect or a problem, then it becomes easier to justify why this needs to be addressed.

Also while you're here, could you take a look at the Rework of paus at height PR, Erwan did a review and we're going into Feature Freeze for the release at the end of the day (2-ish hours) so it would be nice if we can merge it before that.

[GregValiant]

I'm looking but I'll never get it done in 2 hours.

As far as this one goes, it's about what I figured.

[bellzw]

I appreciate your looking into this.

The Z 20 is the initial travel to a safe height before the printing starts and that is the value you see in the gcode as a result. There are some safeguards in place in the engine so to ensure we don't scratch the build plate when starting a print.

Is this causing an issue or is it just the inconsistency between UI and Gcode that raises a question?

It's just that I noticed the inconsistency yesterday. Apparently, it's been there at least since 21 Nov 2024! I have a gcode file from that date, done with 5.9..0 according to the file, with MAX:20.001:
;FLAVOR:Marlin
;TIME:6156
;Filament used: 4.37207m, 0m
;Layer height: 0.15
;MINX:-91.9
;MINY:-11.888
;MINZ:0.3
;MAXX:50
;MAXY:71.888
;MAXZ:20.001
;TARGET_MACHINE.NAME:BIBO2_V4
;MKSPREVIEWPROCESSED
; Postprocessed by MKS WiFi plugin
; simage=0
; gimage=0
;Generated with Cura_SteamEngine 5.9.0
It has not caused any print failures, just a little consternation, and some extra work to verify that the gcode is correct. BIBO2_V4 is a predecessor version of my personal printer definition. It's not very different from the one I used yesterday and does not have any moves to or from Z=20.001.

It might be a concern for a post processor if the MAXZ was used for something. (but I don't actually recall any PP's using it.)

HellAholic I don't see any move to Z20 in the posted Gcode. When I slice that model with any other non-UM printer (single or dual extruder) the MAXZ is the model height of 3.2.

When slicing with an UltiMaker S5 or with the BIBO active - the MAXZ becomes 20.001.

In the Gcode generated by the UM S5 there is indeed a move to Z20.001. G0 Z20.001 G1 F2700 E-6.5 ;LAYER_COUNT:16 G0 F9000 X330 Y237 ;LAYER:0

My first thought was that the Z20 was coming from a Definition or Extruder file but I didn't find it. (The MAXZ in the posters Gcode is actually 4.65 after the Ending Gcode runs. I don't recall the Ending Gcode being used for the footprint or height calculations.)

I'm not using the BIBO definition supplied with Cura; there are some minor bugs in it so I have written my own:

BIBO2_V5.def.json - My printer definition. It includes variants and an image of the bed, uses R in M190 and M109, and adds a T1/G92 E0 to make sure both extruders are zeroed. None of those are in the definition that ships with Cura. Note that this definition, like the one supplied by the now-defunct BIBO manufacturer, inherits from fdmprinter. Is it possible that something in that definition was changed a couple of years ago that is causing what I've observed?

BIBO_E1_V5.def.json - E1 def

BIBO_E2_V5.def.json - E2 def

This is what 5.11.0 shows me for nozzle motion at the start of the print. The nozzle moves to 0,0,0 and then begins the brim at Z=0.

It is correct that Z ends up at 4.65 in this case; there is a move of 1.5 mm in the end code just before the nozzles are parked to the side of the bed.

Aside from Cura postprocessors, the discrepancy could be a problem for someone who writes a code to post-process a gcode file outside of Cura.

[GregValiant]

Between myself and HellaHolic, many of the Cura post-processors have been reworked in the last couple of years. As of right now, none of them care about the MAXZ. A couple of them (Purge Lines and Unload comes to mind) do take note of the MAXX and MAXY.
HellaHolic will know better but this might be a case of the MAXZ being correct, but the G1 Z20.001 line is missing.

At any rate, it does appear to be a minor bug that only seems to only affect the BIBO printers. The UM machines get the G1 Z20.001 line and other dual extruder machines don't get the MAXZ: 20.001 line but rather the actual MAXZ found in the Gcode.

[bellzw]

I agree that it's minor issue, but I'm rather surprised that it seems to affect only the BIBO. I haven't tried other printers since I only have my old BIBO. I'll be happy to try some non-UM models to see what happens.

If you want to close this issue, fine, since it doesn't affect the print job. If you prefer to keep it open, and investigate it when you have nothing better to do or can't sleep, also fine.

[HellAholic]

I do see the issue on the UM printers (without the prime blob) and in case of the UM printers I do have an idea why it's a good idea to be a bit above the build plate. In some of the 3rd party printers I do see it and in others I don't.
I would personally expect it to take the extruder_prime_pos_z as that is advertised as the prime position of the nozzle (literally). So I don't have enough information without an investigation to know if this is a bug, or it's expected behavior that solves specific cases. Let's keep it open for now and see when we'll get to it.

[GregValiant]

From what I can tell in regards to the UM printers -

• With "Prime Blob Enabled" set to True - the Z20.001 line is NOT inserted and G280 IS inserted. From what I read, when the firmware sees G280 it executes a script that includes extruding a blob while simultaneously moving the Z to Z20.
• With "Prime Blob Enabled" set to False - the Z20.001 the line IS inserted along with G280 S1 (no prime blob).

So it seems that for a UM printer - whether Prime Blob is enabled or disabled the print will start with the nozzle at Z20.

For the BIBO my official analysis is "sumptin' be broke".

[bellzw]

Prime Blob Enabled and G280 codes are new to me, but then I'm still using my old BIBO! So I checked and found that this setting is present, enabled, but is hidden "by the active machine." So, I disabled it, and sliced an stl, but it made no difference to the gcode: MAXZ=20.0001 is present, there are no G0 or G1 moves to Z=20 or 20.0001, and still no insertion of a G280 (which would be meaningless to a BIBO). Maybe this behavior is helpful in getting to the bottom of it someday. Sumptin still be broke.

[bellzw]

One last bit of information: If I slice something that is taller than 20 mm, MAXZ correctly reflects the last Z move value. It ignores the 1 and 0.5 mm moves that occurs in the BIBO end code. Here's a few lines from the gcode for an object 88.8 mm tall:

;FLAVOR:Marlin
;TIME:9002
;Filament used: 6.54208m, 0m
;Layer height: 0.15
;MINX:-21.051
;MINY:-24.001
;MINZ:0.3
;MAXX:50
;MAXY:28.826
;MAXZ:88.8

and the last Z move generated by Cura: G0 F120 X-11.226 Y7.094 Z88.8. So, I suppose that Cura only cares about what it slices, at least with the BIBO.