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?
 

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.

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

Colleague, please publish the entire part of the hal file for controlling the probe shutdown? Including the commands addf + loadrt + something like this net probepin parport.0.pin-13-in-not => and2.3.in0

need for v2.8.4
I created a program file and embedded debug messages into it. It was established that the error was triggered directly during execution of the g38.5 command

===========
            (LOG,стр 65 )
        #5070=1
        (LOG,X#5061 Y#5062 Z#5063)
        #5070=1
             (LOG,стр 68)
        #5070=1
        G38.5 F[#<_скорость_отскока>]  Z[#<_z> + #<_отскок>] 
             (LOG,стр 70)
===========
there is an entry in the log "стр 68", the machine was stopped by mistake and the state of the sensor - it drove away and in the "no contact" state #5070=0

Buster.
If you teach how exactly, poke your nose into the "download, enter" type of instructions, then I can. Alas, in this area (patches, sources) I am weaker than in other areas.
While I’m trying to put v2.9.4 on the free partition and even with this there are problems - in the instructions
linuxcnc.org/docs/2.9/html/getting-start...#cha:Installing-RTAI
the required repository is specified with an error, the kernel itself is installed with errors, and For several years now they have forgotten to indicate in the instructions what to do first -

apt-get purge linuxcnc-uspace
apt-get purge linuxcnc-doc*

and then more
apt-get install linuxcnc