Added new 'P' (precise probing) option to G28

[nickweedon]

Description

This feature addesses feature request #9802 and adds a new flag ('P' for precise homing) to G28 (Homing) that provides an alternative to the 'bump' option which is an option configured in Marlin via HOMING_BUMP_MM that causes G28 to perform a second slower and more accurate probe. The 'P' option causes the G28 gcode to use the same algorithm used by bed leveling.

The new 'P' flag is very useful for machines that have probing accuracy issues that cannot be solved by bump. Since the 'P' option allows for all the same flags and options to be configured as for bed leveling, it is possible to configure multiple probes as well as turn off stepper motors and bed heating functions to reduce EMI interferance (as per what already exists for bed leveling). A first probe is still necessary for an initial home as the 'P' option will take the error that it finds and use that as a correction to the homing position.

It is recommend although not mandatory to use this with safe homing as Z_SAFE_HOMING_X_POINT and Z_SAFE_HOMING_Y_POINT can then be set to precisely match a known reference point (e.g. a point on the UBL mesh that is always adjusted to be at Z 0).

If this change looks acceptable then i will follow up with a PR to update the G28 documentation also. I know that this feature has been requested since 2018 so hopefully this is a welcomed addition :)

Requirements

Requires a Bed Probe (i.e. #define HAS_BED_PROBE)

Benefits

Useful alternative to G28 'bump' that allows the G28 homing to be much for configurable. In particular it can benefit for stepper motor and bed heater control to mitigate EMI as well as to use the MULTIPLE_PROBING and EXTRA_PROBING options.
The way that these existing options work (and have always worked but perhaps been scarcely documented) is as follows (this code can be found in probe.cpp):

1. The machine will probe TOTAL_PROBING ((MULTIPLE_PROBING + EXTRA_PROBING) number of times.
2. The results of the probe will be sorted
3. If EXTRA_PROBING is greater than zero then the values fartherest from the middle will be removed. This is accomplished by iteratively comparing both the start and the end values against the middle value and upon each iteration, remove the start or end value that deviates the most from the middle value.
4. Take the average of all that remain and return this as the final value.

I believe this is actually a very good way to remove outliers and works very well for probes that periodically return erroneous results that are significant outliers and would otherwise throw off the whole average.

Configurations

No configuration required

Related Issues

• Closes [FR] Multiple-touch homing  #9802

[dbuezas]

Looking forward to use this!

BTW, have you considered using the median (median != average) instead of

then the values fartherest from the middle will be removed?

This is a more standard procedure to remove outliers in data analysis

[nickweedon]

Looking forward to use this!

BTW, have you considered using the median (median != average) instead of

then the values fartherest from the middle will be removed?

This is a more standard procedure to remove outliers in data analysis

Thanks, I am happy to hear that this is hopefully of benefit to someone :)

With regard to the algorithm described above, it is actually the existing algorithm already used by bed leveling and Z-stepper auto-alignment (G34) and probably other related functions such as probe based mesh tilting.
I simply just call into this code which I think is good for consistency sake.

As I see it this algorithm is quite good as-is however and works very well in practice. The advantage of taking a median would be that it is resistent to outliers however this exsiting algorithm is also resistent to outliers (to an extent configurable via 'EXTRA_PROBING') due to the way that it removes the values from the ends of the list once sorted. I tend to think that the author of this algorithm was actually pretty clever because he/she combined the best of both worlds of both mean and median. More specifically the advantage here of using the mean is that given enough probes the average (mean) would cancel out assuming that both positive and negative error rates are of equal liklihood and at which point the value would eventually converge to the actual true Z value. A median on the other hand would have no such converging property.

That said, I think you could be right under certain scenarios. Specifically when there is a very high and unpredictable number of outliers. Usually though this is very rare (although i did get just one bad home some i made the change now with some ridiculous number of prints/homing) but it is always possible. By the same token, if you are experiencing that many outliers then it is quite likely you could also have a situation where all your probes are outliers and then even a median will not give you an even close to correct value (and its time to buy a new probe or do a serious investigation into EMI shielding lol).

I am no statistician however and so I am more than happy to be proved wrong and maybe learn a thing or two :)

[dbuezas]

I see now, I had missed the fact that the average os used after removing outliers, makes a lot of sense. Thank you