How to fix "Queue is not empty after probing"

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.
 

My recommendation is to migrate your plasma machine to use qtplasmac which has obsoleted the thcud component.
It does not use g38 but probes with external offsets and also retains your probe away from the material.

I have used gcode probing for plasma without issues. I suspect your problem is related to your gcode given M130 is a custom gcode.

I would do some testing of your probe moves as MDI commands to isolate your GUI and custom gcode

it seems to me that this is "not sporty". Together we must force the correctly given commands to be executed correctly. G38.3 should not produce such errors.
You suggested changing the interface to qtplasmac, but it uses the same g-code and linuxCNC. And I have a milling machine.
Unfortunately, my level (of knowledge) is not yet such that I immediately understand the "right path" from the hints of the M130. I would appreciate more precise instructions.
Editing the source code file, as suggested by AkkiSan and Aciera, in my opinion = the right path. And I would be ready to experiment. But I need instructions on exactly how to get v2.9.7 to use these changes.

I must admit with bitterness that version 2.8.4 with its errors in the g38.3+g38.5 part (Probe tripped during non-probe move) works more stably than version 2.9.7 with all its fixes and error (Queue is not empty after probing). The same object (on the machine desktop), ode and the same g-code program, but in version 2.8.4 there are about 60,000 continuous measurements, and in version 2.9.7 there are no more than 40,000.

Published error traversal methods based on wrapping a signal through a digital input cause g38.5 to fail and be replaced by G0 or G1 - an erroneous path due to poor accuracy and surface finish speed. I experimented and compared the smoothness of the result with G38.5 versus G0\G1. To use G0\G1 for rebound, you need to set an excessively large amount of upward rebound, which radically reduces the speed of surface treatment and just as significantly increases the noise of the operation.
Conclusion: we must fight to correct the error.

Please correct me if I'm wrong.
Dealing with a previous mistake
forum.linuxcnc.org/38-general-linuxcnc-q...ue-with-g38-5#337899
it was completed with a victory via a patch -
github.com/LinuxCNC/linuxcnc/pull/3537/c...54ead378bbe05398b9d2

This patch changes the src/emc/motion/control.c file
I prefer the idea of using versions with a real-time kernel, which obliges me to use version 2.9.4. The version of this file in the source code 2.9.4 and 2.9.7 differs in the inserts for this patch. Therefore, I bring this file for version 2.9.4. to the state version 2.9.7 = error correction "probe tripped during non probe move"
Then to implement the version of the respected comrade. AkkiSan from forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578
changes should be made to the src/emc/rs274ngc/rs274ngc_pre.cc file (this file is the same in versions 2.9.4 and 2.9.7 before the fix).
Then you need to build and run.
The trouble is that I have an ArchLinux fast car, but a combat car with a machine tool is leisurely. I'll try to collect it.

abs32 wrote:

it seems to me that this is "not sporty". Together we must force the correctly given commands to be executed correctly. G38.3 should not produce such errors.
You suggested changing the interface to qtplasmac, but it uses the same g-code and linuxCNC. And I have a milling machine.

The difference is that  qtplasmac does not use gcode to control the torch height and it does not use Gcode to probe for the surface. Any gcode affecting the Z axis are ignored as they are filtered out when the file is opened.\. As I said that is al done with external offsets. That is, external to the motion controller. Please watch my video overview wnad read the comprehensive explanation in the comments. 

In the implementation of the version of the respected comrade. AkkiSan from forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578

there is a typo that emerged during compilation -
instead of -
esleep(0.010);

necessary -
usleep(0.010);

So far, I’ve taken turns backporting to version 2.9.4 and running matrixkins + Probe tripped during non-probe move

The first attempt to use the AkkiSan forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578 sentence

it showed a strange result - the signal #5070=1 and ... stopped appearing.
If there are specific proposals for correction github.com/LinuxCNC/linuxcnc/blob/master...4ngc/rs274ngc_pre.cc

I'm ready to test them in practice


I was not too lazy to download the source code of different versions of the program. In my (previously) main 2.8.4 this error never appeared, the records were 59,000 continuous measurement points. So the file src/emc/rs274ngc/rs274ngc_pre.cc before version 2.9.7 has not undergone any significant changes. The block of code we were interested in remained unchanged