[FR] Multiple-touch homing

[VanessaE]

My bot generally works fairly well, but my probe isn't very accurate, at least I don't think so (in the M48 repeatability test, I get a standard deviation of as low as about 0.0015 to as high as about 0.006, depending on what options I use). That said, it's good enough to make auto-level work fine.

However, there's one thing about it that bugs me: homing occasionally results in a Z position that's slightly too high, by around 0.2mm (based on how printed lines look at the too-high vs. "normal" position).

I have Marlin configured to turn the heaters off during probing, and there's nothing anywhere near the probe points that could cause a false reading; it's a NPN NO inductive probe, 8mm sense distance, with four spots of aluminum tape on the underside of the glass bed (all have been burnished down smooth, and all are considerably larger than the diameter of the probe), and the probing positions, including safe Z homing, are tuned to hit each spot dead center. The Z axis on my bot is a pair of nearly brand new (less than a month old) T8x4 leadscrews with anti-backlash nuts. The X carriage and all extruder parts, including the mounted sensor, are all very tightly mounted. In short, I've done everything I can to eliminate intermittent mechanical problems in my bot.

So, I'd like to see an option added to allow Z to be probed for homing thus:

Have Z go down at normal home speed, trigger the sensor, bump up by the configured distance, then down again at low speed until the sensor triggers again (so exactly as it is now), then begin a configurable number of up-down-up-down... moves, watching for the probe to trigger each time, similar to what G29 does when configured for 3 or more probes per point. Have Marlin take the lowest position, relative the top of the first bump, as the Z=0 position.

[thinkyhead]

A maxim of computing is that you cannot use garbage input to do anything useful until you are able to separate what is garbage from what is meaningful … but if you can do that, you actually do have meaningful input. What you want to do is get your standard deviation down as close to zero as possible and then proceed from there.

[thierryzoller]

A maxim of computing is that you cannot use garbage input to do anything useful until you are able to separate what is garbage from what is meaningful … but if you can do that, you actually do have meaningful input. What you want to do is get your standard deviation down as close to zero as possible and then proceed from there.

With my respect, but I think you miss the point. Repeatability is near perfect with my probe. The problem however is that G28 that happens before any print is not accurate (compared to your last G29) and I cannot reproduce the same reliability that I can with the M repeatability command. I believe that is the Gist of this issue as also described by @FanDjango here - https://github.com/MarlinFirmware/Marlin/issues/9802#issuecomment-731395352

[Friday13th87]

@FanDjango Would you mind sharing your homing code with us? Are there any other news on the multiple probing for homing stuff?

[lrpirlet]

Humm My 2 cents about the root cause here... I hade exactly the same problem: after the machine was idle for a while, the first few z moves would be inaccurate...

I ended up having the machine zero then verifying the 0.1 distance to the bed with a sheet of paper... (yes I never calibrate with a hot bed). After 2 to 5 tries it would be better...

So I pointed to the software until it occured to me that the problem was more accute when it was cold...

As an experiment, I cleaned the machine removing the old oil and bingo, it was better, lot better: on the first try it was good... So I think I was facing stiction.

So I guess the solution would be to use mechanical dithering as was proposed once by @AlessandroAU under #15354 ...

I started to develop something around that but stopped when I could not use my printer anymore...

The trick would have been to vibrate the z axis by moving back 12 ticks, then position, then back 9, then position, then back 3... you get the idea.... I was hoping to break the oil stiction...

[slowbro]

Didn't see this ticket before I made #22139 (closed now) - I never realized that double-probing Z wasn't a feature until it mysteriously disappeared. I tracked it down to being dependent on the HOMING_BUMP_MM for Z in the end, which I had disabled as instructed by the comment for SENSORLESS_HOMING.

@FanDjango did you continue work on this?

If there is to be a MULTI_HOMING and a EXTRA_HOMING behaviour, why not just restrict this to Z-AXIS homing and use the values chosen for MULTI_PROBING and EXTRA_PROBING? No new configuration options, no changes there?

This is basically what I outlined in #22139 and I think it would be a good solution and make sense, because when I see "mutli probing" I would assume it applies to ALL uses of the probe, not just ABL.

If no other solutions have been pulled in/suggested I am going to work on decoupling Z from HOMING_BUMP_MM for probe-based homing, and instead just respect MULTIPLE_PROBING and EXTRA_PROBES.

[FanDjango]

No, I am sorry. I have abandoned this topic.

After a fast home approach, stop, bump out and a subsequent slow precise approach and stop, what is the precision advantage of doing more slow approaches, say another 5?

Your precision as to what position you are in depends solely on the last of these approaches and can be quantified as range/variance/std-dev/min/max, but it will be the same error(=lack of precision) as the first slow approach.

Unless your endstop becomes more and more accurate from each approach to the next (like the switch getting "happier" somehow?). In that case, just home 10 times.

[inventabuild]

Bed leveling algorithm allows for multiple probes for a reason. There is incentive to take an average of probes to be more consistent in the end result and prevent an outlier from determining the end result. Why shouldn't homing have the same option to give more consistent results for z=0?

[FanDjango]

Multiple probing to adapt to an unknown relative to the (believed) known is not the same as homing, where you establish your position relative to nothing other then the endstop.

If you are so sure, then you tell me, after (say) 5 home/bump moves, how far would you bump out on the last of the sequence? Regardless, even if you don't bump, to what value do you set the axis, if not 0 = zero?

[FanDjango]

You can home 10 times and if the last one is an outlier, how do you know? Unless you check it against a second value that you trust more.

When probing, this is what you are doing. You are comparing the probe values to the home result.

[inventabuild]

If the bed leveling matrix is positioned relative to the z=0 homing endstop then having a more reliable location value for the homing endstop is desirable.

Generating a location average for the homing endstop via multiple homing probes will give a more accurate location for the homing endstop on average; hence the reason why muliple homing probes are desirable.

[VanessaE]

While I wouldn't bother with something as crazy as 10 probes to home, finding the outliers is trivial: just pick the highest and lowest readings and toss them out, wherever they are in the list of results, and regardless of their differences from the next highest/lowest values in the list. Then average the rest.

Or you could get fancy and calculate standard deviation and toss out any readings that are 1 SD off from the median, then take the average of the remaining readings, or something along those lines.

Doesn't bed level probing do one of these anyway?

[inventabuild]

VanessaE you make my point. Unfortunately, homing position z=0 does not allow for multiple probes and the bed leveling matrix is positioned relative to the homing position z=0. Allowing multiple homing probes (obviously for purposes of creating an average) for homing position z=0 will give a more accurate position for z=0 with which the bed leveling matrix can be more accurately positioned against.

The difference between any one probe and the average of a number of probes obviously depends on the accuracy of the probe.

[FanDjango]

What you are saying, is to home once (1 fast/1 slow), and then to probe a couple of times to that same endstop and reposition slightly, depending on your readings of probing the endstop that you homed on.

Mathematically unsafe. You still only end up at a position that is as precise as the home, only different.

I'm out of this after having played with it for a while. Somebody precisely specify the steps, then someone can code it, maybe

[inventabuild]

FanDjango, you don't even know how accurate home is from the initial 1 fast/1 slow homing until you make additional probes to get a better average result. The number of probes for homing should be determined by the user and how accurate the probe is.

[FanDjango]

Better result relative to what initial position? When you probe, you get results relative to where you firmly believe to be. When homing, you try to set where you are.

[FanDjango]

Here is an example: You home to the endpoint. Motion stops. You set axis to 0. Now you go out 5mm. You are now at+5, ok? Now you probe to the endstop and you needed steps for 4.9mm and reached the endstop. Hmpf, go out again 5mm, probe again, repeat this a couple of times, : 4.8mm 5.3mm 6mm (outlier), We are in at the endstop, and is this zero or -0.1 or what?

[FanDjango]

I would actually suggest multiple approaches to the endstop, and then adding a value to the position depending on the observed range, to avoid a movement to ZERO ever triggering or exceeding the endstop position. Your precision in knowing where you really are (physically) won't get better, but you can be sure to not exceed the machine limits.

[slowbro]

Personally, I just want to have some assurance that my probe actually went off at the proper endstop point. For my purposes, 1fast/1slow is enough: fast to get the rough position of "0", and then another slow to actually home with higher accuracy (due to slower speed). Currently this is not how it works - you just get 1 fast UNLESS you happen to have HOMING_BUMP_MM > 0 for Z.

I think the bickering over semantics in this thread is disatracting from the issue at hand. The issue is that this:

Have Z go down at normal home speed, trigger the sensor, bump up by the configured distance, then down again at low speed until the sensor triggers again (so exactly as it is now)

Is not "as it is now" and was in fact an outlier/relatively unintentional and completely disconnected from MULTIPLE_PROBES. If we drop the need for having EXTRA_PROBES this just simplifies the config & makes MULTIPLE_PROBING do what it says on the tin.

---

In regard to EXTRA_PROBES, yes - if you're setting the axis 0, it can be hard to average that, sure. But if your fast/slow SETS 0, then you come back with n number of EXTRA_PROBES to verify that, it would at least allow for a homing/endstop error if things were WAY off.

[bob-anthony]

Adding my +1 to this request. My end stop deviates up to 0.1 mm even after increasing my bump divisor.

[bunnitech]

Wow ok I can confirm this in marlin-bugfix-2.1.x that's strange... by HOMING_BUMP_MM was 2, and I set it to 0. Double Z probes stopped suddenly. While leveling dual Z with G34 it did check twice though, just not when homing. That really confused me. I think that the number of Z probe checks should be consistent and respect the MULTIPLE_PROBING value during G28, or be defined separately. My old bugfix-2.0.x config just says SENSORLESS_BACKOFF_MM { 2, 2 } and HOMING_BUMP_MM { 0, 0, 0 }, yet always double probed Z so I assumed that was normal. Either this needs to be documented in the comments or the behavior changed.

[jmding8]

+1 vote for this. I have a lot of issues with inconsistent z-homing results. 95% of the time, it's good enough. But 5% of the time, its way off (usually, nozzle way too low). I have swapped main boards multiple times, swapped endstops multiple times, and have experimented with firmware noise filtering, none of which have helped.

I am certain that taking the mean (or better yet IMO, the median) of multiple z-home measurements would solve my problems.

Note that I am not using UBL or any other form of mesh compensation.

[nickweedon]

Added PR #27523 to add this feature. I implemented it as a new flag ('P') to G28. With this flag it will use the same algorithm as bed leveling probing meaning that MULTIPLE_PROBING and other options such as turning off bed the heater and stepper motors can all be configured and used (i.e. it uses the same settings as bed leveling probing).

See the PR for more details and in particular, take a look at the section I wrote undet the 'benefits' section that relates to how the existing MULTIPLE_PROBING and EXTRA_PROBING options actually work as it is actually a very good solution/algorithm IMO. I saw a number of conversations in this thread that lead me to believe that some people may not be aware of what the algothm is doing so i documented it. If the PR is approved I will add this documentation somewhere in the Marlin docs and link to it in the appropriate places such as G28 and G29 gcode documentation.

Motivation

I got sick and tired of my nozzle randomly scraping on the print bed and having to clean out my direct drive every time this happens (especially with TPU) and so i finally got motivated enough to make this PR. I hope this gets approved/merged and it will help all of you as much as it has helped me :)

[nickweedon]

Just reporting back now that I have had this change “in production” for 2 weeks. My machine is now “fire and forget” and putting down phenomenally good and reproducible first layers! One thought on my mind is whether to:

1. Keep this as a flag (‘P’) to G28
2. Remove the flag and make it a configuration option for all G28 gcodes.
3. Keep the flag but also make it a configuration option, in which case the ‘P’ flag becomes redundant when configured to be enabled all the time for G28

I have found that having a flag is useful as I can also do ‘quick homing’ when all I want to do is load filament or some other maintenance related activity that does not require high precision. The downside is that while I can easily configure the flag via Cura’s configurable print start gcode sequence, I still find I sometimes need to modify gcode files such as when running a linear advance calibration generated from the Marlin website. As an aside, the P flag works really well with the ‘O’ flag which skips homing if it has already been performed. Only downside is that you have to be careful not to do a G28 without the ‘P’ option and then print as the ‘O’ flag doesn’t distinguish between a regular G28 and a G28 P (maybe it should?)

[jmding8]

Amazing work! I really hope the maintainers consider merging this functionality, more precise homing is STILL a pain point even now, years later.

As for exposing a runtime parameter vs a compile time configuration, it seems to me that ideally we can do both? Set a default value in the configuration file. But allow runtime override via a G28 parameter? The strengths of both approaches with minimal additional user facing complexity