BLTouch::command Avoid write for duplicate probe commands

[dfries]

Description

BLTouch::command Avoid write for duplicate probe commands

deploy(); deploy(); or the reverse stow(); stow(); would delay 750 ms
each command giving time to check for an alarm. If the command is the
same as the last command, it would have already delayed checking for
an alarm, skip the write, and skip the delay.

Here are the calls that result in the duplicate command at the start
and end of a set or probes. Handling it on the BLTouch side seems
better than coming up with a solution to try to avoid the duplicate calls
in the nested functions.

Probe::probe_at_point() calls deploy(), run_z_probe(), stow()
run_z_probe() calls probe_down_to_z()
probe_down_to_z() calls bltouch.deploy(), bltouch.stow()

Requirements

BLTouch

Benefits

My auto bed level probe time increased 1 minute 15 seconds from 2.0.9.3 to bugfix-2.1.x for G29 5x5 with two touches at each point on Ender 6.

2.0.9.3 took 3:19.75
bugfix-2.1.x took 4:34.13,
bugfix-2.1.x + this change 4:02.02

More changes will be needed to get back to the 2.0.9.3 probing speed.

[thinkyhead]

Nice optimization. Thanks!

More changes will be needed to get back to the 2.0.9.3 probing speed.

To what do you atribute the extra 1.72 seconds per probing point? Is it just the various BLTOUCH_DELAY parameters or extra Z movement, or…?

[thinkyhead]

I see that a previous default for BLTOUCH_DELAY was 375 and this was raised by @InsanityAutomation in May of 2019. I trust that it was important enough to get reliability over speed in that instance.

[dfries]

To what do you attribute the extra 1.72 seconds per probing point? Is it just the various BLTOUCH_DELAY parameters or extra Z movement, or…?

I just did a time test. This was with commit 70063fb
"[cron] Bump distribution date (2023-03-28)"
and a minimally modified configuration for Creality Ender 6 to enable BLTouch.
G29 5x5*2, 4:34 minutes:seconds, baseline time value which matches the slower time I saw going to the bugfix-2.1.x branch.

G29 5x5*2, 3:33 is after only decreasing the BLTouch delay. While that was still higher than 2.0.9.3 time of 3:20 it tells me that most all of the slowdown comes from BLTouch delays. The remaining 13 seconds could be other bugfix-2.1.x slowdowns, or it could be other of my changes on 2.0.9.3.

previous default for BLTOUCH_DELAY was 375 and this was raised by @InsanityAutomation in May of 2019. I trust that it was important enough to get reliability over speed in that instance.

"PR #13814 Id like to get some users with the 3D Touch clone probes to test this and confirm it allows the removal of the version flag."

Or is that increase the delay enough so even the clones are able to function?

6811e29 for stow() and deploy() went from 375 to 750, which are the actions that count for G29. Making a video of G29, I counted frames and deploy I saw as 1.46 and 1.56 seconds, stow was more like 1.00 seconds. The numbers didn't add up to me, I expected them to be symmetric, then again I was looking for the visible change and that's delayed compared to when the printer sent a command.

Configuration for more stock bugfix-2.1.x

#define MULTIPLE_PROBING 2
#define XY_PROBE_FEEDRATE (133*60)
#define Z_PROBE_FEEDRATE_FAST (7*60)
#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)
#define AUTO_BED_LEVELING_BILINEAR
#define Z_CLEARANCE_DEPLOY_PROBE   10 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES  5 // Z Clearance between probe
points
#define Z_CLEARANCE_MULTI_PROBE     5 // Z Clearance between multiple
probes
#define Z_PROBE_LOW_POINT          -2
//#define BLTOUCH_DELAY 500
//#define BLTOUCH_HS_MODE true

G29 5x5*2, 4:34 Matches my earlier bugfix-2.1.x time

Additional configuration to reduce the BLTouch delays

#define BLTOUCH_DELAY 350
#define BLTOUCH_DEPLOY_DELAY   350
#define BLTOUCH_STOW_DELAY     350

G29 5x5*2, 3:33 pretty close to what I was seeing on the 2.0.9.3 release using what I think should be the same smaller delays. My BLTouch has the QR code and I've not observed any issues with these shorter time delays. I'll be switching to these shorter delays myself.

I have had problems with the BLTouch, but that I'm attributing to a design flaw giving it 3.3V instead of 5V that has been corrected.

Oops I did my testing at 350ms, the correct value should have been 375ms, that should take G29 552*.025 = 1.250 seconds longer to complete, which wouldn't change the outcome much, so I don't plan on retesting.