Closed crazy-daddy closed 1 year ago
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).
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
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 :)
I tried a fix in 9713b5b5647a17a28f2b3775c6dc5f10800ba6ac Can you tell me if it's ok?
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?