User error or a strange event on probing. Broken ruby tip.

I have had probing working for a bit and its been solid.  But today I had a strange event happen, not sure if it was me or something else.  I don't believe the settings are different than before.  Not sure what to even check.

I was probing Z only, and things started fine, the probe was going at the slower rate, tripped, then instead of backing off (Z+) it continued at the fast feed rate (Z-).  Another ruby tip smashed.

I tried again, and it did the same thing.  For a third test, I jogged x-y away from the part, and also jog z+, and tried on a "test" part (just a flat pen held off), and it worked fine, and now it seems to work fine.

What would cause a probe cycle to continue vs backing off?  Or did I make some mistake.  Either way, I want to avoid this again... probe tips are expensive.

Sounds like you have some electrical noise or maybe need to add some debounce. Remove slow feed by changing to 0.0 and just try using fast feed rate. If you move to slow probes can sometimes double trigger which cause issue. It's best to use a bit more speed. As long as you calibrate at the speed you probe at, you should retain consistent repeatable results

Is there any logging behind the scenes to know that really happened? As this was working reliably in the past, I was not 100% focused on watching it. It would be good to know when it was tripped and what the feed rate and direction were.

Thanks

you can add all the logging you want in the subroutine, but its not an issue with the probing routines as i use them daily hundreds of times a week without issue. some folks have noisy systems or less rigid machines that may be problematic, moving head routers come to mind. but in most cases it is either debounce needs to be added in the halfile for that input to stop false triggers and force the signal to be solidly recognized and latched before accepting the probe trip as an actual event.

I was not implying there was an issue with the subroutines. While I don't use them as much as you, I have used them quite a bit without any problem. Additionally, my machine is a Bridgeport BOSS, which is quite rigid.

Having a log would provide the facts of what really happened, rather than relying on what I think I saw. Again, as probing has worked flawlessly, I was not 100% focused on the details. It looked like it triggered on the Z and kept going. I always test the probe connection prior to probing, with a manual trigger. So knowing if it triggered, how many times, the feedreate and movement, in chronological order, I could solve this definitively. I was thinking of saving the last 2-3 probes and rolling the logs so one the past probing, but not wasting disk space

Im saying you can add debug in the routines or try reviewing the logs linuxcnc leaves behind. You could add print commands in the routines that only print to the terminal log, just a matter of crazy you want to get with it. I used several while writing the routines as sanity checks.

But its almost always debounce issue, noise, possibly worn pitt d contacts in the probe or a too soft spring in the probe. I've owned about everyone under $300 at some point or a other. They are pretty well similar. If using 24v the contacts can pit if not lubricated with the correct grease fro repetitive micro arcing.

I would take it apart and clean it really well and put the special grease in check your spring pressure maybe give it a stretch.

Set some debounce in hal.

And bump your feed speed up. I don't even use the slow probe anymore so waste of time. My fast probe at 8 in a minute and call it good. Repeats within a tenth or two and is more consistent than fast+slow.