Probe tripped during non-probe move deadlock

More
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?
 

Please Log in or Create an account to join the conversation.

More
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.
Attachments:

Please Log in or Create an account to join the conversation.

More
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.

Please Log in or Create an account to join the conversation.

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

Please Log in or Create an account to join the conversation.

Time to create page: 0.145 seconds
Powered by Kunena Forum