[FR] Faster probing (G29) with probe clearances relative to the probe or relative clearance based on the previous probe

[rondlh]

Is your feature request related to a problem? Please describe.

Slow and inconsistent probing speed for the same printer type (different Z-offset).

Are you looking for hardware support?

MKS Monster 8 V1.0
Genuine BLTouch
BTT TFT35 V3.0

Describe the feature you want

CLEARANCES RELATIVE TO THE PROBE

Bed probing (G29) is slow and inconsistent for different printers with the same setup. This is because the clearances (Z_CLEARANCE_DEPLOY_PROBE, Z_CLEARANCE_BETWEEN_PROBES, Z_CLEARANCE_MULTI_PROBE) used for probing are relative to the nozzle, and not to the probe. This means that the probe Z-offset strongly affects the probing height and thus the probing speed. High clearance values must be chosen to consider the full Z-offset range.
It would be useful if the clearances were relative to the probe position (thus independent of the Z-offset).

RELATIVE PROBING HEIGHTS

Probing can also be done faster if a relative probing height is used. Meaning that the next probe point clearance depends on the just found probe z-height. This makes sense in my view as the Z-height of probe points close to each other in XY direction are also close in Z-direction. So the procedure could be for G29. Use a clearance of Z_CLEARANCE_DEPLOY_PROBE for the first probing, then increase the Z-height with Z_CLEARANCE_BETWEEN_PROBES for the next probe. The Z_CLEARANCE_BETWEEN_PROBES value would depend on the sensor hysteresis/LOCAL bed unevenness/probe push in distance before triggering. Implementing this can drastically increase the probing speed by reducing the required Z-travel distance.

Additional context

No response

[ahmetcemturan]

The idea of a relative clearance sounds really good.

[TheOracle2212]

Sounds like it'll improve the speed of probing. One of my biggest problems is that my printer takes forever to bed level; 100% this should speed it up

[rondlh]

Sounds like it'll improve the speed of probing. One of my biggest problems is that my printer takes forever to bed level; 100% this should speed it up

My configuration:
Genuine BLTouch V3.1 in high speed mode (BLTOUCH_HS_MODE).
Speeds: Z: 8mm/s, XY: 150mm/s
8mm/s is fast but in combination with ENDSTOP_INTERRUPTS_FEATURE (MKS Monster8 V1.0 board) it works fine.
1.4mm relative clearance (Z_CLEARANCE_BETWEEN_PROBES)
Z_CLEARANCE_DEPLOY_PROBE 5
400x400 bed
7 x 7 probing
Total G29 probing time: 65 seconds.

(29 seconds on a 200x200 bed, 5x5 probing).

[lukasradek]

Let's maybe talk some real numbers... without that, there is not even a benchmark, yet alone objective measure.
Btw. in regards to speeding up the leveling, have you tried increasing the feedrate for probing moves in Configuration(_adv).h?

If I understand you correctly...

Clearance relative to probe is quite hard to achieve without knowing the position of the probe, which is set by Z offset. But you can simply set some Z clearance (relative to nozzle) and lower it if is it too high for you.

Implementing such a thing like dynamic clearance based on probed height seems like quite a complex logic / lot of work for such a simple task / small benefit. And still... you would have to rely on some clearance because the firmware has no idea how high the next point is (and trying to assume something is not really helpful). So you can just lower the clearance between probes to account for your bed's maximum unevenness and that is it.

[rondlh]

Let's maybe talk some real numbers... without that, there is not even a benchmark, yet alone objective measure. Btw. in regards to speeding up the leveling, have you tried increasing the feedrate for probing moves in Configuration(_adv).h?

If I understand you correctly...

Clearance relative to probe is quite hard to achieve without knowing the position of the probe, which is set by Z offset. But you can simply set some Z clearance (relative to nozzle) and lower it if is it too high for you.

Implementing such a thing like dynamic clearance based on probed height seems like quite a complex logic / lot of work for such a simple task / small benefit. And still... you would have to rely on some clearance because the firmware has no idea how high the next point is (and trying to assume something is not really helpful). So you can just lower the clearance between probes to account for your bed's maximum unevenness and that is it.

UPDATE: Patch #25631 has done some groundwork, it adds an option to enable raise_after_is_relative. This allows to make the raise after probing to become relative. This is currently not used anywhere, but can be enabled in G29.cpp.

Replace:
abl.measured_z = faux ? 0.001f * random(-100, 101) : probe.probe_at_point(abl.probePos, raise_after, abl.verbose_level);
with

abl.measured_z = faux ? 0.001f * random(-100, 101) : probe.probe_at_point(abl.probePos, raise_after, abl.verbose_level, true, true, Z_PROBE_LOW_POINT, Z_TWEEN_SAFE_CLEARANCE, true);

[CRCinAU]

If you use 1.4mm, what happens if the bed is out by more than 1.4mm from edge to edge?

[TheOracle2212]

You’d be in trouble both in software and hardware. Ideally however, on a smaller bed, you shouldn’t have such a large difference, that’s a hardware issue. Moreover, you can tweak it later on in Marlin (I think)

[rondlh]

If you use 1.4mm, what happens if the bed is out by more than 1.4mm from edge to edge?

Probing will still work fine as long as the bed doesn't increase in height from one probe point to the next by about 1mm (very bad bed!). You care more about the local unevenness (which should be small, < 0.25mm) than the total unevenness (<1mm)
The relative height increase is used at every point, except the first of course. I did some tests by adding some business cards on the bed, and it worked fine, but there are limits of course, then the value needs to be increased and probing will be slower.
Like mentioned, the value of Z_CLEARANCE_BETWEEN_PROBES (1.4mm in my case) depends on the sensor hysteresis/LOCAL bed unevenness/probe push in distance before triggering. I use a BLTouch V3.1.

[rondlh]

You’d be in trouble both in software and hardware. Ideally however, on a smaller bed, you shouldn’t have such a large difference, that’s a hardware issue. Moreover, you can tweak it later on in Marlin (I think)

A 1.4mm unevenness would not be great, but is not problem for the SW or HW when selecting the right probing values.

My findings about total bed unevenness

• 200x200 bed, total unevenness around 0.2mm (2 printers)
• 300x300 bed, total unevenness around 0.4mm
• 400x400 bed, total unevenness around 0.6mm

If your unevenness is too big, and you can remove your build plate then use some tape (blue or kapton) to reduce the unevenness.

[lukasradek]

Let me know what information you need, I made a G29 and G34 implementation already that I have been using for a week now. The implementation for G29 is quite trivial. The required function are all present already. Just replace do_z_clearance with do_z_clearance_by as indicated below in 1 location in probe.cpp

....

I am sorry, I misread your previous posts a bit.
But anyway, what is the probing time with Marlin's current leveling logic (the one that you consider slow) and what is the target or time with your implementation?

I can see two places where time can be saved.

1. If you are probing one spot multiple times, you can raise only high enough to reset the probe state, which can be set by Z_CLEARANCE_MULTI_PROBE.
2. When you are moving between probe points, which is set by Z_CLEARANCE_BETWEEN_PROBES. Isn't it just possible to set it low enough to clear the expected unevenness of your bed and be done with it? In your case that would be 1 - 2 mm?

[rondlh]

Let me know what information you need, I made a G29 and G34 implementation already that I have been using for a week now. The implementation for G29 is quite trivial. The required function are all present already.

I am sorry, I misread your previous posts a bit. But anyway, what is the probing time with Marlin's current leveling logic (the one that you consider slow) and what is the target or time with your implementation?

I can see two places where time can be saved.

1. If you are probing one spot multiple times, you can raise only high enough to reset the probe state, which can be set by `Z_CLEARANCE_MULTI_PROBE`.

Correct, the only issue is that this clearance is defined in relation to the nozzle, not the probe. The difference is the Z-offset. So when setting Z_CLEARANCE_MULTI_PROBE you currently need to consider the full range of Z-offset (configurable at compile time, but usually something like 0 to -5mm). Z-offset is changed dynamically (M851), but Z_CLEARANCE_MULTI_PROBE is fixed when compiling. This means that you will need to set Z_CLEARANCE_MULTI_PROBE to a value that considers a Z-offset of -5 (probe is very low), but if the probe is lower (Z-offset is -3) then probing becomes very slow.

2. When you are moving between probe points, which is set by `Z_CLEARANCE_BETWEEN_PROBES`. Isn't it just possible to set it low enough to clear the expected unevenness of your bed and be done with it? In your case that would be 1 - 2 mm?

In the current probing implementation this will cause issues (just try it), firstly because of the reason mentioned above. Secondly you would have to consider global bed level unevenness, probe hysteresis (inductive probe) and the push in distance before triggering (for BLTouch etc.). Currently the probe clearance is the same for the whole bed, so you need to set a relatively high value to be safe otherwise your probing will intermittently fail.

[lukasradek]

Correct, the only issue is that this clearance is defined in relation to the nozzle, not the probe.

But the Z-offset is known (roughly but precisely enough) so can't you just take it into account when setting clearance in config? Of course it might require recompilation when changing hardware in a way that would significantly affect the offset.

In the current probing implementation this will cause issues (just try it),

I cannot try it at the moment unfortunatelly. Well and with your implementation, what changes? The probe still has to go around the whole bed, so you will still have to clear the highest point anyway. Or does the probe lift X mm before moving to a new point (relative to the point where probe triggered last), meaning that it will stairstep up everytime it encounters a higher probing popint? And possible stairstep down when it encounters lower point?

[TheOracle2212]

Is there any way we can test this as an alpha to see the numerical time change?
As in, is there any quick and dirty way to modify some of the code to make it happen purely for testing purposes to compare it quantitively with the original bed levelling code?

A 1.4mm unevenness would not be great, but is not problem for the SW or HW when selecting the right probing values

Of course. However, software isn’t always a fox for hardware. It would be ideal to have ones hardware “as right as possible” then use software to compensate for and inaccuracies.

[rondlh]

But the Z-offset is known (roughly but precisely enough) so can't you just take it into account when setting clearance in config? Of course it might require recompilation when changing hardware in a way that would significantly affect the offset.
Correct again. You have 2 options to handle this, or you adjust the probe to a required Z-offset, or you need to recompile.
My proposal will just handle this in software.

I cannot try it at the moment unfortunatelly. Well and with your implementation, what changes? The probe still has to go around the whole bed, so you will still have to clear the highest point anyway. Or does the probe lift X mm before moving to a new point (relative to the point where probe triggered last), meaning that it will stairstep up everytime it encounters a higher probing popint? And possible stairstep down when it encounters lower point?
Correct again, the probe will follow/hug the bed, so the Z-movement is minimized, resulting in fast probing.

[rondlh]

Is there any way we can test this as an alpha to see the numerical time change? As in, is there any quick and dirty way to modify some of the code to make it happen purely for testing purposes to compare it quantitively with the original bed levelling code?

Sure, you can test it.
The speed gains strongly depend on the Z-offset of the system, for testing you can adjust the Z-offset, try "M851 Z-1", and "M851 Z-4". If you use relative probing, then the Z-offset doesn't matter much anymore (only for first probe point).

To try it do this:

1. Change the line in G29.cpp as mentioned above

2. Set Z_CLEARANCE_BETWEEN_PROBES (configuration.h) to a suitable value (starting point could be 1.5).
   If you set Z_CLEARANCE_BETWEEN_PROBES to a floating point value, then Conditionals_post.h will complain because the pre-processor cannot handle comparison of floating points. Change the section as shown below (comment out 4 lines).

  //#if Z_CLEARANCE_BETWEEN_PROBES > Z_CLEARANCE_FOR_HOMING 
  //  #define Z_CLEARANCE_BETWEEN_MANUAL_PROBES Z_CLEARANCE_BETWEEN_PROBES
  //#else
    #define Z_CLEARANCE_BETWEEN_MANUAL_PROBES Z_CLEARANCE_FOR_HOMING
  //#endif

[lukasradek]

Alright, that makes sense 🙂.

[rondlh]

I've been running with this update on my 4 printers (1 x IDEX, 1x i3, 2x Custom designed XY kinematics), and it has solved many of my annoyances and inconsistent probing behavior. It has made probing much faster and consistent for different machines. Before it was clear that the probing speed depended on the Z-offset, which can vary strongly on different machines (typically for between -1.2 and -3.5, I use a BLTouch). This currently affects probing speed significantly, the update makes the Z-offset (almost) irrelevant. It's only relevant for the first probe, then relative probing kick in.