How to fix "Queue is not empty after probing"

The second example is compiled-out by
github.com/LinuxCNC/linuxcnc/blame/maste...s274ngc_pre.cc#L1542
(But I am not clear why, the commit message doesn't really say: github.com/LinuxCNC/linuxcnc/commit/b96c...de5e67d2dde0339bece3 )

So, it must be the first one causing the issue.

Did you try adding a queue-buster as suggested? (Not that that is the right fix, but maybe it will tell us something)

Yes, I tried it and reported the result—it doesn't help.

I conducted a large series of experiments with different sensor settings and different ini + hal settings.
First, I achieved smooth operation of the sensor (of my own design) in version 2.8.4. The Chinese sensor could perform 40,000-50,000 continuous measurements (with 38.5 disabled). My sensor completed the entire task, more than 500,000.
That is, it has been established that the quality of the sensor directly affects the appearance of the error “Probe tripped during non-probe move”.
And with the same settings in version 2.9.7, the error “Queue is not empty after probing” recurs. That is, the appearance of the error does not depend on the sensor. The question remained: does this error appear during the working stroke 38.2-38.3 and the reverse?
I disabled the “until open” movement option, as in version 2.8.4, and the error “Queue is not empty after probing” did not appear. Previously, it was not possible to obtain more than 25,000 measurements. The experiment was interrupted at 40,000. Consequently, the error “Queue is not empty after probing” occurs when executing g38.5, during execution. After g38.3, I have a G1 up command.

To disable the possibility of 38.4-38.5 on the defunct Russian forum (к сожалению, я не помню имени автора решения, но честь ему и хвала), such a modification of hal was proposed and tested by me over hundreds of hours of work and hundreds of thousands of measurements -

@ abs32

can you share a screenshot after running on your system

latency-histogram

for a few minutes with a few glxgears running?

да пожалуйста.
According to my observations, the queue error simply replaced the error  Probe tripped during non-probe move.

could you run
latency-histogram
instead of latency-test?
I think you might be onto something, I use a custom version with probe tripped during non-probe move disabled, and I never see queue error...

I just checked master has new option for

[TRAJ]
NO_PROBE_JOG_ERROR = 1

in the .ini file, you could use that to check if the issue goes away?

you have to make sure your version supports this, it's just been added 4 months ago

This feels like possibly a race condition, I wonder what happens if the queue-empty check is just disabled?
(ie, I wonder if it indicates a real problem?)

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

I guess tomorrow I’ll reboot the machine’s computer to version 2.9.8, reinstall the real-time kernel, and apply all the updates—but won’t that be version 2.9.x? And I’m ready to try running the cycle. If you could provide a link to the 2.9.x build for the real-time kernel (or userspace), I’ll be able to test it.