Can't get BLTouch probe working

[J2xWo]

So i have been trying to get my BLTouch probe working using the [bltouch] module but no luck. What am I doing wrong? X and Y are homing fine but when i want to home the z axis it gives me this error: BLTouch sensor test failed I thought that if i just set up the module everything would be configured right or did i misunderstand the use of the module? klippy.log

[BlackStump]

Was the BLTouch working prior or is this a new install of bltouch to klipper? If it is a new install have you wired it correctly? Do you have the right sensor / control pins named in the config? when you first power your printer does the bltouch do its self test ie pin down, pin up, pin down. pin up ?

[J2xWo]

worked before, when the printer starts it does its selftest too and succeeds doing so, no errors

[KevinOConnor]

Have you verified that you have the correct pins defined for the bltouch? The error cited above occurs when the bltouch is unable to raise the signal line during a test.

Separately, I don't think the sensor line should have a pullup enabled for it.

-Kevin

[J2xWo]

Yes I double checked. I got the MKS Gen L board. the servo pin should be D11. I just now tried again after figuring out why i couldnt connect anymore (turns out the port randomly changed from /dev/ttyUSB0 to /dev/ttyUSB1. no idea when and why) So when i try to home z then the servo deploys the probe but the z axis doesnt move and it gives me the previous stated error. The other Axis dont move either (in case they should)

[KevinOConnor]

For the serial port issue - see: https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#when-the-micro-controller-restarts-the-device-changes-to-devttyusb1

The Klipper bltouch code is new. It looks like we'll need to add some diagnostic commands to help figure out what is occurring here.

-Kevin

[BlackStump]

is the Bltouch from antclabs https://www.antclabs.com/ or a clone ?

[J2xWo]

Thanks a bunch! Will be looking forward to it. I got a BLTouch clone in case that makes a difference. Is there a workaround in the mean time?

[BlackStump]

I have a genuine antclabs bltouch and changed to the new bltouch module with no problems worked as it did before. I only ask as there is plenty of info on the web with clones not working as expected. I am not saying that is the reason that yours is not working just conveying that my bltouch seems to work fine with the new module.

[drbobbob]

I have a bltouch clone and it isn't working for me. I think that i have my config correct you can find it on my fork https://github.com/drbobbob/klipper/blob/anetconfig/config/my-anet-a6.cfg

i know that my bltouch works because I have been using it with marlin. One issue I have with my sensor is that for marlin I have set a rather long BLTOUCH_DELAY of 1 second. It was not behaving well with lesser delays. I couldn't figure out how to transfer that setting over as well.

When I try a homing sequence I get the "Endstop z still triggered after retract". I attempted to modify the bltouch python to increase the delay like I have in my marlin config, but that didn't change anything.

Let me know if there are any tests that you would like me to run.

[tvercruysse]

Im in the same boat. when using the servo + probe modules my bltouch clone works (atleast the homing works, mesh leveling + homing gives me a G-code already specified). when using the new bltouch module the printer homes to the set X and Y and then spits Endstop Z still trigered after retract. i'd love to help solve this issue so hit me up if i can be of assistance @KevinOConnor

[case-tm77]

Same problem here. i have installed a clone and since the switch to bltouch-extra he always reports "BLTouch sensor test failed". I received an original Antaclabs today and will report if the problem still exists after the exchange.

[kennethpangky]

I have a clone and the genuine BLTouch. The exact same commands works on the real BLTouch but gives a "BLTouch sensor test failed" on the clone.

Not sure why, but both worked on Marlin.

[BlackStump]

attaching your log files before and after might help also quick search on bltouch clone problems is 5v supply issues depending on controller used. Some clones signal is inverted compared to original bltouch. Wires are incorrectly placed in the connector and or not color coded correctly so need checking . 3pin brown is GND red is 5v orange is control signal 2pin black is GND white is Z min

[kennethpangky]

For my case the wiring should be correct - Got them working under Marlin before I flashed Klipper. Any commands I can run to troubleshoot maybe? Be gentle, I am a noob.

[BlackStump]

Kevin has something in the works that adds some debug commands to the bltouch, well I know he has as I noticed he updated his bltouch branch. I have tried the branch and the debug commands work as expect on a original bltouch, on a clone I don't know as I do not have. hopefully he will chime in to give you some guidance.

[drbobbob]

I am pretty sure that my wiring is correct, as it was working with marlin and I didn't change my wiring.

I have done my tests on the master branch. If you would like me to retest on another branch I can do that as well.

@tvercruysse can you send me your probe + servo config? I would like to test that with my probe. Perhaps that will give us some insights into how to better arrange the bltouch module.

[J2xWo]

@tvercruysse Mind sending me the code for it? would love to get it working to try out klipper etc

[KevinOConnor]

I've updated the bltouch code in the Klipper master branch. For those that are seeing issues, please update to the latest version (see https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#how-do-i-upgrade-to-the-latest-software for details on upgrading) and then run the steps below.

To test the "control pin" run the g-code command BLTOUCH_DEBUG COMMAND=pin_down and verify the pin physically moves down. Then run BLTOUCH_DEBUG COMMAND=pin_up and verify the pin moves up. If it does not, then recheck the control pin wiring and config definition.

To test the "sensor pin" run BLTOUCH_DEBUG COMMAND=pin_down followed by BLTOUCH_DEBUG COMMAND=touch_mode. Verify that QUERY_PROBE reports the probe as not triggered, then manually push the bltouch pin and verify that QUERY_PROBE reports the probe as triggered. If the above does not work, then recheck the sensor pin wiring and sensor config definition.

If the above tests okay, but one still receives "Probe triggered prior to movement", "Endstop Z still triggered after retract", or "BLTouch sensor test failed" errors when actually probing, then try increasing the new pin_move_time config setting (see config/example-extras.cfg for the details).

Success or failure, please report your results here.

-Kevin

[drbobbob]

Thanks for the support. It will be a while before I am back at my printer to test these changes.

[J2xWo]

@KevinOConnor the test works just fine, thanks a lot! When i try to home z then i still get the 'BLTouch sensor test failed' error so i added the config setting and i get this error:

klippy.log

Unhandled exception during connect Traceback (most recent call last): File "/home/pi/Klipper/klippy/klippy.py", line 136, in _connect self._read_config() File "/home/pi/Klipper/klippy/klippy.py", line 126, in _read_config self.try_load_module(config, section_config.get_name()) File "/home/pi/Klipper/klippy/klippy.py", line 115, in try_load_module self.objects[section] = init_func(config.getsection(section)) File "/home/pi/Klipper/klippy/extras/bltouch.py", line 119, in load_config blt = BLTouchEndstopWrapper(config) File "/home/pi/Klipper/klippy/extras/bltouch.py", line 40, in __init__ self.pin_move_time = math.ceil(pmt / SIGNAL_PERIOD) * SIGNAL_PERIOD TypeError: unsupported operand type(s) for /: 'str' and 'float' Internal error during connect. Once the underlying issue is corrected, use the "RESTART" command to reload the config and restart the host software. Printer is halted Klipper state: Not ready

[KevinOConnor]

@J2xWo - I had a typo in the last commit. It should be fixed now (commit 76b57ba0). Try pulling the latest code again and retry.

-Kevin

[J2xWo]

@KevinOConnor That fixed it, at least now I can add config setting. Sadly i still get the error message that the sensor test failed. even after i bumped it up to 1.2s. As before the probe gets deployed and then and then I get the error message :/

[KevinOConnor]

@J2xWo - Okay, that's surprising. Could you make sure nothing is near the probe and then run the following commands:

BLTOUCH_DEBUG COMMAND=pin_down
G4 P1000
QUERY_PROBE
BLTOUCH_DEBUG COMMAND=pin_up
G4 P1000
QUERY_PROBE
BLTOUCH_DEBUG COMMAND=touch_mode
G4 P1000
QUERY_PROBE
BLTOUCH_DEBUG COMMAND=reset
G4 P1000
QUERY_PROBE

After the above is complete, run an M112 and then attach the klipper log file here.

-Kevin

EDIT: Use the g-code script test-bltouch.gcode.txt instead, then after it competes run M112 and attach the Klipper log file here.

[case-tm77]

hey, i pulled the new branch and nothing changed for the clone. but the original antaclabs bltouch works fine, without any changes (firmware and wires).

i made come tests, the klippy_original.log with the antaclaps and the klippy_orignal_clone.log with the clone at the end.

the clone has a problem with the touch_mode (remains open).

thank you, all for your awesome work ;) klippy_original.log klippy_original_clone.log

[jakep82]

Try flipping the sensor plug (2 pin) on the clone. It must be connected with the signal and ground in the appropriate orientation. Perhaps the clone is reversed.

[case-tm77]

Flipping the sensor plug changes nothing, the query_probe reports always "open".

[KevinOConnor]

@case-tm77 - Alas, the log only grabs the last ~20 seconds of messages, so it didn't capture all the necessary info. Could use try again with the clone using the attached g-code script? After it completes, quickly run M112, then attach the klipper log here.

-Kevin

test-bltouch.gcode.txt

[case-tm77]

@Kevin I'll be happy to try it tomorrow.

[drbobbob]

Turns out I needed to invert my input pin. Everything works once I changed the sensor pin to not have an invert. Thanks for adding the debugging commands and thanks for making me think of think of inverting the input.

Just wondering, does klipper have an equivalent to Marlin's M48 for probe accuracy? I was chasing the accuracy of my probing there and I was wondering if I could give a test here. I do know python coding so I might be able to lend a hand coding that up.

http://marlinfw.org/docs/gcode/M048.html

[case-tm77]

so i made some quick test's but for the clone no change.

the clone remains always "open" or if the pin is market negative always "triggered." i inverted the pin twice. -first test normal -second test with inverted signal pin -third test with negative input pin in config and inverted signal pin and last test with negative input pin in config and normal pin.

i hope the log can help. klippy_clone_test.log

[J2xWo]

Sure here you go, hope it helps

klippy.log

[kennethpangky]

Turns out I needed to invert my input pin. Everything works once I changed the sensor pin to not have an invert. Thanks for adding the debugging commands and thanks for making me think of think of inverting the input.

Just wondering, does klipper have an equivalent to Marlin's M48 for probe accuracy? I was chasing the accuracy of my probing there and I was wondering if I could give a test here. I do know python coding so I might be able to lend a hand coding that up.

http://marlinfw.org/docs/gcode/M048.html

Which input pin are you talking about?

[drbobbob]

In the config file I changed: [bltouch] sensor_pin: ^!PC4

To: [bltouch] sensor_pin: ^PC4

I also updated to the new tip of the master branch and got the debugging commands. I ran the BLTOUCH_DEBUG and QUERY_PROBE commands which made me think about inverting the sensor pin. I was able to extend and retract the probe just fine with no modifications, the QUERY_PROBE was returning incorrectly so I thought to invert. I was able to properly home and run probe cycles.

[nandinho84]

I've been experimenting some issues configuring the BL Touch as well. I think now it works ok. However, when probing the same spot ( I chose 3 samples) I got a very different results. In some cases I've got a diference of almost 0.2mm in the same spot (in some cases even more). When I arrive home, I can put here the probe results for the quad_gantry_level. However, I was hopping that someone could verify if this is happening to them as well.... Maybe not a klipper issue, but If anyone could point me what am I'm doing wrong that would be much appreciated

[drbobbob]

I also was fighting with my BL Touch consistency when running Marlin.

Changes that I messed with:

1. Probe speed (slower is better)
2. Decrease height retraction between probes
3. Increasing wait time for BLTouch to improve stability of probing
4. Rewiring Z motors in series rather than parallel. I was seeing that early probes were good but they drifted up over repeated probe sequences. I thought this might be related one of my Z motors losing steps, series should keep them in sync better.

I originally had wide variance but I have gotten it down to under 0.05 mm

What sequence of commands were you using to do the repeated probing? Try running a larger amount of probes. I would notice that over the course of ~20 probes I would get into a state that my probe heights would continue to increase, that led to to question the accuracy of my Z axis.

[jakep82]

@nandinho84 Are you using a clone, or a genuine BLTouch? Many people have reported terrible repeatability with clones. My genuine BLTouch is giving me great results, but I haven't tested standard deviation.

[nandinho84]

@jakep82 I'm using a clone. However, I've already used this 3d Touch in other 3d printer with very reasonable results. In this printer, the biggest difference is the klipper itself and the fact that the wires have almost 2.5 meters lenght. So, or some klipper configuration or some interference from the longer wires (but they have to be this lenght)

[KevinOConnor]

@case-tm77 - Alas, the test didn't have the right timing. You could try again with the script below. However, I suspect you might just need to increase your bltouch pin_move_time config setting.

@J2xWo - In order for the log to be useful, you'll need to run M112 within a couple of seconds of the test finishing. Also, your log appeared corrupted - make sure to scp the log and attach the full contents. You could try again with the updated g-code script below.

-Kevin

test2-bltouch.gcode.txt

[nandinho84]

@drbobbob I'm not using any commands other than the quad_gantry_level with 3 samples (it probes 4 places on the bed, 3 times each...). I have the height retraction at 10mm and the speed at 5mm/s.

[drbobbob]

@nandinho84 I am pretty new to klipper firmware so I didn't know that command existed. I had been doing all of my repeatability testing with marlin firmware because I hadn't gotten my octoprint setup done. Marlin has a nice M48 command that tests for probe repeatability. I'll see if I can figure out a way to get this into klipper. Knowing that the leveling commands do multiple samples should make it easier to write that command. Are you at the latest master? Have you tried changing the pin_move_time config to give the probe time to settle? Is it possible you fouled the probe when moving it between machines. I have read that BLTouch probes are sensitive to getting "stuff" on the probe which interferes with smooth movement. It is also possible that you are getting noisy results because the BLTouch spikes current pretty hard and may be resetting due to voltage sag. 2.5 meter long power leads would have increased inductance. This could probably be mitigated by putting a capacitor near the bltouch itself. Depending on your level of electrical knowledge this may be easy or hard.

[kennethpangky]

I'm using a clone, the commands work (pin up/down/test/reset) but when it reaches G28 it says sensor test failed. I'm using the test2-bltouch.gcode provided. Attached is my klippy log.

klippy.log

[jakep82]

@kennethpangky Have you tried removing the pullup from the sensor pin (PC4 instead of ^PC4)?

Edit: Nevermind, I see you did multiple tests with and without.

[KevinOConnor]

@kennethpangky - in order for the log to help an M112 command must be run right after the gcode script completes. Though, I suspect you just need to increase the bltouch pin_move_time config setting.

-Kevin

[BlackStump]

@drbobbob you can create your own macro for testing probe repeatability ie [gcode_macro blt_test] gcode: G28 G1 Z10 F6000 PROBE G1 Z10 F1000 PROBE G1 Z10 F1000 PROBE G1 Z10 F1000

[kennethpangky]

@KevinOConnor Will take a look at that setting. Meanwhile here's the log with the M112 command run after the sensor test failed. I tried 0.5 and 1s but the same error. klippy.log

[jakep82]

I did some probe testing tonight with a genuine BLTouch. The single largest variance I had was .0375mm, but nearly every other probe was +/- .0125mm.

[tvercruysse]

@J2xWo sorry for the late reply, if you are still in the need of a working setup. i got mine working, board is the ender 3 stock board (atmega 1284p) only thing you need to adjust is the probes z-offset to whatever yours is.

printer.zip

[KevinOConnor]

Just to summarize, I don't know why some bltouch clones do not work with the new bltouch module. The logs so far haven't been contained sufficient detail to track down what's different with these clones. I'm attaching here an updated script for those that are having issues - one can try running this script and then attach the resulting klippy.log file. Separately, a log from a session with pin_move_time=1.0 may also help.

-Kevin

test3-bltouch.gcode.txt

[J2xWo]

Sorry for being away! Uni kept me busy Here is the log after running the gcode. I noticed that it only deploys the probe but doesnt retract it.

klippy - move time 1s.log klippy - move time .2s.log

[case-tm77]

so i have done a new test with my bltouch-clone with the test3-bltouch.gcode file but when i try to home Z klipper says "BLTouch sensor test failed"

klippy_clone_test3.log