How to fix "Queue is not empty after probing"

Can someone help me, how to solve the error "Queue is not empty after probing"

I built a controller for a fiber laser using a floating head system. When the machine starts running everything is fine, but after a few minutes of running, then it stops, and shows "Queue is not empty after probing"

 
​

What routine are you using for probing?
Config files?
When you say "floating head" is that where the Z axis moves down till it touches the material to trigger the switch?

There has been a similar report here, seemed to be maybe PC hardware dependent:
www.forum.linuxcnc.org/38-general-linuxc...ter-probing?start=10

Are you actually using a probe routine?

Yes, I use G38.2 to find material for cutting.



M130 (activated motion.probe-in)
G38.2 Z-10 F800 (probe motion)
M131 (deactivated motion.probe-in)
M3 S1 (THCUD system floating contact)

(cutting code)

I use a core i3 processor, gigabyte motherboard, 8gb RAM

I assume you have checked latency as I have a older i7 3.5gb *gb ram and it is useless for linuxcnc because of massive latency spikes.

John

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