Klipper: [Feature Request] BLTouch Fast Mode (No retract during probing)

[gcurtis79]

Could you enable a setting for the bltouch section for high_speed probing support? I've used a similar setting in other firmware called "High Speed" mode. It makes the probe extend at the beginning of a probe cycle (homing, or mesh calibration) and keeps it extended during sampling, lowering, bumping, raising, so on..... then retracts when complete.

This has cut probing time significantly, and would be a nice feature to use with Klipper as well.

[klipper-gitissuebot]

Hi @gcurtis79,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[gcurtis79]

@klipper-gitissuebot

This is a feature request, thus a log is inconsequential. My printer is functioning normally, I just asked if something could be enhanced.

I know you're a bot, but my reply is so the devs can hopefully sort this out, or tell me if I'm posting in the wrong area.

[FanDjango]

I'm the guy who came up with the "High Speed" mode and most of the BTLOUCH V3.x changes in an "other" firmware last early summer. Since then I have moved on to using klipper and have made the necessary changes to the code in order to have the same behaviour.
Although not really being python expert, my changes work well and are not very extensive, but therefore a kind of kludge and also of course hurtful for those who might have other kinds of probes.
I was planning on enhancing on this some time after new year, thereby learning some (more) python and klipper-architecture as well, perhaps submitting a pull after some people look at the code.

[FanDjango]

Folks, I just had a look at #2170, #1938 and this commit Sort of getting cold feet about this.

One of the main points that I have also seen on my printers is that the following timing is way longer than on marlin:

BLTouch triggers -- ticktockticktock-> klipper retracts pin and then starts moving the toolhead upwards

On a trigger, marlin virtually immediately pulls up the pin by setting the PWM to "STOW" - that's done in the microcontroller. Upward movement also begins very very soon after. In high speed mode (if not in SW MODE = "touch mode"), the only thing preventing an error on the bltouch is the upward movement, because a STOW is not done before the final probe of a sequence.

Although on my system combination (it's a ASUS Tinkerboard + LPC1768) the HIGH SPEED mode works fine, I now think that this approach is asking for trouble on slower systems.

So currently I think I will refrain from putting together a PR for this. If anyone would like to test my version, I've got a fork sitting there. I would appreciate any feedback on this.

[JohnEdwa]

@FanDjango
Decided to give it a go, functionally it seems to work perfectly fine on my setup (RasPi 3, Ender 3, BLTouch V3(something)), though as you noticed the reaction to being triggered is really slow, and high_speed_mode: 2 still does a simultaneous lift&stow between [bed_mesh] samples.

I'll continue using it for now and report if I notice anything odd.

---

Klipper overall seems to be really slow to even notice the trigger, easiest way to see it is to run PROBE_ACCURACY with varying speeds. Here are my results:

• 1mm/s: median 2.337953, standard deviation 0.001871
• 5mm/s: median 2.140453, standard deviation 0.002358
• 9mm/s: median 1.945453, standard deviation 0.002784

If I take the 1mm/s as the "correct" distance, at 9mm/s it moved 0.3925mm further before registering the trigger, which is 157 Z-axis microsteps and 44 milliseconds.
Also, those standard deviations are all within a microstep or so, so the precision of the measurement is spot on - the absolute value is just rubbish.

[FanDjango]

@JohnEdwa
Ok, I was putting on some finishing touches and then reforked, uploaded everything from scratch so to not habe a commit shambles. I did have a version out there that behaved the way you described on mode 2. But now it doesn't. It's like the "other" firmware. So you might need to get it one more time to be safe- you might have got the in-between version. Sigh.

Here's my config for it:

[bltouch]
# 0 = no high-speed
# 1 = simultaneous stow and toolhead raise
# 2 = no intermediate deploy and stow + (1)
high_speed_mode: 2
# you can specify an absolute minimum cmd time
min_cmd_time: 0.150
# set this to false if probe does not support it
test_sensor_before_use: True
# choose to use SW mode
use_sw_mode: True
#
sensor_pin: P1.22
control_pin: P1.23
x_offset: 33.0
y_offset: -5.0
speed: 5.0
samples: 1
sample_retract_dist: 2.5
samples_result: average
#samples_tolerance:
#samples_tolerance_retries:

---

Concerning trigger-delay: You are right it is not a problem if repeatability is ok. Just the resulting absolute position shifts as a constant which you also correct for in the z-probe offset, finally. Problem is the bltouch: In normal mode (as opposed to SW mode) it goes in to blinking error state if you don't STOW and/or raise the probe with 650ms of trigger. Now, the "other" firmware gives you the option of using SW mode for each probe, which gives you more time. Not many people set that, though. And there are concerns that SW mode has less repeatability, which I myself cannot prove nor disprove yet. Some people using the bltouch also simply drive their Z-axis very slow, which exacerbates the problem.

---

I will give the option to use SW mode in the [bltouch] config section and try to make some repeatability tests, maybe. So check the fork in the next few days for new stuff.
For what it's worth, I have done a PROBE_ACCURACY SAMPLES=50 for all combinations of normal mode and SW mode and heaters on/off:

```PROBE_ACCURACY SAMPLES=50
Normal Mode
Heaters Off:
probe accuracy results: maximum 2.485000, minimum 2.471250, range 0.013750, average 2.480075, median 2.480000, standard deviation 0.002697
Heaters On:
probe accuracy results: maximum 2.467500, minimum 2.447500, range 0.020000, average 2.458225, median 2.458125, standard deviation 0.004880

SW Mode
Heaters Off:
probe accuracy results: maximum 2.456250, minimum 2.450000, range 0.006250, average 2.452750, median 2.452500, standard deviation 0.001521
Heaters On:
probe accuracy results: maximum 2.453750, minimum 2.442500, range 0.011250, average 2.448950, median 2.448750, standard deviation 0.001826
```

So, go figure...

---

Someone mentioned to me, where is that fork/branch: BLTOUCH-HIGH-SPEED

I'll keep it current against the main klipper master and gather lots more feedback before anything else. A PR is still far away, I think. Maybe somebody else is also on this, or @KevinOConnor maybe?

[KevinOConnor]

@FanDjango - Thanks for looking at this.

FYI, I'm aware of five open issues with the current Klipper BL-Touch code:

1. There is a race condition on host to mcu query requests that could cause query responses to get delayed ( https://github.com/KevinOConnor/klipper/issues/1938#issuecomment-529255057 ). That delay could cause the bltouch to go into an error state. This race is quite rare in the general case, but for unknown reasons some users are experiencing it with higher frequency.
2. A low level retransmit could cause a delay in processing a query request. (Part of https://github.com/KevinOConnor/klipper/issues/1938#issuecomment-529101191 .) This delay also results in the bltouch going into an error state.
3. The code attempts to clear the error state from the bltouch, however it may not be able to clear the error state when the bltouch is near the bed. Ideally, the code would raise the probe before trying to clear the error state.
4. There are reports that the bltouch reset command is not given enough time. The current code will issue a reset command for 100ms and then issue a pin_up command. (Reported at https://github.com/KevinOConnor/klipper/issues/2197 )
5. There are reports that BLTouch v3 users are having better success with probing in "touch mode". However, as you note, there have been multiple reports of users with earlier BL-Touch and various clones showing severe degradation when probing in touch mode.

BLTouch triggers -- ticktockticktock-> klipper retracts pin

I'm not sure if you observed this with the main Klipper code or on your development. As you've noted, Klipper is performing the pin_up command in the host software. However, barring the rare cases of 1 and 2 above, the host software should issue the pin_up command reliably within 100-110ms of the trigger. The following head movement can take a further ~250ms, however.

Maybe somebody else is also on this, or @KevinOConnor maybe?

Be aware that I do not own a BL-Touch (nor a clone). So, I personally don't have any plans to work on enhancements. I'm certainly open to merging in enhancements from others.

From the above list, I hope to fix the low-level issues causing items 1 and 2. (Addressing 4 is easy, but I'd need to get confirmation and further details for me to do that.)

Let me know if you have any questions.

-Kevin

[FanDjango]

@KevinOConnor - thank you for your comments.

Points 1 & 2:

However, barring the rare cases of 1 and 2 above, the host software should issue the pin_up command reliably within 100-110ms of the trigger. The following head movement can take a further ~250ms, however.

Over the past half year I have been testing the bltouch probes thousands of times and am just oversensitive to "changes" in cadence - I believe I can confirm these timings on klipper and also believe that cases 1 and 2 are of course show stoppers for those that experience them. I am not really qualified to comment on these.

Point 3
Klipper is not alone in this respect. In some very specific cases a slight upward movement would be helpful in recovering. In my opinion, if points 1 & 2 are solved and the user has a reliable wiring situation this kind of situation is extremely rare and also merits aborting the probe sequence anyway to go for a manual recovery.

Point 4
Lot's of testing has shown RESET needs a minimum of 500ms to do its thing internally in the BLTOUCH and clones. So I confirm those reports. ANTCLABS have not published a min time for RESET. I have asked for timings and at least they have produced the timing diagram on their website as a result and it contains some other important timings. Also due to an open issue in their microcode, a RESET will not actually reset the bltouch totally - if it is in SW mode a RESET will NOT fulfill your expectations. You should therefore always follow a 500ms RESET by a 650ms STOW (which finally turns off SW mode) and check for a fault after those. Of course, unless you know for sure you can't be in SW mode.

Point 5
So, one might give the user a choice which probing mode he would like to use.

Another point in case is the ongoing discussion about turning off the PWM at the end of a command. I disagree with your comments about incorrect command sequencing on the bltouch if the PWM is ongoing, but not strongly. My tests one way or the other have shown there is no difference in the bltouch behaviour if PWM is turned off or not (in the other firmware). I have tested this by now in klipper and here it is the same. So no problem either way.

The only danger when turning off the PWM after a command (or after a sequence of commands) is that the specific hardware handler for this must dampen the output signal so that spuirous noise cannot confuse the probe - pull-up/downs must be set and no floating signals. I have not checked the hardware dependant code of the mcu for each architecture and assume all is healthy in there in this respect.

---

So I have added some more options to the HIGH-SPEED fork/branch and will now work on moving it to a PR. That way you can review the changes to get an overview of what is involved. I remember the pain earlier this year in producing something of this complexity and actually do not envision any kind of movement on this - but I wanted to pass these things on before I move on to other things and they might otherwise get lost.

See heaters_off, sw_mode

The code also supports either automatically or manually setting the bltouch V3.1 5V or Open Drain mode and even storing it in the bltouch eeprom. See BLTOUCH_DEBUG COMMAND=STORE_5V and BLTOUCH_DEBUG COMMAND=STORE_OD

[bltouch]
# 0 = no high-speed
# 1 = simultaneous stow and toolhead raise
# 2 = no intermediate deploy and stow + (1)
high_speed_mode: 2
# you can specify an absolute minimum cmd time
min_cmd_time: 0.150
# set this to false if probe does not support it
test_sensor_before_use: True
# use SW Mode if you want instead of normal mode
use_sw_mode: True
# turn heaters off during downward probe motion
heaters_off: True
# set_mode: none=do nothing, 5V=set 5V mode, OD=set OD mode
set_mode: 5V
#
... and so on ...

[KevinOConnor]

Point 3
Klipper is not alone in this respect. In some very specific cases a slight upward movement would be helpful in recovering. In my opinion, if points 1 & 2 are solved and the user has a reliable wiring situation this kind of situation is extremely rare and also merits aborting the probe sequence anyway to go for a manual recovery.

Okay, thanks. That is helpful.

Point 4
Lot's of testing has shown RESET needs a minimum of 500ms to do its thing internally in the BLTOUCH and clones. So I confirm those reports.

Thanks. This is something that is easy to change in the short term. Do you know if a reset should always last 500ms, the configured pin_move_time, or the maximum of 500ms and pin_move_time?

You should therefore always follow a 500ms RESET by a 650ms STOW

Okay, that is the current Klipper behaviour (assuming the user hasn't fiddled with the default pin_move_time).

Point 5
So, one might give the user a choice which probing mode he would like to use.

That's fine if someone wishes to implement it. I do think the default mode needs to be pin_down mode given the concerns with the other popular bltouch versions widely in use.

So I have added some more options to the HIGH-SPEED fork/branch and will now work on moving it to a PR. That way you can review the changes to get an overview of what is involved.

Thanks, that sounds good.

I remember the pain earlier this year in producing something of this complexity and actually do not envision any kind of movement on this - but I wanted to pass these things on before I move on to other things and they might otherwise get lost.

Sorry, I don't understand what you are referring to here.

Cheers,
-Kevin

[KevinOConnor]

FYI, this support should now be available (commit 086c131b).

-Kevin

[sedlacekdavid]

@FanDjango Hi, is it in Master? Thank you

[FanDjango]

@sedlacekdavid Yes, it is.

[sedlacekdavid]

@FanDjango

https://www.youtube.com/watch?v=S7dYOVr_weA

Is this fast?

I've tried:
high_speed_mode = 1
high_speed_mode = True
high_speed_mode = 2

But none of that had any observable results...

Basically it works very well and the only thing I'm missing is reducing delay when rising the probe. It doesn't have to wait anything, since there is a lot of time when rising the probe to do necessary check/communications.

Thanks David

[FanDjango]

@sedlacekdavid It is not called high_speed_mode. Use

stow_on_each_sample: False
#   If set to False, intermediate STOW/DEPLOY sequences on certain
#   operations that use the probe multiple times will be omitted.

in the [bltouch] section

[sedlacekdavid]

@FanDjango thx man, will try that. I wasn't sure what to use after reading all the information here.