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

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

That indeed looks like a very nice design. I couldn't quite figure out the details of your contact pins from the video, though: Do they have still some kind of mechanical hysteresis? If not, do you use some kind of hal or electronical filtering of the probe signal?

Note that if you are using a 7I96S and INM, you already have debounced inputs
(you can change the timing but the default is quite slow)

Hmm, I must admit that I have not looked too closely at the details of Mesa configuration parameters yet. All I did was to use the pcncconf GUI tool (or however it is spelled) to create a Mesa configuration with defaults and then wired the probe directly to the input. I didn't change any defaults, and still got bouncy test probe results ... it didn't really seem to help me either

It seems like it might sense to actually go the other route then and decrease the delay with my additional HAL logic in place?

Do I remember/see correctly that you are the main developer of the Mesa cards?

Maybe that would be a suggestion then from me: To add a FPGA component that would do the job of what I wrote above as 'dsmono'?

That would avoid the additional delay of using a filtering solution and might improve probing results.

Maybe that would be a suggestion then from me: To add a FPGA component that would do the job of what I wrote above as 'dsmono'?

In general, if better than servo thread resolution is not needed, I think this kind
logic belongs in a hal component. That said, there is a oneshot hardware
component that could be used for this kind of application. If setup to generate
a retriggerable 100 ms pulse on the proper input edge, its seems like it would
mask the input after the initial edge detection in a way similar to your component.

So the idea is that in the hal you do a and2 on the motion type and the and2 would be 5 and then this would output a bit of 1 or 0. Do you have an example of this?

rodw wrote:

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. 

motion.motion-type OUT S32

These values are from src/emc/nml_intf/motion_types.h.

0: Idle (no motion)

1: Traverse

2: Linear feed

3: Arc feed

4: Tool change

5: Probing

6: Rotary unlock for traverse


ref: http://linuxcnc.org/docs/2.9/html/man/man9/motion.9.html#MOTION%20PINS