[safe_z_home] Override z_endstops

Basic Information:

Printer Model: voron0.2
MCU / Printerboard:SKR mini E3 v2
klippy.log

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
When pasting code or config snippets use the code tags </> in the menu above

Describe your issue:

z_ hop can’t verify that the hop moves towards the negative value, but the Z zero of voron0.2 and the limit switch are at the maximum value of Z, that is, the bottom. This results in if the platform is at the bottom, and if z is configuredz_hop is 5, and then execute the G28 X0Y0 or G28. Even if Z has triggered the limit switch, z will continue to increase and move downward by 5mm, which will cause Z to exceed the travel and hit the frame.
z_hop向负值方向移动我无法验证,但是voron0.2 的Z归零和限位开关在Z的最大值,也就是最底部。 这样造成如果平台处于最底部,如果配置z_hop为5,然后执行归零XY或者全部归零,即使Z已经触发限位开关,但是z还会继续增加向下移动5mm,也就导致Z会超出行程,撞上框架。

This might help: Moving Z before homing or other

It is because Z is moved before zero and Z is near the maximum value. So continue to move to trigger the limit, or continue to move…

For example, when z is at 148 and the maximum value of Z is 150, Z first_ Hop 5 means that Z has obviously exceeded the maximum value of 150 to change from 148 to 153. Even if the limit switch is triggered, it will still move.
就是因为归零前移动Z 而Z处于接近最大值。 所以继续移动触发限位,还是接着移动。。。
比如:z处于148 ,Z最大值150 归零时首先Z_hop 5 意味着Z要从148变成153 显然已经超出150的最大值,即使触发限位开关,还会照样移动。

I see three potential solutions for your issue:

  1. Do not use z_hop
  2. Use [homing_override] and some macro as detailed in the link above to move upwards before actually homing. This of course shifts your issue to Z=0
  3. Establish a “custom homing”, e.g. HOME_LOW, which you call instead of the regular G28 in case your Z is close to maximum