Hi! I’ve opened a Klipper issue, but seems this is a new place for bug reports.
So please check: safe_z_home: Move out of range if using move_to_previous · Issue #6041 · Klipper3d/klipper · GitHub
Hi there.
I’m getting Move out of range error after g28 if move_to_previous is enabled in safe_z_home section
Related Klipper console message:
!! Move out of range: -40.001 243.001 10.000 [0.000]
Configuration sections:
[stepper_x]
step_pin: AXE_X_STEP
dir_pin: AXE_X_DIR
enable_pin: !AXE_X_EN
microsteps: 256
rotation_distance: 40
full_steps_per_rotation: 400
endstop_pin: tmc2209_stepper_x:virtual_endstop
position_min: -40
position_endstop: -40
position_max: 241
homing_speed: 20
homing_retract_dist: 0
[safe_z_home]
speed: 400
home_xy_position: 88,108
z_hop: 10
z_hop_speed: 100.0
move_to_previous: true
Further investigation:
After issuing g28 x i can observe following position:
// mcu: stepper_x:9217 stepper_y:-760325 stepper_z:-7994 stepper_z1:-7994
// stepper: stepper_x:-40.000781 stepper_y:108.000000 stepper_z:10.000000 stepper_z1:10.000000
// kinematic: X:-40.000781 Y:108.000000 Z:10.000000
// toolhead: X:-40.000781 Y:108.000000 Z:10.000000 E:0.000000
// gcode: X:-40.000781 Y:108.000000 Z:10.000000 E:0.000000
// gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000
// gcode homing: X:0.000000 Y:0.000000 Z:0.000000
Seems final coordinates are not properly set to desired ones
klippy.log (96.2 KB)
Are you using sensorless homing?
for sure, as you can tell from my configuration 
Where you able to successfully tune this according to TMC drivers - Klipper documentation?
I do not see anything apparently wrong maybe except that you seem to have strong steppers (1.2A run_current).
It may be advisable to reduce this during homing and define a movement away from the “touch down”. See using-macros-when-homing
And edit:
Well, this is expected since your homing failed.
What you mean homing has failed? It only produce that error if i add move_to_previous to config, otherwise it works flawlessly.
From my pov it could be some internal klipper problem, not settings final position after homing to position_endstop properly. Other peoples spotted same problem without sensorless setup as well. Only being visible with move_to_previous is enabled so far.
In my opinion gcode position cannot be out of min-max position boundaries.
Not sure about this. I do not know any negative reports about move_to_previous and also in the GH issues or here there is no historical evidence that something is amiss.
For me a plausible cause (just spitballing):
- You sensorless home full force and keep the axes pressed against the homing block
- You move away for z-homing
- You return to the position of No 1 (
move_to_previous) and get an overshoot by 0.001 mm leading to the failure. Or to be more precise: You already “recorded” this overshoot during No. 1 and thenmove_to_previoustries to reach the same position that is then matched againstposition_min: -40
This fits to my observation of problem as well. In my opinion it could be solved if axis position would be actually set to exactly match position_endstop one.
Such reports happens from time to time in out local klipper group.
I believe that in this case the issue might be caused by the “harsh” homing, meaning the high current and keeping it pressed against the block.
The recommendation in the docs is there for a reason.
same problem with normal homing. can’t get log from this person tho…
!! Move out of range: -5.013 -5.000 10.000 [4083.916]
[stepper_x]
step_pin: PC2
dir_pin: PB9
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: !PA5
position_endstop: -5
position_max: 321
position_min: -5
homing_speed: 50
[safe_z_home]
home_xy_position: 187, 192
speed: 75
z_hop: 10
z_hop_speed: 5
move_to_previous: true
I know there are ways to hide tthe problem, but it doesn’t mean problem does not exists at all.
As near as I can tell, the move_to_previous was intended for users that manually home x and y separately. It seems not intended for general G28 usage. My advice would be to not use it. (Or, to use macros to home X and Y, and then Z - which is the recommended setup for sensorless homing.)
The reason for the “move out of bounds” error is that homing can technically move the carriage slightly past the nominal endstop position (such that the carriage is pushing against the rail slightly). Thus, moving away and then back to the previous position is not considered valid. If you really did want to do this (I’m not sure why one would), you could increase the min/max_position settings so that one can move slightly past the nominal endstop position.
-Kevin
Thanks, but it sounds half-sane. Am i supposed to expect axis to be in endstop_position after g28 x or g28 y if no any modifications applied?
Just for better understanding:
After G28 you want to have the head at one corner and not in the middle. Correct?