Variables vs arguments for passing data

Passing data between macros:
I've struggled a bit with the issue of passing values when calling macros from within other macros. As there are quite a few levels of nesting in a typical probing operation, it's necessary to pass parameter values when you call one from another.

Some of the higher level macros seem to be perfectly happy to be passed parameters when you make a "command line" type call. In my relatively limited programming experience, these passed values are often called "arguments". In Centroid syntax, this will typically look something like this:

G65 "c:\cncm\probing\f360_probing-x.cnc" X[-8.] Y[20.] Z[50.] M[6.] F[1000.] D[56.] A[1] C[5.] H[3.] R[50.] W[01.]

Once inside the macro, you pick the parameters up and name them locally. From what I can see from existing examples, this requires something like the following:

DEFINE <x> #x
DEFINE <y> #y
DEFINE <z> #z
DEFINE <nominaldiameter> #m
DEFINE <feed> #f
DEFINE <depth> #d
DEFINE <approach> #a
DEFINE <clearance> #c
DEFINE <overtravel> #h
DEFINE <retract> #r
DEFINE <targetwcs> #w 

You can then use the named variables (rather than the short parameters) within expressions, such as this:

G65 "c:\cncm\probing\f360_probe_x.cnc" A[<approach>] C[<clearance> + <overtravel>]

and 

#100 = [#34006 + <approach> * #34009] ; (where did the hit occur)
However, that leaves the question of how to deal with "new" variables, which will either have to be created as named variables ("aliases") or as new (and therefore hopefully unallocated) numbered variables.

Defining aliases:
I tried to create my own new named variables ("aliases") using the DEFINE statement. This appears to be accepted by the interpreter ie it doesn't create any obvious error. However, it fails when I subsequently try to use said new variables in statements or expressions and may or may not be due to me also trying to include an equation in the definition. Needless to say, there is almost no coverage of this feature in the Centroid documentation and very few examples to go on. 

This works:

#100 = [#34006 + <approach> * #34009] ; (where did the hit occur)
But this doesn't:


<expected> = [<x> + <approach> * [<clearance> + <nominaldiameter>/2.0]], whether or not there was a DEFINE at the front, or a "=" sign.

This whole DEFINE / alias business turned into a bit of an unprofitable shit storm and I finally concluded that aliases were not the way to go. I will stick to using numbered variables inside macros.

This macro call works:

G65 "c:\cncm\probing\f360_update_x.cnc" W[<targetwcs>] H[#34006 + <approach> * #34009] E[[<x> + <approach> * [<clearance> + <nominaldiameter>/2.0]]]

Inside the macro, we have:
DEFINE <wcs> #w
DEFINE <hitfound> #h

DEFINE <expected> #e
...
etc
...
#[#34831] = #[#34831] + #h - #e ; updates the WCS value.

Conventionally, local variables are numbered #100-300 if I understand correctly. However, these are local and volatile ie not for passing between macros, with values that evaporate when you leave the current macro. For higher level, more global variables that can be accessed and shared by multiple macros, you'd want to allocate a unique variable number for each new usage. 

Aha - plenty of system variables!!
It's surely no coincidence that Centroid have created a whole slew of unique system variables in the 30000-34999 range. Each appears to have a unique usage - and there are quite a few gaps which I'm guessing I could grab for my own needs. In particular, there is a fine looking gap between 34100 - 34499. I'm planning on making these my own. I reckon 400 variables should be enough for my purposes.

Most of the rest of the system variables which are already defined and in use are in the range 30000 - 34999, with a bizarre addition between 29561 - 29569 which seems to be used by the "wall following" macro. 

Existing system variables:
There's a file called "probe_user_vars.txt" in the Centroid installation that sort of lists the variables currently in use, although most of them have no useful description to speak of. I've now imported that into Excel and am updating it with vaguely useful notes as I figure out what each of them does. Might have been nice if the originators had done so, mind.

The plan:
I will stick with numbered variables between 34100-34499 for my new probing parameters. As I create them, I will add them to the spreadsheet along with descriptions of what they are used for and comments locally within the macro.