Consecutive Prints fail due to Z Axis limit

[deveth0]

I calibrated the printer using your manual and can usually only print one print before the printer starts to complain about "Move out of range" actions.

This happens, when I start a new print, try to home the axis etc.
Restarting the printer solves the problem.

15:01:38 
!! Move out of range: 120.000 120.000 248.011 [637.988]
15:01:38 
!! Move out of range: 120.000 120.000 248.011 [637.988]
15:01:38 
!! Move out of range: 120.000 120.000 248.011 [637.988]
15:01:38 
// Filament width sensor Turned Off
15:01:38 
!! Move out of range: 4.500 5.500 253.000 [637.988]
15:01:38 
!! Move out of range: 4.500 5.500 253.000 [637.988]

[zakfromevil]

In gcode_macro.cfg change from z-5 to z-10 and all works

SET_KINEMATIC_POSITION Z={printer.toolhead.axis_maximum.z-10}

[frap129]

In gcode_macro.cfg change from z-5 to z-10 and all works

SET_KINEMATIC_POSITION Z={printer.toolhead.axis_maximum.z-10}

Interesting, it was reduced from 10 to 5 specifically to avoid this issue, I guess i'll need to investigate more

[Peck07]

I may be wrong, but could be that it's caused by the extra
G1 Z5 here:

OpenQ1/config/gcode_macro.cfg

Line 233 in e5ab9b9

G1 Z5 F600

My solution was also to change to -10 :)

[BrokenR3C0RD]

This seems to only occur if an adaptive bed mesh is loaded; after adding BED_MESH_CLEAR to my end gcode in OrcaSlicer I don't run into this issue any more.

[frap129]

This seems to only occur if an adaptive bed mesh is loaded; after adding BED_MESH_CLEAR to my end gcode in OrcaSlicer I don't run into this issue any more.

Good find! I'll add that to the main print_end macro

EDIT: It's already in the normal print end macro, odd

[BrokenR3C0RD]

The default end GCode in OrcaSlicer does not call PRINT_END; it does some other stuff instead. With this in mind, it may make sense to provide a custom profile for Orca/other slicers, or at minimum provide instructions on what the start/end gcode should look like afterwards.

[frap129]

The default end GCode in OrcaSlicer does not call PRINT_END; it does some other stuff instead. With this in mind, it may make sense to provide a custom profile for Orca/other slicers, or at minimum provide instructions on what the start/end gcode should look like afterwards.

Huh, thats strange. I've thought about providing custom profiles, guess I really should. Another thing for the TODO list!