[BUG] G29 P1 Retracts Probe at Point 38

[Cooldog1099]

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

Yes, and the problem still exists.

Bug Description

After issuing a G29 P1, it will probe normally (CRTouch) all the way to point 37. At point 38 it retracts the probe and attempts to probe. At best, it causes a failed probe point, at worst it causes a bed crash.

Terminal Output:
[...] Recv: //action:notification Probing Failed Recv: Error:Probing Failed Recv: Probing mesh point 38/100. Recv: //action:notification Probing Point 38/100 [...]

At point 39, it extends the probe and continues to point. From then it continues normally to 58/100 and stops.

Any assistance is appreciated.

Thanks!

Bug Timeline

New printer/first time flash

Expected behavior

It should not retract the probe during probing.

Actual behavior

It retracts the probe, leading to a bed crash.

Steps to Reproduce

Issue G29 P1 from terminal.
configs.zip

Version of Marlin Firmware

Marlin bugfix-2.1.x

Printer model

Ender 3 Neo

Electronics

Stock 4.2.7 board

Add-ons

Stock

Bed Leveling

No Bed Leveling

Your Slicer

None

Host Software

OctoPrint

Don't forget to include

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

Additional information & file uploads

No response

[cinealfa]

I'm having the exact same issue.

[SRCGremlin]

Major issues on migration to 2.1.2 with probe. Have this exact same issue on an Ender 5 plus SKR 1.4 Turbo Hemera build, I have been following the issues and input the change modified here https://github.com/MarlinFirmware/Marlin/pull/25631/files . This fixed some of the buggy crashing behaviour from the G34 command. However I still have a G29 fail at the exact same area everytime (point 3/49 - 7x7 point mesh). This is a repeatable change since upgrade from version 2.1.1. I continued to modify the code and test based on this post #25565 and modified as per this post - #25565 (comment) This did have the effect of changing the failure to mesh point 2/49 on a 7x7 grid (repeatable), hence the relationship of "bltouch.z_extra_clearance" is directly effecting the mesh failure point (seems potentially suspect that the actual Z clearance has changed from a working setup and given that the bed passed a G34). Looking forward to a fix on this issue...

[SRCGremlin]

Confirm pull request #25631 fixes this issue for me.

[thisiskeithb]

@Cooldog1099, @cinealfa: Please test #25631 and report your findings in that PR.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.