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!
 

linuxcnc.org/docs/stable/html/gcode/o-co...ml#ocode:conditional

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:

swarren wrote:

That would work, but I'd essentially be replicating the program many times within the if statement. 

Maybe only the probe moves, it depends on what the rest of the code does. You can pull out the correct probe result bu a computed parameter, for example. 
 

A remap should be as stable as Python, which isn't saying much. I would definitely target Python 3.