-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Z homing using a Z probe should be allowed when using a custom probe pin #16839
Comments
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. |
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. 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 #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 has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Description
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
must be disabled inconfiguration.h
.In
Marlin/src/inc/Conditionals_LCD.h
:2. Having commented out the above,
HAS_CUSTOM_PROBE_PIN
istrue
. This makes sense.3. 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.4. 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
The text was updated successfully, but these errors were encountered: