[BUG] Additional bed move while G29 probing

[unitrix0]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I run the latest version of trhe bugfix-2.1.x branch and recently the printer started to additionally lower the bed when running a G29. Is that a new configuration option or abug?

I configured MULTIPLE_PROBING 2 and BLTOUCH_HS_MODE true

A video showing the problem: https://youtu.be/SN9cbFaW7ks

Bug Timeline

new

Expected behavior

In previous versions it did the two probes and then lowered to Z_CLEARANCE_BETWEEN_PROBES (I think) and then moved to the next point.

Actual behavior

After the two probes it lowers the bed to Z_CLEARANCE_BETWEEN_PROBES and an additional ammount which I cannot tell where it comes from.

Steps to Reproduce

Simply run a G29

Version of Marlin Firmware

Bugfix-2.1.x 2023-03-24

Printer model

Ender 5 plus

Electronics

Bigtreetech SKR MINI E3 V3.0

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configurations.zip

[GMagician]

On code, not checked properly, there is something like:
_MAX(Z_CLEARANCE_BETWEEN_PROBES, Z_CLEARANCE_DEPLOY_PROBE)
when it try to deploy/stow probe. May be your case?

[unitrix0]

I didn't change those values and they worked before. So, I don't know what your suggestion is

[GMagician]

your extra move may be due to Z_CLEARANCE_DEPLOY_PROBE (5mm) vs Z_CLEARANCE_BETWEEN_PROBES (2mm). Not checked when/if something has been changed on probing recently

[unitrix0]

Ok, so I've played around with those values now and, while they of course have an effect, it still does an additional move. It seems to me that there is something hard coded?

[GMagician]

Maybe this. Related to bltouch hispeed mode:
static float z_extra_clearance() { return high_speed_mode ? 7 : 0; }
But this has been present for more than 2 years, looking at blame on github

[unitrix0]

that would match up...
I turned the printer of right after the additional move and then checked the distance with a drill between the nozzle and the bed. 9mm was just fitting through. So those 7 and the 2 from my Z_CLEARANCE_BETWEEN_PROBES value would add up. Allthough why now, when it's there for 2 years...

[unitrix0]

So I gave it a try and changed the line:
const float safe_z = _MAX(current_position.z, SUM_TERN(BLTOUCH, Z_CLEARANCE_BETWEEN_PROBES, bltouch.z_extra_clearance()));
To:
const float safe_z = _MAX(current_position.z, SUM_TERN(BLTOUCH, Z_CLEARANCE_BETWEEN_PROBES, 0));

and voila, No additional move anymore.

[unitrix0]

I've found another commit from March 18. 88da531. There this line was added.

[thisiskeithb]

I've found another commit from March 18. 88da531. There this line was added.

I noticed an new, extra Z move with the latest bugfix on a Ender-3 with a BLTouch and suspected this was the offending commit but I currently have my machine torn apart for a hotend replacement and couldn't test it 🙂

[V1EngineeringInc]

Any chance this is our missing Z move from #25560?

[unitrix0]

I didn't commit my changes if that's what you mean?