Marlin: [BUG] Z homing using a Z probe should be allowed when using a custom probe pin

Created on 11 Feb 2020  路  12Comments  路  Source: MarlinFirmware/Marlin

Bug Description

  1. When using a motherboard with a dedicated probe bin, Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN must be disabled in configuration.h.

In Marlin/src/inc/Conditionals_LCD.h:

  1. Having commented out the above, HAS_CUSTOM_PROBE_PIN is true. This makes sense.
  2. However, HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN) means that, because we have a custom probe pin, HOMING_Z_WITH_PROBE will be false.
  3. I had to change the above to `HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0) to enable homing using my BL Touch plugged into the dedicated ports on my SKR 1.4 Turbo.

My Configurations

Marlin.zip

Steps to Reproduce

Using a board with a dedicated Z probe pin, disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN (because this is the correct setting for this configuration, and try to home Z.

Expected behavior: [What you expect to happen]

Z Probe works

Actual behavior: [What actually happens]

Z Probe does not deploy during Z homing

Additional Information

Most helpful comment

AFAIK, there is no logical reason why Marlin should not allow you to home Z with a probe when using a dedicated probe pin, given it happily lets you home when not using a dedicated probe pin, all because of the one line of code I've highlighted.

That's the only problem in scope for this issue, and it's quite separate (and much simpler) than #15731, which I've also read previously. That one seems to be about using sensorless homing + endstops. I don't agree with closing it for administrative nonsense, it's still a valid issue, just needs renaming, but again, out of scope for this issue.

I think the linked issue might be one step easier to resolve (assuming it's reopened) once this is fixed though?

Also, in fairness, I reckon this code was written when a dedicated Z Probe pin was somewhat rare, so it was an intentional oversight, whereas now it's becoming more common it's becoming a more noticeable problem.

All 12 comments

seems like it was done here #15731

Define "done"

seems like it was done here #15731

Define "done"

as in suggested, the guy tried several combinations,, look at option 7 which seems to be doing the same code you suggested.
this guy went though several combinations, of trying to get his bl-touch AND z-min end stop to work together and failed,. and they closed it because he wouldn't split it into FR and a BUG, (which to me seems like a BUG)
i had a rather long discussion about this on facebook , he said in order to use the custom connections on skr, you need to also use the z min which i tried, and that's how i arrived to that bug.
seems that currently no matter how you look at it, marlin does not support using BL-touch in anything other then z-min
https://www.facebook.com/groups/755135144882809/permalink/996056110790710/

AFAIK, there is no logical reason why Marlin should not allow you to home Z with a probe when using a dedicated probe pin, given it happily lets you home when not using a dedicated probe pin, all because of the one line of code I've highlighted.

That's the only problem in scope for this issue, and it's quite separate (and much simpler) than #15731, which I've also read previously. That one seems to be about using sensorless homing + endstops. I don't agree with closing it for administrative nonsense, it's still a valid issue, just needs renaming, but again, out of scope for this issue.

I think the linked issue might be one step easier to resolve (assuming it's reopened) once this is fixed though?

Also, in fairness, I reckon this code was written when a dedicated Z Probe pin was somewhat rare, so it was an intentional oversight, whereas now it's becoming more common it's becoming a more noticeable problem.

I've re-read #15731, got muddled with another issue - I've commented on it, I think this issue solves part of that one

So realistically that check should look at use_zmin_plug to determine if the z min endstop is being used aside from the probe for homing. Any checks ensuring z min plug should also check for the probe to be in use. If you have both in use, home with the sensor only. Seems straightforward enough anyway.

This fix is much needed for everyone with SKR1.4's and other boards with custom probe pins that use Z probes. Fortunately this bug-report is nicely concise instead of #15731.

Adding a upvote for this, also on SKR1.4 + BLTouch 3.1.

Does anyone know what's the reasoning behind the deactivation of the Z homing with a probe when using a custom PIN? I've tracked and this was added in https://github.com/MarlinFirmware/Marlin/pull/14338. All boards with dedicated probe pins are affected by this.

OK, i'm lost. Is the goal to make zhoming and ABL both work via probe, then just drop the zstop switch 5mm or so below what is realistic so it's effectively only a estop in case probe fails?

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

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.

Was this page helpful?
0 / 5 - 0 ratings