Buildbotics Forum

We use a fixed probe for measuring the z-offset during initialisation or after tool changes. In order to get more consistent results, we let our z-axis approach the probe twice, once with F300 and then again with F100 after a small retract move.

However, sometimes the probing skips the second approach (?) and just retract z to the highest position.
There is no error code displayed and the script seems to continue as if nothing happened (G92 and G53).
This is the probing snippet we use in our program-start and tool-change scripts: It is a huge issue for us, because whenever this happens, Z0 is suddenly shifted off by up to 2mm.
We are basically unable to use toolchanges during programs now, since every one of them could cause the issue, requiring us to stop the current program to repeat the probing.

Does anyone have an idea what might cause this sudden abort/skip of the second probing approach?
What we tried so far is slowing down the Z motor, and adjusting the retract height between first and second approach. So far, this was not successful and we are still unable to consistently reproduce the issue.

I managed to take a video of a faulty probing, let me know if you want to see it

cheers
Vincent

Are your sure that your switch fully opens with the 1.5mm retract? You might want to try retracting a litter further before the second probe.

yes, that was the first thing we tested when the issue came up. Tried heights up to 10mm, but it never seemed to solve the issue and it still skipped the second approach roughly every third or fourth attempt

Have you tried adjusting the 'input-debounce' setting on the SETTINGS-> I/O page?

Feel free to call me at 707-559-8539 if you want me to help you via the phone.

Doug

Try putting in a dwell command (G4) just before the second downward probe. For instance 'G4 P2' would cause the system to wait for two seconds. If this works, you can try reducing the pause time the shortest value that works.

I think this might have something to do with the 'input-lockout' time that can also be adjusted on the SETTINGS->I/O page.

Hi Doug,
thanks for pointing me in the right direction! Somehow never noticed these switch/input settings!
I went with decreasing the 'switch-lockout' the other day since that made the most sense to me, and so far the probing hasn't been aborted again unexpectedly. Hard to say though if that actually fixed it, since we were never able to reproduce it accurately in the first place. We will monitor it over time and let you know if it comes up again 👍🏻

I’m curious about the potential negative effects of setting either of these switch parameters to a very small value. Could this lead to unintended behavior, such as false triggers or missed state changes?

It's mostly about switch bounce. All mechanical switches bounce and that can lead to subsequent triggering. These settings are meant to give the switch a settling time so the bounces are ignored.