Hey Tom, hey Chris @ChrisS, hey Pat @PezWoodworks, hey Derek @WaywardWoodworker, hey all,
By G-code standard, the probing procedure does not need a second switch in the tool setter, because it only knows three states: 1. the probe is still moving along the given travel on the given axis at the given feedrate and has not yet triggered the tool setter, 2. the probe has triggered the tool setter, and 3. the probe has been moved along the given travel on the given axis and has reached the end of the given travel, but has not triggered the tool setter. Reaching the second state sets parameters #5061 to #5069 to the values of the X, Y, Z, A, B, C, U, V, and W axes (relative to the currently active coordinate system) and parameter 5070 to 1 for successful probing, while reaching the third state sets 5070 to zero and triggers an error to stop execution of the G-code program (which is logical, because what useful milling could the machine do if it doesn’t know how long its tool is). All this can be done with one switch. So the second switch, called “Overtravel” in the picture, can only have the sense to indicate that the first switch is not connected or that it or its cable is defective. In any case, this would be a condition that never occurs if the hardware is OK, right?
Since I have no experience with the Masso, I had a look at G38.2 Probing cycle – Masso documentation and it seems that it displays the error and simply stops the program, which is the behaviour described in the standard.
What is the difference for you if you wire the “Overtravel” (second) switch in the Tool setter to cycle stop?
The Masso doc says:
"Tool setters which include include a 2nd switch to detect over travel can be used with the Cycle Stop in case the first switch fails.
This will stop the probing cycle and allow the tool to be moved off the tool setter by jogging the Z axis."
Is there an additional possibility to probe again and resume the program with the Masso when cycling stop was triggered?
Regarding wiring the 2nd switch to emergency stop, I think this is logical in some way too, since it obvioulsy signals a hardware failure, but usually, one would want to know what the exact behaviour is at e-stop.