new Component probefilter to handle "probe tripped ... errors"

Its good you have got your hands dirty early in your linuxcnc journey. As always, there are many approaches to solve this problem.

When I faced this, I modified my probing gcode routine to set a digital output true from gcode and false after probing.
Then you can and2 the probe output with the digital output before connecting to motion.probe-input.

Another robust component based approach would be to read motion.motion-type and only output a probe output when it equals 5. 
ref: linuxcnc.org/docs/2.9/html/man/man9/motion.9.html#MOTION%20PINS

Do you use the same cheap method of just contacting the tool to the workpiece for probing, or do you use the gated approach with a fancier, better probe?

As I wrote, I saw the probe errors even though I gated the (cheap) probe with and2 as you suggested. And after reading the relevant source, I think that is also to be expected, as the probe status might jiggle around after the probing is done but whilst the motion controller is still in probing mode, as those are two different state flags. This jigging can then trigger an error from the probe routine. I didn't try to check the motion.motion-type method but because of this, I'd expect it to not solve that problem either.

A better probe would solve what I am seeing, or said in another way, hide what I think is a peculiarity of the probing process. Using a 'double-sided monoflop' solves this peculiarity, at least for me.

This is also not something that happened very often - after I tuned it just about every 200th probing move or so. But still often enough to become a major annoyance when probing a grid.

Edit: I wrote above: "I also got several messages of the type "probe tripped during non-probe move" even though the active gcode line shown in Axis was right on the G38.3 statement.". I meant this within the context of having it surrounded by M64/M65 statements gating the probe through the and2. The problem is that this approach does not solve any bouncing of the probe after the probing is done but when the motion controller still executing the G38 command, as the logic within the probe routine is so that it triggers an error on any change of the probe input (to guard against crashing the probe in a normal move) even though the motion planner is still in probing mode.

I think one could fix this code by also checking that the motion controller is not in probing mode before raising an error, in this line in control.c:

---

} else if (!old_probeVal && emcmotStatus->probeVal) {
        // not probing, but we have a rising edge on the probe.
        // this could be expensive if we don't stop.
        int i;
----

This else path is executed when the "emcMotStatus->probing" status is false. But, again, that is different to the motion planner's status flag "EMCMOT_PROBE" and after the probe has touched the workpiece, the motion planner is still in EMCMOT_PROBE state as far as I can see, while the probing code has reset emcMotStatus->probing to zero.  Physically, the probe is close to the workpiece still, and the noise that might be generated can then trigger this else path, leading to the "Probe tripped during non-probe move." - error. I haven't fully debugged nor understood the extra check for that error yet, but as I got the error with the and2-ing (which made the problem noticeable better) and with axis showing the G38.3 line, I must assume that it does not catch all potential problems. My mental model here (which might be wrong) is that the motion planner is still moving as it has to adhere to the acceleration limits even though the probe tripped and that passes this extra check "if (GET_MOTION_INPOS_FLAG() && tpQueueDepth(&emcmotDebug->coord_tp) == 0)".

It could probably be fixed by adding a check for the motion planner status here. Though this would also seem a bit like a breach of abstraction to me. And it would not fix the other potential problem, that the probe might trip repeatedly when pulling out of / away from the workpiece again. For that one would still need to and2-gate the probe. Using the dsmono approach fixes both problems. It simply makes the probe inert for a configurable amount (I chose 100ms) after it trips in any direction. This is IMO less complexity and it is also safer as it should not (but no guarantees!) keep linuxcnc from stopping when doing a normal move with an expensive probe attached.

ok wrote:

Do you use the same cheap method of just contacting the tool to the workpiece for probing, or do you use the gated approach with a fancier, better probe?
 

I was using it on a plasma machine for its ohmic probe to sense material height so it was just touching the tool to the workpiece. Will only be true during a G38 move so it will never trigger while machining...

[Still struggling with the forum code, I just wrote a reply that seems to have disappeared]

I see, yes that makes sense. This would be similar to my suggested fix of making sure that the motion type is correct within the probing code (but when the probing code thinks it is not probing).

However, doing it generally like that would make the probe insensitive also outside of probe moves, which would not prevent expensive crashes.

I want the probe to be also insensitive during a normal move when it retracts from the workpiece and might spuriously trip but I want it to be sensitive when I do a rapid move and prevent me from accidentally crashing.

On a plasma cutter doing sheet metal, I can imagine this is a lot less of a worry than on a mill with complex setups that one might easily crash into.

Does that make sense?
 

To summarize it a bit, I looked at the problem and saw that the whole probing process can be just very noisy, and that includes the "surrounding move" of retracting after probe. I think there is an attempted fix in the probing code to make sure it trips for spurious probe inputs only when properly machining, but that code (as the original poster also noticed) is incomplete and it is indeed possible to trip the probing code into an error after probing but while the motion planner still thinks it is in probing state. I was looking for a fix that is:

- as simple as possible
- makes the probing code not trip after being done with probing (*)
- does not interfere with the critical parts of probe tripping (machine moves)
- fixes the trouble of the normal-non-probe-pull-out-move tripping the probe
- does not interfere with more expensive probes that might have good logic/mechanics/eletronics to deal with (*) so that doesn't ever happen anyways but allows simple touch-probing

(It might interfere with retract-probe-G38 moves for expensive probes in the sense that it might delay the probe tripping if it is still with in the dead-time. But a simple dwell that is longer than the probe trip should address this one case and would allow switching probe types on the fly. Didn't test that yet.)
 

Unrelated, but I am quite proud of my probe design (it can be made very small, and has only two machined parts)
(In an earlier video I show a way to make it using only a drill press and a hexagonal collet block). Though a lathe is a big help too.