Probe tripped during non-probe move deadlock

Hi all,
I am running 2.8.4 and only recently noticed that none of my
(indeed very old) touch probe scripts/o-codes do run nowadays.

With this "new" (v2. probe behaviour, which seems to be activated
all the time - how am I supposed to move the probe, including bouncy
ones, off the material after it triggered?
As long as the probe is activated, all (G00/G01) commands fail and
immediateely abort the program.

That also was recently added to the repo tracker (not by me though
github.com/LinuxCNC/linuxcnc/issues/292

This behaviour makes it basically impossible to probe more
than one time, e.g. a grid etc.

Is there any workaround or am I missing something (new)?


AS

Okay; found a workaround.
Just in case someone is having the same issue:

I solved this with an additional AND gate and this
motion-digital-out-nn thingy, controlled via M64 and M65.

Example for a probe on a parport, here also with an additional
debug LED on parport pin 1 (strobe):


In the G-Code, just encapsulate the retraction move(s) with
M65 P0 and M64 P0:

Cheers
AS

It is possible to set up the HAL so that the probe signal is only seen during a probe move.

It's not a particularly elegant fix, as you need to use motion.motion-type
linuxcnc.org/docs/stable/html/man/man9/m...9.html#MOTION%20PINS
and only send through the probe signal when motion.motion-type = 5.
Unfortunately I haven't found a single component that can compare a signed integer (like motion-type) and outut a logical.

So it might be better to use a custom HAL component:
linuxcnc.org/docs/stable/html/hal/comp.html

Incidentally, there are two INI settings related to this, but I don't think that they help here:

linuxcnc.org/docs/stable/html/config/ini...tml#sub:ini:sec:traj

NO_PROBE_JOG_ERROR = 0 - Allow to bypass probe tripped check when you jog manually.

NO_PROBE_HOME_ERROR = 0 - Allow to bypass probe tripped check when homing is in progress.

You could try making a fast probe-away move (G38.5) to clear the probe from the work. (fast so that it overshoots out of the probe dither region)

Thank you very much Andy.
I will give this a try too, although I first need to understand this, hehe.

After some testing, my proposal does not work reliably.
After a couple of probing commands, the error comes back.

I first thought about a race condition, so I also tried the synced
M62/M63 and isolated everything with G04 dwell commands,
up to 1s, like this one here:

After some debugging, it's clear, that the G38 command itself
triggers this error. Most likely dIrectly after the probe made contact.
The short time between the (sucessful) end of G38 and my custom
"probe off" command seems to be the zone, where this happens.

If this is true, probably not even Andy's solution would work here.

To be clear, yes, there is a _lot_ of bouncing involved here.
I am directly probing with a 0.1mm cutter and the touch probe
is connected to the galvanically isolated material.

But this all was working in the past; I almost used this daily,
with previous versions.

Is there a latching element available in HAL?
A flipflop? That might help here, if it's fast enough.

Otherwise, the last resort would be a HW latch - if the bouncing
is the cause of this. If it's just the static "probe HIGH" signal;
well - no go.

My apologies for spamming this forum with stupid questions,
but I was short on time, hehe.

Finally, success. I outsmarted the probe with the Great HAL:

Then use M64/M64 P0 to keep the flipflop in reset during the retraction:


Out probing,
AS