Klipper: BLTouch uses trigger test for actually probing

[oderwat]

I saw that the BLTouch example does use the 60 degree servo angle for doing the probing. Afaik this is just a test mode for checking if the BLTouch triggers manually.

I thought the "real" probing does send a 5 ms signal when the probe triggers. I think in Marlin this trigger is being handled as interrupt or polling at a sufficient resolution. I have no clue if the 60° mode is supposed to be used as it is used here and if that is as exact as the trigger signal.

Anyone knows in more detail how it is supposed to work and if using the sensor test is sufficient exact?

[oderwat]

I think this diagram shows how the BLTouch is supposed to work. This would also allow detection of the alarm state by distinguishing between the 10ms trigger signal and the constant alarm signal at the end stop pin.

[chainsol]

Uhh, so, here's a question for you - is there a downside to the 60° mode? I've been using the BLTouch to mechanically level my bed and I've been getting very good results - any problems so far that I've had have been user error.

[oderwat]

If you set it into 60° and let it trigger, the trigger stays closed instead of opening again after 10ms. This is the same as reporting the alarm state.

I don't actually know if 60° triggering creates different results to 10° polling or interrupt mode. I only know that it is meant to use an interrupt as trigger while being set to 10° position. You can't use an interrupt with the 60° trigger. It may be OK if used with polling.

I am also not really satisfied with the repeatability range of my (clone) device (<0,05mm). But I can't tell of this has to do with the implementation, the "cheap" clone or other problems.

[KevinOConnor]

FYI, after a brief investigation with @chainsol a few days back, I do think there could be improvements to the bltouch handling in Klipper. In particular, it seems code could be written that does some basic sanity checks on the bltouch prior to homing with it.

It seems that if the bltouch is given a 90° command followed by a 60° command then it will signal the mcu (via the "endstop" pin going high). So, it should be possible to implement host code that verifies the "endstop" pin goes from low to high on a 90° -> 60° transition, and verifies the pin is low after a 10° command and prior to moving the head. I think such a sequence would give higher confidence that the bltouch is operating normally prior to head movement. Finally, it seems a 160° command will reset the bltouch state after a homing operation completes.

That said, I don't have any immediate plans to work on this. I do think that this could be done entirely in the python code with a klippy/extras/bltouch.py "extras" module, if someone wishes to tackle it though.

-Kevin

[outlookhazy]

Not sure if this is the place to ask, but this seems the closest thread;

I'm preparing to set up a touch sensor and noticed that the probe section doesn't have an x/y offset.
Does the auto-calibrate math you're using still work in such a scenario? My sensor is going to be hanging off the side of my delta effector.
I imagine it wouldn't matter for a _linear_ bed tilt, but it seems like the delta math might get wonky. Then again, if it's searching for a local minimum - maybe it doesn't matter?

Edit: maybe the correct way to handle it would be to add relative moves accounting for the offset into the probe activate/deactivate g-code? Would the routine still consider those probe results as from the "start" point?
Edit 2: I also see both M206 and SET_GCODE_OFFSET as potential solutions. I have a lot of trouble slogging through the python code trying to make sense of which coordinates would be used internally by the probe routine...

[outlookhazy]

Got my sensor set up and am doing a bit of experimenting.
Looks like if I add a relative move to reposition the sensor over the probe point in the activation script it will move, but then move diagonally to the probe point. I thought maybe I could outsmart it by following that with a set_gcode_offset that would change the underlying probe target to the "updated" position and then restore it during the deactivation script, but no dice.

[oderwat]

@outlookhazy Why not opening an issue related to probe offsets? I would like to keep the BLTouch implementation issues focused.

[outlookhazy]

@oderwat honestly, because the sensor in question is a bltouch, this is the only open thread regarding probing, and I expected the answer to be something silly/obvious that I've missed that someone following this thread may be able to answer as they'd potentially be using a similar setup.

[oderwat]

@outlookhazy so how is your problem related to a BLTouch at all? This seems to be unrelated to the probe type. So any probe user can jump in for discussing your problem. It also will attract more people if it has the correct topic. I think your feeling that this may not be the right place you already expressed in you initial post is correct.

I don't even want to start a discussion on probing offsets in this issue as I feel it is the wrong place. It now already polluted the former clean discussion of the BLTouch triggering internals. This is not a forum and even there it would not be nice to hijack another thread.

[jorgempy]

Hi, first of all thanks for this awesome fw!

I want to join in this discussion. I have read your bltouch related posts @oderwat

I have an anycubic kossel printer (DELTA), and my problem is that in delta printers you dont have z homing (G28 Z), so the homing override cant help you make movements with the probe (@KevinOConnor said in #391 that your shouldnt put movement commands in activate/deactivate gcode)

More on that, if you want to use z min and bed tilt calibration issues arise because in deltas you dont have a z_stepper section to put the virtual endstop. Maybe im just not getting some configuration detail, but im not being able to properly configure my printer for bed tilt and zmin calibration.

Regards

[KevinOConnor]

Is anyone working on this issue (improved bltouch handling and/or improved bltouch signal checking)? If not, I'm inclined to mark this as inactive and close it until someone is actively working on it.

-Kevin

[vertigo235]

It would seem inappropriate to close it, but marking it inactive by the development team if nobody is working on it would make sense.

[chainsol]

I'm happy to poke around on this one. I will say, with a genuine BLtouch, I get repeatability of around 0.005mm, which is my full-step of my printer, so I'm not unhappy with that at all. The alarm state and sanity checking seems smart though.

[KevinOConnor]

FYI - I've committed a new bltouch "extras" module (commit 824e55d7). This module should do a better job at validating that the bltouch is operational prior to probing - see PR #931 for details.

-Kevin

[KevinOConnor]

FYI, as of commit 99f96f28 the bltouch code uses pin_down mode instead of touch_mode for probing.

-Kevin