Unexpected error during probing - Probe tripped during non-probe move

[machmaker]

During the probing procedure, if the sensor causes contact bounce, an error occurs: "Probe tripped during non-probe move." The error suggests that a problem occurs during a move that is not part of the probing motion.

However, the error occurs during the execution of the probing procedure, for example:

G38.3 X-3 F150

When LinuxCNC detects the sensor triggering, it halts the procedure and save the trigger position value. However, the drive, as known, does not come to an immediate stop but decelerates with a specific acceleration.

If, during the deceleration of the drive, there is contact bounce in the sensor, LinuxCNC reports the error: "Probe tripped during non-probe move."

In my opinion, the halting of the drive during G38 is a continuation of the probing procedure and this error should not be reported. The error should be reported during any other move.

• I am using this Linux distribution and version: Linux Mint 20.2
• I am using this kernel version 5.4.230-rt80
• I am running a binary I built myself
• I am using this LinuxCNC version 2.9.1
• I am using this user interface (GUI) AXIS
• I am using this interface hardware: parallel port

[zz912]

Could you show us HALscope with probe signal during probing?

[machmaker]

The sensor in this case is an aluminum cube that the tool touches, causing the flow of current (yes, I know it's not a good device, but precisely because the device is poor, it allowed detecting this situation). Touching the sensor with the tool causes the occurrence of contact vibrations between the tool and the cube, resulting in a signal detected by LinuxCNC, for example, like this:

The code I execute is simply one line, for example: G38.3 X-3 F50 So there should be no error reported: "Probe tripped during non-probe move" because there is no movement here that is not a probing move.

If I set a small acceleration on the axis being tested, this error occurs very often, sometimes even several times during one measurement. If I set a very high acceleration, the error occurs very rarely. This suggests that the algorithm that executes G38, after detecting the sensor's action, treats every subsequent state change on the sensor as an error. However, after detecting the sensor, the drive still needs to decelerate, and it is still the same G38 procedure. In my opinion, a change in the sensor's state during the deceleration of the G38 movement should not be reported as an error "Probe tripped during non-probe move."

[zz912]

Did you try debounce signal? https://linuxcnc.org/docs/stable/html/man/man9/debounce.9.html

[machmaker]

Yes, I know. I'll handle the debouncing myself. I'm not reporting this as an issue I can't solve, but rather as a suggestion for improvement - because in my opinion (as logic suggests), this error should not be reported during the execution of the G38 command, but possibly only during subsequent calls of a different movement.

[zz912]

Ok. I apologize, I cant help you. Maeby somebody with more skills can help you.

[andypugh]

in my opinion (as logic suggests), this error should not be reported during the execution of the G38 command, but possibly only during subsequent calls of a different movement.

I agree with you on this.

What does motion.motion-type do during this sequence? I guess it resets immediately on first contact and then the error is flagged during the decelleration stage.