print starts at negative Z ?? Cura 5.3 crashes bed when the model starts on support

[herzla 3]

i was printing the whole day, since some hours in 5.3 release
suddenly my printhead crashed the bed - after some searching I checked the gcode and the first move goes to Z-1.19

 

G92 E0
G1 F1800 E-0.5
;LAYER_COUNT:396
;LAYER:0
M107
G0 F6000 X206.319 Y233.911 Z-1.19
;TYPE:SUPPORT
G1 F720 E0

i don't have a z-offset plugin installed
I also don'f find a setting to change Z-offset in Cura
currently several instances of Cura are running, all base on same profile, seems like only one instance starts at negative Z

byby PEI

//edit:
after some more testing it seems like Cura 5.3 has a Problem when the model starts in the air and needs to be support on full surface
in Cura 5.2 it works fine

bed_crash.3mf

Edited March 9, 2023 by herzla
new information / new title

[herzla 3]

I added a little tube next to my model so something is touching the buildplate and now the print starts above the build plate but support-brim is missing
/edit: it works again after I enabled skirt - before it was set to 'none' as I don't need print a skirt when support-brim is enabled

 

this is how 1st layer looks in Cura 5.2:

[GregValiant 1,409]

I've never seen Cura add a negative Z value.

Here is your startup gcode:

 

Are you running OctoPrint?  Everything is commented out except the last line. 

That last line appears to be missing the "close curly bracket" at the very end.

The only post-processor I see running is Insert at Layer Change is that correct?

[herzla 3]

no, I'm not runninge Octoprint
my Start-G-Code is corrent
seems to be another Bug in 5.3 - it looked same on my computer until I resized the window - then the full code was visible
only post-process is the standard 'Insert at Layer Change', and another script inserting layer-change information
I can reproduce it any time when the Model starts 2mm above the bed with tree-support and support-roof active
when the model starts on the print-bed everything is fine and working

[GregValiant 1,409]

I opened your project file and immediately created a gcode file.  This a snippet from Layer:0.

 

PRINT_START BED=100 EXTRUDER=260 MATERIAL=ABS MATERIAL_BRAND=Extrudr
G92 E0
G92 E0
G1 F1800 E-0.5
;LAYER_COUNT:410
M240
;LAYER:0
M107
G0 F6000 X176.161 Y218.465 Z0.25
;TYPE:SUPPORT
G1 F720 E0

 

From your StartUp Gcode:

PRINT_START BED={material_bed_temperature_layer_0} EXTRUDER={material_print_temperature_layer_0} MATERIAL={material_type} MATERIAL_BRAND={material_brand}

That line is not a Marlin command and your Machine Settings show you using Marlin firmware.  What is running that will understand that command?  What runs the "other script"?

What is the next "Z" value in the gcode?  Given your settings and "Adaptive Layers" it should be .35.

 

If Cura routinely sent a print head to a negative Z location and smashed nozzles into beds - no one would use the software.

[herzla 3]

2 hours ago, GregValiant said:

If Cura routinely sent a print head to a negative Z location and smashed nozzles into beds - no one would use the software.

it never happened before and I can reproduce it in 5.3 release.. and I think most users place models to the plate..
i also disabled all post-process-scripts and also arc-welder - just in standard-profile I didn't get that error and will continue testing

when you slice it - is the model dropped to the bed in preview or is support below?

PRINT_START is a standard command in klipper - just in Cura there is no option for klipper firmware..

I attached the gcode so you see Z-value starts at -1.19 and continues "correct" (-1.09, -.99, -.89)

negative_z_53.zip

[herzla 3]

i opened the project on another windows 10 computer with fresh cura 5.3 installed
Z ist starting at -1.19
when I use standard-profile the model get's dropped in preview but Z ist starging with positive value
enabling adaptive layer (0.18+-0.8) makse the change - now also with absolute standard voron 2.4 profile Z is starting negative

 

attaching a simple model producing same bug

V350_MGN9_Assembly_Tool.3mf V350_MGN9_Assembly_Tool.gcode

[GregValiant 1,409]

I still can't reproduce it with that new file.  Your gcode file doesn't show any post processors running but I don't believe there is one that could affect the gcode like that.

 

The problem definitely shows up in the gcode and the print doesn't get above Z0 until about Layer:10.  Something has told Cura to alter the Z and I would think that it might be something specific to your system but you said another computer showed the same behavior.

I go over all the bug reports on Github and yours is the first I've seen of this behavior.

 

Maybe @MariMakes and the Cura team have come across something like this during their de-bugging.

 

Edited March 10, 2023 by GregValiant

[herzla 3]

1 hour ago, GregValiant said:

I still can't reproduce it with that new file.

 

may you answer my question about the preview - otherwhise I can't help you

 

1 hour ago, GregValiant said:

Something has told Cura to alter the Z

as the model drops down every time and the bug is only on adaptive layers there is not much outside cura that will affect it
the model dropping down in preview is a bug already and with adaptive layers it get's worse

 

1 hour ago, GregValiant said:

I would think that it might be something specific to your system

😄 😄 😄 for sure, different language on OS and Cura 😄 😄 😄

 

1 hour ago, GregValiant said:

I go over all the bug reports on Github and yours is the first I've seen of this behavior.

I beleve, I was sure before, it workes fine in 5.3 Beta 2 and I just know it's possible to let models start "in the air" since yesterday so I don't think a lot people do that.. and even less with adaptive layers ~~

there have been a lot of (quite deep) changes from Beta 2 to release without public testing so I also still see tree-support growing through the model, brim errors and I see a lot more new and unsolved problems on github depending 5.3 "release"
I got really sad when I saw the xmas-tree and don't know the reason why they needed to hurry on the release so may I just skip 5.3 and come back next year 😄

may this thread prevents others to crash the bed - github may show us the truth soon

[herzla 3]

"Remove Empty First Layers" gehts hidden when support is active - seems like it gets disabled also in older Versions (until Beta2) but is hidden and active in 5.3 release

when I disable support, than disable "Remove Empty First Layers" and then activate support again the GCode looks as espected and starts above the bed

@GregValiant may you can check if this is same on your computer and may it was disabled?