linuxcnc最新源代码

[[cha:remap]](((Remap Extending G code))) = Remap Extending G code :ini: {basebackend@docbook:'':ini} :hal: {basebackend@docbook:'':hal} :ngc: {basebackend@docbook:'':ngc} == Introduction: Extending the RS274NGC Interpreter by Remapping Codes === A Definition: Remapping Codes By 'remapping codes' we mean one of the following: . define the semantics of new - that is, currently unallocated - M- or G-codes . redefine the semantics of a - currently limited - set of existing codes. === Why would you want to extend the RS274NGC Interpreter? The set of codes (M,G,T,S,F) currently understood by the RS274NGC interpreter is fixed and cannot be extended by configuration options. In particular, some of these codes implement a fixed sequence of steps to be executed. While some of these, like M6, can be moderately configured by activating or skipping some of these steps through ini file options, overall the behavior is fairly rigid. So - if your are happy with this situation, then this manual section is not for you. In many cases, this means that supporting a non 'out of the box' configuration or machine is either cumbersome or impossible, or requires resorting to changes at the 'C/C\+\+' language level. The latter is unpopular for good reasons - changing internals requires in-depth understanding of interpreter internals, and moreover brings its own set of support issues. While it is conceivable that certain patches might make their way into the main LinuxCNC distribution, the result of this approach is a hodge-podge of special-case solutions. A good example for this deficiency is tool change support in LinuxCNC: while random tool changers are well supported, it is next to impossible to reasonably define a configuration for a manual-tool change machine with, for example, an automatic tool length offset switch being visited after a tool change, and offsets set accordingly. Also, while a patch for a very specific rack tool changer exists, it has not found its way back into the main code base. However, many of these things may be fixed by using an O-word procedure instead of a built in code - whenever the - insufficient - built in code is to be executed, call the O-word procedure instead. While possible, it is cumbersome - it requires source-editing of NGC programs, replacing all calls to the deficient code by a an O-word procedure call. In it's simplest form a remapped code isn't much more than a spontaneous call to an O-word procedure. This happens behind the scenes - the procedure is visible at the configuration level, but not at the NGC program level. Generally, the behavior of a remapped code may be defined in the following ways: - you define a O-word subroutine which implements the desired behavior - alternatively, you may employ a Python function which extends the interpreter's behavior. .How to glue things together M- and G-codes, and O-words subroutine calls have some fairly different syntax. O-word procedures, for example, take positional parameters with a specific syntax like so: [source,{ngc}] --------------------------------------------------------------------- o<test> call [1.234] [4.65] --------------------------------------------------------------------- whereas M- or G-codes typically take required or optional 'word' parameters. For instance, G76 (threading) requires the P,Z,I,J and K words, and optionally takes the R,Q,H, E and L words. So it isn't simply enough to say 'whenever you encounter code X, please call procedure Y' - at least some checking and conversion of parameters needs to happen. This calls for some 'glue code' between the new code, and its corresponding NGC procedure to execute before passing control to the NGC procedure. This glue code is impossible to write as an O-word procedure itself since the RS274NGC language lacks the introspective capabilities and access into interpreter internal data structures to achieve the required effect. Doing the glue code in - again - 'C/C\+\+' would be an inflexible and therefore unsatisfactory solution. .How Embedded Python fits in To make a simple situation easy and a complex situation solvable, the glue issue is addressed as follows: - for simple situations, a built-in glue procedure (`argspec`) covers most common parameter passing requirements - for remapping T,M6,M61,S,F there is some standard Python glue which should cover most situations, see <<remap:standard-glue,Standard Glue>> - for more complex situations, one can write your own Python glue to implement new behavior. Embedded Python functions in the Interpreter started out as glue code, but turned out very useful well beyond that. Users familiar with Python will likely find it easier to write remapped codes, glue, O-word procedures etc in pure Python, without resorting to the somewhat cumbersome RS274NGC language at all. .A Word on Embedded Python Many people are familiar with 'extending' the Python interpreter by 'C/C\+\+' modules, and this is heavily used in LinuxCNC to access Task, HAL and and Interpreter internals from Python scripts. 'Extending Python' basically means: your Python script executes as 'it is in the driver seat', and may access non-Python code by importing and using extension modules written in 'C/C\+\+'. Examples for this are the LinuxCNC `hal`, `gcode` and `emc` modules. Embedded Python is a bit different and and less commonly known: The main program is written in C/C++ and may use Python like a subroutine. This is powerful extension mechanism and the basis for the 'scripting extensions' found in many successful software packages. Embedded Python code may access 'C/C\+\+' variables and functions through a similar extension module method. [[remap:getting-started]] == Getting started Defining a code involves the following steps: - pick a code - either use an unallocated code, or redefine an existing code - deciding how parameters are handled - decide if and how results are handled - decide about the execution sequencing. === Picking a code Note that currently only a few existing codes may be redefined, whereas there are many 'free' codes which might be made available by remapping. When developing a redefined existing code, it might be a good idea to start with an unallocated G- or M-code so both the existing and new behavior can be exercised. When done, redefine the existing code to use your remapping setup. - the current set of unused M-codes open to user definition can be found <<remap:unallocated-m-codes,here>>, - unallocated G-codes are listed <<remap:unallocated-g-codes,here>>. - Existing codes which may be remapped are listed <<remap:remappable-codes,here>>. [[remap:parameter-handling]] === Parameter handling Let's assume the new code will be defined by an NGC procedure, and needs some parameters, some of which might be required, others might be optional. We have the following options to feed values to the procedure: // . <<remap:extracting-words,extracting words from the current block>> . extracting words from the current block and pass them to the procedure as parameters (like `X22.34` or `P47`) //. <<remap:referto-inifile-variables, referring to ini file //variables>> . referring to ini file variables . referring to global variables (like `#2200 = 47.11` or `#<_global_param> = 315.2` The first method is preferred for parameters of dynamic nature, , like positions. You need to define which words on the current block have any meaning for your new code, and specify how that is passed to the NGC procedure. Any easy way is to use the <<_the_argspec_parameter,argspec statement>>. A custom prolog might provide better error messages. Using to ini file variables is most useful for referring to setup information for your machine, for instance a fixed position like a tool-length sensor position. The advantage of this method is that the parameters are fixed for your configuration regardless which NGC file you're currently executing. Referring to global variables is always