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.

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

There should be no need for any HAL trickery now, the issue is fixed in the latest LinuxCNC release. (2.9.7)

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

Why do you need 2.8.4?
Are you stuck on Buster (or even Stretch / Jessie?

You could, in principle, patch 2.8.4 with the updates made in 2.9 and recompile.