Probe tripped during non-probe move deadlock

As a result, I started experimenting with Z-axis acceleration settings to reduce braking time. Previously, the acceleration was set to 2000. When I set the acceleration to 6000, no errors occurred over 14 hours of operation (115,000 measurements). When I set the acceleration to 12,000, I got an axis misalignment error. It works acceptably at an acceleration of 9,000.

@AkkiSan
github.com/LinuxCNC/linuxcnc/pull/3971
could you test this?

The axis desynchronization issue was caused by an error in my INI configuration—the parameters I had set required a frequency higher than 50 kHz. I changed the servo period, and the error disappeared.

“Probe tripped during non-probe move” is resolved by setting delays. In my case, using an electrical capacitor. Over 2 million activations.

This leads to the conclusion that it would be appropriate to implement a Probe delay parameter in the machine settings. “Feedback” delay. That is, when the probe triggers, the machine must immediately recognize this and begin braking, and then even execute the next command (typically, recording and rebound). And the specified parameter in seconds or milliseconds should not react to a change in the probe’s state.

I mentioned this here: forum.linuxcnc.org/39-pncconf/58480-conf...g-dual-y-axes#344832

I have "write a better debounce module" on my todo list. No guarantees

I have a probe that bounces during the G0 move away after probing.

djdelorie wrote:

I have a probe that bounces during the G0 move away after probing.
 

You can reproduce the queue error?

I don't know what you mean by "queue error" but here's my situation:
I have a pair of mechanical NC probes, one toolsetter and one touch probe. Both are a bit sensitive to machine vibrations (the machine is aluminum extrusions) so I added debounce to reduce those. The toolsetter still trips when I rip a pocket off, but that's useful
However, because of the debounce, the probe trip is now delayed and unpredictable, so I have to probe very slowly.
The probe operation is:
* probe towards, record hit.  Speed in the 1-2 in/min range
* probe away, record hit.  Average the hits to get the final result
* G0 away to clearance.
The problem happens when the "probe away" is still unstable during the G0 move (there really isn't a "deceleration phase" here).  I suspect it's a symptom of the probe design, as it gets *worse* as I go slower, as if the contacts were scraping past each other (yes, I know it's not that kind of probe).
 

"Queue is not empty after probing" error message, is the issue I am hunting for, trying to find anyone that can reproduce this, and see if my patch fixes it, I think your problem is something different, and it is correct that the machine stops when the probe is flickering, the "Queue is not empty after probing" is something different that in theory should not happen, trying to find users that get this message.