Just adding LIFT_SPEED to PROBE_ACCURACY in Docs
docs/G-Codes.md
-PROBE_ACCURACY [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
[SAMPLE_RETRACT_DIST=<mm>]`:
+PROBE_ACCURACY [LIFT_SPEED=<mm/s>] [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
[SAMPLE_RETRACT_DIST=<mm>]`:
Screenshots attached in PR to show it’s working in console
Would you be able to help move this along?
or tell me off in some constructive way
Could you explain the improvement of your PR for Klipper?
Users would know they have another option to control the PROBE_SPEED command, to be able to test issues with their probe/system and ability to test future configuration values
It’s filling a gap in incomplete documentation as that option exists but is not stated clearly in the documentation at this time.
I’ve used it before to debug and optimize by printer’s probing configuration. (this same config of one sample also multiple during probe mesh)
These command options correlate to an option in the config file
under the [bltouch] section
there are:
samples, speed, lift_speed, sample_retract_dist
lift_speed is what I’m adding here to the documentation of the gcode command
(speed in config and terminal output = probe_speed in the command)
For example I discovered that while a speed value of 8 is probably the most I should have for my current hardware, I can have a lift_speed of 100 (possibly even a bit more) without losing accuracy
I’m running a big probe count for the bed_mesh (6, not always probing all the bed), and due to low-quality probe, I probe 3 times with some retries happening
With this and another couple of tweaks I saved several minutes per run
And all my PR suggest is not even a code change, it’s just document what is already there and misses in the document.