Z-probe redeployment timing

[crncrussell]

I am using a BLTouch probe for bed leveling with RC4. This is treated like a servo for deploying the probing pin. I am having random issues where the pin seems to get pushed back out before the the completion of the Z lift, causing it to bounce off the bed and false trigger a second probing. I have created a short video showing what is happening available here: https://youtu.be/X79Ax5g6Eho

The first probe in the video shows the pin being pushed back out too quickly and causing the bounce issue. The second probe is normal.

My assumption is that this is related to timing. I.e. the servo signal pulse hitting the pin at just the right time in the trigger to force it back out quickly. Is there currently a way that I could slow this down to allow the cart to reach the full Z lift before spitting the pin back out? Or possibly, deactivating the servo signal once deployed and reasserting only momentarily again AFTER Z height is reached to redeploy it?

I would be happy to post my config or any other files needed to help find a solution for this.

Many Thanks in advance!

[Blue-Marlin]

You coult try to experiment with DEACTIVATE_SERVOS_AFTER_MOVE.

[crncrussell]

I currently have that disabled. My understanding is with that on, it would not send a servo signal again until the completion of the leveling process when the probe needs to be retracted. Is this not correct? Or would it re-asert the servo signal to push the pin back down after each Z-move?

One correction to above: I am on RC3, not RC4.

[Blue-Marlin]

No. What you are talking about is omitting the 'E' parameter of G29/M48.

Hmmm. My idea was more that deactivating DEACTIVATE_SERVOS_AFTER_MOVE could improve your situation. DEACTIVATE_SERVOS_AFTER_MOVE is not mentioned in their docu., so i assume Marlins default (off) is ok.

---

BLTouch is quite the opposite of open source.

_6. Do you have any patents? We have several patents and some are on patent pending. And we have already completed the patent application for this project.

Please ask the manufacturer for support.

[thinkyhead]

Do you see the same problem with RCBugFix? The code should be waiting (stepper.synchronize()) for the move to finish before changing the probe status. But perhaps the BLTouch is doing this automatically, as soon as it it out of sensor range…? Maybe it needs an additional delay…?

[Grogyan]

I use BLTouch and have had no problems with bounce.

@crncrussell Can you please post your configuration.h file

[crncrussell]

Configuration.h is attached. I have not had the opportunity to try RCBugfix yet, but will try that ASAP. I did attach an image also the ANTCLabs provides showing the timing of their probe if it helps.

For what it's worth, I know several people (probably hundreds by now...) are using the BLTouch with Marlin and no one else had seen this bounce issues that I am aware of. It's odd to say the least.

Configuration.h.zip

[Grogyan]

Try raising #define Z_RAISE_BETWEEN_PROBINGS 5 to 10mm

Also give RCBugFix a try as the configuration.h file shows that you are using an old version of Marlin

[crncrussell]

Thanks I will starting porting my settings over to RCBugFix tonight and give that a try. Aside from a few custom pins on the Ramps for the PT-100, I have to also port over a few small mods I have made to the temperature.cpp file to invert the logic of the heatbed pin. I use an ATX PS for my heatbed, and rather than wiring in a relay, I just inverted the logic and drive the ATX PSON pin to ground to turn the PSU on/off. Not sure what it is going to do to the longevity of the power supply, but it works great...

[crncrussell]

I tried Grogyan's suggestion of changing the Z_RAISE_BETWEEN_PROBINGS to 10 and that did not help. I have not had a chance to upgrade to RCBugFix yet to see if it resolves anything, but I have partially worked around what I am experiencing and think I have an explanation that makes sense:

I think what I am seeing is a combination of hardware and software. Short answer is I think the magnetic force the BLT uses to push down the pin is strong enough that when it hits the bed it bounces causing the false triggers, and because the timing of the signal from firmware, this is being pushed down BEFORE it has enough clearance to clear the bed.

The BLTouch has an adjustment screw on the back that increases/decreases the amount of magnetism of the internal electromagnet that repels the pin. What I was able to do was tighten this down significantly so that the pin is pushed out with less force and the bounce does not have enough momentum to false trigger.

The downside to this, is that by decreasing it this far on the probe, it is not always strong enough to retract it so that it passes the self test and can get out of the way.

So I think if something could be added to Marlin to allow adjusting the timing parameters so that the Z-lift between the first and second probe can be completed before the servo signal gets sent back to redeploy the pin, then the probe could be adjusted back to where the electro-magnet is strong enough to provide a reliable retraction.

I hope all this makes sense. I will keep this updated when I get a chance to load and test RCBugFix to see if it is any improvement on this vs RC3.

Thanks all!

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[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.