Work with probe

ok problem solved .. code 13 ...

net probe-in => motion.probe-input
net probe-in <= hm2_5i25.0.7i77.0.0.input-31

I should not do unknown configuration at night ...

Thanks for the good work by the way !

thanks for the screen. really like the concept.
does Probe_screen work with Master branch? I keep getting 'must be in MDI mode.....' error.
if it's not Master branch related, what could the problem be?

I have just started working with a probe. This is such a great addition, it is very impressive!
One thing I have noticed, is that if a probe routine fails mid cycle for whatever reason, usually because the probe didn't reach the edge of the part, a modal G91 remains. Thus when the necessary numerical changes are made and the probe routine is run gain, there is a very real risk of the Z (now in incremental mode) moving into the work-piece and crashing.
After a situation like this, when the probe has stopped movement mid cycle for whatever reason, it has always been necessary for me to go back to the MDI page and re-insert a G90 so that the routine will not inadvertently crash into the part in Z. At least that is the way it works in in gmoccapy.
Does anyone know whether this bug has been resolved? I.e. ideally if the routine stops mid cycle, the last thing the routine does before exiting is to restore the modal state to a G90 to prevent any crashes next time the routine is run??
Many thanks for a great addition to linuxcnc!
Regards,
Marty.

Im also getting the must be in MDI mode error with master. Any Idea what this could be?

Rene

Restoring a G90 would be correct in some cases, but what if the *user* had set the mode to G91? The correct behavior is to save all of the model state at the beginning of the routine and restore it when the routine exists. That should occur whether the routine existed properly or with an error.

Ken

I think you are exactly correct Ken.
Setting a G90 regardless on exit would not be the correct outcome here.
However, in my case, the machine status when commencing the routine is G90. If the probe routine completes successfully, then it reverts back to the G90. This indicates that, at some point at least, the probe routine commands the machine back to previous defaults.
If the probe routine errors or stops mid cycle, then because the subroutines within the probe cycle are using relative paths, a modal G91 remains.
I suspect this is all done in a python script rather than using overt G code, but as a G code analogy it seems that upon reaching an error in the subroutine, the probe cycle exits without getting to the point of restoring the previous modal G90/G91 (as set respectively by the user pre-start).
In other words, whichever mode the machine was configured in before the probe cycle was started (G90 or G91), regardless of stopping mid cycle due to an error, it is important that the cycle commands whatever the previous state of the machine was (either G90 or G91) to prevent any subsequent surprises/crashes.
In my case, for whatever reason, this is not happening if the routine stops mid cycle for any reason.

what about using this? linuxcnc.org/docs/html/gcode/m-code.html#mcode:m73

I was thinking the same thing Ken.
In other words there is likely an M70/M72/73 going on here which if the o sub completes then the modes return to the preexisting modes.
My question is more along the lines of why if the routine fails is the abort side of the sub not also programmed to restore back to the pre sub state as well? A M73 will behave this way on abort, perhaps the sub needs an M70/M72 involved in BOTH the pass AND the abort paths (either side of the if statement).
This would ensure that if a probe routine fails and aborts for whatever reason there is a M72 in that abort path to restore modes in case the subroutine aborts as well.

Hi Ken,
did you finish this? It would be great to try out!

cheers,
John

I haven't touched this stuff in a long time. It's probably as finished as it will ever be. I don't think it has changed since post #61002.

Ken