Marlin: [BUG] Bl-Touch probing is slow

[lokster]

A new "sanity check" was introduced recently in Marlin 2.0 bugfix, which limits the BLTOUCH_DELAY to no less than 200ms.
Also, the BLTOUCH_DEPLOY_DELAY and BLTOUCH_STOW_DELAY are way too high by default (750ms).
This makes probing very sluggish, especially on a large bed with more probing points.
In earlier Marlin releases I used 50ms BLTOUCH_DELAY. Initially, this resulted in unreliable probing - the pin sometimes did not stow properly etc.
I was able to easily fix the issue by screwing the magnetic core of the sensor a bit deeper. This resulted in 100% reliable probing - I've tested it successfully with a couple of Trianglelab knock-offs, and it seems it does work fine with 50ms delay set for all 3 parameters BLTOUCH_DELAY, BLTOUCH_DEPLOY_DELAY and BLTOUCH_STOW_DELAY (I disabled the BLTOUCH_DELAY sanity check while testing)

[reloxx13]

did u saw this in config_adv ?

  /**
   * Use "HIGH SPEED" mode for probing.
   * Danger: Disable if your probe sometimes fails. Only suitable for stable well-adjusted systems.
   * This feature was designed for Delta's with very fast Z moves however higher speed cartesians may function
   * If the machine cannot raise the probe fast enough after a trigger, it may enter a fault state.
   */
//#define BLTOUCH_HS_MODE

[BigIronGuru]

All true what you say, to a certain degree. But please consider the following:

I think it was a failsafe value and there were a lot of politics involved - doesn't work for everyone, lowest common denominator, problems with one specific printer manufacturer dominating the issue etc.. I used 100ms for while and it worked for me, I also disabled the limit for a while. And don't forget the official ANTCLabs timing information, and people who have clones etc. - and then the poor people who get clobbered with support queries and therefore prefer a real safe value for this sanity check.

By the way: You can be glad it didn't turn out to be a limit of 500ms as it was intended for a while, simply because that "seemed to work better on CReality printers".

But BLTOUCH_HS_MODE will make you even more happy, if you set up your probe clearances and vertical speed well. (Lowest clearance possible, highest Z-speed possible). And then the 200ms and 750ms won't hurt you because then there is no STOW and no DEPLOY going on at all in between probes as was intended in the original probe code for servo type probes. And that wasn't designed "for Deltas", by the way - too many cooks and politics once again.

Do please test that, as @reloxx13 said.

And then, if you still feel the need: If your probing is so reliable and you feel you can afford to lose the error detection and debugging possibilites given by the 750ms wait for alarm on the very few DEPLOYs and STOWs still being done at all, so by all means, set them lower: But once you get a fail, in order to diagnose it easily, you should go back to 750ms for the STOW_ and DEPLOY_DELAY. That way, you will be able to have the failure result in a detection immediately when it happens and not on a subsequent later operation of the probe.

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.