Probe tripped during non-probe move deadlock
- AkkiSan
- Offline
- New Member
-
Less
More
- Posts: 11
- Thank you received: 1
26 Jul 2025 03:30 #332353
by AkkiSan
Probe tripped during non-probe move deadlock was created by AkkiSan
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
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
Please Log in or Create an account to join the conversation.
- AkkiSan
- Offline
- New Member
-
Less
More
- Posts: 11
- Thank you received: 1
26 Jul 2025 23:01 #332382
by AkkiSan
Replied by AkkiSan on topic Probe tripped during non-probe move deadlock
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
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):
net probepin parport.0.pin-11-in-not => and2.3.in0
net probeenable motion.digital-out-00 => and2.3.in1
net probefiltered and2.3.out => motion.probe-input parport.0.pin-01-outIn the G-Code, just encapsulate the retraction move(s) with
M65 P0 and M64 P0:
...
G38.2 Z#8
M65 P0 (turn off touch probe for retraction)
G0 Z#7
M64 P0 (turn on touch probe again)
...Cheers
AS
Please Log in or Create an account to join the conversation.
- andypugh
-
- Away
- Moderator
-
Less
More
- Posts: 23401
- Thank you received: 4971
26 Jul 2025 23:19 #332384
by andypugh
Replied by andypugh on topic Probe tripped during non-probe move deadlock
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
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
component probe-filter "Only pass-through probe when probing"
pin in signed motion-type;
pin in bit probe-in
pin out bit probe-out
;;
if (motion_type) == 5 {
probe_out = probe_in;
} else {
probe_out = 0;
}Please Log in or Create an account to join the conversation.
- andypugh
-
- Away
- Moderator
-
Less
More
- Posts: 23401
- Thank you received: 4971
26 Jul 2025 23:25 #332385
by andypugh
Replied by andypugh on topic Probe tripped during non-probe move deadlock
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)
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)
Please Log in or Create an account to join the conversation.
- AkkiSan
- Offline
- New Member
-
Less
More
- Posts: 11
- Thank you received: 1
27 Jul 2025 02:05 #332392
by AkkiSan
Replied by AkkiSan on topic Probe tripped during non-probe move deadlock
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.
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:
...
M64 P0 (turn on touch probe)
G04 P1
G38.2 Z#8
(also tried wating here)
M65 P0 (turn off touch probe)
G04 P1
G0 Z#7
...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.
Please Log in or Create an account to join the conversation.
- AkkiSan
- Offline
- New Member
-
Less
More
- Posts: 11
- Thank you received: 1
27 Jul 2025 15:00 #332412
by AkkiSan
Replied by AkkiSan on topic Probe tripped during non-probe move deadlock
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
but I was short on time, hehe.
Finally, success. I outsmarted the probe with the Great HAL:
setp flipflop.0.set FALSE
setp flipflop.0.data TRUE
net probepin parport.0.pin-11-in-not => flipflop.0.clk
net probereset motion.digital-out-00 => flipflop.0.reset
net probefiltered flipflop.0.out => motion.probe-input parport.0.pin-01-outThen use M64/M64 P0 to keep the flipflop in reset during the retraction:
...
G38.2 Z#8
M64 P0 (reset probe flipflop HIGH)
G0 Z#7
M65 P0 (reset probe flipflop LOW)
...Out probing,
AS
Please Log in or Create an account to join the conversation.
- andypugh
-
- Away
- Moderator
-
Less
More
- Posts: 23401
- Thank you received: 4971
27 Jul 2025 16:15 #332420
by andypugh
Replied by andypugh on topic Probe tripped during non-probe move deadlock
You could look at the HAL "debounce" too, to require ms of stable signal before tripping. But that does, in principle, lead to a position error (possibly small, at low probe speeds)
Please Log in or Create an account to join the conversation.
Time to create page: 0.107 seconds