Proposal by lerman:
There are a large number of canned cycles that might be implemented in EMC. If we wish to copy one vendor, we might have one set. To emulated another vendor, we might have another set. This page is a proposal for an interpreter change that would let many types of canned cycles be implemented without further change to the system.
The basic idea is that most canned cycles could be implemented as gcode subroutines. The downside of this is that users are used to just specifying a Gcode for a canned cycle with parameters specified as single letters followed by values. This proposal would let the integrator define canned cycles as gcoded subroutines, but the end user would access them as gcodes. The following changes would be made to the interpreter:
1 - The .ini file would have two types of commands added. The first would specify the name of a gcode file containing the canned cycle subroutines. The interpreter would read this file on startup. The second .ini file change would be a command to define a canned cycle. It would contain the code to be used, e.g. G81, and the O-word of the subroutine that would be executed for that cycle, e.g. o999001. An alternative: Negative O-words may be used only in .ini files. When the interpreter sees a Gcode such as G82.1, it would invoke the O-word subroutine O-821. If no such O-word exists, an error would be generated. This alternative approach would be trivial to implement.
2 - The interpreter would be changed to handle the changes, above. When interpreting code, if it sees one of the Gcodes defined in the .ini to be a canned cycle, it would call that canned cycle subroutine (after doing the rest of the stuff in the block). Rules concerning order of operation in a block would be obeyed.
3 - Parameter values 1001 to 1026 (or some other range) would be defined to be the last seen values of A, B, C,...,Z, respectively. So, the canned cycle code could access these parameters to determine the values to use for the canned cycle. Additionally, flags would be set in parameter 1000 (one bit per) which would tell whether which of the parameter words A-Z had been set on the line invoking the canned cycle.
These changes should be sufficient to implement most of the canned cycles I've looked at.
Similar things could be done with m-codes. We might want to add built in interpreter commands to do synchronous and async I/O, also. In that case, we could limit the use of these potentially dangerous command to gcode subroutines that have been defined in the .ini file.
Propoal By JeffT? Something that might work. There are a few out there. The one I have used is Fanuc Custom Macro B.
Parametric programming. It allows the user to do many things. The book that got me started is "Parametric Programming for Computer Numerical Control Machine Tools and Touch Probes" by Mike Lynch. ISBN 0-87263-481-7 (amazon.com, search) or https://shops.ae/books/ Setup somewhere in the code to interpret a predefined set of variables and math functions.
This would allow the user to write and possible share as many canned cycles as they can dream up.