Macro subroutines in LinuxCNC

Does anyone know if macro subroutines are implemented in LinuxCNC?

I found in Gcode documentation that the block of "N120 G65 X2.5 Y3.0 Z5.4" will call a macro subroutine and pass the arguments of X,Y, Z. According to Gcode documentation I can pass arguments to the macro through a system that correlates the argument words to local variable values. The X value will appear as local variable #24, Y as local variable #25, and Z as local variable #26. I am looking to write some general purpose macros and want to use this type of a macro call with arguments.

Linuxcnc can have custom M codes M100-M199 and those can be passed up to 2 parameters P and Q
linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m100-m199
or Linuxcnc can do O<subs> that can be passed up to 30 arguments as local parameters (local vars #1-30)
linuxcnc.org/docs/2.7/html/gcode/o-code.html#ocode:subroutines

But I am pretty sure that N(number) codes are ignored by Linuxcnc, and I don't think X,Y, and Z are ever used to pass parameter information, only positioning.

forget about the N number, the issue is does Linuxcnc support macros with arguments?

Looking up information on GCode macros, I came across the following website.
www.cnccookbook.com/CCCNCGCodeSubprograms.htm
where they talked about programing macros. While I can write a subprogram to do the special machining I want, I would have to load values into local variables before calling the subprogram. This would not be as clean as being able to call a macro and include whatever arguments I want on the same line like in the example on the CNCCookbook website. Yes I know that I can do a o<sub> and include up to 30 arguments afterwards, but then I would have to include all the arguments whether I would be using them or not. Being able to included named parameters would be a lot cleaner and I would only have to include the parameter I would be using. For any of you older folks, this would be like the difference between include input data in a datafile versus using namelists in fortran.

If the application is a repeating one use ngcgui.

JT

jwsigler wrote: forget about the N number, the issue is does Linuxcnc support macros with arguments?

Looking up information on GCode macros, I came across the following website.
www.cnccookbook.com/CCCNCGCodeSubprograms.htm
where they talked about programing macros. While I can write a subprogram to do the special machining I want, I would have to load values into local variables before calling the subprogram. This would not be as clean as being able to call a macro and include whatever arguments I want on the same line like in the example on the CNCCookbook website. Yes I know that I can do a o<sub> and include up to 30 arguments afterwards, but then I would have to include all the arguments whether I would be using them or not. Being able to included named parameters would be a lot cleaner and I would only have to include the parameter I would be using. For any of you older folks, this would be like the difference between include input data in a datafile versus using namelists in fortran.

Yes subs can have arguments. They can use their own local parameters, and or use global parameters and named parameters. (I don't know much about programming so I really don't understand the last half of your question. To pass 2 arguments(20 and 15.25) to a sub program called "sub" you would call it like this. This would set the local parameters for that subroutine to #1=20 and #2=15.25. Is this not what you are wanting to do?

My goal here is to write a multipurpose routine for milling a wide range of circular features. The routine would be able to mill a circle, a circular pocket, or an annular groove using the same routine and just difference inputs. If I give it x,y coordinates it would mill the feature centered on the new coordinates. If I call the subroutine without passing it x,y coordinates, it would mill the feature about the current tool position. There are also other arguments such as finish cut which if specified would rough a hole using incremental Z cuts leaving the finish dimension of material on the part, and then do a single finish cut to remove the leftover 0.005 (or whatever) to produce a good finish without a lot of cutting marks. As such there are going to be arguments that may or may not be used every time I call my macro. According to the other website I previously referred to, a G65 macro call will allow the user to specify arguments (like x,y,z,f,w,r) and give each one a value, exactly like in a G0 command where you may or may not specified all the x,y,z values. I could use the standard subroutine method of "o<sub>call [20] [15.25]", but that would mean that I would have to specify all the parameters every time I called the macro. It is a huge, really huge, advantage if you can specify an argument's name and value in the calling statement. Again, think along the lines of the difference between a code block saying G1 Z1.0, versus having to always specify all the coordinate even though x and y do not change. Wouldn't it drive you crazy if every time you issued a G0 or G1 command you had to always include the X, Y, and Z. According to some documentation some versions of G-Code allow a macro call where you can follow the original call with arguments like X1.0 Y2.0 R4.0 and these values are loaded into specific local variables (X goes in #24, Y goes in #25, R goes in #18,etc). This is what fortran did when it implemented namelists. You provide the variables name and its value. In the example given by Todd, his example of o<sub>call [20] [15.25] is impossible to know what 20 and 15.25 are. Are they X and Y coordinates, or are they Z and a diameter? It is difficult to read this code. If the call used named arguments, then it could read like "o<sub> call x1.0 y3.0 d0.45" and one could see that the point of this sub would be to mill a circle with a diameter of 0.45 and a center at x=1.0, y=3.0 (of course there would be other arguments needed). The call becomes self-explanatory which is really what one should want. That is what we do now with G0 and G1 codes now. Since no one is saying "oh yeah, this is how you do that", and since I find no documentation about a G65 code, and since when I input a G65 code in linuxcnc it says "unknown G code" I am getting the impression that LinuxCNC has not implemented this capability. If this is implemented in some other calling form I would like to know what it is, or if one of the code developers can help me understand how to modify and compile my own version of linuxcnc, I will write the code to implement a G65 code and then you can review it and decide if you want to implement a G65 code in linuxcnc.
Thanks.

You could possibly use named or global named parameters to make your code easier to read.
linuxcnc.org/docs/html/gcode/overview.html#gcode:parameters
But don't let me discourage you from writing macro call support for Linuxcnc. More features/improvements are always welcome. I was just trying to point towards possible workarounds.

Yeah I looked at some of these workarounds, but like in your example you are talking about four lines of code instead of one. I have written code to do this before in technical applicants when I worked full time in the defense industry and it probably would not be difficult to do the actual code writing since I assume linuxcnc is written in something like C++ or one of the higher level languages. The problem I would have is dealing with the linux side of processing and compiling the program. I recently put together a complete how-to guide on how to setup linux, the realtime kernel, linuxcnc, and glade on a modern version of linux. There are automatic installers available, but they use older versions of linux and some do not support more modern hardware. Of course if you go with a modern linux distribution, you lose the functionality of Glade since the version of Glade required for Linuxcnc is an older one and the modern linux distributions load a more recent version of glade which will not work with linuxcnc. I got the whole operation figured out, documented the whole procedure and even wrote a script that would automatically do the old Glade version install, and was going to publish and host all the files in one place so it would have been a "no brainer", but I could never get the script to work. I could cut and paste each line from the script into a terminal window and each command would execute perfectly, but I could not simple execute the script file and get it to do everything on its own. If this was Windows, any bat file I would write and execute in a command prompt window opened to the correct sub directory would easily perform, but Linux has all these little quirks which start eating up 80% of my time. In the end I did my own install which worked flawlessly; although I had to cut and paste the script file line by line into a terminal window, but since I could never solve the script file issue, I moved on and never published the whole process. I am hesitant to start writing a subroutine for a G65 command if I am going to have to spend 80% of my time simply trying to figure out how to get linuxcnc to compile with a new subroutine. The unfriendliness of these overhead type functions I think really cripples new development for linuxcnc. Really, a macro call that uses named arguments like any G0 or G1 command does, is 1980's programming technology. This should have been implemented a long time ago. The fact that it has not I think shows how these user unfriendly overhead functions cripple the development process.

I just tested something you can insert comments in line with the o call and its arguments like this.
o<sub> call (center X)[1.0] (center Y)[3.0] (diameter)[0.45]

(alternatively global or global named parameters don't even need to be passed as arguments they can just be accessed directly by the macro)
have you looked at ngcgui? It can be very useful, and it's subs are useful examples as well.

Did you look at ngcgui in the manual? That's pretty good solution to your problem.

JT