How to fix "Queue is not empty after probing"

I'm setting up my tool height setter and am having a similar issue.  It is not happening every time, but I'd say around 50% of the time i run the command.  I am running 2.9.4, gmoccapy and on an intel N100 PC and have no other latency issues.
Full error line is: emc/task/emctask.cc 68: interp_error: Queue is not empty after probing.  The other odd thing is when I don't get the error, #5063 will have a good value in it, but #5070 never gets set to 1

Gcode for the probe sub:
o<tool_probe> sub
O100 if [#<_task> EQ 0]
O100     return
O100 endif
G17 G20 G49 G90
G0 G53 X35.52 Y13.415
G0 G53 Z-7.0
G91
G38.3 Z-4 F10
(DEBUG, Z#5063)
G90 G53 Z-4.0
o<tool_probe> endsub
 

This is not a full fix, but it reduced the issue from 50% to less than 10% of the probes.  I added in a 'Queue-Buster' if statement.  see the bold/italic lines below.  If anyone has any better solutions I'd love to hear them, but for now I think I can move forward with my machine. #5070 will be set to 1 maybe one time out of 50.  If anyone knows the source file where the 'Queue is not empty after probing' is coming from I'd be glad to look myself.  I found the listed file in my last post, but it seems to be a general error reporting function and not the source of the error.

o<tool_probe> sub
O999 if [#<_task> EQ 0]
O999     return
O999 endif
G17 G20 G49 G90
G0 G53 X35.52 Y13.415
G0 G53 Z-8.5
G91 G38.3 Z-4 F10
O998 if [#5063 GT 1.0]
    G91 G0 Z0.1
O998 else
    G91 G0 Z0.11
O998 endif
(DEBUG, Z#5063 #5070)
G90 G0 G53 Z-8.5
o<tool_probe> endsub
M2

I now have the same issues.  
Happening after ~250 probe commands or so. All at different positions; of course also encapsulated in oword-loops.  

 

Initially, I only had severe problems with bouncing and had to fix it with a flipflop (which works fine):  
www.forum.linuxcnc.org/38-general-linuxc...move-deadlock#332412

And now this.  
Is this even related to the probe command or is it also possible that the origins are something completely different?

This all was never an issue with (really old versions; I probed millions of positions.


Meh,
AS
 

If anyone knows the source file where the 'Queue is not empty after probing' is coming from I'd be glad to look myself.

Likely these:

github.com/LinuxCNC/linuxcnc/blob/master...s274ngc_pre.cc#L1470
github.com/LinuxCNC/linuxcnc/blob/master...s274ngc_pre.cc#L1545

With a comment here:
github.com/LinuxCNC/linuxcnc/blob/master...s274ngc_pre.cc#L1514

A lot of things could go wrong there; why not check the "obvious error" ```[tm]``` first?  
Probably just a race condition?


Out testing,
AS
 

v2.9.7, encountered the same problem – Die Warteschlange ist nach dem Prüfen nicht leer.

I see that references to this string have been found in the source files.

From the description " 2. Das probe_flag ist wahr, aber die HME-Befehlswarteschlange ist nicht leer: NCE_QUEUE_IS_NOT_EMPTY_AFTER_PROBING" follows that such an error should occur, for example, in the combination -
g38.2
g38.2

But when executing g38.3 (single), such an error can never happen. Maybe it would be wise then to disable some of the checks completely for the 38.3 command option?

The process is greatly influenced by the speed setting -
1. The kinetic energy of an impact is a function of the square of the velocity g38.3 (strain)
2. the machine does not stop immediately. After operation, a stop occurs and during this time the Z coordinate changes. An example is flights: at speeds 110=0.006785, at 180=0.012583. According to the sensor documentation "scan speed 200". Acceleration at my Z axis = 5000.
3. the reverse stroke of g38.5, accordingly, first overcomes the flight from g38.3, then the hysteresis of the sensor and now braking and stopping with its flight. 

In my case, reducing the speed of the G38.5 from 300 to 200 increases the overall processing speed - by reducing flights (g38.3 at speed 110)

And if possible, please give instructions for (beginners) - I’ll take this file and make changes to it. How exactly to get the system to use these changes? I mean the timid hope that there will be a cunning way without a complete reassembly.