It is a very specific problem to the Elegoo Neptune 3 printer which uses a weird sensor probe but maybe that can be useful for other implementations of the same probe.
The Elegoo probe must slow down the gantry a lot before hitting the bed for accurate measurements. On the Marlin code they do that by using a light sensor on Z that tells the Marlin code that the probe is about 6mm away from the bed, and then it slows down the “homing_speed” and “second_homing_speed” significantly.
This is the piece of Marlin code that does that:
Neptune_3/probe.cpp at main · NARUTOfzr/Neptune_3 · GitHub (lines 577 to 593).
So, to mimic that behaviour it would be interesting if Klipper allowed me to dynamically change the “homing_speed” and “second_homing_speed” parameters if a sensor is triggered. So, it would be as simple as:
[gcode_button z-sensor]
pin: PC14
press_gcode:
SET_STEPPER_Z_HOMING_SPEED = 0.2
SET_STEPPER_Z_SECOND_HOMING_SPPED = 0.1
release_gcode:
SET_STEPPER_Z_HOMING_SPEED = 5
SET_STEPPER_Z_SECOND_HOMING_SPPED = 2.5
One can see that me and “jerryngm” tried our best to make this printer work, but with some “hacks”.
In my case I am using the z-sensor as an z-endstop and I am setting the “position_endstop = 6”:
“jerryngm” is doing a far more complex g-code and pin override, but both homing speeds are still set to very low values which makes homing and ABL very slow (see link based on my config, it is where I forked from).
With those parameters being possible to be dynamically changed, it would be far easier.
Also, if you look closely to the Marlin code, there is an PROBE_TARE_PIN that should get a signal to reset the probe. I cannot see a way to do that with custom G-CODE currently 