Faster "pinup" on BL-Touch #4124
Conversation
|
Thanks for addressing this, Kevin. It closes the aperture for error state on BLTouch probes and the main observed difference to Marlin, the 2nd being the non-continuous PWM (which has been discussed and is not an issue). After introduction of SW-Mode in klipper, there was a way to avoid the error state when unable to either raise the probe or stow the pin within about 700ms due to inner delays. SW-Mode has no max-time when triggered. But this change is very positive nonetheless as you intend to add multi-mcu homing. Do not want to have only the choice of using SW-Mode, it is nice to be able to use the native mode and not have the delay glitches. Unfortunately I won't be able to test this for you for another few weeks as the (klipper) printers are in the office and I won't be going in for some time. I dare say that any one of the current BLTouch users who test this should be able to see an immediate difference in homing/probing behaviour. |
|
I was able to confirm that my bltouch 3.1 operates as expected for both stow_on_each_sample True and False. Probing during G28, SCREWS_TILT_CALCULATE, and PROBE_ACCURACY all work as expected. |
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Start the raise sequence once the endstop notification arrives. This can reduce the response time as it does not require waiting for the homing sequence to fully finalize. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
KevinOConnor
force-pushed
the
work-bltouch-20210329
branch
from
50b42bd
to
3cfc42e
Compare
|
Okay, thanks. I went ahead and committed this change. FYI, I don't think this will be noticeable to most users. I expect the response time to now be around ~102ms instead of ~110ms. The main goal is to prevent that time from further increasing with future changes and to make it less likely comms jitter impacts the timing. -Kevin |
|
I'll be honest, I didn't notice any speed changes. |
So disregard my statement above. I stand corrected. I was actually hoping for a discernable improvement. I understand now that we are getting an "upper limit" on possible delays due to the factors Kevin mentioned. |
When probing, the current bltouch code will detect a trigger signal, acknowledge the mcu homing event, and then send a pin_up command. The "mcu acknowledge" stage may require a few messages to be sent to the micro-controller which normally takes a few milliseconds. However, in the event of communication errors or delays, it's possible for that process to delay the pin_up command. As we work on multi-mcu homing (PR #3956) the "mcu acknowledgement" becomes more complex and it increases the risk of a delay.
This PR alters the bltouch code so that it can send the pin_up immediately after a trigger signal. This should reduce the risk of a delayed pin_up command.
I don't actually own a bltouch, so I can't directly test this code. Testers would be welcome. Basic verification that probing continues to work (in both stow_on_retract=False and stow_on_rectract=True modes) should be sufficient.
cd ~/klipper ; git fetch ; git checkout origin/work-bltouch-20210329 ; sudo service klipper restart@FanDjango - FYI.
-Kevin