[flick]

I make a number of different things, including ultra-light winter mountaineering canister stoves. I looked at modelling the parts on 3D parametric CAD (I have several), but it was faster to sketch them in 2D and write the g-code. As I was making the parts in batches of 8 - 10 at a time, I could integrate the machining across the stack of 10 in a way I doubt CAM could ever achieve. Tool changes were highly optimised. That was because I understood what I was doing. CAM can never do that. But I am sure there are other cases where CAD/CAM is quite suitable.

I very much understand the advantages of hand-writing g-code, and in our brief interaction you've easily convinced me that you can do everything you say can, because I can too, but that doesn't make hand programming the best choice for most people most of the time.

And that's entirely separate from the issue of whether standardization is important - if you're capable enough to understand both machining and programming to the point that you can significantly optimize your gcode without much effort, then you can also write excellent code for a variety of machines. I can understand the draw of standardization, but it seems to me there are enough advantageous non-standard features to various controls that it's very much worthwhile to learn and utilize them.

Your concerns about low-number variables do not seem to apply to NIST g-code and Mach, and I don't understand them. They may apply to old versions of other languages? I don't actually create 'macros' as you call them, although this may be a terminology problem. In Mach a 'macro' is called by an M-code, and is often used for control of external devices such as spindle, misting, safety sensing, etc. Templates for reuse might be a better description. Does Fanuc use the word 'macro' for a subroutine?

I did refer to reading in a data file at the start of a program - that data file actually contains a huge list of the parameters (and their definitions of course), but rarely includes any movement instructions. But there is no restriction on the use of low-numbered parameters like #1 - #26. Use them as you will. Mach3 allows up to about 32,000 parameters, Typically I will reserve parameters #1 - #19 for use as very local variables within a subroutine, while parameters with bigger numbers are more global in the program, but that is SOLELY a matter of MY programming style.

The example you give of a G65 instruction is not valid in Mach3: it is not implemented. The idea that a passed A parameter ends up as #1 does not apply at all.

That's too bad, because it's a really attractive methodology. G65 is what fanuc terms "custom macro B". It's a specific feature emulated by many other controls, and is the more powerful version of their early and mostly defunct custom macro A. It seems that from what your describing, the way that "parameters are passed" between a program and a subroutine in Mach is to simply set global variables. This is Ok, I guess, but requires a tremendous amount of discipline on the part of the programmer, and leaves you open to the likelihood of stomping on the "namespace" of other subroutines if you happen to write a program that uses multiple subroutines that are all parameterized in such a way, or if such subroutines use each other. When you pass a parameter through G65, it becomes a truly "local" variable in the subroutine referred to by the P value - IE 26 shiny new words of memory are dynamically allocated for the use of that instance of that subroutine - no namespace issues. Also, once you've written a really nice, flexible custom macro, you can invoke it in a similar style to a canned cycle, albeit without the modality thereof. So while I can't write something like:

G0 G54 G90 X0. Y0.
G65 P1234 %threadmill first hole
G91 X1. L9 %threadmill remaining holes

But at least I can write something like:

G0 G54 G90 X0. Y0.
G65 P1234 A1.79 F.087 Z-1. D1 R.1 Q5 J.5001 %threadmill 3/4 NPT
X1.
G65 P1234 A1.79 F.087 Z-1. D1 R.1 Q5 J.5001 %next hole
X2.
etc.

And the code to call your macro looks almost like using standard canned cycle, is easier to remember because the letters all resemble uses that they have with other codes, and is a lot nicer to write (I think) than:

#101=1.79
#106=.087
#126=-1.
#104=1
etc
etc
etc
M98 P1234

Which is how I imagine you passing data from you main program to your subroutine. But to each their own, certainly, and forgive me if that doesn't actually resemble how "parameters" are "sent" in NIST g code.