Queue is not empty after probing

Hello everyone,

I use codes that probe parts a lot, and every once in a while linuxcnc stops and gives "Queue is not empty after probing" error.
Interesting enough running the same exact gcode doesn't present problems, i made a custom hal and a gcode so you guys can test this too.



Add the custom.hal to the 9axis configuration ini file and run the smartprobe-mod.ngc code, sometimes error comes up after few minutes, sometimes it takes hours, but it will come up.

I've seen in the forum some other users experiencing this, but no clear reproduction method, the best method i found to make the error come up is just probing constantly till the error comes up, right now my test files are probing on very short distances, but feel free to increase the distances, the error will come up eventually.

I'd also like to know why this error comes up and a possible fix...

this comes up if you probe x times same position and do not readout the Parameters
interpreter expects you may hit a 90deg Wall and your probe gone break so it stops

You can change the position it will come up, the problem is almost random, it may come up after 1000 probes, or after 18000 probes, it's not always an x ammount that is defined anywhere.

I just made a code to probe very quickly in the same position for demonstration purpose, the error will show up even if the position that it gets is different, even if the probing time is long, make any probing loop, and run it for a couple of hours, the error will come up, if you can make it not come up, I'd be interested in seeing the g-code.

After probing 10005 times, i was bored waiting for the error, then aborted. The code is simple z probing at same x y position, without loging, only debug the testcounter.

Took 28178 probes but it came out, i know it may take a while, sometimes hours, but it will always eventually come out, let it run trough the night, you don't have to stand there watching it...

It is impossible for me, to evoke this error. This time probing 36000 times, also on release, G38.4, so it was 72000 finally. As I did not want to use the touch probe, I rewired the triangulation sensor to do this test. It's a bit picky about the material used. Wood and non glossy surfaces work well, but with polished steel or aluminium the results are not trustable. The other thing is, because of the construction, there is one direction to approach the edge, maybe from opposite side results loose accuracy. Sidewards is useless to do, if you want usable results.

For this test, there was a travel distance to trigger, G38.2, about 0.65mm. The release trigger, G38.4, was in the area of 0.07mm, so the hysteresis of this device is roughly 0.6mm from trigger to release, F500 programmed.
If someone is interrested for the repeatability, there is the logfile. Unfortunately I only saved the release trigger, which is less accurate. Telling about this sensor, is just to describe the setup used. As i am unable to produce any error while probing, i stop testing.

Thank you very much for spending time testing this, it's really amazing that the error doesn't come up to you, haven't had a setup without error.

What kernel you using? what version of linuxcnc? what hardware is it running on? motherboard cpu ram...

I ran the same code as you trough the night again and it came up again with the error after 18617 probes.

I tested your new code on my setup, error came up after 489 probe the first time and 298 probes the second time, that's the quickest i have seen on my setup, i have no idea why it's not coming up for you...

EDIT:

Maybe i have an idea why, i built linuxcnc 2.9 from github that i downloaded a while ago, and seems like the error is not coming up as quickly, i got to 30792, what version of linuxcnc are you using? i'll try with the latest master..

I installed DEBIAN Stretch ISO, 2.7.14, Mainboard is Gigabyte GA-Z68AP-D3, enough DDR3 RAM, the onboard graphics must be deactivated. HIS Graphiccard, 60GB SSDD. The BIOS was Gigabyte-like difficult to adjust for Linuxcnc, before with parallelport was even tougher. Now I have a Mesa 7i76E card. The latency is about 6us with 4 GLX Gears running, the spikes ocuring sometimes, reaching 73us are not high enough to disturb. Testing was done on this real hardware.