SKR Mini E3 V2 with BLTouch connected to Z-STOP. ^PC2 always says open

Trying out Klipper for the first time. I have my BLTouch connected to Z-STOP on the board and it works fine with Marlin. My Marlin config is configured like this:

/**
 * Enable this option for a probe connected to the Z-MIN pin.
 * The probe replaces the Z-MIN endstop and is used for Z homing.
 * (Automatically enables USE_PROBE_FOR_Z_HOMING.)
 */
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.

How do I replicate that in Klipper on a SKR Mini E3 V2 board? I tried every possible combination listed in the documentation, but it seems like the sensor just doesn’t work. It works flawlessly in Marlin, though.

Example config:

[bltouch]
sensor_pin: ^PC2
control_pin: PA1
pin_move_time: 0.675
stow_on_each_sample: False

I tried with/without probe_with_touch_mode set to True/False, I tried a lot of different other things such as pin_up_touch_mode_reports_triggered as well. However, no matter what I do, it always says “probe: open”:

Send: BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok

Send: QUERY_PROBE
Recv: // probe: open
Recv: ok

Send: BLTOUCH_DEBUG COMMAND=pin_up
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Recv: ok

Send: QUERY_PROBE
Recv: // probe: open
Recv: ok

What do I do? I have a BLTouch clone but it works fine with Marlin. My firmware on the printer is:

STM32F103
28 KiB bootloader
8 MHz clock
USB on PA11/PA12
!PA14 GPIO pins at startup

Please review the BLTouch document. Specifically the section quoted below. You need to put the probe in touch mode and push the pin up to trigger it.

The next step is to confirm that the sensor pin is working correctly. Run BLTOUCH_DEBUG COMMAND=pin_down, verify that the pin moves down, run BLTOUCH_DEBUG COMMAND=touch_mode, run QUERY_PROBE, and verify that command reports “probe: open”. Then while gently pushing the pin up slightly with the nail of your finger run QUERY_PROBE again. Verify the command reports “probe: TRIGGERED”. If either query does not report the correct message then check your wiring and configuration again. At the completion of this test run BLTOUCH_DEBUG COMMAND=pin_up and verify that the pin moves up.

I did view the documentation and I think I’ve read it 200 times by now.

I run pin_down and the pin goes down
I set it into touch_mode
I run QUERY_PROBE and it says “probe: open”
I physically push the pin up with my nail and it snaps into place
I run QUERY_PROBE again and it still says “probe: open”

It should say “probe: TRIGGERED” after pushing it up with my nail according to the documentation, but it does not. I also tried PC14 (Z-PROBE) as well as any combination with pulldown, pullup, and inverting. Depending on how I set the pin, I can either get it to say open or TRIGGERED all the time. Never open and TRIGGERED.

I verified that a lot of people have this issue with clones, and that they opted to get a genuine one instead. I’m not willing to pay $42 just to get Klipper to work (the price of a genuine BLTouch v3.1). I was hoping Klipper would support it just like Marlin does, but I guess this is a bug that’s probably not getting fixed.

In the code block in your original post, you did not show putting the probe in touch mode. Only pin down and pin up. That will never report triggered.

If you have gone through that process, then I would verify you have the correct pin configured, and make sure you have the sensor pin plugged in to the correct spot. Also make sure you have the correct options configured based on whether you have a genuine bltouch or a clone. That’s all the help I can offer.

Thanks for the reply. Yes, I realise I didn’t specify that I put it into touch mode. I’ve written this post a handful of times by now, and I guess I forgot to specify it here. I tried all combinations specified in the documentation.

I have verified that everything is as it should be. After talking to a handful of people, I’ve verified that this is a bug with Klipper.

I see you opened an issue on GH. Just a heads up, you won’t receive a response from a developer. They don’t have access to your specific hardware, so it’s impossible to verify if the problem is a configuration issue, or some incompatibility between Klipper and the clone device you’re trying to use.

In general, the bltouch code is known to work with genuine devices because many people use them successfully with Klipper. Clone devices are often poor imitations, and don’t have the same specifications. Many pull requests have been submitted and merged over the years in an attempt to support as many clones as possible, but it’s not possible to guarantee they will all work.

I understand that. I was hoping that since I have a working Marlin version, someone could look through the Marlin configuration for my BLTouch and see if that same behavior is implemented in Klipper. Not impossible, but definitely worth the time if you ask me (otherwise people (like myself) might not get into Klipper).

I’m willing to do any testing and spend time on this, as I know other people, like myself, have issues with these clones.

I can assure you that people have compared the Klipper and Marlin implementations of the bltouch code. If you want to go down the rabbit hole, feel free to read this pull request, or this issue, or do a search on GH and you can find a lot more posts. Unless you can point to a concrete bug, you aren’t likely to find a developer willing to invest time chasing this down.

Oof. Well okay, guess I’ll go back to Marlin then. Thanks for the replies.

I’d like to say that I received a response on Github from someone who experienced the same issue, and now it works: BLTouch clone not supported in Klipper. Always reports open or TRIGGERED despite trying every single combination · Issue #5080 · Klipper3d/klipper · GitHub

Turns out “all” I had to do was remove the probe_with_touch_mode and just ignore whatever QUERY_PROBE returns. I should instead rely on the Z axis actually stopping when I’m doing G28, G29, etc. which I only tried a few times.

To clarify why query_probe doesn’t work, it’s because of how the bltouch (and clones) work. An inductive or capacitive probe will pull a pin low or high whenever it’s close enough to the bed to trigger. Running query_probe shows the status of the probe at that moment, so it will show triggered.

A bltouch instead only sends a very short pulse when it’s triggered. When the probe is in touch mode on a genuine bltouch, Klipper will monitor for that pulse, and when it sees it the probe status will report triggered until the status is cleared. On your clone touch mode doesn’t work, so the only time it reports triggered is the exact moment the pin snaps up. This is not a problem for homing or probing because Klipper is polling the probe pin looking for it to trigger. If it’s not probing or homing, it’s not actively polling that pin.

I see. I’m not sure if I’m able to pull the state of the probe using Marlin, but it would be fun to see, if the same happened there.