The problem with the "write to file" is that mach3 does NOT issue error codes when that occurs. So to the program that processes the points file it cannot tell the difference between an actual trip or an end of motion value. That leaves the points file corrupted. NO point is much better than a corrupt value as far as the point cloud is concerned.
Could be complex, or even 'not possible'.
The ESS (for instance) logs the XYZ values within nanoseconds of the touchprobe signal (which completely ignores the delay introduced by any filter on the line!) and passes the data back to Mach. But I question whether Mach can distinguish between genuine touch-probe data and the end-of-motion values. Yes, to be sure, a design problem. But since V.043.022 manages to get confused between the touch-probe data and the START-probe values, it would seem that the code there may have some very fundamental design faults. Yes. that version of mach can write either value to the data file - and does on my machine.
I find it useful to have the data written to the file whether or not the touch-probe actually touched. I can filter out the end-of-motion data later, and that tells me when I have a problem with the scan path. If you have a multi-megabyte file of points that could be painful, but I don't probe for point clouds at present.
IF you are doing the write to file VIA CB you can do a compare BUT that really SLOWS the process down.
Yes, I am using CB for the file writing, but I hadn't noticed any speed penalty myself. I do probe slowly.
Cheers
Roger