Well, you might like to read this thread:

http://cncdrive.com/forum/viewtopic.php?f=2&t=288

...which includes this reply from CNCDrive:

"cncdrive wrote:
I can't say anything about if it matters in Mach3 or not, I did not use it for a too long time now and I can't remember how this is handled in Mach3.

In the UCCNC as I wrote the probing input is not polled, but a software interrupt is generated on the 2 probe pins on the edge which is set to the active one.

The sofware interrupt means that the code exacution inside the microcontroller jumps to the interrupt service routine as soon as the microcontroller detects the set edge on the probe pin.

This is a hardware microcontroller feature and happens immediately without any delays, the only delay, the max. 50nsec is because the return address to return back after the interrupt has to be saved to the stack prior to doing anything else and then the coordinates are read, these takes upto 50nanoseconds with the 200MHz CPU frequency microcontroller in the UC300ETH, because one micro CPU cycle is 5nanosec and it can take upto 10 CPU cycles to do the mentioned things.

After these are saved the saved coordinates are sent back to the computer via the ethernet, so the user can access them.

It is another thing when and how the probe stops, that can be a problem if the probing is too fast, it does not influance the programmatic measurement accuracy though, however of course too fast probing could cause the switch to jump/prell and could cause the machine to shake and also the axis stops a bit further since it has to stop, but again the probe coordinates are already saved when the axis stops, so these things are no more UC300ETH, but machine and sensor dependents."

So at least one motion controller works this way even if Mach doesn't.

As for the probe delay, I need to get a copy of the Renishaw presentation I referred to but meantime you might refer to the RMP60 installation guide.  This product has a programmable filter delay to help reject false triggers which can be set to 0, 10, or 20ms.  Clearly this has to be taken into account in the probing routine.  I'm not sure if that is in addition to the 5ms.  The presentation dealt with a trial comparing delays between their stand alone wireless system and one using a 5G private local network.  There's a lot of interest in using private 5G in factories to connect automation systems and if you have machine tools with probes it's an obvious question whether you could fit a 5G modem in the probe and use the local infrastructure.  The 5G network was tested against the 5ms criterion of the stand-alone system - not surprisingly it failed.  Also worth looking at their application note TE412 comparing 1-touch with 2-touch probing, which points out that some controllers poll hardware inputs perhaps every 4ms which introduces an inherent uncertainty averaging 2ms into the probe response in addition to the sensing delay.

As to why there is a delay, as I mentioned the RMP60 uses a frequency-hopping system for robustness in an electrically noisy environment, and to distinguish between different probes in the vicinity (say a tool setter and a probe on the same machine).  Inherently in such a system it would take at least one complete FH sequence to decode a trigger signal, so there's bound to be a delay.

I was impressed by the fact that the probe can operate whilst rotating at up to 1000rpm!

Hi,
maybe UCCNC operates differently however when operating with Mach a UCnnn motion controller latches data when the axis is stopped.
Read the excerpt I posted earlier, that is the instructions o0ffered by NFS as to how a motion controller must handle probing in
order to work with Mach, UCnnn works with Machs g31 probing therefore it must comply with the procedure set out by NFS.

The two motion controllers that I've use are the ESS and Machs parallel port, and both operate identically, namely the trigger event
causes the axis to decelerate to a stop and then the data is latched once still.

Why don't you do some experiments and probe a surface at varying approach speeds. Another way to illustrate what's going on is to  as an experiment,
reduce the z axis acceleration down to 10% of normal and try probing again. In both of these circumstances I would expect the the overtravel
change and therefore the position latched into Mach. If you choose to experiment with a fast approach speed AND a low acceleration you will end up with
overtravel and you'll need some springiness in either the probe or the probed surface to avoid damage.

Craig

I'm sure you're correct Craig about how Mach works, and of course since there's a plugin for each controller presumably NFS can define how probing should work.  But the way UCCNC works with its native controllers still seems much more satisfactory to me as it registers the ACTUAL point at which the probe triggers. 

I've enquired on the UCCNC forum and it does not have a probe delay parameter so one still has to use slow probing to minimise the error. 

I attach the Renishaw slide I referred to.

Hi,
well if you ask me I would say that probe is junk, 40um overtravel before the motion controller detects the event?
Irrespective of whether the position is latched at the probe event OR after the axis is decelerated to a stop....40um is BS.

I probe printed circuit board blanks, inevitably there is some bow or warp that needs be accommodated, the copper layer is only 35um thick
and I require the tool to cut that 35um but do not want it to cut into the substrate. In practice you do have to have some cutting into the substrate to
reliably cut the 35um copper layer. In practice I use a cut depth of 0.08mm, or 80um. With the corrections provide by probing the surface prior to cutting
this results in 100% reliable cutting of the copper layer without unduly cutting into the substrate. For this to work I require the probing to be
10um or better....40um would screw me.

If I used a probe that had 5ms latency then I can kiss making PCBs goodbye.

I have read that much of the latency that these RF probes exhibit is because it can take 5ms for the radio link to synchronise. If it were a straight wired
probe (like the only type I can afford) then there would be no latency, or at least reduced to 10us or less.

Craig

But that's why the delay is precisely controlled.  If you know the overtravel since you know the feed rate and delay you can simply correct the value.  These probes are used in machines with tool changers and have to be wireless.  Also in certain operations the probe is rotated, which is slightly difficult with a wire connected!  You would have no problem using this probe for autolevelling, you just need to add or subtract the 40um from the measured values in the probe macro.  The radio link is much faster but in a noisy environment with several machines and Wi-Fi etc you have to have a robust protocol with retransmission and padding to give a known total delay. 

When it comes to machine probes I think I'll accept Renishaw's point of view as they have just a little experience in the topic.

Hi,
Reinshaw have a magnificent reputation, and prices to match. Certainly the circumstances of use preclude the use of a wire, and if
you can alter the probe result after detection then you can recover the accurate position.

Can you afford one of these things? Even second hand?

My probe circuit is two wires with clips, one going to the spindle nose, and the other to the PCB blank, cost....near zero, and repeatability of
several um.

Craig

Er. which part?

Hello everyone!

After almost three years I came back to this long, tedious and infuriating post, with some good news though...partially to be fair.

This whole topic began after not being able to properly use the G31 command on my WiHXC MK6-ET V1.5 Ethernet card, two of the problems being:

1) Z movement stopped way after probing tripped, randomly between 0.2mm and 0.5mm after.
2) Only the Work Offset was being saved for each XYZ coordinate on the file that is opened with G40 command.

About a year ago, sales department contacted me to see if I was having a great time with my product, which definitely was not the case, and I stated many times that I had a very crappy response from the technical department with my issues, pretty much blaming it on me for not writing a proper script when using those commands.

So, after that moment, I decided to hunt into their webpages for a solution after many times of doing so, given the fact that they hadn't updated their Mach3 Plugins links since ages (yes, they have a Chinese version and an English version without the same content); and OH SURPRISE, after two years of owning their card, they had uploaded a new Plugin version a few months back, just right after I had given up with the whole thing.

So, I downloaded it, replaced the old one, and probing worked fine!. Just the probing part though, now G31 wouldn't stop the probe way beyond the surface, but very accurately and repeatedly on the material surface, which meant they definitely had something wrong all the time and would admit it, nor face it at the moment.

Note aside, their readme files state it, in a very funny way:

please copy the NcEther.dll to mach3\plugins
everything will be ok.

Release Notes:
2023.1.10 v3.19.1
solve the probe precision diff problem

Now, point 2 stated above was not solved, so I definitely had to go in there and learn some Cypress Basic for Mach3 in order to write a functional script that works without that G40 command, and it worked as well, painfully, but I can finally probe as many points as I like over a crooked surface automatically, as it should've been...

There are still plenty of things to talk about this, but this got long enough for the time being.