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.8) 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

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

As far as I'm aware, motion.probe-input only causes the "probe tripped during non probe move" message if the pin goes high during a non-probe move, not if it's already high.
(I know you figured that out, just wanted to state directly that in theory there's no issue with a non-probe move which starts with the probe triggered)
The real issue is, as Andy says, is that the raw probe input is going to bounce and cause the "probe tripped during non probe move" message, and halt the subsequent move/jog.

But, actually, most of the time this behaviour occurs during probing, it's during the deceleration phase of the probe move itself (as you mentioned). This was opened as an issue last year:
github.com/LinuxCNC/linuxcnc/issues/2926
While you can work round this in hal in various ways (many already discussed), ideally I think this should be patched.
When I had this issue I also thought the same as the title of this post, that the probe must be triggering during the pulloff move (on account of the message wording) when actually it was occuring during the probe move itself. This is confusing and the "probe tripped during non probe move" message is somewhere between misleading and incorrect in this context.
The way I see it is that the deceleration phase is definitely part of the probe move, since you can't have a probe move without deceleration. Therefore, it doesn't make sense to claim that a trigger during a probe move deceleration phase should be treated the same way as a trigger during a jog or commanded non-probe move. The fact that this behaviour only seems to be worked around definitely supports this view.

But I get how this might be complicated to patch if it is the case that the motion type can't stay as "probing" and so is set a different motion type, which causes this issue.
I'm assuming that the fix isn't as simple as keeping the motion type as "probing" after the first trigger, because then subsequent bounces would also be registered as triggers to update the probed position variable? And that definitely isn't ideal, if you commanded one probe move, you shouldn't get several updates to the probe result when only the first one is the canonical result.
So ideally you'd just want to set a flag in the motion type used during deceleration to ignore further probe inputs until the end of that move? Or create a new motion type for "probe decelerating" which has this applied by default?

Either way, this doesn't solve the issue of bouncing during the subsequent pulloff moves. But since the pulloff move is typically at a much higher feed, it's far less likely to be affected by this issue.

And yeah, debounce does work for this, and the increased latency isn't actually a huge issue (as long as it is repeatable) if you calibrate the probe on a known artefact at the probing speed(s) you're planning to use. Probe Basic has this built into the probing routines.

But re. your flipflop logic, you're essentially using the same logic I'm using, which is the "dsmono" component from this comment here, which also makes the the probe "sticky":
forum.linuxcnc.org/24-hal-components/423...rrors?start=0#269004 
(In fact I'd recommend reading that thread from the top, lots of good info)
I think the advantages of dsmono (or implementing the same thing using EDGE) over your component are that you don't need to add M64/M65 to your probing routines, and the pulloff move is protected once the "sticky" period expires.

This is indeed a much neater method, great! I also solved it quickly and durty with an AND gate. But creating your own component is much nicer in the Hal code.
If I have an evening off, I'll play around with creating a comp.