Probing routines changing mode from G90 to G91

I've noticed that some probing routines in Probe Basic change the distance mode from G90 (absolute) to relative (G91). Took me while to figure this out 

Some routines do it only when there is an error during problem while a few others always leave the machine in G91 even after successful probing.

Is this by design or is it something that should be looked into?

Reply redacted.

I have a hard time seeing that this could be intentional design as randomly changing the behavior of MDI commands without any hint at all to the user can be very dangerous.

An MDI move command in G90 can yield very different results compared to one in G91.

Yes this should be raised as an issue, GitHub might be the best place.
I concur with your statements regarding relative vs absolute moves.

Please disregard the comments in the previous post as they appear to have been made by an idiot.

You are right, i never ran into it because i almost always am running in auto mode but i found a handful of subroutines that fail to revert to G90 at the end of completion. i have corrected them and they will be up on on the next push for the development branch. for the stable branch you will need to manually copy over the edited files or make the same adjustments in your local subroutines if you have edited them. the list of affected subroutines are below:

probe_cal_round_pocket
probe_cal_square_pocket
probe_round_pocket
probe_valley_x
probe_valley_y

if you want to manually add in the return to G90 immediately you would add it after the end of the last move that is NOT in a confitional "if" statement o110 for example:


Regarding when a routine fails to complete from an motion internal abort scenario, that is an unfortunate situation where the G91 was active at the time of the routine abort failure typically in a G38.x move.  I am not sure the best way to do anything about that so I am open to ideas, this abort comes from linuxcnc so i don't think i can add additional code to follow in the subroutine that would be executed.  i could be wrong, but i'm simply unsure how i would do it, so if you know post up please and we can incorporate that safety!

Thanks,

Chris

Big thanks Chris, that was a really quick fix from you!

Fixing the bug in the normal uses cases is what's most important as probing errors are not that common once you get used to the various probing functions.

The abort handling seems tricky to solve indeed. I went through the documentation in search for a solution. I was looking for a hook to detect when a program has been halted but I came up with nothing.

Maybe some of the more experienced LinuxCNC gurus here on the forum has some input on how this could be solved.

This may sound dumb as I am no gcode expert, but is there a way to "push" the current gcode settings
and restore them later?