SKR v1.4 Turbo + BLTouch marlin configuration

[flyhigh-hifi]

Initial marlin configuration has Z_MIN_PROBE_PIN and I don't see in manual what should it be. Currently my BlTouch doesn't work because of that I guess.

[Evanlec]

I'm having the same issue with SKR v1.4 Turbo + BLTOUCH v3.1.
BLTOUCH wires are connected to SERVOS header and Probe header as indicated in the wiring diagram documentation:

I tried just commenting out this line:
// #define Z_MIN_PROBE_PIN 32 // Pin 32 is the RAMPS default
and also leaving this line commented out:
// #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

The probe can do self-test etc, but when I try to home the Z axis, the BLTOUCH probe does not deploy. And thus causes the nozzle to crash into the bed.

When the BLTOUCH is sitting idle, an M119 command shows that Z_Probe and z_min are in state 'TRIGGERED' , when they should not be, according to Marlin firmware documentation:

The BLTOUCH probe only sends a brief pulse, so “TRIGGERED” indicates the probe is in error state.

Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: TRIGGERED
Recv: z_probe: TRIGGERED
Recv: ok

[oldman4U]

Hi.

I am new to 3D printing and Marlin but have been able to get the BLTouch working on my SKR Pro v1.1, so maybe i can help a bit.

I assume you use an end stop device for X, Y and Z and the BLTouch in addition to them.

Using the dedicated Probe connector on the mainboard, the "define" values in Marlin to use the end stop pin have to be commended out, so there has to be a // in front of the two lines shown above starting with #define Z_MIN_Probe_... and "define BLTouch" has to be used. This is also shown in the pins file, like you can see in the screenshot.

Hope this helps

[flyhigh-hifi]

Hi.

I am new to 3D printing and Marlin but have been able to get the BLTouch working on my SKR Pro v1.1, so maybe i can help a bit.

I assume you use an end stop device for X, Y and Z and the BLTouch in addition to them.

Using the dedicated Probe connector on the mainboard, the "define" values in Marlin to use the end stop pin have to be commended out, so there has to be a // in front of the two lines shown above starting with #define Z_MIN_Probe_... and "define BLTouch" has to be used. This is also shown in the pins file, like you can see in the screenshot.

Hope this helps

Thanks for your addition. Bltouch works on my SKR 1.4 Turbo when I'm using Z_MIN_ENDSTOP as bltouch probe pin, but there's new port on SKR 1.4 Turbo designed exactly for Bltouch, would be nice to use it as it was designed.

[S13Tyler]

IDK if this helps but I pulled an all-nighter getting my SKR V1.4 (non-turbo) all configured for my printer and first time installing BLTouch. I managed to get the BLTouch pin headers on the board to work by making a few changes. I started with a fresh 2.0.x branch since I couldn't get the BTT version to compile.

Comment out the line in Configuration.H:
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

and define:
#define Z_MIN_PROBE_PIN P0_10

Open Conditionals_LCD.h located in ..Marlin\src\inc.. and change these lines:
#define HAS_CUSTOM_PROBE_PIN DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN)

to:
#define HAS_CUSTOM_PROBE_PIN true
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0)

Basically Marlin doesn't let the printer home the Z-axis with the probe when an end-stop is connected. When I get time, I'll mess around some more and try to add some lines so that the end-stop can be used as a fail-safe in case of probe failure (which is probably the original code's intent).

My BLTouch is fully functional and tested with this method. Just keep an eye on it because I'm not sure if the end-stop will do anything if the probe doesn't home properly.

[Evanlec]

IDK if this helps but I pulled an all-nighter getting my SKR V1.4 (non-turbo) all configured for my printer and first time installing BLTouch. I managed to get the BLTouch pin headers on the board to work by making a few changes. I started with a fresh 2.0.x branch since I couldn't get the BTT version to compile.

Comment out the line in Configuration.H:
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

and define:
#define Z_MIN_PROBE_PIN P0_10

Open Conditionals_LCD.h located in ..Marlin\src\inc.. and change these lines:
#define HAS_CUSTOM_PROBE_PIN DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN)

to:
#define HAS_CUSTOM_PROBE_PIN true
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0)

Basically Marlin doesn't let the printer home the Z-axis with the probe when an end-stop is connected. When I get time, I'll mess around some more and try to add some lines so that the end-stop can be used as a fail-safe in case of probe failure (which is probably the original code's intent).

My BLTouch is fully functional and tested with this method. Just keep an eye on it because I'm not sure if the end-stop will do anything if the probe doesn't home properly.

Thanks for this work. I shall try it out as soon as this current print is finished.

One question just to clarify:

This is when using the designated BLTOUCH probe pins, i.e. these:

and not plugging the probe into the Z-min stop header (as was required with SKR v1.3) correct?

Also, should it not be possible to have both the BLTOUCH and the stock Ender 3 Z end-stop (it being plugged into Z-Min header) working as well, to provide as you said, a failsafe?

[hopeinformer]

That is very interesting. I will give that a try. I am having a similar issue. However, I did finally fix the BLTouch not homing Z by using the Z-endstop pins for it instead of the designated probe pins. It worked as it should for a few times then went right back to crashing into the bed. I didn't change the firmware at all between it working and it not working. So this leads me to believe the actual motherboard SKR V1.4 has an issue. I can't figure it out. I'm thinking of just ditching the whole BTT line and going with a Duet instead. On 2/2/20 11:53 PM, Evan LeCompte wrote: IDK if this helps but I pulled an all-nighter getting my SKR V1.4 (non-turbo) all configured for my printer and first time installing BLTouch. I managed to get the BLTouch pin headers on the board to work by making a few changes. I started with a fresh 2.0.x branch since I couldn't get the BTT version to compile. Comment out the line in *Configuration.H*: //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and define: #define Z_MIN_PROBE_PIN P0_10 Open *Conditionals_LCD.h* located in ..Marlin\src\inc.. and change these lines: #define HAS_CUSTOM_PROBE_PIN DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) #define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN) to: #define HAS_CUSTOM_PROBE_PIN true #define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0) Basically Marlin doesn't let the printer home the Z-axis with the probe when an end-stop is connected. When I get time, I'll mess around some more and try to add some lines so that the end-stop can be used as a fail-safe in case of probe failure (which is probably the original code's intent). My BLTouch is fully functional and tested with this method. Just keep an eye on it because I'm not sure if the end-stop will do anything if the probe doesn't home properly. Thanks for this work. I shall try it out as soon as this current print is finished. One question just to clarify: This is when using the designated BLTOUCH probe pins, i.e. these: [image: image] <https://user-images.githubusercontent.com/10586/73634800-02594200-4630-11ea-815a-910f9334f5e1.png> and *not* plugging the probe into the Z-min stop header (as was required with SKR v1.3) *correct*? Also, should it not be possible to have both the BLTOUCH and the stock Ender 3 Z end-stop (it being plugged into Z-Min header) working as well, to provide as you said, a failsafe? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#207?email_source=notifications&email_token=AMTMQMIILE7IDG5MTCXUTP3RA7EPDA5CNFSM4KLW3342YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKS2SKQ#issuecomment-581282090>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMTMQMOEOD4MAZR3KAAO2LLRA7EPDANCNFSM4KLW334Q> .

[Evanlec]

Thank you very much @S13Tyler , that did the trick!

[S13Tyler]

@Evanlec No problem man! As a warning though this is just a band-aid fix. As soon as I have time to sit down and write some new lines I'll post it for you guys or maybe someone else will dive in beforehand!

[thelittlemike]

@Evanlec No problem man! As a warning though this is just a band-aid fix. As soon as I have time to sit down and write some new lines I'll post it for you guys or maybe someone else will dive in beforehand!

Have you got this working using the dedicated pins yet? I've been asking around, but no one seems to have found a solution.

[stantond]

Good work @hopeinformer ! I've just run into this myself and you've saved me a lot of pain. For anyone else reading through this:

Comment out the line in Configuration.H:
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

Let's assume this is set correctly by the user. This should be commented out on any board, including the SKR 1.4/Turbo, where there's a dedicated pin/port for the probe that you plan on using.

and define:
#define Z_MIN_PROBE_PIN P0_10

This isn't required - it's already set correctly in the appropriate pins file.

Open Conditionals_LCD.h located in ..Marlin\src\inc.. and change these
lines:
#define HAS_CUSTOM_PROBE_PIN DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN)

to:
#define HAS_CUSTOM_PROBE_PIN true
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0)

No need to modify the first line. If configured correctly by commenting out Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN because we have a dedicated probe pin, the DISABLED function here returns true, so HAS_CUSTOM_PROBE_PIN is true. That's all fine and correct. We agree that we have a custom probe pin, and the pins file also agrees.

Now, that last line... Z_HOME_DIR < 0 is fine, this ensures you're probing downwards for your Z axis, which we are, and by default this is set to -1. So for most users, this returns true and we can ignore it here.

However, !HAS_CUSTOM_PROBE_PIN... This will be true if we do not have a custom probe pin (the ! causes the inversion). As we do have a custom probe pin, this is false, so HOMING_Z_WITH_PROBE is also set to false.

In essence, the Marlin developers have said, "If you have a custom probe pin, you cannot home with your Z probe." I can't believe this is desired behavior, more of an oversight, so I've raised this as a Marlin bug. This is not a BigTreeTech issue, though they themselves should have raised this with Marlin.

Tl;dr: in Marlin/src/inc/Conditionals_LCD.h, replace:

#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 &&!HAS_CUSTOM_PROBE_PIN)

with

#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0)// &&!HAS_CUSTOM_PROBE_PIN)

[emaayan]

i've managed to reproduced as well , correcting
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0)// && !HAS_CUSTOM_PROBE_PIN)
and commenting //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

this is a rather dangerous band-aid, if you just disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN the probe will come crushing down the bed, so this fix could be forgotten during upgrades between firmwares!

[PapiOrso]

@S13Tyler - The change you suggested in the Conditionals_LCD.h file works great until version 2.0.4.4. of Marlin.
Unfortunately in the new Marlin release 2.0.5 the Conditionals_LCD.h file is very different.
Can you still help us? Thank you very much!

[thelittlemike]

So I got the BLTouch (3.1 version) to work just fine making no edits whatsoever to vanilla Marlin other than enabling BL Touch and 5V and a single change to the pins file:

#else
#define Z_STOP_PIN P0_10 // Z-STOP
#endif

This uses the dedicated pins on the board, with the hotend fan plugged into HE1 and the cooling fan plugged into FAN0

[nakedandjameson]

@thelittlemike Did you get this working with the v1.4 turbo? Been having a lot of difficulty with trying to get my BLTouch set up with no luck. I tried the fix above (commenting out second half of HOMING_Z_WITH_PROBE) and that didn't work for me. I'll try modifying the pins.h file like you did and see what happens.

Also, if it is the v1.4 turbo, shouldn't BLTouch be in 3.3v mode since the v1.4 turbo has 3.3v logic? Why set it to 5v mode?