The motion controller plugin should only deal in counts (or steps) so that it remains unit agnostic. So this is usually an integer number, but it can be a real number as well (micro stepping, etc..). All of the conversion to the native machine units is done in Mach. The position (in counts) is then divided by the counts per unit in the motor tuning tab to derive a position in the native units of the machine.
For the case of a probe strike, the motion controller should:
1. Latch the probed strike position (in ABS counts) for each motor.
2. Decelerate all of the motors involved in the probe operation to a stop.
3. Report the probed positons (in ABS counts) to Mach.
4. Report its' current positions to Mach (because Mach doesn't know where it all stopped!)
5. Tell Mach that the probe operations is complete. (This will sync the real world position to Mach's planners.)
6. Ack the stop report requests.
All of this is documented in the API manual if you want a more technical explanation with the API calls that are to be used.
Anyway, the Mach 4 motion control plugin paradigm is designed to be dumb as a rock. All a motion plugin needs to do. basically, is follow the ball. And tell mach when the requested movement is done, in most cases. Homing and probing as about as complex as it needs to get, as these are real-time processes that just can't be handled in Mach.
What is reported by the motion plugin ends up in 5071-5076. The actual machine positions with no offsets applied. Then the current offsets are applied to those and they go in 5061-5066. So Michael is correct in stating that if what ends up in 5071-5076 will affect what is in 5061-5066.
Steve