Bug on z homing in Marlin 1.1.8?

[darkytoothpaste]

Description

There seems to be a bug in 1.1.8 (and I think it affects 1.1.6 as well, which was the version that I was using) that when the first z home position is erroneous, the second (slower) tap seems to completely ignore the z probe and simply "gives up".

Steps to Reproduce

1. My printer is configured to do a XY homing first, following by moving to the centre of the bed for the z home. It is using a piezo probe.
2. Issue a "G28"
3. While the printer is homing along the z axis, deliberately introduce an erroneous z home position (by tapping the nozzle).
4. When the printer attempts to do the second tap (with the slower speed), it does not seem to want to continue homing downwards and seems to "give up".

Expected behavior: [What you expect to happen] The second homing should continue downwards towards the bed.

Actual behavior: [What actually happens] The second homing "gives up" after a certain amount of movement.

A video of the behaviour can be found here: https://www.youtube.com/watch?v=08gCZViTe3s

[AnHardt]

The wanted behaviour is. At the first move, move up to 1.5*axis_length towards the endstop. Back up homebump_mm The second move moves up to 2*homebump_mm towards the endstop.

[darkytoothpaste]

Sorry I don't understand your response. You are saying that the observed behaviour is the correct behaviour?

[AnHardt]

I don't say its the best or correct behaviour, but the, up to now, intended.

[darkytoothpaste]

Would you be able to point me the lines of code in marlin.cpp that perhaps I can take a look? I can't seem to find (or understand) the section of code that is meant to home the z axis.

[AnHardt]

https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/Marlin_main.cpp#L2965-L2987

[darkytoothpaste]

Thanks @AnHardt!!

[MasterPIC]

I think it's a good idea to make it giving up...

[darkytoothpaste]

The problem with a piezo probe is that it is highly sensitive to noise associated with vibrations from lateral movements and from the nozzle itself when it goes up and down at a high speed. The problem is while the nozzle is on its way down for the first probe, there is a possibility that a false trigger can occur. I'm dependent on the second trigger which has a less likely chance of a false trigger as it moves with a slower speed.

This leads me to wonder why there is a need for a limit in distance for the second movement, especially when the second probe is intended to introduce a more accurate probe.

[MasterPIC]

I think you should reduce the fast probing speed. The double probing is only meant to improve accuracy (thanks to low speed). So your system should be tuned to provide good probing also at high speed. So, if your fast probing works as expected then limiting the slow probing range (around the properly detected z home) is useful to take care of possible faults that could make the nozzle crashing on the hotbed. Actual range is well over the expected accuracy, so I see no reasons to increase it...

[AnHardt]

Both of the search length are limited to avoid endless grinding in case of false negative (no) endstop triggers.

[darkytoothpaste]

Thanks to @AnHardt for pointing out the lines of code to me, I don't mind making changes to suit my own application, but I was just wondering on the design philosophy behind it. Without understanding that, it seemed like a bug to me.

[github-actions[bot]]

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.