Parametric G-Code; take axis name/ID from a variable?

I am writing a script to automate touch-off against a probe bar. I have written the same script 3 times; once each for the X, Y, and Z axes. The body of the script is identical in all 3 cases except for the axis name in the G38/G01 commands. Is there any way to use a variable for the axis name, so that I can either (a) use a sub-routine for the body of the script, or (b) make the scripts 100% identical so that it's easier to keep them in sync using "diff" or similar?

My current Z-axis script: github.com/fortcollinscreatorhub/cnc/blo...cnc/nc_files/100.ngc
My current X-axis script: github.com/fortcollinscreatorhub/cnc/blo...cnc/nc_files/103.ngc
My current Y-axis script: github.com/fortcollinscreatorhub/cnc/blo...cnc/nc_files/104.ngc

Some ideas that have been suggested:

a) Include all 3 of X, Y, Z axes in each G38/G01 command, and have separate probe_x/y/z_dir variables (with value -1 or 1 for the desired axis, and 0 for the other 2 axes, which will zero out the movement in unwanted directions). This will work, but will make the script a bit harder to read and understand.

b) Maybe "G10 L2 P0 R90" can be used to rotate between X/Y axes, but I'm not sure, and it won't work for Z.

Ideally, I'd love to do this: "G38.3 #<axis_name>[#<probe_dir> * #<probe_max_distance>] F[#<fast_probe_rate>]". However, variables can apparently only contain numbers, not strings/text:-(

Thanks for any ideas!
 

That would work, but I'd essentially be replicating the program many times within the if statement. I was hoping for one statement that'd cover all the axes.

I'm thinking of just writing a custom M code in Python, since that allows much more flexible use of variables...

OK, so I've started to work out how to do this in a Python remap. A couple of questions:

1. linuxcnc.org/docs/stable/html/remap/rema...ming-embedded-python says:

• Code following a yield may not recursively call the interpreter, like with self.execute("<mdi command>"). This is an architectural restriction of the interpreter and is not fixable without a major redesign.

 

However, in practice my code is calling self.execute() after yielding, and works fine. Are the docs simply out-of-date, or are there cases where I'll see this randomly break if I'm unlucky?

2. How stable is this Python remap feature? Clearly if I write my code in G-Code, it's quite likely to keep working whenever I upgrade  LinuxCNC. However, since Python remaps seem like a less commonly used and documented feature, I worry whether using it may cause headaches for some future maintainer of this machine, e.g. if I'm no longer involved in a few years and someone upgrades LinuxCNC, then everything breaks and they have a hard time fixing it if they aren't a programmer.

For the record, here's the very bare skeleton that I've been using to test the feature:

configs/sim/axis/axis.ini:
python/toplevel.py:
python/remap.py:

For anyone finding this thread later by Google, an update on the Python approach:

I've found an example of the problems that the documentation describe, where you can't issue and wait for multiple batches of G-Code commands within a Python remap. If I execute the remapped G-Code from the MDI, the code I wrote above works. If I execute the remapped code from 100.ngc which I trigger from an Axis UI button, then I get an error:

So, I guess I'll do this in plain old G-Code.