[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?

[V1EngineeringInc]

My untrained brain was just thinking, these issues popped up in the same timeframe. One has an extra Z move, and the other has a missing Z move. I was hoping this fix might also fix the other. I will try to test it in the next few days if no one gets there before I do.

[thinkyhead]

I'm in the midst of trying to obtain consistent probe behavior across different probing procedures. I've added more debugging to get a better idea where and how to adjust things. Please test the latest code…

• Download Marlin bugfix-2.1.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Issue the command M111 S247 to enable maximum logging.
• Perform a G28 to do your standard homing procedure.
• Do a G29 to probe the bed. This will also enable bed leveling.
• Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs I can get a better idea of where the raises are occurring and apply additional refinements.

[V1EngineeringInc]

Hope this helps, My G29 works, it does seem to move extra far before probes. Next up trying the bltouch hs mode for the g34 error.
g29log.txt

[jamespearson04]

would you say about 7mm extra?

https:/MarlinFirmware/Marlin/blob/bugfix-2.1.x/Marlin/src/feature/bltouch.h#L79

That function is now used for some reason, implemented in the suspected PR #25498, commit 88da531

ETA: if it is that, it should raise 7mm more with HS mode off than otherwise

[V1EngineeringInc]

Maybe. My other printers will be printing most of the night so I can't easily compare.

HS mode, for me, just keeps the bed in contact with the BLTouch, and doesn't ever clear all the way. I do not like the way it crashed so I prefer not to use it. Everything else seemed the same. Still missing the clearing move after the bed physically (g34) levels.

[jamespearson04]

@unitrix0 For clarity, when you say extra move, do you mean it moves further than it should, but in one movement, or that it makes two distinct moves? because extra distance will definitely be from that commit, an additional move however, definitely not

[V1EngineeringInc]

I'm not the right one to ask about this. G29 works fine for me. I was just hoping my logs might help clarify the actual moves happening.

I only have an issue with g34.

I do not see two distinct moves.

[jamespearson04]

That's why I @'d unitrix ;)

I've tried taking a look into G34, but I can't do any testing since my printer isn't dual Z

[thinkyhead]

Hope this helps, My G29 works

I have one machine with a BLTouch that I have been trying out. So far, just the G28 stuff. I noticed a behavior of M402 that annoyed me, so I got distracted, but I can get back to testing G29 soon. Generally, I want to localize all the clearance and probe handling in the Probe class, and of course this is bound to lead to some glitches. But through the logs we should be able to pinpoint the exact places where unnecessary motion is being applied. There is a lot on my plate, so it's hard to stay on track and it's rare for me to get directly involved in testing, but since I broke it I figure I should join the effort in earnest. Anyway, I'll get back into it in about 10 hours or so….

[jamespearson04]

I had a bit of a mess around with it, I could tell that's what you were going for, so tried to tidy up the loose ends :) I'll open up a PR for it, so hopefully it'll just need merging in.

[unitrix0]

@unitrix0 For clarity, when you say extra move, do you mean it moves further than it should, but in one movement, or that it makes two distinct moves? because extra distance will definitely be from that commit, an additional move however, definitely not

it actually makes an addittional move. I've changed my configuration to make another video with slower probing speeds. Now it's also clear that the second move comes from somewhere else since it uses not the probing speed value.

https://youtu.be/USxZ_kpf-90

[thisiskeithb]

Likely related, but possibly a different bug:

I updated to the current bugfix-2.1.x (c25a673) on a Prusa Bear with a PINDA V2 (FIX_MOUNTED_PROBE) and MULTIPLE_PROBING 3, it will only probe once on each point now.

Changing MULTIPLE_PROBING 3 to MULTIPLE_PROBING 2 and enabling EXTRA_PROBING 1 doesn't affect the probing behavior. It still only probes once per point.

Some other relevant settings that work fine in older versions of Marlin:

#define Z_CLEARANCE_DEPLOY_PROBE    0 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES  2 // Z Clearance between probe points
#define Z_CLEARANCE_MULTI_PROBE     1 // Z Clearance between multiple probes
#define Z_AFTER_PROBING             5 // Z position after probing is done

Link to full config

[unitrix0]

I updated to the current bugfix-2.1.x (c25a673) on a Prusa Bear with a PINDA V2 (FIX_MOUNTED_PROBE) and MULTIPLE_PROBING 3, it will only probe once on each point now.

Changing MULTIPLE_PROBING 3 to MULTIPLE_PROBING 2 and enabling EXTRA_PROBING 1 doesn't affect the probing behavior. It still only probes once per point.

Yes, can confirm that.

[thisiskeithb]

Reverting 49f1cc8 fixes the single probe per point issue for me.

[jamespearson04]

So for the double lift, this is because before probing it lifts to Z_PROBE_SAFE_CLEARANCE, but after probing it only lifts to Z_CLEARANCE_BETWEEN_PROBES. So you get an additional lift from Z_CLEARANCE_BETWEEN_PROBES to Z_PROBE_SAFE_CLEARANCE after probing.

[jamespearson04]

This should be fixed with #25631 - testing on my printer shows no extra lifts now.

[unitrix0]

This should be fixed with #25631 - testing on my printer shows no extra lifts now.

For G34 I assume?

[thisiskeithb]

For G34 I assume?

Both G34 & G29 issues.

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.