Issue on V0 with homing_zhop - Bug or Layer 8 problem

[crazy-daddy]

My V0 has an issue where after homing Z he always tries to move out of bounds. Problem is G0 Z{homing_zhop} F{z_drop_speed} # small Z hop to avoid grinding the bed in homing_override.cfg - homing_zhop is ofc positive to not grind the bed for homing X,Y but Z endstop is in positive direction. So bed ends at z=118 (in my case) and tries to move to z=123 . For X,Y there's the homing_backoff_distance_xy - but not for Z.

I added variable_homing_backoff_distance_z: 5 and execute the G0 with that after homing Z in the meantime, but don't love having a changed codebase ;-) I imagine it has to be a layer 8 issue, as noone else seems to have that issue with their V0. Could someone point out what I'm doing wrong?

[crazy-daddy]

EDIT: In case I'm not just stupid I can ofc submit a PR.

EDIT2: Maybe a check for homing_direction would be useful for X,Y,Z... so that backoff_distance can always be positive (as a "distance" should be - physicist here ;-) ). Then the appropriate section could add the SIGN to it as needed (i.e. negative for positive homing_direction and positive otherwise).

[Surion79]

hmm, same issue here on my v0.2. But i am not sure if your solution is the best one. need to think about it. There were some changes regarding the probe sections introduced with 4.0

[Frix-x]

Hello, I'm taking this subject to be able to solve it for all without any special tweaks. It's a known problem: the Z hop is not doing any good on a stock V0.2 due to the endstop at the bottom.

Adding a homing backoff Z is probably something I want to avoid becasue it can add a breaking change for everyone. Instead, I think I'll check about the direction of homing (homing_positive_dir: True/False) and do the hop in the opposite automatically.

Also in the meantime, as a quick solution, just put the Klippain variable_homing_zhop to 0 and it will fix it on your side :)

[Frix-x]

I tried a fix in 9713b5b5647a17a28f2b3775c6dc5f10800ba6ac Can you tell me if it's ok?