-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
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 with BLTouch and Z-endstop switch #15731
Comments
@bojanpotocnik is this a bug or ??? |
Well, it is a bug and a question/feature request - maybe I'm just missing something. The bug part: DescriptionZ-endstop is ignored while homing if using BLTouch probe despite the Steps to Reproduce
Expected behavior: Z homing is stopped as soon as (BLTouch or) Z-endstop switch is triggered. Actual behavior: Z-endstop switch is ignored, Z homing stops only when the BLTouch probe is triggered. And now for the feature request / question part: Should it be by default or at least possible for the the user to use Z-endstop switch and BLTouch probe simultaneously without editing the |
can we split it up 2? ie one bug and one fr ? |
Hmm, is the other thing more of a bug
because of the
? |
+1 for this logical behaviour. I was think the exact same thing. I've an skr mini v1.1 so same mcu. |
@bojanpotocnik please split this up in a bug and then a feature request so the 2 things are not mixed |
will temp close this one until its split up in a bug and one feature request |
I have the same issue with my both brand new SKR1.4 & BL-Touch, installed on my Creality Ender 4. My BLT was functioning correctly: controllable with G-Code commands, M119 gave triggered & open responses when deploying BLT probing pin and pushing it up by hand. However when homing Z the BLT probe signal was ignored every time & only the Z endpoint switch would conclude the homing. I tried an enormous amount of settings on/off, trying to use as little changes as possible to firmware, but growing in changes because I had simply tried every possible combination. Disabling Z endpoint would just result in the bed crashing/grinding against my nozzle after my BLT measured and indicated a STOP signal in time, until reset/power off. Until I found this issue! With the settings in option #7 from @bojanpotocnik it all suddenly worked. Note that I tried tens of firmware settings except editing Conditionals_LCD.h. This has been the key to fix my issue, except it is not straightforward or well documented at all. I hope others with similar issues can find a solution here. My case would most certainly on it's own be a BUG if using BLT homing does not work until using I want to point out that using BLT in conjunction with a Z endstop switch is so simple in essence and important, a more complex & fragile Z-probe protecting important parts like nozzle, bed, belts should have a fail-safe. Making this fully functional and easily selectable is a wise idea. @bojanpotocnik did excellent work in documenting and analyzing this problem. Wich part is a BUG or FEATURE REQUEST is just simply a matter of perspective and even argumenting this binary descision get's endlessly complex, stopping @bojanpotocnik, me or someone else to continue this issue. That shouldn't be a reason for this to just become forgotten. Is there no way to get attention from someone with enough expertise who can make this nessecary distinction? PS: probably irrelevant, but I use 4x TMC2209 with DIAG pin cut off on XYZ |
it's a bug. period, the real issue is that marlin does not allow the usage of a custom pin as a BL-TOUCH probe connector as the new SKR boards are made for. everything else is not relevant, z-min should be not effected by this, and triggering it should stop the printer as it did in the past, and if it doesn't , then it's another bug. |
@boelle there are two bugs here, I can't see an FR. One I already raised, #16839. This deals with not being able to Z home with a probe when using a dedicated probe pin. The other bug (I suggest reopening and renaming this issue) would be "[BUG] Z endstop is ignored when homing with separate Z probe despite defining ENDSTOPS_ALWAYS_ON_DEFAULT" |
A probe is not an endstop. An endstop is not a probe. A probe can be used as a z-min-home-switch, not as a z-min-security-endstop. When this was invented about no board had dedicated pins for a probe. The simplest way was to use a unused endstop-pin. Most of us just simply replaced the z-min-endstop with a probe. PROBE_USES_Z_MIN_ENDSTOP implied there is no z-min-endstop - use the probe for homing z to min. Defining a dedicated probe-pin implied there is a z-min-endstop and to use that for homing. Now - since more boards do have a dedicated probe-pin we could rethink that. |
yep, but in the mean time you could probably add some more documentation , probably near the Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN field clarifying the use of the dedicated probe connector |
Option 1 : Good As far as I can see there is only 1 actionable item here. #16839 encompasses that item. |
@InsanityAutomation I think there's an additional piece here - when both Z Probe and Z endstop are connected, provide an option to listen to both probe and endstop for homing, stopping when either one of them triggers. On a good setup, this isn't really required, but when getting to that point, it seems crashing into the bed isn't as uncommon as it should be, and a probe can fail even after working for some time. It's certainly no physical hardship to have both probe and endstop installed - I suspect many users have the endstop from the factory and add a probe later - so this would provide a safety feature which becomes more applicable as more boards introduce a dedicated Z Probe pin, and takes advantage of hardware that many Marlin users will already have. |
I'm new to bltouch and found this thread while planning to put in my probe. I'm surprised this hasn't been figured out and intergrated as it seems like basic functionality. Having now told you my inexperience, please allow me to ask a potentially stupid question. Can option 7 be accomplished by connecting the probe of the bltouch and the z endstop in parallel? Assuming they are sending the same signal, to the board, the end switch would represent a lower bound for the probe. It would be a dirty hack though. |
I fully agree with: "A probe is not an endstop. An endstop is not a probe"
In "failsafe" mode the trigger of Z_STOP_PIN should be mounted 0.5-1.0 mm under the trigger point of the probe. So it prevents the head from crashing into the bed and breaking thinner glasses or making some nice holes into the surface. The "combined" mode is more a "soft failsafe", if probe has failed or is missing (for unknown reason). It then behaves like classic homing with manually leveled bed (traditional way). |
I have been struggling for a week with a new BL Touch and a SKR V1.4 Turbo (TMC2209s with sensorless homing on the X only) with Marlin 020004 on a Hypercupe Evo Core XY Build. As soon as I used the option 7 suggestion in |
Just to be clear, when you guys say option 7 works, the end switch is still not being monitoring during homing, correct? |
Hi, I changed my firmware settings in conditionals_lcd.h as per the attached screen grab from the default and the 5 test prints I have undertaken since have worked well with the BLTouch with no problems. Prior to changing these settings I was getting repeat lack of homing on Z and home failures with a request to reset. I am techy but no coder so you have to bear with my results only comments\response. When you say not being monitored do you mean the Z end switch is disabled ? In my case changing these settings made the Z end stop work in conjunction with the probe when homing .Before these changes it did not work at all even though I had the //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN disabled\uncommented in configuration.h due to the SKR V1.4 board having a specific set of BLTouch connectors. Apologies again for my lack of experience. Best Boothy |
Option 7 only works when you enforce "HOMING_Z_WITH_PROBE" by commenting out the check of "!HAS_CUSTOM_PROBE_PIN" in 'inc/Conditionals_LCD.h'. In the code you can see, that the author disabled homing with a probe explicitly if a custom probe pin was configured. The original z-min-pin is not monitored during homing or printing with this configuration! |
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. |
I know this is the same title as #12726, however I rather started a new issue for clarity as I made quite a few tests. It is also hard to decide if this is a [BUG] or [FR] for Marlin, however it is certainly [BUG] for me.
I have Ender 3 with SKR Mini E3 v1.2 board, which has separate connectors for Z-endstop switch and BLTouch probe. For the whole day I am trying to configure Marlin
bugfix-2.0.x
to achieve seemingly very simple things:ENDSTOPS_ALWAYS_ON_DEFAULT
in Configuration_adv.h, however look at the following line.That's it. Below is the description of all combinations of configurations, tested on the Ender 3 using SKR Mini E3 v1.2 with Z-endstop switch connected to the Z-STOP connector (PC2) and BLTouch connected to the SERVOS and PROBE connector (PC14).
Setup
Thanks to #7470,
#define ENDSTOPS_ALWAYS_ON_DEFAULT
is always uncommented (enabled). In every step/combination, all other relevant configuration defines are shown for clarity. All 4 files are also in the attached Base config (Z-endstop only, no BLTouch, homing at X=0, Y=0).zip file, the configuration in them matches the config in Option 1.Steps to Reproduce
Option 1
Default configuration, using only Z-endstop switch as Z-endstop. Printer homes X and Y, then Z at the same spot (X = 0, Y = 0).
From this point onwards, the following is also uncommented:
In every of the following options, after homing X and Y, printer goes to the center of the bed and performs Z-homing (
Z_SAFE_HOMING
) ✔️.Option 2
Option 3
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
we specified that the BLTouch is connected to the Z-endstop switch pin, therefore it is ✔️ that Marlin only monitors Z-endstop switch because it thinks it is actually the BLTouch.Option 4
❌ overall despite all ✔️, because we lost the Z-endstop switch.
Option 5
This was accidentally tested as I forgot to comment
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
.Effectively printer is unstoppable when homing Z and will smash to the bed.
Option 6
Option 7
Option ?
I have run out of ideas. Maybe the solution would be:
and some fix for Option 7 point 1.
The text was updated successfully, but these errors were encountered: