Marlin: BLTouch Improvements

[gcormier]

I dug through the code... I'm trying to determine how BLTouch works with Marlin.

When running any probe operation, the pin will often tap the plate immediately after it is triggered - the build plate can't move out of the way fast enough. I figure it's one of two things:

1) Once Z probe is triggered, Marlin redeploys the probe immediately.

2) The BLTouch itself re-deploys the pin until it gets another command.

I suspect it is #2, and if it is, we obviously can't change anything, except perhaps try to set the Z speed to something really fast to try and get out of the way.

I did try a STOW PROBE, but that stows it too late; it's stowed just before we're ready to change XY to the next point. I also tried changing SERVO_DELAY to both 50 and 3000 to see how it affects things, but that didn't.

Also to note I don't think this has any effect on the probing... it's more a polish item. Although if the Z is too slow, it could indeed be an issue and trigger an error state on the BLTouch as it tries to deploy the pin and is not allowed to deploy the pin fully.

[thinkyhead]

@gcormier I think it is #2, but maybe we can fix that by making BLTOUCH a special case and having it "stow" immediately after probing, then re-"deploy" before each probe. This would be distinct from the G29 E option, which moves Z up before stowing.

Before making the change, try the "G29 E" option to have the probe stow and re-deploy after each probe operation and see if it does the normal raise quickly enough.

[bgort]

I've noticed the same issue (relatively random pin-glass impact, and some related minor reduction in accuracy) and first contacted ANTCLABS to rule out a hardware problem and to clarify whether the firmware or BLTouch itself redeploys the pin; turns out that the BLTouch is 'dumb' in that it only stows/deploys as directed by Marlin.

They indicated that this is a known issue related to Marlin and how it does probe-trigger-detection, and pin stow->redeployment. They said that if interrupts were used, triggers and stow->redeployment would be more consistent, which would improve accuracy. I had felt that the pin impacting the glass would likely result in minor variance in pin height, and therefore trigger height, and they seemed to agree.

I was planning on looking into this myself in the coming weeks, though I'm not at all sure that implementing endstop trigger detection with interrupts would be simple. @thinkyhead?

Though the first thing I was going to try was going to be increasing Marlin's delay between the automatic stow-on-trigger and then redeployment, if possible. I suspect that'll likely help some, at least.

[thinkyhead]

Interrupts are not necessary. And in any case, servos (including this one) already use interrupts.

[bgort]

I think it is #2, but maybe we can fix that by making BLTOUCH a special case and having it "stow" immediately after probing, then re-"deploy" before each probe. This would be distinct from the G29 E option, which moves Z up before stowing.

I think this would help quite a bit.

Before making the change, try the "G29 E" option to have the probe stow and re-deploy after each probe operation and see if it does the normal raise quickly enough.

Will try this now. Just trying the latest RCBugFix, anyway.

[bgort]

Interrupts are not necessary. And in any case, servos (including this one) already use interrupts.

Yeah, I was having a hard time accepting that the timing could be so critical, but I hadn't investigated at all yet. That's just what they said the issue was.

[gcormier]

G29 E did not resolve the issue. You still get the small glass impact... and then it stows the probe to travel.

[bgort]

G29 E did not resolve the issue. You still get the small glass impact... and then it stows the probe to travel.

Same here.

[thinkyhead]

Ok, so I've added onto the PR #4856, which also fixes BLTouch status handling. Relatively simple change:

• Have the BLTouch pin deploy _immediately_ before the probe moves towards the bed
• Have the BLTouch pin retract _immediately_ after every probe

This should also work well with G30.

[bgort]

I'll test the PR in a few minutes.

[bgort]

Just tested: No probe deployment on G28, resulting in a nozzle crash. The probe works fine when stowed/deployed manually with M280.

[thinkyhead]

Ah, G28… right. Forgot about that.

[thinkyhead]

Ok, added the same BLTouch quick deploy/stow to the function do_homing_move.

[bgort]

I'm not seeing the changes. Are they in PR #4856, or thinkyhead/rc_bltouch_update, or?

Am I missing something?

[thinkyhead]

Should be there now. I might have forgotten to actually type "git push -f" earlier.

[bgort]

Suspected that might be the case. Been there, done that.

Yep, they're here now.

[bgort]

Two instances of BLTOUCH_RETRACT weren't renamed to BLTOUCH_STOW:

• Marlin_main.cpp:2007
• Marlin_main.cpp:2028

[thinkyhead]

That code was superseded, probably just after you downloaded. Try again.

[bgort]

I pulled thinkyhead/rc_bltouch_update again, then just fixed the errors (renaming _RETRACT to _STOW), and there are a bunch of 'extra' stows/deploys, as follows (in order):

• G28
• Z probe deploy
• travel to X0 until endstop triggers
• stow probe
• deploy probe
• travel to X2 (give or take - small movement in positive direction)
• stow
• deploy
• travel to X0, trigger endstop
• stow
• deploy
• travel to Y0, trigger endstop
• stow
• deploy
• travel to Y2 (give or take)
• stow
• deploy
• travel to Y0, trigger endstop
• stow
• travel to center (Z_SAFE_HOMING point)
• axis raises to safe height
• deploy
• axis lowers until touch
• stow
• deploy immediately (pin impacts glass)
• axis raises
• stow
• deploy
• axis lowers slowly until touch
• stow
• axis raises
• G28 complete

[bgort]

Looks like my local repository got fargled up, somehow. I did a hard reset and tried again, and _RETRACT had been renamed to _STOW properly, etc. Still seeing the aberrant probing and such, though.

[thinkyhead]

Are _all_ the BLTOUCH owners here today?? I've never seen so much enthusiasm for a feature.

[gcormier]

:) I'll try to get the updated fixes and test today.

I expect interest in BLTOUCH to only grow, I think it's probably one of the best probes out there?

[Roxy-3D]

I expect interest in BLTOUCH to only grow, I think it's probably one of the best probes out there?

I think its appeal is more because of how I view it. I think people see it as a self contained Z-Probe that can be attached any way you can to the nozzle. It can even be glued in place if you can hold it in position long enough for the glue to dry.

[gcormier]

@thinkyhead Tested. G29 looks good. G28 behaves as it previously did. Note I am using double touch... so that 2nd touch, probe is deployed before bed goes down.

(G29, no issues even with double touch)

[thinkyhead]

When you say G28 behaves as it "previously" did, what do you mean?

[gcormier]

Sorry.

So on the first touch, the pin retracts - then it deploys before the bed has moved out of the way, hitting the bed before the 2nd slower touch operation.

[gordo3di]

We've been using the BLTouch since the campaign. We are testing the BLTouch on the gMax 1.5+ using the RCBugFix branch from 3-4 days ago with no issues. Upon bed leveling the printer first raises (if it hasn't already been homed), goes to 0,0 (well for us its actually 0,410) goes to the center, raises slightly, waits while the pin drops then lowers. Plenty of time for it to drop. We also set the servo delay to 350 just to make sure it has time. Note the BLTouch behaves much better on this release over our current firmware (which is 1.0.1 I believe).

[gcormier]

Here's my G28 behaviour with the latest RCBugFix

https://goo.gl/photos/tJ8FVFpQu4HQkFiWA

[gordo3di]

Very weird. We have seen the fast "double tap" on very few bltouches as we have gone through maybe 150 of them... I have seen this exact problem maybe 1-2 times but when switching the bltouch it was fine. Hope it isn't this. Sure it isn't the wires or something weird? Ours perform fine with the same code. I'm new to github and will be here a LOT.

[gcormier]

@gordo3di you'll be happy to know that @thinkyhead has modified the firmware in the last 24 hours to avoid the double tap. I think it's just an issue of it being implemented in G29, but G28 has an mistake or was forgotten.

[gordo3di]

@gcormier Thanks. Uploading our vid right now so you can see what we have anyway.

[gordo3di]

BLTouch, ramps v1.4 RCBranchFix (3-4 days ago). Fresh restart after powerdown (sorry for the refresh flashes) https://youtu.be/o2LLd8TIdTk

[thinkyhead]

but G28 has an mistake or was forgotten

@gcormier Hmm, I dunno. Did you try setting a larger value for Z_HOME_BUMP_MM to see if it still deploys too early? It looks to me like it's deploying for the second Z homing when it's supposed to, but the raise between probes isn't large enough.

For BLTOUCH we may have to enforce a minimum bump distance to avoid this. @gordo3di Yours seems to be set at about the minimum. What is your setting? Would 4mm be enough space?

/**
 * BLTOUCH minimum bump distance
 */
#if ENABLED(BLTOUCH) && HOMING_Z_WITH_PROBE && Z_HOME_BUMP_MM > 0 && Z_HOME_BUMP_MM < 4
  #error "Z_HOME_BUMP_MM must be at least 4mm for BLTOUCH."
#endif

[bgort]

I just tried the latest RCBugFix (087223f) and I'm still seeing the glass impact when it does the double probe w/G28, but G29 is now perfect.

EDIT: Just tried increasing Z_HOME_BUMP_MM, though the probe still redeploys too early - almost immediately after the endstop triggers - resulting in a glass impact. There's also an extra stow+deploy after the z bump completes.

Video: https://youtu.be/_R7ctZLlNxg

EDIT2: Just want to say thank you for all the hard work you guys do. Marlin really is great. Hoping to have more time to contribute in the future.

[gcormier]

I'll try to change the bump to 5mm and test today!

The only thing that comes to mind is G29 worked fine without adjusting that setting... what is G29 doing (right) that G28 is doing (wrong) ? Both do a double touch.

[thinkyhead]

The raise value for G29 is separate from the "bump" value for G28, so your G29 is probably raising by a more useful distance. Perhaps the larger of the two values should apply when homing with a probe.

[thinkyhead]

@bgort @gcormier I think I have the cause and solution worked out. I will post shortly.

[gcormier]

Sweet!

[gcormier]

@thinkyhead With that commit, probe did not deploy and head crashed into the bed trying to home Z. (This was G28.)

[bgort]

Just tested 9b7742f; probe doesn't deploy at all on G28. I turned the printer off before a bed strike could occur.

[thinkyhead]

Sorry about that. It's patched properly now.

[gcormier]

I think that did it! G28 has proper behaviour to match G29 now!

[bgort]

Working here too! Great! Thanks much, @thinkyhead.

[thinkyhead]

Glad to hear it. Whew!

Just one more minor change soon… #4875

[bgort]

FYI, this considerably improved my M48 probe test standard deviation.

Before, I would see an average of ~20um, with outliers down to 4-6um and up to 35-40um; now, so far, I'm seeing a ~5um average, 11um max (once), with 3-4um pretty common. I've done ~10 trials, so far.

The pin hitting the glass was obviously a bigger problem than I had thought previously.

[gcormier]

That is really interesting. I figure that it had no effect whatsoever, as it was still outside the infinitely tiny range where the probe is triggered. I think really good news, and awesome work - big thanks to @thinkyhead for pushing this one through so quickly!

[bgort]

@gcormier Yeah, I'm thrilled. Really great work.

[jonathanlundstrom]

Hey guys!

I just updated my machine to 1.10-RC7 the other day and installed a BLTouch at the same time. While doing G28 it never fails, but sometimes, more often than not, G29 fails. Somehow it doesn't seem like the pin retracts properly, or maybe it's dropped to quickly after a probe. This leads to the nozzle crashing in to the bed before the probe realizes something is wrong. It then starts flashing (have to remove USB and power to reset). I'm not sure if this is the same problem as you were all describing?

Once the problem occurs, it looks like this:
https://photos.google.com/share/AF1QipNzprFZxQxeSfLZPov7_1XFVJiyu0ZCK3x4ELxMGu7JXdXIe6WIF3n4Tx4KKvcWgA?key=SnR6WGgzelNwcG5aWWJLSmptMUdnd2ZLOUlydEp3

A normal G28 and G29 looks like this now:
https://photos.google.com/share/AF1QipPJ066X3aU-L54jzB0mwQP-2oFEDHYmqbIgdJvV_LtAPQ-pZofbSWsTfmEFH6cgxA/photo/AF1QipMK2HwINUMVFA7kODw-DAAvckD_IHSgsK1qSw8c?key=dVpSd1NRQ29OdTZ0NEhVWmpaRVNOVlo3bDFCMGln

Here's how my configuration file looks like, if anyone can think of something that's wrong:
http://pastebin.com/rPsntFuW

Thank you so much!!

EDIT: It looks just like this:
https://youtu.be/CO_2BeMpbSQ?t=45s
(Referenced here: https://github.com/MarlinFirmware/Marlin/issues/4653)

[thinkyhead]

Please test with RCBugFix @jonathanlundstrom. It has code specifically for BLTOUCH.

[jonathanlundstrom]

Quite right! After posting this I configured RCBugFix and was testing it for a few hours. G28, G29 and M48 now seems to work perfectly fine and I've had zero issues since. Great work!

[thinkyhead]

Good news @jonathanlundstrom — Others have not had the best luck with BLTouch, but apparently there's a way to update the onboard software on that device which should make it less flaky with the way we use it.