Probe tripped during non-probe move deadlock
- djdelorie
- Offline
- Junior Member
-
Less
More
- Posts: 21
- Thank you received: 6
30 Jul 2025 15:51 #332563
by djdelorie
Replied by djdelorie on topic Probe tripped during non-probe move deadlock
I had similar problems with my toolsetter, and initially used an AND gate - until the time I forgot to enable it (I used a manual signal, not motion.*) and crashed my toolsetter. Then I tried smoothing, which worked OK. It turns out the toolsetter is a good seismic monitor, and trips when I have issues with toolchanging 
However, my comment here is... have you considered using a dummy probe move to retract the probe?

However, my comment here is... have you considered using a dummy probe move to retract the probe?
Please Log in or Create an account to join the conversation.
- DauntlessA
- Offline
- Junior Member
-
Less
More
- Posts: 23
- Thank you received: 5
01 Aug 2025 02:56 #332616
by DauntlessA
Replied by DauntlessA on topic Probe tripped during non-probe move deadlock
Hi Andy,
I believe that the issue I'm describing is exactly the one here:
github.com/LinuxCNC/linuxcnc/issues/2926
The last comment from that issue was you asking about the motion.motion-type following motion.probe-input going high.
I've looked in the halscope and it does seem that motion.motion-type remains at a value of 5 (Probing) until deceleration is completed, at which point the motion-type goes directly to 0 (Idle). So the issue isn't that the motion type resets immediately when the probe input triggers.
I was probing using just the X axis/joint 0 when I tested this.
I'll try and find out a bit more if I can.
I believe that the issue I'm describing is exactly the one here:
github.com/LinuxCNC/linuxcnc/issues/2926
The last comment from that issue was you asking about the motion.motion-type following motion.probe-input going high.
I've looked in the halscope and it does seem that motion.motion-type remains at a value of 5 (Probing) until deceleration is completed, at which point the motion-type goes directly to 0 (Idle). So the issue isn't that the motion type resets immediately when the probe input triggers.
I was probing using just the X axis/joint 0 when I tested this.
I'll try and find out a bit more if I can.
Attachments:
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 19620
- Thank you received: 4526
03 Aug 2025 19:09 #332746
by andypugh
Replied by andypugh on topic Probe tripped during non-probe move deadlock
The logic looks fairly simple, and is here:
github.com/LinuxCNC/linuxcnc/blob/2.9/sr...otion/control.c#L716
That only fails if "if (emcmotStatus->probing) {" (line 691) is false.
The confusion here is that I don't see any change in state in your motion.probe-in channel, it doesn't actually appear to be bouncing (or maybe only not in the plotted example?)
I don't know for sure that "SET_MOTION_ERROR_FLAG(1);" (line 726)drives motion.coord-error but it might be worth plotting that too.
github.com/LinuxCNC/linuxcnc/blob/2.9/sr...otion/control.c#L716
That only fails if "if (emcmotStatus->probing) {" (line 691) is false.
The confusion here is that I don't see any change in state in your motion.probe-in channel, it doesn't actually appear to be bouncing (or maybe only not in the plotted example?)
I don't know for sure that "SET_MOTION_ERROR_FLAG(1);" (line 726)drives motion.coord-error but it might be worth plotting that too.
Please Log in or Create an account to join the conversation.
- DauntlessA
- Offline
- Junior Member
-
Less
More
- Posts: 23
- Thank you received: 5
04 Aug 2025 17:22 #332829
by DauntlessA
Replied by DauntlessA on topic Probe tripped during non-probe move deadlock
Sorry, I forget to mention I'd started working on this, only saw you'd self-assigned the issue once I'd nearly finished!
But I see you've seen my pull request now, just linking it here for anyone else since I'll carry on discussion there.
github.com/LinuxCNC/linuxcnc/pull/3534
The test above doesn't show the probe bouncing, it just shows that motion.motion-type remains 5 (Probing), which is what I initially wanted to test.
In hindsight I should've just looked at control.c first, because the logic in there fully explains why the probe bouncing during probe move deceleration causes the issue.
Currently, after the probe is first triggered from a probe move, it doesn't matter what the motion type is, because it's either the first and only valid trigger during a probing move, or a trigger during a non-probe coordinated move.
So the simplest fix to just give an accurate error message which checks the motion type to determine the error message (which is where having confirmed that the motion.motion-type remains as probing for the entire probe move is ideal).
But I see you've seen my pull request now, just linking it here for anyone else since I'll carry on discussion there.
github.com/LinuxCNC/linuxcnc/pull/3534
The test above doesn't show the probe bouncing, it just shows that motion.motion-type remains 5 (Probing), which is what I initially wanted to test.
In hindsight I should've just looked at control.c first, because the logic in there fully explains why the probe bouncing during probe move deceleration causes the issue.
Currently, after the probe is first triggered from a probe move, it doesn't matter what the motion type is, because it's either the first and only valid trigger during a probing move, or a trigger during a non-probe coordinated move.
So the simplest fix to just give an accurate error message which checks the motion type to determine the error message (which is where having confirmed that the motion.motion-type remains as probing for the entire probe move is ideal).
Please Log in or Create an account to join the conversation.
Time to create page: 0.145 seconds