Hi,
homing is rightly the job of the motion controller.
When an axis homes it travels in a given (programmable) direction at a given (programmable) speed until the home switch
changes state. Then the axis is to stop. The axis must stop exactly when, or very close to, when the switch operates.
That makes it a real time detection, that is the axis must stop within a few or perhaps tens of microseconds.
If you programmed Mach to drive an axis until a switch activated it would fail because Mach is not a realtime controller.
When the switch activates it would take several or perhaps tens of milliseconds for the signal to propagate back to Mach
and then another several or tens of milliseconds for Machs STOP instruction to get back to the motion controller.
All precision is lost because of the communication delay.
Your motion controller is however very fast and normally has responsibility for homing. Most motion controllers cannot be
programmed by a user however. Thus if controller is instructed to home an axis, it will and reset the machine coordinate.
What you really want is for it to home an axis, ie drive slowly to the home switch until it activates , back up until it
deactivates, but NOT reset the machine coordinate.
I am still trying to contemplate a way of doing as you want.
If you were prepared for the axes to drive very VERY slowly so that the communication delay does not adversely affect
the accuracy of the result then programming it in Lua would be easy.
The other way I'm thinking of would require the button to cause the machine to drive (at traverse speed) to machine
cords 0,0,0 and THEN be instructed to <ref all> and detect the distance moved between the original 0,0,0 and the newly
minted 0,0,0 position. The difference between the two would represent lost steps/inaccuracy that had accumulated between
homing operations.
Craig