Probe tripped during non-probe move deadlock

I installed version 2.9.4 and 2.9.7 and they work worse, replacing this error with another one - Queue is not empty after probing.
In this regard, I ask you to publish a complete road map on what is quoted here forum.linuxcnc.org/38-general-linuxcnc-q...obing?start=0#333528 "
a solution to this topic.
It says about "Great HAL": www.forum.linuxcnc.org/38-general-linuxc...dlock?start=0#332412

Now I have such entries in hal -
By analogy with "Great HAL" I assume this -

However, how can this be related to the M64 P0 + M65 P0 call?
It is not clear why the Greet HAL example contains addf flipflop.1 (in addition to addf flipflop.0) if flipflop.1 is not used in any way according to the example?

Do you still get this error without the flipflops and filters etc? Noe of this HAL complexity should be needed.

If there is a problem (possibly with repeated G38.2 commands) than please raise an issue on the Github so that it can be tracked. Not everyone reads every forum post (I don't) and so the forum is not a good place to report issues.

github.com/LinuxCNC/linuxcnc/issues

This error appeared and continues to appear in versions 2.8.4 and 2.9.4 when executing G38.5. By tricking hal for version 2.8.4, the problem is partially solved.

It is impossible to verify that the problem has been solved in version 2.9.7 because a new error, “Queue is not empty after probing,” appears much more frequently in it (and in 2.9.4 as well) -
forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#338958
github.com/LinuxCNC/linuxcnc/issues/3650

I tested a „clean“ 2.9.7+ setup, without my M64/M65-flipflop solution, but no, the issue was not (completely) fixed.

It kinda improved, but the „probe triggered“ fault is still happening.
I was not able to finish even shorter milling programs (<5 mins).

But the „queue full“ bug did indeed not appear anymore.

AkkiSan wrote:

 without my M64/M65-flipflop solution, 

 

Please publish your solution in full, including function declarations such as loadrt + everything, everything, everything. So that I can repeat it.

AkkiSan wrote:

It kinda improved, but the „probe triggered“ fault is still happening.
I was not able to finish even shorter milling programs (<5 mins).

The updates in 2.9.7 fix (hopefully) a bug where the "probe triggered during non-probe move" error was raised when the machine was actually probing (due to probe contact bounce). 

If you are seeing the message when _not_ actually probing (and you refer to a 5 minute milling cycle, with no mention of probing) then that is a different issue. 
 

andypugh wrote:

The updates in 2.9.7 fix (hopefully) a bug where the "probe triggered during non-probe move" error was raised when the machine was actually probing (due to probe contact bounce). 

Am i understanding this correctly:
A software solution was implemented in LinuxCNC for a hardware problem/issue ?
It does seem like it, or what am i missing?

Perhaps due to the language barrier, we are misunderstanding each other.
1. There was a bug in version 2.8.4, which was fixed in 2.9.7.
2. Instead of fixing the bug that was interfering with the operation, they created a new one for which there is no solution.

However! First, I used a steel probe (before electrical contact) as a probe. Then I bought a Chinese Probe sensor (a so-called center finder). It did not suit me for a number of reasons:
1. Unacceptably high operating force (“out of the box” 450 grams, with my processing “with a file” (and a hammer) about 220 grams.
2. speed of operation
In version 2.8.4, I got 50,000-80,000 continuous sequential measurements at a rate of 5,000-6,500 per hour. But in version 2.9.7, the usual error for 2.9.7 appeared

And the other day I made my own version of such a sensor. The actuation force is 15 grams. The operating speed is higher (to such an extent that during G0 movements, the vibration sensor is triggered). But in version 2.8.4, I haven't exceeded 10,000 continuous measurements yet. In version 2.9.7, I got up to 12,000 measurements per hour, and now (tests are being conducted right now) more than 13,000 measurements without errors.

Conclusions: it is quite possible that version 2.9.7 works adequately with high-quality sensors.

I rejoiced too soon. After 17,000 measurements 2.9.7, the error forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#338958

tommylight wrote:

Am i understanding this correctly:
A software solution was implemented in LinuxCNC for a hardware problem/issue ?
It does seem like it, or what am i missing?

Not really. The problem was that LinuxCNC was setting the status to "not probing" before the end of the deceleration stage of a probe move. In cases where the probe triggers more than once (as many will) this led to a "non probe move" error during a probe move. 
Discussion here:
github.com/LinuxCNC/linuxcnc/pull/3534
In response to this bug report:
github.com/LinuxCNC/linuxcnc/issues/2926