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

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.

ok wrote:

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?

I use filtering in HAL, the contact pins in my design have all the faults and flaws of any other mechanical contact. 

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.