LinuxCNC Documentation Wiki: User Defined Gcodes

User Defined Gcode (by lerman)

This page contains a proposed mechanism for user/integrator defined gcodes (and mcodes). The term user and integrator are used interchangeably for now as are gcode and mcode.

A user defined gcode is declared in the .ini file by a stanza like (subject to change)

[gcode]
G31
G1
G2.2
G2
M10

Revised by KL

The CUSTOM section will have custom gcodes and mcodes.

[CUSTOM]
DIRECTORY = /path/to/directory/containing/custom/codes 

GCODE = 31
GCODE = 1
GCODE = 2.2
GCODE = 2

MCODE = 10

AJ: maybe have it like "G31=/path/to/g31.ngc" </pre> Each of the above lines declares that the corresponding gcode will be handled by a variabless subroutine of the same name; eg, O<G31>, O<G1>, O<G2.2>, etc. If there is already a "hardwired" gcode with that number, it may be accessed by adding 100 to the gcode. So, the original G1 will be accessed as G101. For mcodes, add 1000 to the original code. So the original M10 will be accessed as M1010, etc.

A Subroutine For User Defined Gcode

Within a user defined gcode subroutine, special named parameters are accessible.

#<_mask> has one bit set for each word on the line invoking the gcode. Bit 1 set (2^1) means that there was an A word on the line; bit 2 set (2^2) means that there was a B word on the line; and so on through the alphabet.
#<_A> contains the value of the A word if one was defined (and should not be used if one was not defined)
#<_B> contains the value of the B word
and so on through the alphabet.

Consider adding:

#<__A> contains the value 2
#<__B> contains the value 4
#<__C> contains the value 8
and so on through the alphabet

This would let the programmer write things like [#<__A> OR #<__X>] to create a mask indicating that A and X are required.

AJ: I suggest a different approach:

#<_A>, #<_B>, .. would be set to 1 if that word was specified on the same line (-1 if not)
#<__A>, #<__B>, .. would contain the actual value for the present words

Additional commodity functions would be present:

O<neededword> call <_A>
- this would check if _A is different from -1, and report an error otherwise
- maybe the current function name can be stored in a global variable, so that <neededword> can reference it (although current filename might also be enough..)

(KL) Instead of the above:

O<_allow_require> call [mask of optional words] [mask of required words]
- This would generate an error if any of the required words was missing and would generate an error if words other than the set of optional words was present.

The masks could look like: [#<_Mx> OR #<_My>]. The _allow_require subroutine would check the masks against the variable _mask.

Variables _a, _b, ...,_x, _y, _z would contain the values (assuming the proper mask bits were set). Also, variables __a, __b, ..., __x, __y, __Z would be non-zero if the variables were set.

This would let the user test for the presence of variables in a variety of ways.

Order Of Execution

Gcodes (and mcodes) are executed in the same order as they would have been executed if they were hard implemented gcodes or mcodes. The same rules concerning modal groups, etc are enforced.

Some Infrastructure

After a user defined gcode routine determines that some parameters are missing, it should call:

O<GmissingWord> call [1] [#<missing>] [#<extra>]

In this case, 1 is the gcode number (1) and missing is a parameter with mask bits for the missing parameters. This subroutine will print messages describing the problem and then exit. A similar routine MmissingWord? should be called from mcode subroutines detecting errors.