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

[teemuatlut]

Does MULTIPLE_PROBING not apply to G28? It probably should if it doesn't.

[VanessaE]

Nope, it doesn't. I have it configured for 4 probes per point, and it does exactly that during G29, but homing is just a simple double-touch.

[thinkyhead]

For homing the general recommendation is to use a larger HOMING_BUMP_DIVISOR for Z. Slow probing is known to greatly increase accuracy.

[VanessaE]

I have the divisor at 8, but there seems to be no difference in accuracy compared to having it at 4.

(EDITED, I originally thought I'd changed it to 4. Nope)

[thinkyhead]

What kind of repeatability do you get with your probe? How out is it typically? What kind of probe design is it?

I suppose it makes sense to have the probe follow probe settings instead of Z homing settings. I'll look into implementing this in my copious free time.

[VanessaE]

Sorry for the delayed response, can't exactly run M48 while there's a print going. :smile:

For repeatability, that's what I meant by the 0.0015/0.006 values, but here's some representative best and worst output, done with the nozzle at 215°, bed at 65° (idled there for a minute or so before starting):

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.004000 Min: -0.006 Max: -0.002 Range: 0.004
Standard Deviation: 0.001611

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.056437 Min: -0.074 Max: -0.033 Range: 0.041
Standard Deviation: 0.013308

That higher reading is actually worse than before, which I guess is a good thing in this case.

I'm not sure what you mean by how "out" it is... how wrong, you mean? That's what I meant by the 0.2 mm guess; either it's dead on where I wanted it, and I get a perfect first layer, or it's off by a few tenths of a millimeter (I'm not sure how to measure it), there seems to be no in-between.

As for the probe design, it's one of these: https://www.ebay.com/itm/292154003394

[thinkyhead]

there seems to be no in-between.

Do you get good probes after a reboot, but worse ones if the machine has been on a while?

Do you notice differences with a heated versus cold bed?

[VanessaE]

I have not tried to print on a cold bed. Haven't had occasion to do so, and being Printbite-covered,[*] I'm not sure that I could, except with flexible filament, which I don't have.

It does seem like the home position is wrong most often right after a reboot or when the machine has been idle for a while, but not as a factor of bed heat - I tried to control for that by letting the machine sit, heated and ready, for a good 15 or 20 minutes, and still got a bad home.

It also seems like if I get a bad home, it's virtually guaranteed to be good on the next print, and the next several after that, so long as I don't let the printer sit for too long between good prints.

It's almost as if the loss of precision that comes with the steppers shutting off during M84 or idle hold timeout, is not being corrected-for initially. That's the only thing I can see that's common between bad homes.

FWIW, here's the best and worst M48's with the entire printer cold (room temp ~19°C when I sat down, guess I shoulda turned the heat on today :smile: )

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.050062 Min: -0.051 Max: -0.048 Range: 0.004
Standard Deviation: 0.000946

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.075625 Min: -0.107 Max: -0.057 Range: 0.050
Standard Deviation: 0.017930

So, similar to when heated.

Oh, I should mention, the sensor that's on my bot is fairly new, having been purchased to replace one that went bad. It's been a problem for quite some time, with both sensors, and even back when I was just using a Z end stop switch, but I always dismissed occasional bad homing as normal behavior.

[*] I've experienced this "bad homing" on plain, unadorned glass, too.

[thinkyhead]

so long as I don't let the printer sit for too long between good prints.

So obviously, static buildup. 😉

Hmm… Well multiple probing can definitely help then.

[VanessaE]

Static? Heh. You know, it wouldn't surprise me if it were exactly that. :smile:

[teemuatlut]

@thinkyhead Can we include an outlier filter into the mix when a higher number of probes is configured? Just keep track of the min and max results and exclude them when averaging for the final value. Especially the piezo sensors can be sensitive to false triggers where just bumping the table will cause the probe to trigger.

[thinkyhead]

It gets tricky. Homing sets the current position to Z_HOME_POS at the end, wherever the nozzle happens to be. This is requesting some tweaking of the final position (and a move back to 0 possibly), so it's a bit of extra work. It should be ok in the meantime to set the HOMING_BUMP_DIVISOR for Z to a larger value, and perhaps increase the HOME_BUMP_MM.

[boelle]

@thinkyhead add feature request label ?

[boelle]

missing label

[InsanityAutomation]

This exists and now there is a hysteresis to throw out results that differ too much. This can be closed.

[VanessaE]

I can see the outlier filter has been added, but at what point was more-than-double-touch homing added?

[InsanityAutomation]

Its been awhile, but the extra_probing bit is only a few days old.

/**

• Multiple Probing
• You may get improved results by probing 2 or more times.
• With EXTRA_PROBING the more atypical reading(s) will be disregarded.
• A total of 2 does fast/slow probes with a weighted average.
• A total of 3 or more adds more slow probes, taking the average. */ //#define MULTIPLE_PROBING 2 //#define EXTRA_PROBING 1

[VanessaE]

Right, but MULTIPLE_PROBING is only for sensing the bed during G29 leveling, is it not?

[InsanityAutomation]

No, it applies during G28 as well.

[VanessaE]

Just out of academic curiosity, can you point me to the commit that made that particular change?

[InsanityAutomation]

At a quick read of the code, it seems to have G28 trigger bump for a second hit not actually looping using the number since it sets just as a true/false. Also the extra_probes isnt applied in G28, just G29 so it does appear there is room for a bit more improvement at least to bring the two into parity completely.

[ghost]

May I add something here?

You are looking at repeatbilty, I copied it from above:

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.050062 Min: -0.051 Max: -0.048 Range: 0.004
Standard Deviation: 0.000946

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.075625 Min: -0.107 Max: -0.057 Range: 0.050
Standard Deviation: 0.017930

Now I don't want to comment on how good or bad these Range values are, compared to other probe types, ok? But a range of 0.050mm is definitely not the cause of your probe being off by .1mm or more. What these numbers DO NOT tell you, is that the probe will measure a different absolute value on different occasions over the period of hours or days. You would need to run this M48 thing over a couple of days spaced at one every hour (which it cannot do) to see long time drift. So when the probe has a "bad hair" day, it will report a different value 10 times in a row with good repeatabilty but off by 0.2mm (perhaps) from yesterdays tries.

Inductive sensors and their siblings, capacitative sensors are slightly temperature dependant. And even if you have prepared the bed well with the aluminum foils and are able to supress stray magnetic fields, I don't trust them so much anymore.

And yes, @InsanityAutomation is right after looking at that code. G28 does not repeat like G29. But I really feel that even if it did, it wouldn't make things better - just 5 nice measurements all of them off by a millimeter or so since yesterday.

[AnHardt]

If you are interested in how much and why z-home could shift, watch Advanced heated bed tests Averaging some probes does not help at all.

[VanessaE]

(22 minute video.... tl;dw)

Wouldn't that only apply to setups that do not sense the position of the print surface, i.e. if a sensor reads the bed under the glass, or if you're just using an end stop switch mounted on the frame?

[InsanityAutomation]

No, it'll move the top surface as well depending on temp probed at, soak time and potentially other variables.

[AnHardt]

... or if you're just using an end stop switch mounted on the frame?

That's a good solution to have the beds mounting points always at the same height. But usually with that you don't have problems with the repeatability of homing. So averaging will not help.

However. That will not help to get the first layer stick better. The beds surface moves in relation to the mounting points.

My recipe for our machines is:

• Prelevel the bed mechanically as good as possible to keep the z ways short while probing.
• A constant workflow home on cold bed (room temperature) bring the bed to temperature wait wait longer wait another bit be really patient here until the beds temperature stabilized probe the bed fast to give the (inductive) probe no chance to change temperature much (9 points in 15 seconds) print a good first layer (if the probes z offset is right. It's constant for me)

[VanessaE]

You may have missed earlier: I already controlled for bed temperature early-on in this thread, to the tune of testing first-thing in the morning, after sitting turned-off overnight (and waking-up to 19°C room temp) as a "cold" test, and also testing only after allowing 15-20 minutes just sitting at the target temperature, for a "hot" test.

Plus, being TR8 screws, Z-homing after most prints is quick since I don'y routinely print big stuff. I don't run G29 per-print anymore, either.

I'm 100% certain that whatever issue my bot has with homing, it is not temperature-related (or the majority of the difference, anyways).

[ghost]

Temperature is not the only thing that throws off inductive probes.

It's enough to place a metal tool or something close to the printer.

Here's a small test for you:

Lower the nozzle using the LCD by .1 mm steps until the probe's red light goes on (it triggers). Then back off .1mm and the probe light will just go off.

Now they have a very slight hysteresis, but now move your hands, or a metal screwdriver close to the probe slowly and note how the probe suddenly triggers. Try moving other stuff, and try to get a feel for what else might be influencing the trigger point of the probe by 0.1mm, which is the amount we are more or less looking at right now.

Once you get a feel for how flaky this inductive sensor really is, you will see the problem.

You could also position the sensor as I described above, .1mm above the trigger point, and then check a day later if going down .1mm will trigger the probe same as the day before.

[AnHardt]

If occasionally triggering to early/high - it could be a false positive caused by electrical noise. Sometimes inducted by a surprising source like a near by desk lamp being on or off.

How are your noise filtering settings? Did you try to increase them? Is there any hardware denoising? Is the processors internal pullup resistor on or off? What voltage gets the probe? How is that made? What else gets this voltage from this power supply? For example cold-end-fan. Are that users always in the same (on/off) state? How do you get the signals 5/3.3V level? If by a voltage divider - are the resistors values very high?

[VanessaE]

@BigIronGuru I have controlled for stray bits of metal and magnetic fields, too.

@AnHardt

• Noise filtering/Denoising: I have none in place that aren't already part of the hardware, and no firmware-based filtering that I'm aware of.
• Internal pullups: no idea on that. Probably enabled, though.
• Supply voltage: probe is fed 12v from the main 30A power supply, which handles motors, heaters, etc.
• Usage: everything that draws power is in a consistent state i.e. when homing, X/Y/Z motors are on, extruder motor is usually off, cold-end and controller fans always on, hotend and bed at their needed temperatures, and so on.
• Probe signals: it's a NPN-NO probe, so there are no voltage divider resistors -- this type of probe uses an open-collector output, and pulls the signal line to ground when triggered, or tri-stated/high-Z when idle.

[lrpirlet]

Now I don't want to comment on how good or bad these Range values are, compared to other probe types, ok? But a range of 0.050mm is definitely not the cause of your probe being off by .1mm or more.

Well here we are talking statistics, we need to define the boundary conditions… M48 does probe several time in a row from a known position. We only measure the repeatability of a row of probe…

We are NOT talking about defining 0,0,0 coordinate point. This involve many controlled and uncontrolled aspects including dried oil, cleanliness of rods, room and bot temperature... (not to mention Murfy's law's events)

The STORY and the fact is that MARLIN HAS NEVER (yet) defined 0,0,0 point with PRECISION and repeatability...

proof? why do we need to cheat Z position using BABYSTEPPING??? This option is commonly defined as THE way to print a good first layer… Please translate that in terms of repeatability at defining 0,0,0 coordinate point.

I am pleading for multiple probe on G28 ONLY... G29 multiprobe?, I do not care, it is recorded after correction using G26 anyway...

[inventabuild]

Please let me know if MULTIPLE_PROBING feature request has been added for G28.

[mikeshub]

@lrpirlet - my CR10 is setup well enough baby stepping is never touched. I just preheat the bed, run leveling, then print. The precision is entirely dependent on how mechanically sound the printer is.

[GRUXXKi]

Got really the same issue there since I've change my way to probe the bed.

I do a G29 only when I change my bed with 25 points with 3 probes and store it.

It's great because it makes a very great accuracy for probbing the bed. But on G28 it seems that the accuracy is really bad and now I've destroyed 2 bed with the noozle being to low despite the fact it was perfectly calibrate the time before !

G28 in 3 probes would be a great way to increase the Z accuracy, mostly when you don't do a G29 on each print.

[salacpavel]

I second this FR

[Thorinair]

Wait, its been over 2 years, and this is still not a thing? I just encountered similar issues, and I definitely would like the homing to do multiple probes...

[qwewer0]

It would be a useful feature in order to make the bed zeroing more precise, and with that, allowing a more consistent first layer on prints for z-endstop and probe users. This idea at the moment, is only for Z axis, but it could be useful on X and Y axis too. (POWER_LOSS_RECOVERY, NOZZLE_PARK_FEATURE) This would need to be compatible with TMC_HOME_PHASE. (In my opinion)

This is how I could imagine it in Configuration.h: (naming features isn't my strongest suit)

//#define MULTIPLE_PROBING 2
//#define EXTRA_PROBING    1
#if EITHER(MULTIPLE_PROBING, EXTRA_PROBING)
   //#define MULTIPLE_HOMING
   //#if ENABLED(MULTIPLE_HOMING)
      //#define MULTIPLE_HOMING_X
      //#define MULTIPLE_HOMING_Y
      #define MULTIPLE_HOMING_Z

If there is no chance that someone would want to use it for only X and not Y, then those can be shrunk down to //#define MULTIPLE_HOMING_XY

A potential issue that I could think of is if a user would like to use MULTIPLE_PROBING/EXTRA_PROBING, but only for homing and not for ABL. (Not sure if anyone would want that, but...) That would need an option like:

   //#if ENABLED(MULTIPLE_HOMING)
      ...
      //#define ONLY_MULTIPLE_HOMING

Not sure if this writhing is anything useful, but here it is.

[thierryzoller]

Funny - I arrived at this thread via Google. My current Sapphire PRO does exactly what is being asked (First homes Z, then homes Z slower during G28) I wanted to replicate this for a second Printer, but... I can't. So I was looking for what made my Marlin Build have my sapphire exactly act like this, currently can't replicate..

Just thought of one of the differences it's a corexy

[qwewer0]

@thierryzoller Do you mean, G28 does a fast (Z_PROBE_SPEED_FAST) probing, then a slow (Z_PROBE_SPEED_SLOW) probing? Because that is how it is currently working, and this FR is for to be able to do more than one slow probing after the fast probe.

Edit: If your setup does more than one slow probing, then I have no idea how could that happen.

[thierryzoller]

@qwewer0 : Don't want to hijack this issue, but I have multiple_probing set to 2 but it does only one probing move.

[qwewer0]

@thierryzoller Exactly why we have this FR...

[thierryzoller]

@thierryzoller Exactly why we have this FR...

It does only 1 (one) move, it does not do the fast then the slow. So I think it must be something else outside of this FR

[qwewer0]

@thierryzoller Sorry, I misunderstood.

At the moment, when Z homing with a probe (and with endstop if HOMING_BUMP_MM isn't 0), the Z axis moves to the homing position, once with Z_PROBE_SPEED_FAST speed, then once with slow Z_PROBE_SPEED_SLOW speed, like it can be seen here. MULTIPLE_PROBING and EXTRA_PROBING has no effect on G28 probing, which is what this FR wants to be changed.

If there is anything else that isn't connected to this, then we could continue it on discord.

[thierryzoller]

Thank you, that likely will solve it (Bump was set to 0). Considering this FR, I also agree that unifying this through G28 makes a lot of sense and would support this FR

[FanDjango]

RFC and WIP

I have been playing around with the homing code and as a first step, added some position reports and a loop for 5 (hard coded for now) "bumps".

This was to get some indication of "how accurate" the microswitch endstops are compared to the BLTOUCH on the Z-Axis (on this machine).

You can see that the first home after the BUMP is slightly worse off on the X and Y Axes compared to the Z-axis, it seems that the preceeding FAST (1st) home move has maybe gone inwards slightly farther than if it had been slower.

Note: That kind of means that the second home (the "bump") is a good thing, its far off value is not an indication of bad variance but rather a direct result of the abrupt stop of the preceeding FAST home.

Or in other words: Looking at the values for X: After the FAST home and then bumping outwards 5mm, we are actually only 4.86mm outward in reality, the slow homes after that first bump confirm that.

The first bump actually suffices, for accuracy further bumps seem to have a range of about 0.02mm on my machine.

Here is the output for a G28 home command, with some comments added:

G28

Report after FAST HOME X-AXIS:
(you can see we "came from far off")
X:-94.13 Y:-23.00 Z:5.00 E:0.00 Count X:-18826 Y:-4600 Z:4000

5 X-AXIS Bumps: (do "bump", then re-home, then report)
X:-4.86 Y:-23.00 Z:5.00 E:0.00 Count X:-973 Y:-4600 Z:4000
X:-5.01 Y:-23.00 Z:5.00 E:0.00 Count X:-1003 Y:-4600 Z:4000
X:-4.99 Y:-23.00 Z:5.00 E:0.00 Count X:-998 Y:-4600 Z:4000
X:-5.01 Y:-23.00 Z:5.00 E:0.00 Count X:-1001 Y:-4600 Z:4000
X:-5.00 Y:-23.00 Z:5.00 E:0.00 Count X:-1000 Y:-4600 Z:4000

Report after FAST HOME Y-AXIS:
X:-30.00 Y:-125.20 Z:5.00 E:0.00 Count X:-6000 Y:-25040 Z:4000

5 Y-AXIS Bumps: (do "bump", then re-home, then report)
X:-30.00 Y:-4.80 Z:5.00 E:0.00 Count X:-6000 Y:-960 Z:4000
X:-30.00 Y:-5.01 Z:5.00 E:0.00 Count X:-6000 Y:-1001 Z:4000
X:-30.00 Y:-5.00 Z:5.00 E:0.00 Count X:-6000 Y:-1000 Z:4000
X:-30.00 Y:-4.99 Z:5.00 E:0.00 Count X:-6000 Y:-999 Z:4000
X:-30.00 Y:-5.00 Z:5.00 E:0.00 Count X:-6000 Y:-1000 Z:4000

Report after FAST HOME Z-AXIS:
X:64.00 Y:102.00 Z:-7.99 E:0.00 Count X:12800 Y:20400 Z:-6396

5 Z-AXIS Bumps: (do "bump", then re-home, then report)
X:64.00 Y:102.00 Z:-2.99 E:0.00 Count X:12800 Y:20400 Z:-2396
X:64.00 Y:102.00 Z:-3.01 E:0.00 Count X:12800 Y:20400 Z:-2405
X:64.00 Y:102.00 Z:-3.00 E:0.00 Count X:12800 Y:20400 Z:-2397
X:64.00 Y:102.00 Z:-3.00 E:0.00 Count X:12800 Y:20400 Z:-2404
X:64.00 Y:102.00 Z:-3.00 E:0.00 Count X:12800 Y:20400 Z:-2397

Final Report:
(This is the offical position when homing is over)
X:64.00 Y:102.00 Z:5.00 E:0.00 Count X:12800 Y:20400 Z:4000

ok P15 B31

As requested by the TO, one could now move out by a value derived from this series and zero the position on each axis to be safe. The same mechanism as with homing could be used: Throw out any outliers and take an average.

But that's WIP for now.

In the end one could move towards this or something similar but less complicated placed in the homing section of the config files:

@qwewer0 wrote:

This is how I could imagine it in Configuration.h: (naming features isn't my strongest suit)

//#define MULTIPLE_PROBING 2 //#define EXTRA_PROBING 1

if EITHER(MULTIPLE_PROBING, EXTRA_PROBING)

//#define MULTIPLE_HOMING //#if ENABLED(MULTIPLE_HOMING) //#define MULTIPLE_HOMING_X //#define MULTIPLE_HOMING_Y

define MULTIPLE_HOMING_Z

If there is no chance that someone would want to use it for only X and not Y, then those can be shrunk down to //#define MULTIPLE_HOMING_XY

A potential issue that I could think of is if a user would like to use MULTIPLE_PROBING/EXTRA_PROBING, but only for homing and not for ABL. (Not sure if anyone would want that, but...) That would need an option like:

//#if ENABLED(MULTIPLE_HOMING) ... //#define ONLY_MULTIPLE_HOMING Not sure if this writhing is anything useful, but here it is.

[FanDjango]

I'd like to add something:

In my opinion, the following is the real issue here:

@GRUXXKi wrote:

Got really the same issue there since I've change my way to probe the bed.

I do a G29 only when I change my bed with 25 points with 3 probes and store it.

It's great because it makes a very great accuracy for probbing the bed. But on G28 it seems that the accuracy is really bad and now I've destroyed 2 bed with the noozle being to low despite the fact it was perfectly calibrate the time before !

G28 in 3 probes would be a great way to increase the Z accuracy, mostly when you don't do a G29 on each print.

If acquiring your Z-Axis home position uses a probe and has an unacceptable range over a single use (= does not repeat well), your first option is to do a G29 on each print, regardless how long that might take.

Second option: Add a Z-MIN microswitch or home to Z-MAX against a microswitch.

Now for the Multi-Homing option: If your probe repeats well (you can test this with M48) but has a different base offset between individual uses (over many days), this option won't help you. I.e. the probe might offset some millimeters today but differently tommorow. This is possibly the case for inductive and capacitative probes. In this case multi-homing won't really help.

The issue being with the Z-Axis:

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

[thierryzoller]

Now for the Multi-Homing option: If your probe repeats well (you can test this with M48) but has a different base offset between individual uses (over many days), this option won't help you. I.e. the probe might offset some millimeters today but differently tommorow. This is possibly the case for inductive and capacitative probes. In this case multi-homing won't really help.

This is exacty the issue I have with one of my printers using a fixed probe for Z.

[FanDjango]

Ok, here is the next version of the modified homing code for discussion:

G28 Z

echo:Home bumps for Z

echo:EXTRA PROBING = 2
echo:MULTIPLE PROBING = 5
echo:TOTAL PROBING = 7
echo:BUMP = 3.00

echo:bump loop begins

echo:measured pos = 3.01
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 2.99
echo:measured pos = 3.01

echo:bump loop finished 

echo:min pos = 2.99
echo:delta pos = 0.01

X:64.00 Y:102.00 Z:5.00 E:0.00 Count X:12800 Y:20400 Z:4000

ok P15 B31

The debug SERIAL_ stuff is just for info for the following questions and discussion:

Oh, and currently we are assuming to talk about the Z-AXIS and using a probe. Much of the following is also true for the other axes, but there you have less impact if the home is slightly off.

1. The TO stipulated using the minimum value - to ensure that a EEPROM stored distance to the bed would not be to high. Of course using the minimum value negates any advantage of statistics (median, average, standard deviation) in determining the most probable position that a homing operation produces. But it would be no problem at all to use the average as is done in probing.

2. What is now to be done? Well, I suppose, correct the current position by delta_pos without actually moving the axis. Shall I put the stage I have reached out as a PR so that others can help and chime in?

Everyone should be aware that this will not help you if your probe values drift over time even if it has good repeatability.

If you have 7 homing bumps, see above, with a range of 0.02mm this morning but absolute values are 1mm different this evening, you have a real problem - the bed is actually further away or closer than the stored value, or the probe thinks so - and that can only be fixed by a bed probe (perhaps of a single point in comparison to the stored value).

[qwewer0]

@FanDjango Do you think that your modifications are PR ready, or just a concept?

[FanDjango]

@qwewer0 80%. Here's what is missing at this stage:

Discussion and decision as to how to proceed.

Apart from outliers, the average of all (sufficiently numerous) homing probe operations should always report having moved in by the amount that we had bumped outwards. If the standard deviation here is high, then the probe is no good, but the average should be correct. If the average is wrong, then you have defined incorrect steps/mm in configuration.h.

Let me give an example -

5 slow homing approaches into the endstop, say 2.95, 2.99, 3.00, 3.00, 3.01.

Remove the 2.95 outlier, then the average of the rest is then 3.00, as expected, taking note of the range, which is 3.01-2.99 = 0.02.

The last approach was 3.01 and then a 3.00 move outwards will have been done. Depending on the endstop accuracy, nobody knows where we are now physically, we only know where we most probably are (i.e. 3.00mm out on average).

Now I need to decide:

Do I correct my position (to be real safe) to the farthest away (from the bed i.e. to 2.99), as @VanessaE requested? That would make sure that I would not be too close to the bed. But note: In that case I am assuming the most improbable position, which would possibly be different on each home, and therefore make the stored mesh unusable.

The real point of the excercise is to choose the most probable position, which is given by the average (i.e. 3.00 in our example, which needs no correction (by definition).

My opinion: The cat is byteing its tail here. There is no way to be absolutely sure of where the axis is, physically, as the last one of the multiple homing operations is subject to the full inadequacies of the limit switch or probe. I can see the range, the average and the std_deviation after multiple homes but the last home of that sequence will take me somewhere, dunno where.

---

@AnHardt wrote:

My recipe for our machines is:

Prelevel the bed mechanically as good as possible to keep the z ways short while probing. A constant workflow home on cold bed (room temperature) bring the bed to temperature wait wait longer wait another bit be really patient here until the beds temperature stabilized probe the bed fast to give the (inductive) probe no chance to change temperature much (9 points in 15 seconds) print a good first layer (if the probes z offset is right. It's constant for me)

It's what we do too: We do a fast bed probe before every print. That's why I was so keen on speeding up the bltouch operations some time ago together with @InsanityAutomation.

---

So my current code currently actually tells me the range, the average and the std_deviation of multiple homing operations on each individual axis. But there seems to be no sensible corrective move that would occur to me. A search on homing operations of other machine types, robots and so on, yields no solution. Perhaps someone else would like to propose some ideas?