How to fix "Queue is not empty after probing"

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.