I have bought and wired in a 0.01mm capable touch probe (various people have referred to one, from Amazon or wherever for about $70). It works really well, and leaves me now to adapt @NeilFerreri macros to be able to probe back left as well as front left.
These macros are up and running, and working exactly as I hoped, except for inertial errors…
The probing technique in these macros is to call G38.2 and wait for a trigger, then read the machine position.
Link to Chamnit discussing this (Grbl leader/guru): Change probe architecture from polled to interrupt · Issue #1095 · grbl/grbl · GitHub
I am seeing a consistent X and Y error when using my 0.01mm touch probe, and from what I can read this is down to deceleration (of necessity) in the X and Y gantries, the ‘inertia’ mentioned above. A suggestion to improve this (0.3mm approx) error is to read the PRBZ, PRBX and PRBY machine co-ordinates that are stored in the same stepper ‘step’ as the trigger happened, rather than the machine position when G38.2 returns.
The original macro line that stores X after probing is, current X ± probe dimensions etc;
G10 L20 P1 X[-ENDMILL_DIAMETER/2 -PROBE_BLOCK_X]
This would become, I think, with PRBX access;
G10 L20 P1 X[PRBX -ENDMILL_DIAMETER/2 -PROBE_BLOCK_X]
So, can gSender read PRBX etc parameters? They appear in the console log, so I reckon gSender might have seen them…
I can concoct a test tomorrow, when I can get back on my machine, but I wonder if anyone knows for fact EDIT: testing doesn’t reveal any obvious way to obtain the PRB: results that happen in the instant the probe triggers - without access to this, one is reliant upon ‘calibrating the overshoot’ and compensating accordingly…
Any inputs on the PRB: data, and whether it does in fact get captured into a variable(s) would be much appreciated - for example: Tormach describe exactly this capture, but I cannot find anything in gSender or CNCjs that refers…