Klipper: 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

[fredizzimo]

It seems like if you start the printer with the bltouch pin down, then it won't pull the pin up before homing and it will fail. If the printer is started with the pin up, then everything seems to work fine. At least that's how it behaves for me.

You can easily verify this:

BLTOUCH_DEBUG COMMAND=pin_down
RESTART
G28

The probing will fail with "Recv: !! BLTouch sensor test failed"

If you now run this

BLTOUCH_DEBUG COMMAND=pin_up
G28

Then the homing will succeed.

So the fix should be as easy as adding a BLTOUCH_DEBUG COMMAND=pin_up command before the homing process starts. And this should be done before homing x and y, since it could be fatal if it tries to move with the pin down.

I changed the code in to test_sensor

self.send_cmd(print_time, 'reset')
self.send_cmd(print_time + self.pin_move_time, 'pin_up')
home_time = print_time + 2 * self.pin_move_time

And it seems to work, but it's not a good sollution, since x and y is homed first, so it needs to be fixed in some other way.

[fredizzimo]

It also fails to do the self-test when restarting the printer with RESTART, which is part of the reason, since the self-test moves the pin to the up state.

Also it seems like we could add more sanity checks. I will take a look at these issues and also see if I can do something about #387 - BLTouch uses trigger test for actually probing. I hope I will have a pull request ready later today.

[oleplay]

@fredizzimo This doesn't fix it for me.
I still get BLTouch sensor test failed after the pin was pushed down while homing.

[fredizzimo]

@oleplay, strange, did you restart the klipper service after making the changes? If you did, then we are most likely dealing with different issues.

Also, without the "fix", it works for me, as long as the pin is in the up state when staring the homing, if it's down, then it fails.

[oleplay]

@fredizzimo I did not make any changes yet. I just tried homing with the pin up and pin down, both fail for me.

[oleplay]

@fredizzimo I just tried changing the code and restarting the service. No change still fails to Home.

[fredizzimo]

@oleplay, It's probably the different behaviour between the clone and the original. I have the original one.

I checked the marlin source code and it does the equivalent to this in order to reset the probe, if it shows that it's triggered at the start

BLTOUCH_DEBUG COMMAND=reset
G4 P375
BLTOUCH_DEBUG COMMAND=pin_down
G4 P375
BLTOUCH_DEBUG COMMAND=pin_up
G4 P1500 

After this the QUERY_PROBE command should show that the probe is not triggered. And hopefully homing should also work.

Could somone with a clone test if that works?

[oleplay]

@fredizzimo I just tested your commands with my clone.
The QUERY_PROBE says probe: open but homing still doesn't work BLTouch sensor test failed

[fredizzimo]

Ok, good. The current code does things in a differerent way, so there's probably something that causes it to enter the error condition again. But hopefully it will work after my changes, I will try to make it work exactly as Marlin.

[fredizzimo]

I suspect that it's the touch_mode, that's not working on the clones. Could you run the following macro and paste the terminal output

[gcode_macro touchtest]
gcode:
    BLTOUCH_DEBUG COMMAND=reset
    BLTOUCH_DEBUG COMMAND=pin_down
    BLTOUCH_DEBUG COMMAND=pin_up
    G4 P1500
    M400
    QUERY_PROBE
    QUERY_ENDSTOPS
    BLTOUCH_DEBUG COMMAND=touch_mode
    G4 P1500
    M400
    QUERY_PROBE
    QUERY_ENDSTOPS
```` 

For me it shows this

Send: touchtest
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
[...]
Recv: // probe: open
Recv: x:open y:open z:open
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // probe: TRIGGERED
Recv: x:open y:open z:TRIGGERED
Recv: ok
```

The original code assumes that the endstop is triggered after the reset, which is why it failed for me with the probe in the down position. On the clones, the touch mode might not be implemented at all, therefore never reports the triggered state under those conditions.

[oleplay]

Sure my Output:

Send: touchtest
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Send: M105
Recv: // probe: open
Recv: x:open y:open z:open
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Send: M105
Recv: // probe: open
Recv: x:open y:open z:open

[fredizzimo]

Thanks, that confirms that the touch mode is not working. If the pin is in the up state at the end of the test, it should return TRIGGERED, but for you it doesn't.

Hopefully this will work better when switching to the 10 degree probe. My progress with that is a bit slow, it takes some time to figure out the inner workings of Klipper.

[oleplay]

I found this issue from Marlin
https://github.com/MarlinFirmware/Marlin/issues/5817#issuecomment-279312462
Maybe that helps

[KevinOConnor]

@case-tm77 , @J2xWo , @fredizzimo - if you run a BLTOUCH_DEBUG COMMAND=pin_down then BLTOUCH_DEBUG COMMAND=touch_mode and then manually push the pin up a small amount, what does QUERY_PROBE report?

Also, I have a further refined test - if you have time, can you run the script below and forward the log?

-Kevin

test4-bltouch.gcode.txt

[fredizzimo]

@KevinOConnor
One a genuine bltouch it reports triggered as it should. One a clone, I believe it still reports open. I don't think the touch mode is implemented on the clones at all.

I'm still working on my changes, which implements the proper 10 degree mode, and takes advantage of the built in error checking that the BLTouch has.

I will also enable an option, which enables touch mode error checking, similar to what you already have (but only for error checking), which can be enabled on genuine BLTouch probes, but not on clones. The advantage with that, is that it can detect the situation where the endstop is not configured with a pull up resistor.

I has taken longer than I would have hoped, partly because of me being unfamilar with the klipper code, and partly because the BLTouch is not well documented. For example the error checking seems to take quite long to trigger, I think close to 1 second after you try to set the pin down, and it hits the bed prematurely.

One small not about these, changes, they will not work without having a small z-hop after homing, otherwise you could never home if the nozzle is too close to the bed when you start.

I would also like to add the bltouch checks before any homing move on any axis is taken place. Since if you are in an error condition, the pin might be ouching the bed, and if you move to the side at that point then it could destroy the probe.

[J2xWo]

@KevinOConnor
Sure I am glad if I can be of help
So I played around a little and it seems that after running your gcode the probe will always report back "open". After cutting the printers power and turning it on again klipper reported back either open or triggered.
When executing BLTOUCH_DEBUG COMMAND=touch_mode and moving it up just a little it reports back "open". when moving it up until it automatically retracts it reports back "triggered"

EDIT: also same as before when running the gcode, it fails. probe deploys but never retracts. Is there a way yet to reset the probe and let it do its selftest? or do i need to restart my whole printer if the probe starts blinking, signaling an error? (happened cause i wondered why it only reports back open)

klippy.log

[fredizzimo]

I added a new pull request with 10 degree probing and some error checking. It's stil WIP, because I would like to add a few more improvements, but I would be happy if someone could test it, to see if this is the way to go forward.

NOTE that you have to set the pin_move_time quite hight for reliable error reporting. I was testing with 1.5 seconds, but you can probably go lower than that. 0.5 seconds failed to trigger on some errors, so at least it has to be bigger than that.

The pull request can be seen here https://github.com/KevinOConnor/klipper/pull/982

[fredizzimo]

Another thing, it will trigger an error if the probe is touching the bed in the down position, and you don't move up before homing. So if you home twice in a row, the second one will fail. But that's easy to add to your homing_override, which you probably need in order to probe inside the bed anyway.

Also moving up, is a good way to ensure that you won't be hitting any clips on the bed.

[J2xWo]

Would love to test it! How do i do that though? New to github n stuff
Also thanks a lot!

[fredizzimo]

@J2xWo. this is how I usually do it https://help.github.com/articles/checking-out-pull-requests-locally/. It's not that hard, but might still be a bit tricky if you are new to git.

Another option is to clone my repository and switch to the bltouch_improvement branch. But in that case you either have to run klipper manually, or modify the service settings to use another path.

If you chose the first way, you only need to restart the service after switching to the pull requst branch

[KevinOConnor]

@J2xWo - Okay. I'm a little confused on what you are seeing. Separate from @fredizzimo test, could you run the following test with the current Klipper code:
1 - do a full power off and power on of the machine
2 - run QUERY_PROBE
3 - run BLTOUCH_DEBUG COMMAND=pin_down
4 - run QUERY_PROBE
5 - manually touch the bltouch a little
6 - run QUERY_PROBE
7 - fully press the bltouch
8 - run QUERY_PROBE

Please then cut-and-paste the output from octoprint for all four QUERY_PROBE results and label each one with the manual action you took. If the bltouch moves/blinks on its own after any of the above steps could you also describe what movement/blinking it does during each step?

Thanks,
-Kevin

[J2xWo]

@fredizzimo - So I think I did everything right. this is what i did just to make sure:
cd Klipper/
git fetch origin pull/982/head:bltest
git checkout bltest
and then i restarted
What is nice is that now the probe retracts before trying to home the probe if it was deployed.
But its not working yet. It retracts, then deploys and then throws an error. I didnt change the homing behavior yet. Here is the log:

klippy.log

[fredizzimo]

@J2xWo, strange, I don't see any errors in the log. From the log it looks like it has homed properly. prepare was called then finalize for the first fast probe, then again the same pair for the slower probe.

What kind of error do you see?

[fredizzimo]

Sorry, the editor autoloaded another log and switched to that tab, so I was reading the wrong log... Let me take another look

[fredizzimo]

Hm... MCU 'mcu' shutdown: Rescheduled timer in the past. It doesn't seem to be related to BLTouch, but proably something else I'm doing wrong. I haven't seen that happen at all in my tests. Although I have been running at a slightly older Klipper version (from a couple of days ago)

@KevinOConnor, do you have any ideas?

[J2xWo]

@KevinOConnor - Ok I powered it off and on, run QUERY_PROBE and it said its open. So i got suspicious and got my multimeter and measured the resistance when the probe is deployed or retracted. Both times i had a resistance of 130Ohm.. When it was working before i had either 130Ohm or no connection. So it seems the clone doesnt have a reliable switch? or what is the issue here? when i used the probe before, the printhead never crashed into the buildplate and i never got an error which would be expected if the probe always reports the status "open". Quite confusing

[fredizzimo]

@J2xWo. I don't think it really has a real switch at all. There's a microcontroller inside, controlling the output. When you do the normal 10 degree probing that switch is only activated for 10 ms, then it deactivates itself, that way the code can know about error conditions with only one pin.

In the touch_mode, which the scripts are testing, it should behave as a switch, and a genuine BLTouch does indeed behave like that, but I'm not sure if the clones actually implement it correctly. The link @oleplay posted above seem to indicate that they don't.

Another reason why I'm suspecting that the touch_mode is broken, is that Marlin for example doesn't use it, outside some test commands, normal homing doesn't.

[J2xWo]

Oops.. now i feel silly^^ thanks for the clarification. Will continue the testing tomorrow since it already gotten a bit late here

[KevinOConnor]

I've put together a development branch to gather more information on the clone bltouch behaviour. To use this test, ssh into the rpi and run:

cd ~/klipper ; git fetch ; git checkout origin/work-bltouch-debug-20181211 ; sudo service klipper restart

Then download the attached gcode, run it on the printer, and then attach the klipper log file to a new comment in this issue.

test5-bltouch.gcode.txt

At this point, it looks like it will be necessary to delay the v0.7.0 release due to this issue. Hopefully we'll be able to gather sufficient information so that we can resolve this issue and continue with the release.

Thanks,
-Kevin

[BlackStump]

@J2xWo on a side note what sort of movement mechanism do you have that has a step distance of
0.00078125 or if put the other way 12800 steps/mm because you will exceed the capabilities of the controller very quickly

[jakep82]

@J2xWo Using 256 microsteps is not a good idea. It looks like you're using a Mega2560 which can only handle 100K steps per second. At 256 microsteps you're capped at less than 8mm/s. That's likely why your G28 is failing. You shouldn't use more than 16 microsteps on any axis with that controller.

If you want to retain the smoothness of 256usteps, just leave the interpolation turned on.

[fredizzimo]

I noticed that too, and commented about it here already
https://github.com/KevinOConnor/klipper/pull/982. That’s the most likely version my code failed for him.

But I still believe that my pull request fixes the issue, and that the touch mode is broken on the clones. So if anyone else wants to try it, I would be happy.

[jakep82]

Yes, but changing the endstop_max won't allow the homing sequence to finish. At that step distance with that MCU, he's capped at around 7mm/s. That printer will never work unless he reduces the microsteps.

[fredizzimo]

Yes, that part of the diagnostics was most likely wrong. To me it looked like a communication buffer filling up. And that just barely, since the whole move was almost sent when it choked.

But then again I’m totally new to Klipper. I installed it on Friday, and I haven’t even looked at the native code yet.

[drbobbob]

@fredizzimo I have been able to successfully use a BLTouch Clone. My initial problem in this thread was due to misconfiguration of inversion. I would have to double check the specific hash that I am using. You can see in this thread when I would have updated and got it working.

[fredizzimo]

@drbobbob,

Perhaps we should not talk about a generic clone, because there are several different ones. There's the Geeetech 3D touch, which is generally considered to be reasonably compatible, at least if you read the issues on the Marlin github. Then there's some clone "based on Antclabs, which looks almost the same as the real one", there might be ones that looks exactly like the real one, but perhaps missing the QR code, or the certificate that comes with it. There's also a clone of the clone, the black 3D Touch.

I have read about the inverted ones too. And those might actually be totally uncomfirming with the default behaviour, and might actually require this touch mode. But I have no definite confirmation about that.

So could you do some tests, and verify in the default state, if you start the printer with the probe up or down. That it's not blinking, and that it returns not triggered no matter which state the probe is.

The second test, move the probe up and down while the printer is on, using the BLTOUCH_DEBUG. Just use pin_up and pin_down, and don't enable the touch_mode

The third test, do the same thing manually by hand, but very carefully, if it tries to pull the pin back, then don't pull harder, as that might damage the probe. You might have to do that from a clean state after turning the printer on, without commanding the probe to a certain state.

All of those cases should return not triggered if the probe is confirming. It should only return triggered when it's in an error state and blinking red.

[fredizzimo]

I just checked some more, if those tests are failing, you most likely have a so called TL Touch https://github.com/MarlinFirmware/Marlin/files/816612/322.pdf. More information here https://github.com/MarlinFirmware/Marlin/issues/5817

The TL Touch won't be compatible with the pull request that I made, but should be compatible with the current version that's in the master. So I guess we need an option to switch between the two.

For genuine and compatibles, the way I'm doing in my pull request is much better due to the extra safety and error handling. We should do everything we can in order to avoid destroying a 40€ probe, which is most likely the single most expensive part on the printer...

[drbobbob]

@fredizzimo Thanks for the additional details. I believe that I have a geeetech clone. I bought it from ebay and the listing mentioned geeetech. I won't be back to my printer until this evening. I also need to reflash back to klipper since I hopped back to marlin for some printing.

https://www.ebay.com/itm/No-Tax-Geeetech-Auto-Bed-Leveling-Sensor-3D-Touch-for-Reprap-3D-Printer-from-US/312153467476

[kennethpangky]

I just checked some more, if those tests are failing, you most likely have a so called TL Touch https://github.com/MarlinFirmware/Marlin/files/816612/322.pdf. More information here MarlinFirmware/Marlin#5817

The TL Touch won't be compatible with the pull request that I made, but should be compatible with the current version that's in the master. So I guess we need an option to switch between the two.

For genuine and compatibles, the way I'm doing in my pull request is much better due to the extra safety and error handling. We should do everything we can in order to avoid destroying a 40€ probe, which is most likely the single most expensive part on the printer...

Mine's a TL Touch, but it isn't working with the current version. So that's that. :)

[fredizzimo]

@kennethpangky, With the TL Touch, you also need to invert the endstop behaviour, that's clearly documented in the PDF.

You should probably not enable the pull up resistor on the endstop either, but I'm not 100% sure on that. The only thing I can see is that the example configuration in the PDF does not define it

In any case, pull up resistors on the endstop side with that probe is not really good, since a disconnected cable would cause the probe to crash. What it really should have, is a pull down resistor, but I'm not sure if Klipper supports that, and even if it does, it can only be done one ARM chips, since AVR chips don't have internal pull down resistors. Without either a pull-up or pull-down resistor, the behaviour with a disconnected cable will be random, sometimes it crashes to the bed, and sometimes it stops.

With a genuine BLTouch, however, and my code you generally want pull up resistors on the end-stop side enabled, since it means that when the cable is disconnected, the endstop will immediately trigger, and any homing operation will stop.

[kennethpangky]

@kennethpangky, With the TL Touch, you also need to invert the endstop behaviour, that's clearly documented in the PDF.

You should probably not enable the pull up resistor on the endstop either, but I'm not 100% sure on that. The only thing I can see is that the example configuration in the PDF does not define it

In any case, pull up resistors on the endstop side with that probe is not really good, since a disconnected cable would cause the probe to crash. What it really should have, is a pull down resistor, but I'm not sure if Klipper supports that, and even if it does, it can only be done one ARM chips, since AVR chips don't have internal pull down resistors. Without either a pull-up or pull-down resistor, the behaviour with a disconnected cable will be random, sometimes it crashes to the bed, and sometimes it stops.

With a genuine BLTouch, however, and my code you generally want pull up resistors on the end-stop side enabled, since it means that when the cable is disconnected, the endstop will immediately trigger, and any homing operation will stop.

I've tried it both ways, but it still fails with sensor test fail. You have one working with the TL Touch?

[fredizzimo]

No, I don't, I'm just going with the information in the PDF document, and what people have reported.

I can think of two reasons why it fails for you:

1. You don't have the same TL touch as documented in the PDF, and it behaves in some other way
2. Enabling the touch mode causes some undefined behaviour.

[kennethpangky]

No, I don't, I'm just going with the information in the PDF document, and what people have reported.

I can think of two reasons why it fails for you:

1. You don't have the same TL touch as documented in the PDF, and it behaves in some other way
2. Enabling the touch mode causes some undefined behaviour.

Could be. That pdf is pretty old, my TL Touch is directly from Triangle Labs, less than a week old.

On a side note, in Marlin, the TL Touch ran on the same exact codes as the official BL Touch. Because I swapped out the TL Touch with the BL Touch in Marlin without compiling and flashing the firmware, and it worked fine. Maybe you should be less reliant on that pdf and guess work.

[fredizzimo]

If it works with Marlin, then I'm almost 100% sure that it will work with my pull request. I'm still looking for people to try it out.

And @KevinOConnor, is looking for people to try out his test, which tests the touch mode

In addition to that, I would like to see his test done without the touch mode on the same setup, so once with his test
```
; BLTouch diagnostic test (touch mode).

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

G28

G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0

M112

And once without out

; BLTouch diagnostic test (normal mode).

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

G28

G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0
G4 P0

M112
```

Those should be done in his branch, as he told above.

Until we get this data, all we can do is guessing, and going by information reported by other people.

We also need information about what kind of BLTouch Clone you are using, since there's so many difference clones

[kennethpangky]

Yeah. Looking forward to what you guys have done.

But I ordered another genuine BLTouch during the recent promo, guess that TL Touch's going into the drawer.

[drbobbob]

@fredizzimo At startup and with all combinations of BLTOUCH_DEBUG the reports from QUERY_PROBE were open. Even with pulling / pushing the pin on the BLTOUCH I was never able to get it into an error state.

[...]
Send: QUERY_PROBE
Recv: // probe: openRecv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=reset
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: ok
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
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
[...]
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
[...]
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=pin_up
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Recv: ok
[...]
Send: QUERY_PROBE
Recv: // probe: openRecv: ok
[...]
Send: QUERY_PROBE
Recv: // probe: open
Recv: ok
[...]
Send: G28Recv: ok

I am working with klipper from master hash 76b57ba05a5b89b291d43dfe1a6c2e3e5f1c661e.

[fredizzimo]

@drbobbob,

Thank you this confirms two things.

1. In normal mode, the probe is most likely behaving as it should.
2. In touch mode it's behaving differently than a Genuine BLTouch

My suspicion has been, and still is, that the touch mode is simply ignored at least on the 3DTouch clones. The report in this issue https://github.com/KevinOConnor/klipper/issues/976, is consistent with that too.

However, your report is also confusing in a sense, since with that behaviour it should not work with the code in the master branch and the version you are having. The code does a reset follwoing by quickly enabling the touch mode, it then expect the signal to rise high. If touch mode is working as it should, then that should be true, if and only if the probe was in an error state, or in the up state when performing those commands. The reason for that, is that resetting a working probe does not move the pin, unlike resetting it from an error condition. If however the touch mode is ignored, or the touch mode command would be missing, then that code should always fail.

Therefore, it looks likely that there's a second bug in at least your probe, which causes a short signal just after the reset of the probe. That bug makes it work for you. The question is why does it not happen for everyone else with that probe? Although you didn't attach the log file here, I found your config with the inversion of the pins on your github, and that makes me even more confused about why it's the case for you.

It's probably somehow related to your inversions of the pins. The 3DTouch does not have inverted pins, http://www.geeetech.com/wiki/index.php/3DTouch_Auto_Leveling_Sensor. But you could of course have some strange clone that has it. But the more sensible explanation is that you also have the cable connected the wrong way around. But since you also have the pull up resistors enabled, that would mean that you are pulling up the ground signal. That could have some bad side effects, or perhaps the backflow in this case saves the situation?

Anyway in order to answer at least some of the remaining questions, it would be really nice if you could do the test procedure that @KevinOConnor requested here in this comment https://github.com/KevinOConnor/klipper/issues/955#issuecomment-446327773

[noud-github]

First thing: Great 3d printer firmware, really love the multiple mcu setup.

I use a 3Dtouch clone, works Oke in marlin, works with servo/probe setup in klipper with but not always smooth, I get the error with de bltouch config.

I attached the requested test log

klippy.log

[nandinho84]

Just for information... I have a 3DTouch and it worked ok with servo/probe setup and works ok with the new bltouch configuration as well. The only problem I saw was the bad repeatability and a problem with the temperature that isn't stable. But these two problems might not have to do with klipper... I still haven't gotten time to check what might be happening...

[drbobbob]

@fredizzimo The config file you found isn't the latest. There is another comment on this thread that says that I removed the inversion and it started working. Also to note, according to my board schematics (that are reverse engineered rather than original) there is a hardware 10K pullup and
10uF smothing capacitor to ground on the pin that I am using for input. I don't know how that will affect things, but apparently not too badly.

Board Schematic has the Z endstop in the middle towards the right.

For the sake of others, I'll try the other test. I was able to do a mesh probing last night and print successfully with klipper so my setup isn't too broken.

[fredizzimo]

@drbobbob

Ah, I didn't read your messages well enough. But it still doesn't explain anything new.

Have two pull up resistors in parallel should just make it a bit stronger, with less resistance. It probably should do no other harm than to make the printer draw slightly more current when the probe is not triggered. There's a very slight chance that it changes the behaviour when resetting, due to having lower resistance, and therefore allowing more leakage current and impedance on the probe side.

@noud-github, Unfortunately the logs don't show any useful information. If you are able to and know how to do it, I recommend that you perform @KevinOConnor's test, and if possible also test with my pull request.

[noud-github]

@noud-github, Unfortunately the logs don't show any useful information. If you are able to and know how to do it, I recommend that you perform @KevinOConnor's test, and if possible also test with my pull request.

That is exacly what i thought i did.
steps taken:
boot raspberry
tested with servo setup with G28 (result Ok)
changed config to bltouch
tested with this config with G28 (result error)
update with the @KevinOConnor's :

cd ~/klipper ; git fetch ; git checkout origin/work-bltouch-debug-20181211 ; sudo service klipper restart

download test5-bltouch.gcode.txt
renamed it to test5-bltouch.gcode
run that as a print job from octoprint.

scp the klippy.log file and uploaded it here. (second time it workt ;-)

git checkout master
and config back to servo

if you can tell me were i went wrong i will try again

[fredizzimo]

Hm, your steps look right. But for some reason the the log doesn't seem to show the information that it's supposed to.

I think part of the reason is that it got into an error state before it had a chance to finish. But it's also missing the bltouch sensor log statements that @KevinOConnor added.

[noud-github]

I try again later what lines am i looking for in the klippy log file does it contain >bltouch

[KevinOConnor]

@noud-github - thanks. That's very strange - the log indicates you are running the correct code, but it show that there were no signal line changes detected on the bltouch sensor. When you ran the test, did the bltouch pin move up and down at all? Did the leds flash or otherwise indicate it was in an error state?

-Kevin

[fredizzimo]

He added this
https://github.com/KevinOConnor/klipper/commit/f8f5ba3e2b32f051efb54c412183e99e770779d0#diff-2bd92b768f690a1f9479ad8b4548af9eR59

So it should say

bltouch sensor @ followed by a timestap and is followed by the state of the sensor.

[noud-github]

(bad anwer) but my wife started talking to me while running te test script so i don't know .
will run again when the kids are in bed. and take notice of the probe state this time

[fredizzimo]

It might actually be that the logs are working, and showing exactly what happens.

I can't test it right now, since I'm not at my printer, but I believe that with a probe in normal mode, the state should never change during that test, until the actual homing happens.

If that's what happens, it's a further indication that the clones simply might ignore the touch_mode command.

[noud-github]

state of pin while running the gcode:
start: up, Or down
down
up
down,
blue light flashes
start G28 with pin down!!
blue ligth flash
Error

klippy.log

[noud-github]

manual test,
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
makes the probe flash blue and drop the pin down,

between the two M119 I manual pushed up the pin:

Send: BLTOUCH_DEBUG COMMAND=pin_up
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Recv: ok
[...]
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
[...]
Send: M119
Recv: x:open y:open z:open
Recv: ok
[...]
Send: M119
Recv: x:open y:open z:TRIGGERED
Recv: ok

[noud-github]

In servo mode when i set angle 60 it wil drop down, en turn blue, than i can trigger the probe,
but it will only stay up, color red and triggerd for about 5 seconds, unlike the touch_mode that stayed up red and triggered until command=pin_up

between Set_SERVO and first m119 I pushed pin up. after about 5 sec it changedby it self

Send: SET_SERVO SERVO=bltouch ANGLE=60
Recv: ok
[...]
Send: M119
Recv: x:open y:open z:TRIGGERED
Recv: ok
[...]
Send: M119
Recv: x:open y:open z:open
Recv: ok
[...]

[fredizzimo]

Ok, so if I'm interpreting this right, it seems like touch mode responds to manual input, but not automatic one.

While you are testing, could you also test my pull request?

sudo service klipper stop
git fetch origin pull/982/head:fredizzimo_bltouch
git checkout fredizzimo_bltouch
sudo service klipper start

And when done testing you can go back to master

sudo service klipper stop
git checkout master
sudo service klipper start

EDIT I forgot to tell, that you don't really need to do any special testing there, other than to test that homing and bed leveling works as it should

[noud-github]

With your branch it homes with out error n=1

[noud-github]

Ok, so if I'm interpreting this right, it seems like touch mode responds to manual input, but not automatic one.

I guess you are spot on, if i do a pin_up it dus'n trigger (for long) if i push it up manual it stays triggert for ever

[fredizzimo]

To be honest, I don't think this problem is worth debugging any further. It doesn't look like we could get touch mode to work, and even if we do, it will never deal with errors as well as the normal mode, in my branch.

So what's left to do is to get my branch into shape so it can be merged.

[fredizzimo]

That said, a genuine BLTouch responds to the touch mode as you would expect, and homes fine with @KevinOConnor's script

touchmode.log

[fredizzimo]

The normal mode on a genuine BLTouch creates the same kind of log as @noud-github had. No pin state changes reported at all, and probing failing.

I removed the touch_mode commands from @KevinOConnor's script, and also from bltouch.py

normalmode.log

[KevinOConnor]

The normal mode on a genuine BLTouch creates the same kind of log as @noud-github had. No pin state changes reported at all, and probing failing.

Interesting. That could certainly explain the lack of debugging information. Unfortunately, I can't see any way to perform the sensor test on this particular set of clones. (We really want to force the bltouch to report the sensor as triggered and then not triggered, before moving the head towards the bed.) I suppose we could add a config option to disable the sensor test.

If these probes really don't support touch_mode at all, then the bltouch.py code will also need an update to make sure it checks the endstop a minimum of every 1ms.

Not using touch_mode at all is not a great solution as we know pin_down can cause problems on some bltouch hardware, including the real ones. After a successful probe event, if the pin_down is not cleared within a 100ms or so it will push the pin down a second time and hit the bed a second time. That will result in the bltouch going into an error mode. As I understand it, clearing the error mode on the bltouch is known to be finicky (very finicky on clones, but even so on the original).

-Kevin

[noud-github]

I think the clone i own does support touch_mode, but does not behave in touch_mode like the real thing,
differance i notice is in normal mode it will not stay triggerd
I think the disable sensor test is a nice solution for the people with a clone, and a bonus for the real ones. just my 2 cents

[fredizzimo]

Unfortunately, I can't see any way to perform the sensor test on this particular set of clones. (We really want to force the bltouch to report the sensor as triggered and then not triggered, before moving the head towards the bed.) I suppose we could add a config option to disable the sensor test.

That's exactly what the built in error checking does. If we command the probe to move up, and it fails, it goes into error mode. In that particular case the printer is shutdown, because there should be nothing preventing the pin from moving up. This works completely reliably on the genuine BLTouch as long as you allow for big enough movement time.

If these probes really don't support touch_mode at all, then the bltouch.py code will also need an update to make sure it checks the endstop a minimum of every 1ms.

Why would we need to do that? That can be an additional safety check, but it's really not needed. My code ensures the probe moves up when the printer starts, and after it's done probing. Furthermore there's a mechanical pull-up force enabled, so it should really not go down by itself at this stage. Marlin has been doing completely well without this kind of check.

Not using touch_mode at all is not a great solution as we know pin_down can cause problems on some bltouch hardware, including the real ones. After a successful probe event, if the pin_down is not cleared within a 100ms or so it will push the pin down a second time and hit the bed a second time. That will result in the bltouch going into an error mode. As I understand it, clearing the error mode on the bltouch is known to be finicky (very finicky on clones, but even so on the original).

Again, if the pin does not move down, the probe goes into error mode. The typical case is not really an error, you might just be too close to the bed. So my code tries to clear the error and move the pin up. If the error is triggered again after we try to move the pin up, then the printer is shutdown.

Clearing the error condition automatically can be a bit tricky. And I find the way Marlin does it very risky. Marlin moves the pin down, then up, and after that checks if the error condition is cleared. If the command to move the pin down fails (which it does easily when you are close to the bed), the code would leave the pin down. My code never goes into that kind of situation. I believe what they were trying to do here, is clear the error in a very edge-case very the probe is really close to the bed and down. In that case you should be able to clear it manually by shutting down the printer and move the pin up, perhaps you have to manually move the printhead up too.

Edit In addition to this, my code shuts the printer down, if one of the cables are disconnected, either when you start the probing, or when the printer is started. At least if you have pull up resistors enabled.

[fredizzimo]

Touch mode can be there as an additional safety meassure, but it can never be the main way of probing. At least I would never use it.

The reason is simple, touch mode can't make a difference between these two cases without extra logic

1. The pin is down, and the probe is in error mode
2. The pin is up

You can try to detect this by trying to move the probe down and see if the triggered status clears. However, now you have a problem, if the probe is too close to the bed then the status won't clear. I guess that could be solvable too by trying to move the z-axis up, then do a reset, then try to move the pin down again. But the logic of doing that gets complex and error prone.

I'm also quite sure that the built-in error checking is doing more than just checking that the pin moves to the right place.

[KevinOConnor]

I've updated the work-bltouch-debug-20181211 branch. It will now enforce a minimum probe query time and it adds a new "test_sensor_pin" config option. If you have a BLTouch clone, are receiving the "BLTouch sensor test failed" errors, and are sure it is wired correctly then you can set this new option to False to disable the internal software check.

cd ~/klipper ; git fetch ; git checkout origin/work-bltouch-debug-20181211 ; sudo service klipper restart

-Kevin

[KevinOConnor]

@fredizzimo - my comments above were not related to your code - they were general comments on bltouch support. I believe all of my comments above are accurate observations - if you're not sure why after re-reading, let me know and I will expand.

My focus is solely on bug fixes at this point. The goal is to complete the Klipper v0.7.0 release. A significant change to bltouch.py prior to that release is not something I am considering.

-Kevin

[fredizzimo]

The only thing, I see that I missed is the marginal case where you are probing so slowly that one step takes longer than 5 ms, for the rest I still see my code as a far safer alternative for a release.

But since you are concentating on bugs, I feel obligated to report what I see. There are two very serious issues in your code still.

1. My original problem. Nothing makes sure that the printer starts with the probe in the up position. This is very critical, since the first move you do is typically sideways.
2. The probe is not guaranteed to be in the up position after probing. The BLTouch has a tendency to return back on some touches. See this
   https://github.com/MarlinFirmware/Marlin/issues/4855. Now that I see this, I realize that you might actually be referring to this in your last comment. However your code does not handle that, mine does. A reset command does not move the probe up, unless the probe is in an error state. I do a pin up, just like been confirmed working in marlin, and also actually check that the probe reports that it went up correctly.

If you can fix these two issues, then I guess your code is reasonably safe for use. Although completely without safety nets on clones and a quite nasty nozzle crashing issue remains, even on a genuine BLTouch.

If you start probing too low, then you will see a trigger immediately(remember that you don’t see any difference between errors and normal triggers) This means that you will be closer to the bed than you should. If you now have the z offset configured and move down to your first layer hight, then it’s likely that you will go too low and crash into the bed.

The problems with malfunctioning probes and disconnected cables are probably not that likely. But especially on the clones they could cause prints in the air, or even a similar nozzle crash issue as described above.

[noud-github]

@KevinOConnor

tested work-bltouch-debug-20181211, this introduces a new bug, the pin is DOWN after probing,

the option works as expected,
tested both "test_sensor_pin" options and as expected( error with true en working with false.)

I only think the option name, is not self explaining en open for misinterpetation, some thing like: use_test_function, covers it better.

[noud-github]

@fredizzimo

changed "pin_down" to "touch_mode" in your latest bltouch.py, this works better, (on my clone 3Dtouch) because, now the pin will not drop immediately after probing with a annoying TIK sound on the glass plate. but i don't know if this code works on an original BLTouch

def home_prepare(self):
logging.info("BLTouch prepare")
self.test_sensor()
try:
self.send_cmd_and_verify("touch_mode")

[fredizzimo]

@noud-github.

Hm.. My code does try to pull the pin up like the fix for the Marlin issue, I linked. That should happen immediately, and it should also go into an error if it fails.

But maybe the code is not fast enough. Does the probe start to blink when it happens? And is the probe eventually raised afterwards, after clearing the reset condition?

The Marlin issue I’m referring to
https://github.com/MarlinFirmware/Marlin/issues/4855

[noud-github]

@fredizzimo,

your code works, and pin goes up no errors. what happens:
1 head in place
2 pin drops down blue light turns on
3 head and bed meet pin goes up red light goes on.
4 pin drop hit bed en goes up again red light momentery of and on.
5 next action in g code

[noud-github]

with my change from pin_down to touch_mode the pin also goes down but does't hit the glass.

[fredizzimo]

Hm.. That happens for me if there’s no retract of the printhead between the probes, homing should probe twice. In that case it tries to deploy the pin when there’s already contact. A genuine probe sees this as a failure and errors the homing operation. Yours probably see it as an immediate contact.

I don’t know why it doesn’t move up for you after the first probe. There should be a homing_retract_dist with a default value of 5 on stepper_z. But I have mine manually set to 5 mm. For mesh bed leveling, I think the default is only 2mm, and that’s too low for BLTouch

Also these errors are only reliably detected with a pin_move_time of at least 1.0 on a real bltouch.

[noud-github]

sorry for not being clear, everting works as it shoud, with your code!
it retracs after probing no errors nothing. usable for everyday printing.

only problem is a distubing tik from the pin hitting the bed after every probe.

is it posible to upload a mp4 maybe i can make a movie of it this weekend

[arminth]

Hi guys,
I just received my clone from Triangle Labs (saying based on ANTCLAPS BL Touch) and ran into the error today. The debug-commands all work, just G28 fails. I will install the pull later this day and then immediately contribute. And it's 2 week of holiday now - so lot oft testing possible!
Still: Klipper rulez!!

Cheers
Armin

[fredizzimo]

Well, it looks like it might only make one probe instead of two. When homing, it should probe one time with a faster speed and another time with a slower speed.

So the sequence should be the following (after any custom G-code you might have in your homing override)

1. Move into place
2. Deploy the probe (it should not touch the bed at this point, otherwise you should get an error. To fix that you need a custom lift code in homing override). The probe should have a very faint blue color
3. Move down until the pin touches
4. The pin should move up and the bltouch turn red
5. Move up the homing_retract_dist, the bltouch should still be sold red
6. Move the pin down, the bltouch should turn very faint blue. The pin should not touch, otherwise your homing_retract_dist is too small
7. Move down until the pin touches
8. The pin should move up and the bltouch turn red
9. The printer should now be fully working, the pin should remain up, and the probe should stay solid red

From your description it looks like step 4 does not happen, or that it moves up a little bit too little.

On a side-note, I set my second_homing_speed, and also the bltouch speed (for mesh bed leveling and just probing) to 1 mm/s, because there's a constant overshoot with higher speeds. There's almost 20 microns difference between 5 mm/s and 1 mm/s. I still get a couple of micro-steps variations, even with the lower speed though, but not constantly in one direction, like altering the speed does. So it seems like there's some improvements to be done on the controller side too. I'm not sure if the accuracy can be improved, but at least I don't think it should overshoot at these speeds.

[danielkucera]

Hi all,
my bltouch clone arrived today and doesn't work. Running version
Git version: 'v0.6.0-671-g084e230-dirty'
The probe goes correctly up and down when issuing pin_down and pin_up
here is my log:

Changing monitoring state from "Operational" to "Printing"
Send: N0 M110 N0*125
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=pin_down
Send: QUERY_PROBE
Send: N1 G4 P1000*93
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok
Send: QUERY_PROBE
Send: BLTOUCH_DEBUG COMMAND=pin_up
Send: QUERY_PROBE
Send: N2 G4 P1000*94
Recv: // probe: open
Recv: ok
Send: QUERY_PROBE
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Send: QUERY_PROBE
Send: N3 G4 P1000*95
Send: QUERY_PROBE
Send: BLTOUCH_DEBUG COMMAND=reset
Send: QUERY_PROBE
Send: N4 G4 P1000*88
Recv: // probe: open
Recv: ok
Send: QUERY_PROBE
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Recv: okChanging monitoring state from "Printing" to "Finishing"
Send: N5 G28 Z0*92
Send: N6 M400*33
Recv: // probe: open
Recv: okChanging monitoring state from "Finishing" to "Operational"
Recv: ok
Recv: // probe: open
Recv: ok
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
Recv: // probe: open
Recv: ok
Recv: ok
Recv: // probe: open
Recv: ok
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: ok
Recv: // probe: open
Recv: ok
Recv: ok
Recv: // probe: open
Recv: ok
Recv: !! BLTouch sensor test failed

[arminth]

Here are my results. Using a Fysetc F6 board with the following bltouch section:

[bltouch]
sensor_pin: ^ar12
control_pin: ar13
pin_move_time: 1
x_offset: -42
y_offset: -5
z_offset: 1.5
speed: 5

This is my Terminal output:

Send: M400
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=reset
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: ok
Send: G4 P1000
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=pin_down
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_down
Recv: ok
Send: G4 P1000
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
Send: G4 P1000
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=pin_up
Recv: // Sending BLTOUCH_DEBUG COMMAND=pin_up
Recv: ok
Send: G4 P1000
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=reset
Recv: // Sending BLTOUCH_DEBUG COMMAND=reset
Recv: ok
Send: G4 P1000
Recv: ok
Send: BLTOUCH_DEBUG COMMAND=touch_mode
Recv: // Sending BLTOUCH_DEBUG COMMAND=touch_mode
Recv: ok
Send: G4 P1000
Recv: ok
Send: M400
Recv: ok
Send: query_probe
Recv: // probe: open
Recv: ok
Send: G28
Recv: !! BLTouch sensor test failed
Changing monitoring state from "Operational" to "Error: BLTouch sensor test failed"
Changing monitoring state from "Error: BLTouch sensor test failed" to "Offline (Error: BLTouch sensor test failed)"
Connection closed, closing down monitor

One observation is: When going in touch_mode, the blue LED is lighting up for 2 seconds or so. Same with G28 when trying to home Z shortly before Error.

I am on the test-branch.
I also tested a second Sensor, same brand, same result.

Can't do more atm.

:(

Cheers
Armin

P.S.: How do I format this stupid terminal output correctly!?

[fredizzimo]

@danielkucera,

If you read this issue, or just a few messages up, then you can see that we have two different solutions to the problem in the works.

1. My pull request, which uses the BLTouch normal mode, so it automatically has a lot of different safety tests included. This is also very close to how Marlin does its probing, which has been working for a lot of people for a long time. There might still be a minor issue in my code, which needs fixing, as reported by @noud-github, just a few messages above this.
2. @KevinOConnor's branch, if you disable the test_sensor_pin option. This uses what's called with many different names "touch mode", "Alarm Release& Touch SW Mode", "M119 Test mode", That gives you close to no guarantees about things operating correctly, though, so be aware. Being labeled as "alarm release" in the newest versions of the BLTouch manual, also seems to indicate that it disables all built-in error checking. Additionally the code leaves the pin down, touching the bed, like I predicted it would in a couple messages about, and that @noud-github, later confirmed was the case. So it's impossible to start a print using that, unless you add additional commands to retract the pin manually. Don't try to do any movement commands when it's in that state either, since that could destroy the probe!

[fredizzimo]

@arminth,

You will need to disable test_sensor_pin, to get the clone to do any probing in the test branch. So you could try that, however be aware that it leaves the pin down after probing, so be very careful.

Personally I would also like to see my pull requested tested a bit more, even if it seems unlikely that it will be included in the official release. @KevinOConnor seem to be completely determined in doing tings the way it was done before, no matter what short-comings it has

My branch can be tested with

sudo service klipper stop
git fetch origin pull/982/head:fredizzimo_bltouch
git checkout fredizzimo_bltouch
sudo service klipper start

And when done testing you can go back to master

sudo service klipper stop
git checkout master
sudo service klipper start

[arminth]

@fredizzimo
Thanks for the heads up! I got lost a bit on catching up!
With option, G28 does something! Haven't mounted my probe yet, just using it in mid air to test..
So from my understanding, ther must be a pin_up after every G28 (how about G29 then?). This could be covered by scripts but it will not be save when using homing through octoprint controls...

Will try your branch now and report!
Cheers
Armin

[fredizzimo]

There's actually no G29 command in klipper, you are supposed to make your own macro for that. But BED_MESH_CALIBRATE does essentially the same.

And yes, it will raise the probe and also the print head between each test point. How much is controlled by sample_retract_dist and horizontal_move_z. The first when doing multiple probes on the same spot, and the second, when moving from point to point.

When homing, the option that controls the same thing is homing_retract_dist, and should be set for the z_axis.

I set all of those to 5mm to be safe.

[arminth]

I tried your branch and in general it looks like working.
Still I highly doubt the quality of this stupid triangle lab clones!
I bought these more out of interest as I am normally using a capacitive probe which works perfect!
So this BLtouch thing for me is more a tinkering thing and I am new to BL Touch (clones). I had a G29-macro already in place so that's why I was talking G29.
So when doing my mesh-leveling, at several spots the pin didn't stay up during probing. One run went through and showed a totally bumpy bed in bed visualizer. Next trial even ended up in crashing the nozzle into the bed! I am using the extension cables that were provided with the kit.

So I can confirm, your branch is working in general. Still I am not convinced to change from my capacitive probe to this clone-solution....

Happy for hint's!

cheers
Armin

[fredizzimo]

Than you @arminth,

You result seems to indicate the same thing as for @noud-github, the probe does not stay up for some strange reason. I'm requesting a pin-up command right after the triggering, but apparently that's not enough. The issue I linked above from Marlin, suggest that it has to be done immediately, so at this point I suspect that the communication between the firmware and klipper is just too slow for that. Or maybe there's some command in the queue preventing that from happening. This obviously need to be fixed.

Did the nozzle crash happen during the probing, or because the mesh bed leveling had generated a bad mesh, causing the nozzle being too close to the bed? I'm not sure if the previous mesh is actually cleared before starting the next probe or not.

You can use something like this to test the repeatability, which should be easier to interpret than the mesh, because all probe points are at the same place

[gcode_macro test_repeatability]
gcode:
    G1 Z5
    PROBE
    G1 Z5
    PROBE
    G1 Z5
    PROBE
    G1 Z5
    PROBE
    G1 Z5
    PROBE

For me it's highly dependent on what speed I have configured for the probe. I briefly described that in a post above. You also need to set second_homing_speed to the same, otherwise the mesh bed leveling will use a different speed than the actual homing.

The speed mostly affect when it triggers though, it seems the faster the speed there is, the lower it goes before triggering. But the reputability was slightly worse as well. I noticed the speed sensitivity, because at that time my homing speed was slower than the probe speed, and I constantly got values that were offset from zero.

With a speed of 1mm/s my Antclabs BLTouch smart was reasonably good, with most values varying between -0.005 and 0.005. The step size is 0.0025 on my Ender-3, so mechanically it should probably be better than that.

Anyway the speed sensitivity seem to indicate that we are probably not fast enough to react on the firmware side. My slight inaccuracy could also be a consequence of that.

[fredizzimo]

I would like some information about how well the clones implement the error handling.

If you use my branch and do a homing operation, depending on your z offset, it should leave you closer or at least equal to the pin length from the bed.

So if you now perform a BLTOUCH_DEBUG COMMAND=pin_down, the pin should hit the bed, and the probe should go into an error condition and start flashing in red. On a genuine BLTouch I found that having a pin_move_time of 0.5 caused the error to be detected most of the time, but not always. With a move time of 1, I have not seen it failing.

You could also verify that the error condition is cleared and it homes again with G28, but be very careful, the z-axis is homed last, which means that the pin won't move up before that, so make sure that you homing operation moves enough up before moving x or y to not destroy the pin. I'm not handling this case, because it would require some bigger structural changes to the code, and the automatic homing should never leave the probe in that kind of state without shutting down the printer.

If it doesn't start flashing red to indicate an error on your clone, then you might need to change the z offsets and move the head just slightly down before trying to deploy the pin. Or alternatively you might need a bigger pin_move_time.

[KevinOConnor]

@noud-github

tested work-bltouch-debug-20181211, this introduces a new bug, the pin is DOWN after probing,

Thanks. Could you (and @arminth ) retest with the latest code on the work-bltouch-debug-20181211 branch?

cd ~/klipper ; git fetch ; git checkout origin/work-bltouch-debug-20181211 ; sudo service klipper restart

This changes the post probe code to do both a "reset" and a "pin up".

@arminth - Also, if you get a chance can you run the test5-bltouch.gcode (described at https://github.com/KevinOConnor/klipper/issues/955#issuecomment-446327773 ) on the above branch and then attach the klipper log file to a new comment in this issue (see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md ).

@fredizzimo

A reset command does not move the probe up, unless the probe is in an error state.

It appears that a genuine bltouch will raise the probe on a "reset" regardless of the error state. As above, I've updated the code to try to account for the clones - it would be great if you can verify this continues to work on your genuine bltouch.

Nothing makes sure that the printer starts with the probe in the up position. This is very critical, since the first move you do is typically sideways.

Understood - however this isn't (as near as I can tell) a regression, and the bulk of bltouch users are not reporting this behaviour, so it will wait until after v0.7.0 .

Thanks,
-Kevin

[arminth]

@fredizzimo
Your first question: Crash happened for the first time at the last row of probing. The second time it happened on the first probe after homing.

Your second request regarding error handling:
The Triangle-Thing does exactly, what you describe: the pin-down after home results in error-condition. The condition can be solved by rehoming. My homing lifts 5mm regardless the Z-position. (The pin didn't break! ;) )
@KevinOConnor
Will do my best but I think, I have to take care a bit of my wife now! Otherwise there is a good chance of my printer and me living on the street in the near future! :)

cheers and keep up the good work!

Armin

[fredizzimo]

@arminth. I suppose you didn't see if the pin was down or up during the probes that crashed? Or actually exactly what happened, since there are tons of different things that could have happened physically.

And obviously I can't ask you to test again, since it might damage your printer :disappointed: At least if you are not carefully watching, or have another mechanical endstop connected to the same wire, that will guarantee that it's triggered.

Right now I don't really have any explanation for this. The only difference is that your probe most likely have a 5ms signal, and mine being a newer BLTouch smart has a 10ms signal.

@KevinOConnor made some changes to his branch to guarantee checking the state of the endstops at least once every ms. But I don't really see how it could be a problem in the normal case for you. As far as I can see, the code in homing.py makes sure that we check the state at least once every microstep. I don't know the specs of your machine, but on mine, if I'm homing with 5 mm/s and the microstep size is 0.0025mm, then 0.0025 mm / 5 mm/s = 0.0005 s. So one step takes 0.5 ms, well within the margins. But of course if I slow down the speed close to 0.5 mm/s, then I'm starting to approach the danger zone. So the safety check should be there.

But could your printer is configured, so that your printer is in the danger zone already with your normal probing speed?

Or maybe there are some other bugs with the Endstop checking?. My previous tests with the varying homing speeds indicates that there might be.

[danielkucera]

Hi @fredizzimo , I tried your branch but homing Z ended with "The BLTouch probe is malfunctioning" when running command: "G28" while the printhead hit my beatbed in the middle

[fredizzimo]

@danielkucera, I'm sorry to hear that, my code is supposed to prevent that from happening in all cases, not cause it 😢

I think I can explain the "BLTouch probe is malfunctioning". After it hit the bed, it tries to probe a second time, but it's too close to the bed and went into an error condition. Some clones are known to go into an almost unrecoverable error condition when it's way too close to the bed. So the fact that you got that error is a good thing.

Now the question remains, why did it hit the bed? My speculations are still the same as in the post above where I'm answering @arminth. That somehow, the short 5ms pulse is not detected by the firmware. Currently I don't see how that's possible, after looking at the code a bit more. Also if we in normal situations don't react within 5ms, then the results would be highly inaccurate.

The other potential cause, would be if the pin somehow doesn't go down before starting the probe. But like @arminth tested, at least his clone detected that kind of error perfectly

[danielkucera]

@fredizzimo , if it helps you, I can create a log using logic analyzer. If so, what signals would be helpful?

[fredizzimo]

First, do you still have the klipper log left from the crashing operation? See the instructions here https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md?

Well, I guess there's two different things that could be gathered with a logic analyzer, and especially if done at the same time.

The endstop trigger signal, we could verify that the probe really sends a 5ms long singal upon contact, and not somehting much shorter for example.

For the other signals, we could verify that Klipper generates pulses of the correct length. And together we could verify that things are done in the correct order. If additionally the Klipper log is attached, then the timing from there could be correlated to the analyzer output too, that would give a lot of information.

Here's the wiring information and what kind of signals we should expect for the original one https://docs.wixstatic.com/ugd/f5a1c8_77c6538efc934dbeab2f6e06e175ec35.pdf. But on your, the colors might be different.

[danielkucera]

There is a lot of other stuff but you will find it, if you search for the error I posted above.

klippy.log

[fredizzimo]

From what I can see in the log, my code looks like it's behaving like it should, but there's some other strange things going on. The second slower home move failed to stop in time, the first one stopped as stepper pos -38977 and the second one at -40030.

The interesting thing is that the second one did eventually return triggered, but way too late.

The other thing that I can't explain now, is that after the head crash, the code tried to move the pin up, but that failed. I can only think about one possible reason for that, other than the probe behaving completely strange. That the probe is mounted too low, and a secondary error triggers, because you try to push it beyond the real up position.

Is your probe mounted high enough, so that it's above the nozzle when it's in the up position?

[danielkucera]

After the crash, the mcu was halted and I needed to powercycle it.
I was watching the process a I'm trying to remember if the probe light up red before crashing (it seems to me that it did) but I'm not sure.

Nevertheless, if I'm using work-bltouch-debug-20181211 with test_sensor_pin: False , it works fine except the need to quickly touch the probe to retract it after mesh probing (otherwise it would stay out and crash to my bed from side after printing the "purge" line) - this should mean that the probe is mounted correctly, does it?

[fredizzimo]

Yes, it printing works, then it should probably be high enough.

BTW, the distance between the working move and the crashing one was around 2.63 mm. But I'm not sure how accurate that is, if the stepper could not move anymore.

I also checked your stepper settings, and that's exactly the same as on mine, 0.0025mm. So at your speed of 5 mm/s for probing there should be plentty of margin for timing issues. On the C side of the firmware there's a simple switch debouncing algorithm, which adds a tiny delay. But that has no problems with 5ms pulses either. The debouncing could be totally disabled on the BLTouch, since it's not a physical swictch which needs it. That could sometimes be the differnce between detecting things one microstep too late or not, but in this case it doesn't matter.

[fredizzimo]

@danielkucera, Good point about the colors. The color should be blue when going down, and when the pin is a little bit pressed in after touching the bed, it should turn red and the movement stop. Mine activates after being pressed for I guess 1-2 mm.

I'm starting to run out of ideas here... So it would be good to run with the logic analzyer, I think that would answer a lot of questions. But remember to protect your bed, and be ready to run m112 for emergency stop.

[noud-github]

@KevinOConnor

tested work-bltouch-debug-20181211 it fixed the pin_down bug en works as expected,
also a z_tilt_addust goes well,

Bonus your code does't have the pin hit the bed after probing like fredizzimo's

[noud-github]

@fredizzimo

in your steps, the pin hitting the hotbed is between 4 and 5, I think it is because with pin_down the 3Dtouch will drop the pin almost imidialty after "sensing en going up"
and with touch_mode the pin will stay up.

[fredizzimo]

Interesting, that happens even on a genuine BLTouch,

If you run BLTOUCH_DEBUG COMMAND=pin_down and push the pin up, it triggers and re-deploys. It's like it was meant to be used for multi-probing. So you can leave it in that stage and do multiple probes without having to give additional commands.

Now, both Marlin and my code perform a pin up command immediately after we detect that the probe is triggered. On Marlin this seems to work, and for me with my BLTouch smart, it also seems to work reliably. I have never seen it fail yet.

However on your probe, I think Klipper is too slow to react to the signal, due to having to communicate to python, and back to C in order to perform the reset. There are also some minor calculations between.

I'm also fairly sure that this is what causes the missing detections as well. There's probably a race condition bug in the clone code. If we give the command too late, when the probe is already moving the pin down again, then it goes into an invalid state, where its confused if the pin is actually up or down.

After that, this is what most likely happened for @danielkucera, the pin was down just as it should have been, everything looking fine. The pin was activated, but in the wrong state, it moved up because of it's mechanical properties, then it was moved down automatically because of the behaviour I described above. This now turned the probe into the right state, and it detected the trigger. But this up down movement caused an additional delay of around a half second, which caused the head to crash.

The sollution seems to be quite simple, actually, and will preserve (at least almost) all the error handling present in my pull request. I just need to enable touch mode after I have moved the pin down, and then disable the touch mode again, to retain all the error checking. Note that touch mode is enabled after the pin moves down, which means that we get the correct error checking, that the pin is actually deployed correctly.

I will try out that here locally now, and then update my pull request if everything is fine

[KevinOConnor]

@danielkucera

Nevertheless, if I'm using work-bltouch-debug-20181211 with test_sensor_pin: False , it works fine except the need to quickly touch the probe to retract it after mesh probing (otherwise it would stay out and crash to my bed from side after printing the "purge" line)

Thanks. Is this still an issue with the latest work-bltouch-debug-20181211 code? (The code on that branch was recently changed to perform both a "reset" and "pin up" after each probe -see https://github.com/KevinOConnor/klipper/issues/955#issuecomment-447431354 .) It would be great if you could attach a klipper log file from a session with that branch.

@noud-github

tested work-bltouch-debug-20181211 it fixed the pin_down bug en works as expected,

Thanks.

-Kevin

[danielkucera]

@KevinOConnor ,
it's happening with this commit

commit 084e2309a688fccee1b751091c07fcc4cd355780 (HEAD -> work-bltouch-debug-20181211, origin/work-bltouch-debug-20181211)

yes, it's not the most recent, I'll update and report back.

[fredizzimo]

I updated my pull request with touch mode enabled. It retains all the error checking of the original pull request, and actually adds one more extra check, to ensure that the pin is actually down when starting probe.

However, it slows down the probing a little bit, due to more commands and checks.

But that's not the worst thing, the repeatability of my BLTouch got one order of magnitue worse. I now get errors as much as 40 microns, with a 1mm probing speed. So on genuine BLTouch devices, this is definitely not the way to go.

Still it's probably worth testing on the clones.

The best way to update to the latest version is probably to delete the branch, and re-create it.

sudo service klipper stop
git checkout master
git branch --delete fredizzimo_bltouch
git fetch origin pull/982/head:fredizzimo_bltouch
git checkout fredizzimo_bltouch
sudo service klipper start

[fredizzimo]

I verified by switching back to my old version, and the repeatbility got back to normal. Then I switched over to @KevinOConnor's branch. And the repeatability was all over the place again.

[fredizzimo]

I should probably do more than 5 samples to get good statistics, but here's what I got

with normal mode

Recv: // probe at 166.000,120.000 is z=-0.002500
Recv: // probe at 166.000,120.000 is z=-0.007500
Recv: // probe at 166.000,120.000 is z=-0.010000
Recv: // probe at 166.000,120.000 is z=-0.010000
Recv: // probe at 166.000,120.000 is z=0.002500


Sample Standard Deviation, s | 0.0054198708471697
-- | --
Variance (Sample Standard), s2 | 2.9375E-5
Population Standard Deviation, σ | 0.0048476798574163
Variance (Population Standard), σ2 | 2.35E-5
Total Numbers, N | 5
Sum: | -0.0275
Mean (Average): | -0.0055
Standard Error of the Mean (SEx̄): | 0.0024238399287082

Touch mode

Recv: // probe at 166.000,120.000 is z=-0.005000
Recv: // probe at 166.000,120.000 is z=-0.032500
Recv: // probe at 166.000,120.000 is z=-0.040000
Recv: // probe at 166.000,120.000 is z=-0.010000
Recv: // probe at 166.000,120.000 is z=-0.002500


Sample Standard Deviation, s | 0.01708434956327
-- | --
Variance (Sample Standard), s2 | 0.000291875
Population Standard Deviation, σ | 0.015280706789936
Variance (Population Standard), σ2 | 0.0002335
Total Numbers, N | 5
Sum: | -0.09
Mean (Average): | -0.018
Standard Error of the Mean (SEx̄): | 0.0076403533949681

I'm not entirely happy with the normal mode either, but it's still clearly within the promised 0.01 standard deviation

[fredizzimo]

The clonk-clonk mode, where you don't try to force the pin up at all, which makes it drop down again, seems to work, as long as you start moving the printhead up fast enough. That could be an option for the clones without modifying the C code.

But it does seem to have a little bit worse accuracy than when forcing the probe up

Recv: // probe at 166.000,120.000 is z=0.005000
Recv: // probe at 166.000,120.000 is z=-0.005000
Recv: // probe at 166.000,120.000 is z=-0.005000
Recv: // probe at 166.000,120.000 is z=-0.012500
Recv: // probe at 166.000,120.000 is z=-0.010000

Sample Standard Deviation, s | 0.010606601717798
-- | --
Variance (Sample Standard), s2 | 0.0001125
Population Standard Deviation, σ | 0.0094868329805051
Variance (Population Standard), σ2 | 9.0E-5
Total Numbers, N | 5
Sum: | -0.025
Mean (Average): | -0.005
Standard Error of the Mean (SEx̄): | 0.0047434164902526

These observations are consitent with what's been reported in this issue too https://github.com/MarlinFirmware/Marlin/issues/4855

[pipo1000]

I have a TriableLabs BLtouch and the standard code is not working for me. I have been testing all modes and when testing all modes, all modes give a 'open'. The only way to get a 'triggered' is to go to 'touch_mode' and move the pin up by hand like it is touching the heatbed.

When you pull the pin_up it is going to 'open' again. The pin_down mode is not working for sensing at all, as it will not give a good 'triggered' and the pin automatically drops again within a second when touching the heatbed and it will hit the heatbed. The touch_mode keeps the pin up for about 10 seconds when it has touch the heatbed. Enough time to pin_up and touch_mode again. An extra pin_up as in most example scripts on the internet makes the sensing less reliable, with only a pin_up and touch_mode all works 100% for me. I also needed to not invert the probe pin.

This is my config which works 100% perfect with my BLtouch on a ANet AM8 ;

[servo bltouch]
pin: PA4
maximum_servo_angle: 180
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024


# SET_SERVO SERVO=bltouch ANGLE=x
# 10 = push pin down
# 60 = endstop test mode
# 90 = pull pin up
# 120 = self test (pin up & down)
# 160 = release alarm / reset

# probe using the BLTouch
[probe]
pin: ^PC4
speed: 5.0
x_offset: -37
y_offset: 0
; higher number means closer to bed
z_offset: 1.15
activate_gcode:
    G4 P200
    SET_SERVO SERVO=bltouch ANGLE=60
    G4 P400
deactivate_gcode:
    G4 P200
    SET_SERVO SERVO=bltouch ANGLE=90
    G4 P400

[fredizzimo]

I think there's finally success, thanks to the testing we did with the help of @danielkucera.

It turns out, that both my and @KevinOConnor's code forget to turn off the PWM signal to the probe. So it will continously send the last command. His code does it in most places, but not all, and I didn't do that at all, since I thought that it was already done automatically. This in itself is probably not as bad as the fact that the following command could start anywhere inside that pulse, and send the completely wrong thing.

Now this is fixed, and my branch seems to be running fine with normal mode on both my BLTouch Smart, and @danielkucera's clone probe.

Now this needs testing with different types of clones and different configurations. You can test it the following way

sudo service klipper stop
git fetch origin pull/982/head:fredizzimo_bltouch_pwm_fix
git checkout fredizzimo_bltouch_pwm_fix
sudo service klipper start

And to return back to the master branch for example

sudo service klipper stop
git checkout master
sudo service klipper start

[danielkucera]

I can confirm, @fredizzimo's version now works perfectly, without any bed hitting and seems much more accurate.

[arminth]

I will test tomorrow morning. Today I did a clean Marlin 1.1.9 to verify the triangle labs is working at all. And it worked.
So more tomorrow! Thanks guys, you're the best!

[noud-github]

@fredizzimo just tested pull/982/head:fredizzimo_bltouch.
works perfectly, repatabilty is the same as with the code from @KevinOConnor

Recv: // probe at 90.000,110.000 is z=0.997500
[...]
Recv: // probe at 90.000,110.000 is z=0.985000
Recv: // probe at 90.000,110.000 is z=0.995000
[...]
Recv: // probe at 90.000,110.000 is z=0.992500
Recv: // probe at 90.000,110.000 is z=1.022500
Recv: ok

[fredizzimo]

After adjusting the leveling screws, I just mapped out my Ender-3 bed with 4,4 probes, 2,2 pps, and bicubic interpolation.

It looks quite believable, because the surface is clipped with 3 clips on the x axis, and I can visually see that it's not really that clamped down in the middle of the y axis.

[arminth]

Just returned from a christmasparty of my Tabletennsis-club. Couldn't leave my hands off and tested! :-)

First, I ran into the issue of a git-error.
@fredizzimo

shouldn't

git fetch origin pull/982/head:fredizzimo_bltouch

be correctly

git fetch origin pull/982/head:fredizzimo_bltouch_pwm_fix

?
Or should it be

git checkout fredizzimo_bltouch
instead of

git checkout fredizzimo_bltouch_pwm_fix
?

I did the first version.

Probing now works like a champ! No dropping pin anymore!

[grizzlybearrr]

Hello. I use bltouch clone on Ender3. And use console commands for test. (https://github.com/KevinOConnor/klipper/issues/955)
My results( probe not fix after trigger ):
Send: QUERY_PROBE
Recv: // probe: open
My log:
klippy.log

[fredizzimo]

@arminth, yes, you are right, I will fix that in my instructions. I used a different branch name than my previous instructions, so that people would be guaranteed to have the right version, but forgot to change both commands.

@grizzlybearrr, QUERY_PROBE from the terminal will still always return open on some clones, when you move it using commands, even when touch_mode is enabled.

But the G28 command, and all the probe related commands will still work, since they listen for the very short 5-10ms long signal.

[grizzlybearrr]

@fredizzimo i test branch 'fredizzimo_bltouch_pwm_fix'. G28 command correctly works!
Other probe related commands(i try to use bed visualizer):

Recv: // Unknown command:"M155"
Recv: // Unknown command:"G29"

[fredizzimo]

@grizzlybearrr. Klipper does not have those commands mapped directly. You could use these commands instead https://github.com/KevinOConnor/klipper/blob/master/docs/G-Codes.md#mesh-bed-leveling

If you want, you can also create macros that calls those, so that you can continue to use the familiar G29 command.

[kennethpangky]

I have a TriableLabs BLtouch and the standard code is not working for me. I have been testing all modes and when testing all modes, all modes give a 'open'. The only way to get a 'triggered' is to go to 'touch_mode' and move the pin up by hand like it is touching the heatbed.

When you pull the pin_up it is going to 'open' again. The pin_down mode is not working for sensing at all, as it will not give a good 'triggered' and the pin automatically drops again within a second when touching the heatbed and it will hit the heatbed. The touch_mode keeps the pin up for about 10 seconds when it has touch the heatbed. Enough time to pin_up and touch_mode again. An extra pin_up as in most example scripts on the internet makes the sensing less reliable, with only a pin_up and touch_mode all works 100% for me. I also needed to not invert the probe pin.

This is my config which works 100% perfect with my BLtouch on a ANet AM8 ;

[servo bltouch]
pin: PA4
maximum_servo_angle: 180
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024


# SET_SERVO SERVO=bltouch ANGLE=x
# 10 = push pin down
# 60 = endstop test mode
# 90 = pull pin up
# 120 = self test (pin up & down)
# 160 = release alarm / reset

# probe using the BLTouch
[probe]
pin: ^PC4
speed: 5.0
x_offset: -37
y_offset: 0
; higher number means closer to bed
z_offset: 1.15
activate_gcode:
    G4 P200
    SET_SERVO SERVO=bltouch ANGLE=60
    G4 P400
deactivate_gcode:
    G4 P200
    SET_SERVO SERVO=bltouch ANGLE=90
    G4 P400

Thank you so much. Your code made my TL Touch past the sensor error issue. Much appreciated.

[xsasx]

I see here muuuuuuch experts WOW ! But im really confused now !

I have a BLtouch from TriangleLab mounted it on my A8 with this https://www.thingiverse.com/thing:2773637

I cabled it correct and updated my klipper with original branch.

Now I stuck- didnt know how to start , where to messure and what to implement in config.

Could anyone so kind and advice me little bit what to do ? The very good marlin manuals and how tos seems not to bring me any step further :(

[danielkucera]

With commit 7997f85bd5bdd3ff9721c7824eff5e446cea522a (HEAD -> work-bltouch-debug-20181211, origin/work-bltouch-debug-20181211) it still hits the bed sometimes, probably because the PWM is not disabled when approaching bed. @KevinOConnor ?

[KevinOConnor]

@danielkucera - I don't see how PWM timing would result in a bed crash. The log would certainly give lots of information though - if you've encountered a problem like that, try to issue an M112 quickly, and then attach the klipper log file - see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[danielkucera]

@KevinOConnor if the probe is constantly getting commands it might get interrupted right at the moment of touching bed thus delaying or completely skipping the Z endstop signal

[fredizzimo]

@KevinOConnor, since your version

1. Still has bugs
2. Forces you too disable all error handling on clones
3. Lacks proper error handling even on genuine BLTouch
4. Has much worse accuracy, but perhaps not on all clones
5. Does not ensure that the probe is retracted when the printer starts

I highly suggest that we use my version instead.

I can work it into a usable pull request, if you or someone else can explain to me how the exception handling in Klipper is supposed to work, see my last comment here https://github.com/KevinOConnor/klipper/pull/982. More specifically, I don't think I should have to modify all gcode commands that has anything to do with probing, in order to get a proper error message. And to me it seems like the common path is, exactly where I added the handling in first place.

[danielkucera]

regarding accuracy, let's talk about hard data (5 measurements are not statistically significant).
I've created a script to count this for me: https://gist.github.com/danielkucera/04dccd8e0a78df31f49c4ed1da034511

results with fredizzimo_bltouch_pwm_fix:

[0.7425, 0.7475, 0.7875, 0.7525, 0.785, 0.7725, 0.745, 0.76, 0.7475, 0.7975, 0.7925, 0.79, 0.7825, 0.75, 0.78, 0.79, 0.8025, 0.73, 0.78, 0.7925, 0.8075, 0.79, 0.7875, 0.795, 0.79, 0.7875, 0.7825, 0.7475, 0.7975, 0.795, 0.805, 0.775, 0.7725, 0.7875, 0.78, 0.77, 0.75, 0.76, 0.79, 0.805, 0.79, 0.7875, 0.7925, 0.77, 0.7975, 0.79, 0.7875, 0.78, 0.785, 0.8075, 0.7875, 0.8075, 0.7875, 0.785, 0.7975, 0.755, 0.805, 0.7825, 0.8025, 0.805, 0.7825, 0.785, 0.8025, 0.79, 0.7925, 0.785, 0.75, 0.78, 0.775, 0.7825, 0.7875, 0.8025, 0.8025, 0.785, 0.79, 0.785, 0.7975, 0.78, 0.8125, 0.7925, 0.795, 0.79, 0.79, 0.7925, 0.7925, 0.785, 0.79, 0.7375, 0.79, 0.7875, 0.8125, 0.7925, 0.8025, 0.7575, 0.7925, 0.785, 0.79, 0.765, 0.8025]
stdev: 0.0177170187693

[0.7625, 0.765, 0.7575, 0.7625, 0.755, 0.7875, 0.7725, 0.7725, 0.765, 0.7725, 0.79, 0.775, 0.7625, 0.7275, 0.765, 0.785, 0.76, 0.7575, 0.785, 0.7725, 0.77, 0.7875, 0.77, 0.7625, 0.775, 0.7775, 0.7125, 0.7275, 0.7175, 0.75, 0.775, 0.745, 0.76, 0.77, 0.75, 0.73, 0.745, 0.7825, 0.77, 0.76, 0.7625, 0.755, 0.7625, 0.785, 0.73, 0.7375, 0.78, 0.76, 0.7675, 0.7525, 0.75, 0.76, 0.7575, 0.73, 0.7675, 0.795, 0.7625, 0.7825, 0.7575, 0.78, 0.765, 0.76, 0.7625, 0.7625, 0.7375, 0.76, 0.7775, 0.77, 0.7725, 0.76, 0.7875, 0.77, 0.7725, 0.7875, 0.7825, 0.7675, 0.76, 0.77, 0.7525, 0.7875, 0.7725, 0.765, 0.77, 0.7675, 0.7675, 0.7875, 0.7725, 0.775, 0.7675, 0.77, 0.81, 0.7725, 0.775, 0.775, 0.7675, 0.7625, 0.8, 0.76, 0.77]
stdev: 0.0167794191628

[0.745, 0.73, 0.7525, 0.725, 0.745, 0.745, 0.745, 0.745, 0.7525, 0.7425, 0.75, 0.73, 0.71, 0.77, 0.7525, 0.735, 0.7375, 0.735, 0.7475, 0.7325, 0.7425, 0.735, 0.7275, 0.755, 0.7375, 0.755, 0.7325, 0.7725, 0.75, 0.7375, 0.7425, 0.7275, 0.72, 0.72, 0.705, 0.7475, 0.73, 0.7225, 0.725, 0.7525, 0.75, 0.72, 0.755, 0.68, 0.725, 0.7475, 0.7325, 0.7475, 0.74, 0.7275, 0.7425, 0.75, 0.7475, 0.725, 0.765, 0.7475, 0.75, 0.75, 0.7425, 0.7425, 0.75, 0.745, 0.7325, 0.75, 0.745, 0.75, 0.7475, 0.7475, 0.7425, 0.7475, 0.74, 0.7475, 0.695, 0.705, 0.7475, 0.735, 0.7425, 0.7475, 0.7475, 0.725, 0.7325, 0.7325, 0.7525, 0.7475, 0.745, 0.7525, 0.7425, 0.735, 0.7425, 0.745, 0.735, 0.75, 0.74, 0.74, 0.7125, 0.71, 0.7425, 0.7275, 0.735]
stdev: 0.0146028118877

results with work-bltouch-debug-20181211 (I had to trash two measurements because the head hit the bed):

[0.7025, 0.7625, 0.735, 0.72, 0.7325, 0.7375, 0.7325, 0.755, 0.715, 0.735, 0.72, 0.69, 0.72, 0.7075, 0.72, 0.7225, 0.7025, 0.71, 0.715, 0.6875, 0.71, 0.74, 0.7125, 0.7275, 0.7125, 0.7125, 0.7275, 0.7225, 0.7125, 0.705, 0.75, 0.7225, 0.7425, 0.7325, 0.7375, 0.705, 0.7425, 0.7225, 0.7275, 0.7675, 0.7125, 0.7, 0.7075, 0.7275, 0.7025, 0.7275, 0.6975, 0.69, 0.7375, 0.7375, 0.7, 0.725, 0.7375, 0.7275, 0.7525, 0.7275, 0.7375, 0.7475, 0.705, 0.7425, 0.7375, 0.725, 0.7525, 0.73, 0.7575, 0.73, 0.6825, 0.7375, 0.75, 0.74, 0.7375, 0.74, 0.6975, 0.7, 0.7025, 0.7325, 0.74, 0.77, 0.7075, 0.725, 0.72, 0.73, 0.735, 0.7375, 0.7075, 0.755, 0.705, 0.73, 0.73, 0.735, 0.76, 0.715, 0.745, 0.72, 0.745, 0.735, 0.7275, 0.735, 0.735]
stdev: 0.0184417299242

[0.7225, 0.73, 0.7525, 0.695, 0.7225, 0.725, 0.75, 0.76, 0.72, 0.7675, 0.72, 0.7225, 0.7575, 0.725, 0.75, 0.7225, 0.7275, 0.75, 0.705, 0.7275, 0.7225, 0.7025, 0.7525, 0.76, 0.76, 0.76, 0.7325, 0.7625, 0.7525, 0.75, 0.7375, 0.7325, 0.745, 0.72, 0.755, 0.765, 0.72, 0.75, 0.755, 0.755, 0.7575, 0.755, 0.7025, 0.705, 0.75, 0.7575, 0.74, 0.74, 0.755, 0.73, 0.7525, 0.7775, 0.7575, 0.7625, 0.7275, 0.7475, 0.73, 0.7475, 0.75, 0.7525, 0.7675, 0.7625, 0.7375, 0.73, 0.7375, 0.74, 0.7325, 0.755, 0.76, 0.7525, 0.76, 0.75, 0.72, 0.7575, 0.7575, 0.75, 0.7725, 0.7475, 0.7625, 0.7475, 0.7675, 0.7575, 0.755, 0.76, 0.7475, 0.75, 0.7625, 0.7575, 0.76, 0.7675, 0.7725, 0.76, 0.7525, 0.7475, 0.74, 0.745, 0.7525, 0.75, 0.775]
stdev: 0.017625591098

[0.7225, 0.725, 0.74, 0.735, 0.74, 0.7125, 0.7325, 0.7175, 0.745, 0.745, 0.7375, 0.73, 0.74, 0.7175, 0.7325, 0.715, 0.6825, 0.735, 0.6975, 0.74, 0.69, 0.69, 0.69, 0.71, 0.73, 0.7325, 0.69, 0.73, 0.71, 0.7175, 0.7375, 0.725, 0.7125, 0.7325, 0.7225, 0.72, 0.7325, 0.7125, 0.715, 0.7325, 0.7525, 0.71, 0.7225, 0.6975, 0.6875, 0.715, 0.6875, 0.7325, 0.725, 0.7325, 0.7, 0.6975, 0.7125, 0.7075, 0.7225, 0.68, 0.685, 0.6975, 0.755, 0.725, 0.705, 0.7275, 0.7275, 0.74, 0.695, 0.7275, 0.6725, 0.7325, 0.7225, 0.7225, 0.7125, 0.7425, 0.73, 0.73, 0.6875, 0.69, 0.7325, 0.7425, 0.7425, 0.7325, 0.7075, 0.6925, 0.7425, 0.73, 0.6875, 0.7375, 0.7025, 0.7375, 0.71, 0.7325, 0.7675, 0.7375, 0.715, 0.71, 0.7275, 0.715, 0.74, 0.745, 0.74]
stdev: 0.0193867935293

[fredizzimo]

Well, I know that 5 samples is not enough, but if you look at my results with a BLTouch smart, the results are way different. I have done a lot of probing, other than those that I have posted here, but never seen anything remotely close to the 40 and 32 micron differences, I immediately saw with the touch mode.

Edit 1: Unfortunately for people with clones, it looks like my probe is almost as accurate in touch mode as yours is in normal mode, but my results gets much, much better when switching over to normal mode

Edit 2, it's possible the the outliers in my reports are caused by the PWM bugs, because the rest of the values looks reasonable close to zero. So on a genuine BLTouch the bug just causes the probe to move too far, rather than not stopping at all and hitting the bed.

[KevinOConnor]

@KevinOConnor if the probe is constantly getting commands it might get interrupted right at the moment of touching bed thus delaying or completely skipping the Z endstop signal

I don't think this was ever a problem on the master or work-bltouch branches. The code is careful to disable the pwm between probes. The only command sent without synchronization is the "reset" command and I don't see an issue with that (it occurs only after the head stops moving, and any error resulting from an out of sync reset should immediately be cleared by the reset). That said, I don't see any issue with changing the code to eliminating this "reset" race post release.

-Kevin

[KevinOConnor]

@fredizzimo

I highly suggest that we use my version instead.

My focus at this point is on addressing any regressions and then to make the upcoming Klipper v0.7.0 release. I feel changing to your code raises too high of a risk of regressions. You've stated this desire to move to your code multiple times; you've fixed multiple regressions since originally stating it. Last I looked at your code, I saw what I believe are regressions (eg, incorrect change to gcode.py, removal of the trigger high test to verify signal pin wiring, use of wait_moves() instead of the more precise event timing).

I feel I'm repeating myself and I don't feel that is a productive use of my time. I understand you don't agree with me, please take a moment to understand and respect what I am saying.

-Kevin

[danielkucera]

@KevinOConnor , why there is no send_cmd(..., None) after here:
https://github.com/KevinOConnor/klipper/blob/work-bltouch-debug-20181211/klippy/extras/bltouch.py#L100
?

[KevinOConnor]

@KevinOConnor , why there is no send_cmd(..., None) after here:
https://github.com/KevinOConnor/klipper/blob/work-bltouch-debug-20181211/klippy/extras/bltouch.py#L100
?

That is the "reset" case I mentioned above. The next thing invoked after home_prepare() is home_finalize() (which is called after the head stops) and the first command home_finalize() invokes is "reset".

-Kevin

[danielkucera]

The only command sent without synchronization is the "reset"

but I see this is "touch_mode"... Am I missing something?

[KevinOConnor]

but I see this is "touch_mode"... Am I missing something?

The race (as I understand it) is a new pwm command that is scheduled in the middle of the transmission of the previous command. The "touch_mode" command should be sent synchronized so there is no race on its initial transmission. There is a possibility that the following "reset" could be transmitted while in the middle of a retransmit of the previous "touch_mode" command, but this would only occur after the head has stopped moving (and ideally the reset itself would clear any error introduced).

If I've missed something, please let me know.

-Kevin

[danielkucera]

I'm not talking about race condition. My concern is that the probe's mcu is loaded by permanently receiving new commands and might miss a response from the hall sensor.

[KevinOConnor]

I'm not talking about race condition. My concern is that the probe's mcu is loaded by permanently receiving new commands and might miss a response from the hall sensor.

Okay, I understand. The bltouch docs all recommend configuring it as a "servo" which would normally get a command repeat every 20ms. So, it seems odd that getting a repeat of the same command would cause it problems (as that should be the norm). What leads you to believe command repeats could be an issue?

If you disable the command repeats, does the variability of the measurements improve (the change below would disable repeats)?

-Kevin

--- a/klippy/extras/bltouch.py
+++ b/klippy/extras/bltouch.py
@@ -92,7 +92,8 @@ class BLTouchEndstopWrapper:
         print_time = toolhead.get_last_move_time()
         self.send_cmd(print_time, 'pin_down')
         self.send_cmd(print_time + self.pin_move_time, 'touch_mode')
-        toolhead.dwell(self.pin_move_time + MIN_CMD_TIME)
+        self.send_cmd(print_time + self.pin_move_time + MIN_CMD_TIME, None)
+        toolhead.dwell(self.pin_move_time + 2*MIN_CMD_TIME)
         self.mcu_endstop.home_prepare()
     def home_finalize(self):
         toolhead = self.printer.lookup_object('toolhead')

[fredizzimo]

@KevinOConnor,

First of all, your code is one week older than mine, that's hardly a comparison between well functional old code and brand new functionality. Especially since this issue was opened two days after that, and so far you haven't got it successfully to work on clone probes in practice.

you've fixed multiple regressions since originally stating it

I have not fixed multiple bugs, since I submitted the pull request, the only bug that I have fixed is the pwm bug. I did attempts with the touch mode between, but I have since then reverted all those. BTW, regression is the wrong term to use here, since it was never working correctly to begin with.

Furthermore, my code has always worked correctly on my genuine probe. Finally one of the reason why the bug took so long to fix, was because I tried to help you finding out what's wrong with the touch mode, instead of concentrating on my code.

incorrect change to gcode.py

You have still not explained to me how we are supposed to use exceptions in Klipper. I raise mcu.error, when I detect an unrecoverably hardware error with the probe. This error can be detected both when running gcode and when running other code. For example it can be raised when running G28, it can be raised when running PROBE, it can be raised when running BED_MESH_CALIBRATE, but also when starting the printer, during the connect callback.

The connect handling does not catch gcode.error, but does handle mcu.error. The main gcode process_command function does not handle mcu.error and neither does any function between. So at this point I'm left with four options:

1. Modify the _connect function in klippy.py to handle gcode.error and raise that instead. That doesn't sound right, since we are not running any gcode at this time
2. Modify process_command to handle mcu.error sounds right to me
3. Raise gcode.error if we are running a gcode command (how on earth am I going to know that?), and mcu.error otherwise. In addition to being completely against good software principles of always raising the same type of exception for the same type of error, it doesn't sound right to raise a gcode error for hardware related things. To me it sounds like gcode errors should be reserved for parsing errors, or otherwise invalid parameters, which isn't the case here. But then again, I don't think the exceptions are documented anywhere, so my intuition could be wrong.
4. Raise mcu.error like before, but expect it in G28, PROBE, MESH_BED_CALIBRATE, DELTA_CALIBRATE, Z_TILT_ADJUST and ENDSTOP_PHASE_CALIBRATE (I might have missed some). This is clearly not extensible at all, and if we add new commands in the future that could indirectly use the BLTouch, we need to remember to add it there.

, use of wait_moves

I kind of agree with this. But during my testing, I saw one case where the state of the endstop was reported wrongly with the state that it had before my intended time to check it. That could have been my mistake, especially since I didn't understand exactly how the endstop query functions worked. Hower in any case, we do have to wait for all movements to definitely stop, before trying to verify any endstop state. I can easily change the code to not have the dwell commands, provided that scheduling an endstop query at a future time, only reads the state from that point forward, and nothing before that.

removal of the trigger high test to verify signal pin wiring

With this one you are completely, wrong!
Here are the cases where your code handles things wrong, but mine works:

1. If the wiring is wrong, a genuine BLTouch smart will always report high https://www.antclabs.com/wiring. Therefore your test will pass without any issues, and the homing operation will start and immediately complete. Probably resulting in a z-offset far up in the air.
2. If you disconnect the z-stop cable, and have a pull up resistor enabled, like you are supposed to (many mainboards have this hardwired). Then again, your code sees that as a successful tests, and homes in the air.
3. If you start the homing operation too close to the bed. The BLTouch will trigger an error because it was unable to move the pin down completely. Your code sees this as a successful test, starts the homing operation, but this time way too far down, resulting in the nozzle hitting the bed when you set the z_offset correctly.
4. If the pin is stuck for some reason, your test will immediately pass. Again this results with wrong detection of the z_offset

In the first two cases, my code will detect the fatal hardware error, shut down the printer, using the exception, I explained above

In the 3rd case, the operation will fail, and you get a message telling you that the probe is most likely too close to the bed

The 4th case is handled roughly the same way as the third, but if the pin is really stuck, and it can't be pulled up either, it will detect it as a fatal hardware error.

Please don't claim false things, especially since you don't own a probe yourself!

[danielkucera]

@KevinOConnor I can confirm no more hitting bed with that change applied (300+ tries)

[danielkucera]

@KevinOConnor another issue here: I pulled out Z axis cable from the probe and tried homing. The head moved! If the pin was out, I could hit my bed from side when centering.

I was not able to do this with @fredizzimo 's branch, he's returning: Error: The BLTouch probe is malfunctioning

[fredizzimo]

It looks like this code

if probe_pos:
    raise EndstopError("Probe triggered prior to movement")
raise EndstopError("Endstop %s still triggered after retract" % (name,))

Saves you from running badly into problems 1-2. However that is only done for the second probe, so if you are homing with a single probe, you would still run into them.

[fredizzimo]

I wasn’t imagining about the need to wait for moves, or otherwise wait, before querying the endstops

    def query_endstop(self, print_time):
        self._homing = False
        self._min_query_time = self._next_query_time = self._mcu.monotonic()
    def query_endstop_wait(self):
        eventtime = self._mcu.monotonic()
        while self._check_busy(eventtime):
            eventtime = self._mcu.pause(eventtime + 0.1)

        return self._last_state.get('pin', self._invert) ^ self._invert

print_time is completely ignored there

[arminth]

Also crushed into bed again yesterday. Had switched back to my capacitive probe and closed the lid of my mb-box. Didn't pay attention and ripped out z-stop switch from the connector.
It homes to ground zero (for God sake I was in the cellar already! :D).
I didn't expect it to do so, as I still remember getting homing errors when not connected. But I got lost in all the versions...

[fredizzimo]

@arminth, Check that you have pull up resistors enabled on all your endstop pins. Some printer boards have a hardware pull-up resistor enabled, but it should not harm to enable it on those too.

The reason, why it should be be enabled for both normal endstops and for BLTouch, is simple, we use normally connected switches, which means that the signal is connected to ground, when you have the endstop or BLTouch properly connected connected, and therefore it reads zero. Hower if you disconnect the cable, or activate the switch, the circuit is open and it should read one, thanks to the pull up resistor. In other words, activating the switch and pulling the cable out is the exact same thing.

So if you have a properly configured pull up resistor it should always trigger immediately, and therefore not crash into the bed. That should be the case with both my code and @KevinOConnor's code. The difference is how the errors are detected.

NOTE: Some printer boards might connect a positive signal to the endstop, but those are not compatible with BLTouch anyway.

I have never studied how capacitive probes works, but if they require the pull up resistor to be disabled, then there could be a problem.

[fredizzimo]

It still keeps bothering me that @KevinOConnor, who has made this highly complicated firmware almost all by himself, is in the belief that his high pin check test_sensor, which has to be disabled on some clones, does anything useful at all (he called this a regression "removal of the trigger high test to verify signal pin wiring").

It does the following (Check the code yourself to verify https://github.com/KevinOConnor/klipper/blob/master/klippy/extras/bltouch.py#L62)

1. Calls reset
2. Enables touch mode
3. Waits for the endstop to return high, and pass the check if it does. Otherwise fails the test with "BLTouch sensor test failed"

The endstop returns high in the following situations

1. The pin is up and the touch mode is on
2. Very briefely for 10 ms after touching the bed in normal mode
3. The probe detects an error, which includes the following
   
   
   
   1. The probe failed the initial self-test
   
   
   2. The pin failed to move to the commanded position within around a second
   
   
   3. The BLTouch smart detects a wiring error
   
   
4. The endstop cable is disconnected, as explained in the above message
5. The probe control cable is disconnected (it doesn't get any power, and therefore acts as an open circuit

So essentially what his check does is the following:
Check if the touch mode is enabled and the pin is attracted, or any errors were reported. Which is just as good as saying, ok we might have an error, let's continue probing

His test fails and reports an error in the following situations:

1. The probe is fully functional, but the pin happens to be down when the printer starts (the reset call does not move the probe up)
2. The probe does not handle touch mode according to the specifications (like most of the clones)
3. The signal pin is disconnected and the probe does not have built in wiring detection

Only number 3. of those is important, but it can only be enabled on genuine BLTouch classic probes, which as far as I understand lacks the wiring check of the smart ones (the smart ones gives an error in this case, and therfore pass his check), but it's possible that even those have it and the difference between the smart and classic is something else. It can also possibly be enabled on 3D Touch clones, which might respond to the touch mode correctly, and possibly does not implement the wire checking.

Numer 1. Could be important, but unfortunately this check is done only after doing the initial movement, and we are going to put the pin down anyway. So it doesn't prevent the pin from being destroyed due to sideways movement and it's just an annoyance to the user to manually have to push the pin to get it working again. Also, the error message does not even give a hint that it might be the problem.

Am I missing something here? I would like to hear someone else's opinion too, not just @KevinOConnor's.

[kennethpangky]

Looks like someone's pushing his agenda a bit too hard. Step back, give it a rest.

[arminth]

Why should he, if he is having a valid argument?

As long as things are discussed like grown ups do it...

@fredizzimo
I am using pin: ^!ar12
That should be pullup enabled.

Strange... Maybe, I will test it again...
Cheers
Armin

[fredizzimo]

@kennethpangky
That's fine, I'm perfectly OK, with continuing using my own branch.

I thought other people were interested in having their BLTouch (genuine or fake) work as well as it could, with as much error checking as it can, but apparently I'm wrong. That's why I have been pushing this.

I have been trying to explain the same things countless times, but there's still a very deep technical disagreement between me and @KevinOConnor. My last message was a desperate attempt to get someone else's view on the matter, and to explain it in as simple terms I could, because otherwise you are all going to silently accept Kevin's view and things will stay the same. He might be right, and I'm going to accept that, if he or someone else can give a proof about the matter. If no one comments, I'm going to close my pull request and keep on improving Klipper for my own needs in my own branch.

[fredizzimo]

@arminth,

That's pull up resistor with inversion enabled, so it will unfortunately do exactly the opposite. If you remve the !, then only the pull up resistor should be enabled.

If the capacitive probe needs that, then there can be a problem...

[arminth]

The probe is NO. So I am pulling the Z-Offset to ground. If I wanted to inverse the logic, I would need an extra 5V line on my circuit (which could be done) and a pull down resistor.
I had uploaded my solution on Thingiverse.

At least, that's how it works atm.

[fredizzimo]

Ah, yes. I guess you either have to be careful with the cables, or change the hardware, so that it acts as a NC switch. It's not really possible to see the difference between a disconnected cable, and an untriggered NO switch from the firmware side, since both are essentially the same open circuit.

[noud-github]

@fredizzimo ,

Testing your code, runs fine, the pin movement look snoother than the kevin code. unlike before the PWM update

[KevinOConnor]

I am aware of the following issues with the current bltouch.py module:

1. touch_mode is not as accurate as pin_down mode on some hardware
2. sending repeat touch_mode commands during probing causes bad behaviour on some clones
3. the code should issue a pin_up on startup
4. it would be useful for the code to verify that pin_up succeeds (for hardware that can verify it)
5. the current sensor test code does not work as intended on "probe:z_virtual_endstop" with "homing_retract_dist=0"

I think this github issue has taken too many "twists and turns" to be productive. If you feel there are issues not identified, please open a new github issue, describe the issue anew, and be sure to attach a klipper log file from the event. See: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[fredizzimo]

Just for the information, my pull request takes care of all those cases, yes 4. is handled even on clones, as long as you set pin_move_time high enough. I recommend at least 1 second, on a genuine BLTouch Smart.

In addition, it handles the following issues, which are issues with the current module:

1. need to verify that the pin goes down before starting to probe, otherwise, even if it would immediately trigger with touch_mode, the detected offset will be wrong. Currently it's only partially handled, by the verify_movement code in homing.py. But that code is disabled if you have homing_retract_dist disabled. In addition to that it's only done for the second attempt to probe
2. Need to detect that the endstop or signal cable is disconnected. This is also only partially handled by the verify_movement code

There's also a likely issue with both versions. Yesterday, I had a nozzle crash during normal usage, after hundreds of successful probes when testing my code. It also slightly damaged my bed, since the nozzle was hot. I don't have much information right now, because the logs didn't contain the command history, I shut down the printer with the power switch. But as far as I can see, it happened just as the nozzle had heated up completely, when starting the probe around midway through a mesh bed leveling. I don't know if that's a coincidence or not.

Anyway, so far my investigation tells me that this type of code

print_time = toolhead.get_last_move_time()
self.send_cmd(print_time, cmd)
self.send_cmd(print_time + MIN_CMD_TIME, None)

Is not guaranteed to actually send the cmd, even if it logically should send it 4 times (MIN_CMD_TIME) is four cycles). In my case it looked like it had completely ignored the pin_down command(I know that I stated that I verify this case above, and I do, as long as the command is actually going through). The problem seems to be here https://github.com/KevinOConnor/klipper/blob/06ef60011e548f9734a83244f1038e90f353c50d/src/gpiocmds.c#L170

That blindly uses the end_time, which as far as I can see, comes directly from the print_time parameter, without further patching. The problem is that if we are lagging behind, for example the OS decides to schedule some other tasks, between getting the print time and actually sending the command, it could be in the past. There are some validations for this when adding timers, but the code never adds a timer, it just updates the timing of an existing one. So far I haven't seen anything that would catch the time in past there. Also, note that, in addition to completely ignoring the command, the initial pulse could be too short, and potentially cause a completely different command to be triggered.

I have also not verified this experimentally yet, which should be quite easy by adding an artificial delay in the Python code. Attaching a logical analyzer would also be helpful.

The PWM code on the C side also has another potential issue. If you change the PWM delay, it doesn't wait until the whole cycle is completed, it can schedule it in the middle of the cycle just as well, which would cause a too long pulse to be generated. That can be seen here for example:
https://github.com/KevinOConnor/klipper/blob/06ef60011e548f9734a83244f1038e90f353c50d/src/gpiocmds.c#L141

There are no checks that the previous state was off, so it's entirely possible that we get two on pulses in a row. With careful timing of commands, or if you have the pwm disabled for long enough, that shouldn't be a huge problem. However, if my observation about the wake_time is above is correct, then we can no longer schedule the PWM timing precisely from the Python side, unless we always make sure to schedule it enough in the future, to guarantee that it's processed correctly on the firmware side.

As I said, I can be totally wrong on this one (my investigation is still in the middle), all I know is that this happened, and that seems like the most plausible explanation at this point. I know for fact from the logs that the pin was commanded down, and I also know for fact, that if the pin is obstructed the probe will go into an error state. Neither of the two happened in my case. @KevinOConnor's code is probably slightly more resistant, since it repeats the pin_down command for pin_move_time, instead of MIN_CMD_TIME

Another potential cause could be EMI. There have been reports about BLTouch being very sensitive to EMI. In fact, in Marlin, they turn off the heaters when probing to avoid issues. So that's a potential problem as well. However it has mostly been seen as slightly reduced accuracy.

Finally, the short 5-10ms pulse could have got undetected. I can not for sure confirm that the pin was up all the time, because I didn't watch the printer. However BLTouch actually has a built-in protection for that. Remember, the automatic re-deployment? When it touches, the probe automatically re-deploys, and if we move further down before it hits again, the probe will go into an error state, since it could not fully extend the pin. Because the error stage is the state as triggered, it should be detected. And even if the error detection fails, it should immediately re-trigger.

[jesperldk]

I switched to fredizzimo_bltouch_pwm_fix, and now my bltouch clone works great!

Thank you to Kevin for Klipper and to Fred for this fix 👍

UPDATE after some frustrating hours:
well, it works nice enough, but the measures are all over the board; sometimes 4 measures can differ 0.2mm :-( I have tried varying the parameters, but it does not seem to help.
I have given up on my clone and have ordered a real BL touch. Will probably shift back to 0.7 when I get it in a few days.

[jakep82]

well, it works nice enough, but the measures are all over the board; sometimes 4 measures can differ 0.2mm :-( I have tried varying the parameters, but it does not seem to help.
I have given up on my clone and have ordered a real BL touch. Will probably shift back to 0.7 when I get it in a few days.

Unfortunately I've seen the same thing reported in many places by other people, even when running Marlin. Many of the clones are very poor copies, and they simply aren't accurate enough to use as a precision endstop.

[noud-github]

I have 3 3dtouch clones they look exect the same but 2 work more or less relayable 0.08 the other one is with 0.3 totaly use less. just ordered a original bltouch.
while testing with the off one, looked like the realy off values started after about 10 or more minutes after a fresh start it always worked oke @jesperldk is yours off from the start or after some time.

[fredizzimo]

While it's probably true that most clones have worse accuracy than genuine ones, 0.2mm sounds way off, and would indeed make the probe completely useless.

There has been reports that touching the probe, making it greasy can make it really inaccurate https://www.reddit.com/r/3Dprinting/comments/6kch74/the_bltouch_pin_no_touchie/. So maybe you can try to clean it up. That's something I only read very recently, and knowing this I would probably not even have bought the original one.

At the moment, I'm happy with my genuine BLTouch Smart one, but I don't know for how long, so I have been looking at something like this https://www.thingiverse.com/thing:2841443, this https://www.thingiverse.com/thing:2769816, or this https://www.thingiverse.com/thing:3303618. They are all basically the same idea, but slightly different implementaiton.

[fredizzimo]

I have looked more into the nozzle crash that I reported a few messages back and I no longer think it was a software issue.

I still think the PWM code has some problems when you update the duty cycle. However my code avoids that problem by zeroing it out between the commands, therefore a new timer will be created and the timer creation tests should be triggered if something goes wrong.

What I think that happeneds was this.

1. There was some ooze on the nozzle, which had been oozing out when the nozzle was heated up. That all is a completley verified fact.
2. The oozed plastic touched the bed first
3. Thanks to the bed leveling springs, the bed moved down instead of the probe triggering
4. Finally the normal homing timeout protection triggered, stopping the homing operation
5. Now the nozzle started to melt the filament more, so the bed moved up, and the probe triggered
6. But because of the error condition the nozzle never moved up, starting to damage the bed instead

There are two things I will do to prevent this from happening in the future. The first one is just a configuration fix, and the other one a software fix, which I will push to my pull request branch at some point.

1. Make sure I home at the highest point of the bed. That means that I now can set position_min very close to zero, or maybe even slightly positive to something less than the first layer height. Since the mesh bed leveling does not need to move to zero to trigger (the probe is around 1mm lower than the nozzle), this should be safe for that. And since we during normal printing don't move closer than the first layer height, printing should also not be a problem.

This will make sure that as long as the initial homing positon is correctly probed, then no matter what

kind of errors we get during the mesh bed leveling stage, it will always stop before the nozzle hits the
bed.

1. If there's an error detected after the homing move has started, then immediately peform a retract move (homing_retract_dist) before reporting the error. This makes sure that the move doesn't stop at the lowest position with the nozzle touching the bed.

[arminth]

I experienced the same inconsistent measurements with my two triangle labs clones. Where I got a totally leveled bed with +-0.05mm differences between corners and middle part with the capacitive probe, mounting the clones resulted in probing the bed to be going up to the left side by 3 tenth of a millimetre! Probing was also not really repeatable. I ordered an original blt now. Hopefully arriving tomorrow.

[Alex-Hedstrom]

Hello,

New user to the subject.
I've been trying to get my 3D Touch (not BLTouch) to work with my Ender 3 the last couple of days. I have to say that I've fairly new to programming but 15 years ago I have to courses of Java on high school, its something at least.

The probe worked before i changed to Klipper. Kevins gcode seems to work as intended but not when performing G28. It does not react even if I hit the pin just after 1 sec. Do I hold the pin up when it tries to push it down I got a error and that's great.

I changed yesterday to fredizzimo's "fredizzimo_bltouch_pwm_fix" and it started to perform the G28 as intended. Its homing and running the mesh bed leveling also. But I had a couple of crashes as well and I would like to submit the log here, maybe firstly to fredizzimo.

The last shutdown was when homing Z, It just hit the bed and i run M112. But it happended a couple of times. It also seems not to work when homing from >200mm.

If you are missing some information just say.
I will try to get a log when performing G28 with Kevin's code as well but later today.

klippy.log

[fredizzimo]

@Alex-Hedstrom

Thanks for the logs. The only thing that I can see so far is that everything appears to be in order, all commands performed in the correct order, as they should.

However, the code failed to detect the endstop trigger pulse, which should be around 5-10ms long. That detection is done on the printer side, with a much higher rate than that, so I don't really see how it fails. I don't think it's a communication error either, since in that case the the probing action should still stop, even if the Python side is not correctly informed.

I will continue looking at endstop.c, especially command_end_stop_home and the two event functions, to see if I find something. It's also possible that there is some bug in the event queue system, or the timer system, and the whole timer is ignored, although it's very unlikely, since timers are used for a lot of other things.

There is another small hint that the timers might not work as intended, which relates to my previous reports, that it seems like the faster you go, the more the position will overshot. It also sounds like the x and y axis are both bottoming out their respective endstop on the initial homing move on my Ender-3. And that's even when I have slowed down the speed to 30 mm/s. And there should still be at least 1 mm to spare after they trigger. But we are sampling multiple times per each stepper motor step, so the speed should not matter that much, especially not for the z-axis and the default 5mm/s speed.

[fredizzimo]

This part of the log (starting from line 3211) is quite interesting for two different reasons

Receive: 4 5049.775765 5049.774983 11: seq: 15, clock clock=3305107611
Receive: 5 5049.904357 5049.774983 9: seq: 15, end_stop_state oid=12 homing=0 pin=1
Receive: 6 5049.935810 5049.927525 10: seq: 16, stepper_position oid=1 pos=18238
Receive: 7 5049.935686 5049.927525 14: seq: 16, analog_in_state oid=7 next_clock=3312247040 value=7832
Receive: 8 5050.016293 5050.004666 14: seq: 1a, analog_in_state oid=15 next_clock=3313527040 value=7831
Receive: 9 5050.239293 5050.004666 14: seq: 1a, analog_in_state oid=7 next_clock=3317047040 value=7835
Receive: 10 5050.319912 5050.004666 14: seq: 1a, analog_in_state oid=15 next_clock=3318327040 value=7832
Receive: 11 5050.542940 5050.004666 14: seq: 1a, analog_in_state oid=7 next_clock=3321847040 value=7834
Receive: 12 5050.623525 5050.004666 14: seq: 1a, analog_in_state oid=15 next_clock=3323127040 value=7835
Receive: 13 5050.767270 5050.759378 11: seq: 1b, clock clock=3320858165
Receive: 14 5050.830157 5050.759378 14: seq: 1b, analog_in_state oid=7 next_clock=3326647040 value=7834
Receive: 15 5050.894598 5050.759378 9: seq: 1b, end_stop_state oid=13 homing=0 pin=1
Receive: 16 5050.910936 5050.907866 10: seq: 1c, stepper_position oid=2 pos=18216
Receive: 17 5050.910813 5050.907866 14: seq: 1c, analog_in_state oid=15 next_clock=3327927040 value=7833
Receive: 18 5051.133765 5051.086185 14: seq: 10, analog_in_state oid=7 next_clock=3331447040 value=7832
Receive: 19 5051.214400 5051.086185 14: seq: 10, analog_in_state oid=15 next_clock=3332727040 value=7832
Receive: 20 5051.437403 5051.086185 14: seq: 10, analog_in_state oid=7 next_clock=3336247040 value=7834
Receive: 21 5051.518062 5051.086185 14: seq: 10, analog_in_state oid=15 next_clock=3337527040 value=7830
Receive: 22 5051.549722 5051.086185 9: seq: 10, end_stop_state oid=13 homing=0 pin=1
Receive: 23 5051.581191 5051.570224 10: seq: 11, stepper_position oid=2 pos=18238

First for the endstop with oid=13, I'm assuimg that's the y axis. The first probe got the postion 18216, while the other one got the position 18238, so quite a difference there. The direction is negative in the configuration, so it means that it overshot by 22 steps, which is 0.275 mm. Part of this can probably be explained by the debouncing algorithm (endstop_oversample_event). Which could be called multiple times if the state of the pin changes. But I have seen the same effect on the BLTouch, which should have an absolutely stable signal, and done the calculations for that, and it can't be explained.

Anyway, I'm not sure if debouncing is actually helpful or not for normal endstops, for the BLTouch it's not. Typically it's used to avoid multiple triggers, for example in keyboards, where you don't want several keypresses for one press. So the question is, is the first contact point more determinisitic, than when the contact has been stable for some time? Edit On Marlin, the ENDSTOP_NOISE_FILTER is almost always disabled, so it seems like no debouncing would be better.

The second even more interesting thing is that both stepper oid=1 and oid=2, ended up in the exact same position. Other than in a very unlikely coincidence, this should not be possible, especially since you started homing the x-axis a fair bit from the edge, while the y-endstop triggered almost immediately, so they were not even at the same distance from the start. I have no explanation for this, but there's probably some secrets in the firmware that I don't know, so @KevinOConnor might have the answer.

Finally some more numbers from the Z-axis to show that it should not be possible to miss the 10 ms signal.

Sent 84 5055.716095 5055.715375 18: seq: 11, end_stop_home oid=6 clock=3404097853 sample_ticks=240 sample_count=4 rest_ticks=8000 pin_value=1

The rest ticks, determines how often we intial check the endstop in end_stop_event, that is 8000 ticks, and with a tick rate of 16000000, that means that we are checking it every 0.5ms. Once it's triggered, we check it sample_count=4 more times, with a rate of 240, so 960 ticks or 0.06ms. Which means that the signal has to be high for at least 0.56ms for us to be able to detect it. We need to detect a 5ms signal, so there should be plenty of margin to spare.

We also know that Marlin is able to detect this signal with ease, so something is definitely off for us. I can think of 3 different reasons

1. The pulse is much shorter than 5ms. Edit: Marlin polls the endstops every 1ms, so we are actually polling more frequently here, so this is an unlikely cause.
2. The pin didn't move down when we commanded it to do so. The only way to tell if that was the case is to visually verify or deny the statement. So that's something for you @Alex-Hedstrom to look at. Another thing to watch is if it starts off with no color when the pin is down, then turns red when it activates (which means that the probe detects the activation), but the steppers continue moving, which means that the firmware failed to detect it.
3. Something is off with the way the firmware schedules the timers

[fredizzimo]

@Alex-Hedstrom,

There's another m112, quite near the beginning of the log. That seems to have happened during a mesh leveling procedure. It looks like it finished successfully and printed out the mesh. As far as I can see no errors were reported, and the probe was triggered.

However, I can see that the last point triggered much before the other points. I'm not sure if that's an error or not, because the whole side appears to be around 1mm higher than the other side, so maybe you just had the last corner set too high on that one?

[fredizzimo]

@KevinOConnor,

I can see that you add a timer here https://github.com/KevinOConnor/klipper/blob/master/src/endstop.c#L123, without disabling the IRQ. I'm not sure how it's supposed to work, or if the IRQs are disabled elsewhere, but to me it seems like it could cause problems, since the timer handle and the adding of timer, both maninpulate the same linked list.

Some command handlers that calls sched_add_timer disables the IRQs while others don't, so I can't check the rest of the code for a reference either.

EDIT You can ignore the above, irq_save seem to disable the interrupts in additon to returning the current status. So sched_add_timer takes care of it already.

[Hiasl2603]

Hey guys,
my z-axis is not high enough at the second touch test.
can one adjust the higher after the first touch test ??
Also the error is Endstop z still triggered after retract
because he does not go far enough !!

Thanks

[fredizzimo]

@Hiasl2603,

You can increase the homing_retract_dist for the z axis.

[Hiasl2603]

@fredizzimo thanks a lot!!!
2 days work on this :-)

[Alex-Hedstrom]

@fredizzimo

Ignore the fact that its 1mm higher, its because I didn't update the mesh coordinates så the 3DTouch was outside of bed so i triggered it myself. It's all updated now.

I can't really tell if the red LED was on or off when it hit the bed. I actually think it was off.
I tried multiple times yesterday to home Z without any issues. But I found a other strange behavior and its when homing Z when the probe is triggered it pulls upp as it should but then I hear a clicking and sees that it's trying to move the pin down. I got no error and it lift up as it should after and do the second homing but slower.
I think this information is in klippy2.log and in klippy3.log is from today, it did the same thing but when performing the slow homing Z, but this time with an error. I think it was the 3rd time i run G28.

klippy2.log
klippy3.log

[fredizzimo]

@Alex-Hedstrom

I think the clicking sound comes from the fact that the BLTouch automatically tries to re-deploy, that's built in in the probe and not somehting you can configure. The Klipper code then pulls it up, but it might be just a little bit too slow, so it already starts re-deploying when it's done. That should probably not matter other than the sound.

Actually this re-deployment should protect the nozzle from hitting the bed. Because if we didn't detect the short pulse when it initially hit, the axis should continue to move down. Very soon after that, the pin re-deploys, but the nozzle is now very likely too far down, so the probe enters an error condition, with a completely stable high signal, which we should easily detect.

However, that is a case that my code doesn't handle properly, so it could end up with the wrong z-offset. I will fix that and update my pull request at some point. What it should do is to wait for at least 10 ms, then check if the pin is still high, if it is, then there was an error, and the probing should be reported as failed.

Unfortunately the logs have too little information in them to find the real cause of the nozzle crash, so unless @KevinOConnor figures something out, I need to modify the code to include more information.

One thing that I noticed is that you have the pin_move_time set to the default 0.3 seconds. That is likely too slow, even 0.5s does not reliably detect an error in time for me. I have mine set to 1s, it slows down the probing, but it adds some extra checks, especially if the probe is malfunctioning, or you start probing too close to the bed. But this should not cause the problems you are seeing. But it has these two effects

1. If you are really close to the bed, when you start, then it could, but the retract distances should take care of that.
2. If you are just a little bit too close, then the probe should enter an error state just after it has started to move down. My code will unfortunately not detect this situation, it's the same case that I described above, and instead return an offset a little bit too low. Setting the pin_move_time high enough ensures that we do the check before any movement, and also properly detects this error.

[Alex-Hedstrom]

@fredizzimo

Sorry about the pin_move_time, i was trying both lower and higher settings but I didn't realise that it might been the problem in this case.
I've set pin_move_time to 1 from now on and will keep it at that value.

The reason I'm asking about this re-deployment is that I've never seen it with the Marlin firmware.

I didn't have a nozzle crash with the klippy2 and klippy3-log files. And from now on i think the first one we can close as I think the red LED did not turn on.

Thank you for your help.

I have a very poor accuracy even at 2mm/s . See below. I can't remember it was this bad when I run the M48 gcode on Marlin.

This is with 7 samples when running G29:

probe at 82.000,46.000 is z=0.337500
probe at 82.000,46.000 is z=0.247500
probe at 82.000,46.000 is z=0.257500
probe at 82.000,46.000 is z=0.257500
probe at 82.000,46.000 is z=0.270000
probe at 82.000,46.000 is z=0.255000
probe at 82.000,46.000 is z=0.155000

probe at 120.250,46.000 is z=0.162500
probe at 120.250,46.000 is z=0.177500
probe at 120.250,46.000 is z=0.162500
probe at 120.250,46.000 is z=0.167500
probe at 120.250,46.000 is z=0.172500
probe at 120.250,46.000 is z=0.190000
probe at 120.250,46.000 is z=0.245000

probe at 158.500,46.000 is z=0.260000
probe at 158.500,46.000 is z=0.340000
probe at 158.500,46.000 is z=0.375000
probe at 158.500,46.000 is z=0.265000
probe at 158.500,46.000 is z=0.297500
probe at 158.500,46.000 is z=0.195000
probe at 158.500,46.000 is z=0.275000

probe at 196.750,46.000 is z=0.295000
probe at 196.750,46.000 is z=0.217500
probe at 196.750,46.000 is z=0.220000
probe at 196.750,46.000 is z=0.230000
probe at 196.750,46.000 is z=0.220000
probe at 196.750,46.000 is z=0.205000
probe at 196.750,46.000 is z=0.185000

probe at 235.000,46.000 is z=0.132500
probe at 235.000,46.000 is z=0.110000
probe at 235.000,46.000 is z=0.132500
probe at 235.000,46.000 is z=0.110000
probe at 235.000,46.000 is z=0.105000
probe at 235.000,46.000 is z=0.110000
probe at 235.000,46.000 is z=0.180000

I did try the test_repeatability after that and it doesn't look better. This is 2 test with 10 samples with a 10 sec pause between tests. I find it interesting that it goes up, and then down in values. Starting low at 0.3 and goes to 0.41 and then down to 0.38. It's not like it's 0.3 and directly after that 0.41 and then back to 0.33 and then to 0.40.

probe at 161.000,126.000 is z=0.305000
probe at 161.000,126.000 is z=0.335000
probe at 161.000,126.000 is z=0.377500
probe at 161.000,126.000 is z=0.385000
probe at 161.000,126.000 is z=0.400000
probe at 161.000,126.000 is z=0.407500
probe at 161.000,126.000 is z=0.392500
probe at 161.000,126.000 is z=0.387500
probe at 161.000,126.000 is z=0.415000
probe at 161.000,126.000 is z=0.395000

probe at 161.000,126.000 is z=0.430000
probe at 161.000,126.000 is z=0.417500
probe at 161.000,126.000 is z=0.407500
probe at 161.000,126.000 is z=0.402500
probe at 161.000,126.000 is z=0.402500
probe at 161.000,126.000 is z=0.372500
probe at 161.000,126.000 is z=0.407500
probe at 161.000,126.000 is z=0.382500
probe at 161.000,126.000 is z=0.385000
probe at 161.000,126.000 is z=0.380000

[fredizzimo]

Hm, have you checked that the probe is mounted tight, so that it doesn't slide up and down?

I can't hear any clicking with my genuine BLTouch Smart, so it's not somehting that happenes for everyone. But it could be explained by the code being a little bit slower to react than Marlin, so some clones might behave differently.

Another explaination would be if you don't run the latest version of my branch, the one without the pwm fix. That had a little bit similar symptoms, where it sometimes failed to retract the probe properly. But then again, the behaviour in the logs matches the fixed version, so that can't be the cause.

A wrongly set adjustment screw could also probably cause the problems that you are seeing. The screw adjusts the force that pulls the pin up. And maybe it's set slightly to weak for you. I didn't find any reliable information of how to do that, but I have seen it somewhere.

This could also be relevant https://www.reddit.com/r/3Dprinting/comments/6kch74/the_bltouch_pin_no_touchie/.

However, before all that, it would probably be good to re-check with Marlin, to confirm that everything is still working correctly there.

[Alex-Hedstrom]

@fredizzimo

Thanks for your help. I've cleaned the pin and did minor adjustment to the screw.
Now I more often get values closer and not in the pattern I had before

probe at 161.000,126.000 is z=0.855000
probe at 161.000,126.000 is z=0.867500
probe at 161.000,126.000 is z=0.887500
probe at 161.000,126.000 is z=0.882500
probe at 161.000,126.000 is z=0.897500
probe at 161.000,126.000 is z=0.887500
probe at 161.000,126.000 is z=0.882500
probe at 161.000,126.000 is z=0.887500
probe at 161.000,126.000 is z=0.892500
probe at 161.000,126.000 is z=0.882500

Standard deviation 0.0123855

@KevinOConnor
Now I have another strange thing. When i run G1 Z0 I see that the value Z0.16 on the display and one time I got full information in the klipper tab and I saw the true value toolhead.zpos = 0.158..... I don't know how to get this information again.. :(
It this related to the BLTouch section or should I start a new issue?

[KevinOConnor]

I have not been following this github issue closely. For those experiencing issues with their bltouch, they might have luck with PR #1091.

-Kevin

[markmosleh]

@fredizzimo i changed to ur branch, been trying to make a triangle TLtouch lab works, when probe touches the bed it is not trigerring and nozzle is keeping on hitting the bed while i force it to stop with M112.. any ideas
klippy3.log

[fredizzimo]

@markmosleh,

The only two things I can think of is that you have the same bug as @Alex-Hedstrom, sometimes has, and that I also saw once (out of probably 1000 probes). But for you it happens all the time.

Your cabling is wrong. I do have something connected to ar18, since otherwise the pull up resistor should pull it to triggered state, and you should see different types of errors. But is that the wrong cable? Or perhaps the polarity of the cable is wrong, try to turn it around. One of the pins should be GND and the other ZMin. Since the signal is not a real switch, but something emulated by the probe, I'm not entirely sure what happens if they are switched around.

[markmosleh]

@fredizzimo it was working with the same installation on marlin! with no problem whatsoever! however.. i tried to adjust the probe location and make it 1.5 mm above the nozzle when probe is pin upped! now it worked!!! ( i think it needed a bit more push to get triggered which i think it is the case of a lot of people here that no one knows about... at least with clones) with ur branch! when g28, pin is upped , hotend in center , z stepper works it way down and prob triggered and voila! but i dont know how to handle the z offset of the probe along with the home_retract_distance and the ovveride homing z position... can you explain these plz! regards

[xsasx]

@fredizzimo

working config on your pull with my anet a8:

[servo bltouch]
pin: PA4
maximum_servo_angle: 180
minimum_pulse_width: 0.0006
maximum_pulse_width: 0.0024

# Define a probe using the BLTouch
[probe]
pin: ^PC4
x_offset: -13
Y_offset: 22
z_offset: 2.41
activate_gcode:
    SET_SERVO SERVO=bltouch ANGLE=120
    G4 P200
deactivate_gcode:
    SET_SERVO SERVO=bltouch ANGLE=10
    G4 P100

but if i try the new config like this

[bltouch]
sensor_pin: PA4
control_pin ^PC4
pin_move_time: 0.3
x_offset: -13
Y_offset: 22
z_offset: 2.41
speed: 8

I got an error like "invalid pin description"

If i change than ^PC4 to PC4

and run g28 i got directly BLtouch failed to verify sensor state ?!

Whats wrong here

[jakep82]

The config you posted is missing a colon after control_pin.

[drbobbob]

Also, I think you have sensor pin and control pin backwards. I'm pretty
sure that control_pin needs to be the same as what you previously had for
the servo pin.

On Thu, Jan 10, 2019 at 9:05 AM jakep82 [e-mail] wrote:

The config you posted is missing a colon after control_pin.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KevinOConnor/klipper/issues/955#issuecomment-453127103,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATgPaXkBk3e5NN5E-g_l7OEr1fbamAXks5vB1bHgaJpZM4Y9p2P
.

[xsasx]

so you mean like this

[bltouch]
sensor_pin: ^PC4
control_pin: PA4
pin_move_time: 0.3
x_offset: -13
Y_offset: 22
z_offset: 2.41
speed: 8

[drbobbob]

I believe that is a more correct translation from servo / probe to the
bltouch module.

On Thu, Jan 10, 2019 at 9:15 AM xsasx [e-mail] wrote:

so you mean like this

[bltouch]
sensor_pin: ^PC4
control_pin: PA4
pin_move_time: 0.3
x_offset: -13
Y_offset: 22
z_offset: 2.41
speed: 8

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KevinOConnor/klipper/issues/955#issuecomment-453130796,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATgPQowSvkLp0j6H7yI3kedO8eeNW9Lks5vB1kUgaJpZM4Y9p2P
.

[xsasx]

Ok thanks must test - actually im on @fredizzimo branch with the old [probe] setup and so on - made a BED_MESH_CALIBRATION and it looks like that:

Send: BED_MESH_CALIBRATE
Send: M105
Recv: // probe at -30.000,10.000 is z=2.130000
Recv: // probe at -30.000,10.000 is z=2.112500
Recv: // probe at -30.000,10.000 is z=2.107500
Recv: // probe at -4.290,10.000 is z=2.185000
Recv: // probe at -4.290,10.000 is z=2.197500
Recv: // probe at -4.290,10.000 is z=2.192500
Recv: // probe at 21.420,10.000 is z=2.350000
Recv: // probe at 21.420,10.000 is z=2.350000
Recv: // probe at 21.420,10.000 is z=2.347500
Recv: // probe at 47.130,10.000 is z=2.402500
Recv: // probe at 47.130,10.000 is z=2.420000
Recv: // probe at 47.130,10.000 is z=2.415000
Recv: // probe at 72.840,10.000 is z=2.480000
Recv: // probe at 72.840,10.000 is z=2.485000
Recv: // probe at 72.840,10.000 is z=2.482500
Recv: // probe at 98.550,10.000 is z=2.457500
Recv: // probe at 98.550,10.000 is z=2.492500
Recv: // probe at 98.550,10.000 is z=2.497500
Recv: // probe at 124.260,10.000 is z=2.540000
Recv: // probe at 124.260,10.000 is z=2.457500
Recv: // probe at 124.260,10.000 is z=2.565000
Recv: // probe at 149.970,10.000 is z=2.487500
Recv: // probe at 149.970,10.000 is z=2.507500
Recv: // probe at 149.970,10.000 is z=2.485000
Recv: // probe at 149.970,38.570 is z=2.450000
Recv: // probe at 149.970,38.570 is z=2.465000
Recv: // probe at 149.970,38.570 is z=2.475000
Recv: // probe at 124.260,38.570 is z=2.515000
Recv: // probe at 124.260,38.570 is z=2.497500
Recv: // probe at 124.260,38.570 is z=2.510000
Recv: // probe at 98.550,38.570 is z=2.512500
Recv: // probe at 98.550,38.570 is z=2.515000
Recv: // probe at 98.550,38.570 is z=2.520000
Recv: // probe at 72.840,38.570 is z=2.512500
Recv: // probe at 72.840,38.570 is z=2.505000
Recv: // probe at 72.840,38.570 is z=2.502500
Recv: // probe at 47.130,38.570 is z=2.410000
Recv: // probe at 47.130,38.570 is z=2.415000
Recv: // probe at 47.130,38.570 is z=2.432500
Recv: // probe at 21.420,38.570 is z=2.272500
Recv: // probe at 21.420,38.570 is z=2.285000
Recv: // probe at 21.420,38.570 is z=2.277500
Recv: // probe at -4.290,38.570 is z=2.195000
Recv: // probe at -4.290,38.570 is z=2.190000
Recv: // probe at -4.290,38.570 is z=2.187500
Recv: // probe at -30.000,38.570 is z=2.147500
Recv: // probe at -30.000,38.570 is z=2.140000
Recv: // probe at -30.000,38.570 is z=2.162500
Recv: // probe at -30.000,67.140 is z=2.162500
Recv: // probe at -30.000,67.140 is z=2.157500
Recv: // probe at -30.000,67.140 is z=2.162500
Recv: // probe at -4.290,67.140 is z=2.197500
Recv: // probe at -4.290,67.140 is z=2.205000
Recv: // probe at -4.290,67.140 is z=2.212500
Recv: // probe at 21.420,67.140 is z=2.330000
Recv: // probe at 21.420,67.140 is z=2.302500
Recv: // probe at 21.420,67.140 is z=2.330000
Recv: // probe at 47.130,67.140 is z=2.395000
Recv: // probe at 47.130,67.140 is z=2.385000
Recv: // probe at 47.130,67.140 is z=2.400000
Recv: // probe at 72.840,67.140 is z=2.507500
Recv: // probe at 72.840,67.140 is z=2.480000
Recv: // probe at 72.840,67.140 is z=2.490000
Recv: // probe at 98.550,67.140 is z=2.515000
Recv: // probe at 98.550,67.140 is z=2.502500
Recv: // probe at 98.550,67.140 is z=2.502500
Recv: // probe at 124.260,67.140 is z=2.560000
Recv: // probe at 124.260,67.140 is z=2.525000
Recv: // probe at 124.260,67.140 is z=2.567500
Recv: // probe at 149.970,67.140 is z=2.520000
Recv: // probe at 149.970,67.140 is z=2.530000
Recv: // probe at 149.970,67.140 is z=2.507500
Recv: // probe at 149.970,95.710 is z=2.525000
Recv: // probe at 149.970,95.710 is z=2.547500
Recv: // probe at 149.970,95.710 is z=2.537500
Recv: // probe at 124.260,95.710 is z=2.502500
Recv: // probe at 124.260,95.710 is z=2.517500
Recv: // probe at 124.260,95.710 is z=2.495000
Recv: // probe at 98.550,95.710 is z=2.575000
Recv: // probe at 98.550,95.710 is z=2.590000
Recv: // probe at 98.550,95.710 is z=2.575000
Recv: // probe at 72.840,95.710 is z=2.492500
Recv: // probe at 72.840,95.710 is z=2.475000
Recv: // probe at 72.840,95.710 is z=2.472500
Recv: // probe at 47.130,95.710 is z=2.352500
Recv: // probe at 47.130,95.710 is z=2.355000
Recv: // probe at 47.130,95.710 is z=2.382500
Recv: // probe at 21.420,95.710 is z=2.295000
Recv: // probe at 21.420,95.710 is z=2.292500
Recv: // probe at 21.420,95.710 is z=2.305000
Recv: // probe at -4.290,95.710 is z=2.165000
Recv: // probe at -4.290,95.710 is z=2.175000
Recv: // probe at -4.290,95.710 is z=2.167500
Recv: // probe at -30.000,95.710 is z=2.155000
Recv: // probe at -30.000,95.710 is z=2.180000
Recv: // probe at -30.000,95.710 is z=2.175000
Recv: // probe at -30.000,124.280 is z=2.157500
Recv: // probe at -30.000,124.280 is z=2.177500
Recv: // probe at -30.000,124.280 is z=2.175000
Recv: // probe at -4.290,124.280 is z=2.212500
Recv: // probe at -4.290,124.280 is z=2.227500
Recv: // probe at -4.290,124.280 is z=2.227500
Recv: // probe at 21.420,124.280 is z=2.300000
Recv: // probe at 21.420,124.280 is z=2.305000
Recv: // probe at 21.420,124.280 is z=2.290000
Recv: // probe at 47.130,124.280 is z=2.392500
Recv: // probe at 47.130,124.280 is z=2.405000
Recv: // probe at 47.130,124.280 is z=2.397500
Recv: // probe at 72.840,124.280 is z=2.482500
Recv: // probe at 72.840,124.280 is z=2.495000
Recv: // probe at 72.840,124.280 is z=2.487500
Recv: // probe at 98.550,124.280 is z=2.550000
Recv: // probe at 98.550,124.280 is z=2.545000
Recv: // probe at 98.550,124.280 is z=2.537500
Recv: // probe at 124.260,124.280 is z=2.542500
Recv: // probe at 124.260,124.280 is z=2.552500
Recv: // probe at 124.260,124.280 is z=2.547500
Recv: // probe at 149.970,124.280 is z=2.482500
Recv: // probe at 149.970,124.280 is z=2.497500
Recv: // probe at 149.970,124.280 is z=2.495000
Recv: // probe at 149.970,152.850 is z=2.540000
Recv: // probe at 149.970,152.850 is z=2.512500
Recv: // probe at 149.970,152.850 is z=2.517500
Recv: // probe at 124.260,152.850 is z=2.565000
Recv: // probe at 124.260,152.850 is z=2.595000
Recv: // probe at 124.260,152.850 is z=2.597500
Recv: // probe at 98.550,152.850 is z=2.507500
Recv: // probe at 98.550,152.850 is z=2.532500
Recv: // probe at 98.550,152.850 is z=2.515000
Recv: // probe at 72.840,152.850 is z=2.482500
Recv: // probe at 72.840,152.850 is z=2.495000
Recv: // probe at 72.840,152.850 is z=2.485000
Recv: // probe at 47.130,152.850 is z=2.430000
Recv: // probe at 47.130,152.850 is z=2.445000
Recv: // probe at 47.130,152.850 is z=2.430000
Recv: // probe at 21.420,152.850 is z=2.352500
Recv: // probe at 21.420,152.850 is z=2.347500
Recv: // probe at 21.420,152.850 is z=2.357500
Recv: // probe at -4.290,152.850 is z=2.195000
Recv: // probe at -4.290,152.850 is z=2.215000
Recv: // probe at -4.290,152.850 is z=2.245000
Recv: // probe at -30.000,152.850 is z=2.180000
Recv: // probe at -30.000,152.850 is z=2.182500
Recv: // probe at -30.000,152.850 is z=2.175000
Recv: // probe at -30.000,181.420 is z=2.220000
Recv: // probe at -30.000,181.420 is z=2.222500
Recv: // probe at -30.000,181.420 is z=2.222500
Recv: // probe at -4.290,181.420 is z=2.230000
Recv: // probe at -4.290,181.420 is z=2.232500
Recv: // probe at -4.290,181.420 is z=2.230000
Recv: // probe at 21.420,181.420 is z=2.372500
Recv: // probe at 21.420,181.420 is z=2.360000
Recv: // probe at 21.420,181.420 is z=2.360000
Recv: // probe at 47.130,181.420 is z=2.452500
Recv: // probe at 47.130,181.420 is z=2.440000
Recv: // probe at 47.130,181.420 is z=2.455000
Recv: // probe at 72.840,181.420 is z=2.545000
Recv: // probe at 72.840,181.420 is z=2.545000
Recv: // probe at 72.840,181.420 is z=2.552500
Recv: // probe at 98.550,181.420 is z=2.592500
Recv: // probe at 98.550,181.420 is z=2.600000
Recv: // probe at 98.550,181.420 is z=2.592500
Recv: // probe at 124.260,181.420 is z=2.427500
Recv: // probe at 124.260,181.420 is z=2.362500
Recv: // probe at 124.260,181.420 is z=2.425000
Recv: // probe at 149.970,181.420 is z=2.517500
Recv: // probe at 149.970,181.420 is z=2.512500
Recv: // probe at 149.970,181.420 is z=2.512500
Recv: // probe at 149.970,209.990 is z=2.632500
Recv: // probe at 149.970,209.990 is z=2.637500
Recv: // probe at 149.970,209.990 is z=2.645000
Recv: // probe at 124.260,209.990 is z=2.557500
Recv: // probe at 124.260,209.990 is z=2.552500
Recv: // probe at 124.260,209.990 is z=2.517500
Recv: // probe at 98.550,209.990 is z=2.645000
Recv: // probe at 98.550,209.990 is z=2.647500
Recv: // probe at 98.550,209.990 is z=2.632500
Recv: // probe at 72.840,209.990 is z=2.632500
Recv: // probe at 72.840,209.990 is z=2.630000
Recv: // probe at 72.840,209.990 is z=2.635000
Recv: // probe at 47.130,209.990 is z=2.480000
Recv: // probe at 47.130,209.990 is z=2.480000
Recv: // probe at 47.130,209.990 is z=2.487500
Recv: // probe at 21.420,209.990 is z=2.435000
Recv: // probe at 21.420,209.990 is z=2.440000
Recv: // probe at 21.420,209.990 is z=2.430000
Recv: // probe at -4.290,209.990 is z=2.320000
Recv: // probe at -4.290,209.990 is z=2.300000
Recv: // probe at -4.290,209.990 is z=2.307500
Recv: // probe at -30.000,209.990 is z=2.262500
Recv: // probe at -30.000,209.990 is z=2.255000
Recv: // probe at -30.000,209.990 is z=2.262500
Recv: // Mesh Bed Leveling Complete
Recv: // Bed Mesh state has been saved to profile [default]
Recv: // for the current session.  The SAVE_CONFIG command will
Recv: // update the printer config file and restart the printer.

Start a test print with 4 small Objects and by 2 objects it printed only sh** i must cancel the print cause 2 or 3 of the object was printed in the air :( any tip

BED_MESH settings looks like that:

[bed_mesh]
speed: 50
horizontal_move_z: 5
samples: 2
sample_retract_dist: 2.0
min_point: -50,10
max_point: 150,210
probe_count: 8,8
fade_start: 1.0
fade_end: 10.0
split_delta_z: 0.025
move_check_distance: 5.0
mesh_pps: 3,3
algorithm: bicubic
bicubic_tension: .2

[fredizzimo]

@xsasx, my guess is that your z-offset of the probe is set wrong. I have improved the instructions for how to calibrate it in this pull request https://github.com/KevinOConnor/klipper/pull/1107

The other possibility is that you are repeatability problems, and your probe is not very accurate, but it's hard to see that from just the bed mesh leveling output.

@markmosleh, I hope those instructions help you too.

[KevinOConnor]

I'm going to close this issue as there have been a number of items fixed in the bltouch code since it was originally opened. If there are additional problems, please open a new github issue and attach the klipper log file.

-Kevin

[gerrylenz]

I have the same problem.
Workaround
[bltouch]
...
pin_up_touch_mode_reports_triggered: False
...

[cahayez]

I have the same problem.
Workaround
[bltouch]
...
pin_up_touch_mode_reports_triggered: False
...

I also had to make this change on my genuine BLTouch Smart v3.0

[CircuitSetup]

I have the same problem.
Workaround
[bltouch]
...
pin_up_touch_mode_reports_triggered: False
...

I also had to make this change on my genuine BLTouch Smart v3.0

Is that all you did to get the v3 working properly? I'm having a hard time getting it to work.

[elcojacobs]

I found this on reddit:
"The issue is that Creality added a condensator on the Z endstop input, I guess to have a cleaner signal, but it adds a slight delay in the signal detection.

Since the endstop signal sent by the BLTOUCH V3 is a spike shorter than the previous version, that condensator prevent the software to see the signal. It can be solved via software by using the BLTOUCH in switch mode (no spike signal, the signal stays ON until cleared by the next measure, i.e. the probe being deployed again), or by removing the condensator (the one marked C7) with small pliers.

The MKS Gen L., like every board except the Creality ones, have no condensator on the endstops inputs, so the BLTOUCH V3 works just fine and is more precise than the previous versions."

Source: https://www.reddit.com/r/ender3/comments/bhk7xn/mks_gen_l_bltouch/

I just upgraded my main board to MKS gen L. About to install the BLtouch V3. But this might explain the issues with the original board.

[florianschroen]

I connected a 3D-Touch v3 (china-clone) to the z-endstop connector of the creality mainboard v1.1.3 (ender 3 pro).
In fact it was not possible to get it working. So I tried a little bit around.

Indeed, the problem seems to be the capacitor attached to the z-endstop-connector (PC4). (Like noted in https://github.com/KevinOConnor/klipper/blob/master/docs/BLTouch.md)

I fixed this by switching to the MOSI GPIO PIN (PB5).
This works like a charm:

• Disconnect the 2Pin-Cable from z-endstop-connector of motherboard.
• Orientation of the board for the following descriptions: Stepper-Motor-Connectors top, Fan-/Endstop-Connectors button, USB right (like this shop image)
• Connect the 2Pin-Cable to the ISP Header:
  
  
  
  • GND to GND (from Z-Stop left pin to ISP bottom right pin)
  
  
  • Data to MOSI (from Z-Stop right pin to ISP middle right pin)
  
  
  • _I made a adapter for this. If you can't and if it does not fit, try a male to female dupont cable._
  
  
• update [bltouch] section in printer.cfg:
  replace sensor_pin: ^PC4 with sensor_pin: ^PB5
• restart klipper daemon