use Tcl_SetResult and Tcl_GetStringResult #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Please do not use the "pull request" feature on the linuxcnc-mirror repository. The way to get your work integrated with linuxcnc.org continues to be the developers mailing list and the #linuxcnc-devel IRC channel on freenode. http://mid.gmane.org/20120309014743.GA26045%40unpythonic.net |
jepler
pushed a commit
that referenced
this pull request
Jul 10, 2013
…g a sub this fixes the second reported issue in https://sourceforge.net/p/emc/bugs/315/, the following now parses OK: O<multipass> SUB #<sub> = #1 O#<sub> CALL O<multipass> ENDSUB m2
mhaberler
referenced
this pull request
in mhaberler/machinekit
Jul 15, 2013
jepler
pushed a commit
that referenced
this pull request
Aug 3, 2013
jepler
pushed a commit
that referenced
this pull request
Oct 10, 2013
seems this was triggered by the CXXFLAGS change (-std=c++0x being used) only seen on gcc 4.6.3/wheezy/arm7l see answer #1 http://stackoverflow.com/questions/14072009/error-using-algorithm-header-file-in-c
robEllenberg
pushed a commit
to robEllenberg/linuxcnc-mirror
that referenced
this pull request
Jan 19, 2015
Changes to make integration into qmake easier
jepler
pushed a commit
that referenced
this pull request
Apr 16, 2015
jepler
pushed a commit
that referenced
this pull request
Oct 28, 2015
## Implementation
In essence, `M98` and `M99` are O-words. O-words are handled
specially compared to M- and G-words, both when being read
(e.g. parsed earlier in interp loop than other codes) and when being
executed (e.g. own translation unit with functions for searching and
seeking across g-code file blocks). Therefore, they are implemented
next to other O-word code, and as much as possible they share the same
read and execute flow.
`M98 P1` is mostly similar to `O1 call`, and they share the
`Interp::execute_call()` function. When `M98` is followed by an
L-word (repeat count), it maintains a loop counter in the parent
context `m98_loop_counter` field, and special logic in
`execute_call()` manages call return block location for iteration.
Other minor changes are spread around `interp_read.cc`,
`rs274ngc_pre.cc` and related header files, some requiring distributed
coordination. To carry this state, new values are established for the
`context_struct` and `block_struct` fields, `call_type` and `o_type`.
## Fanuc compatibility
No changes to existing rs274ngc-style G-code compatibility are made.
The Fanuc compatibility specifics:
- `O....` == `O.... sub`
- Online examples show the bare `O....` marking the start of a
subroutine called from `M98`
- `M99` == `O.... endsub`, except params are not restored (*)
- `M98 P....` == `O.... call`, with differences:
- `M98` passes params `#1` to `#30` into sub context (*)
- Params may not be passed in the `M98` block, unlike O-word call
(e.g. `O.... call [...] [...]`)
- `M98` calls have no return value
- `M98 P.... L2` == `O... repeat [2]`, `O.... call`, `O... endrepeat`
- The `OWORD_N_ARGS` feature will not work
- Subroutines may follow main program
- (After a bugfix, there is no difference with rs274ngc-style
G-code.)
- Fanuc-style subroutines my be disabled by placing
`ENABLE_FANUC_STYLE_SUB = false` in the `[RS274NGC]`
section of the `.ini` file.
## * Subroutines
O-word calls pass local parameters `#1` to `#30` in the O-word block,
and parameter scope is limited to the subroutine, e.g. the value of
param`#10` defined in the main program will not be visible in the
scope of the sub.
By contrast, Fanuc parameters always have global scope, including
numbers `#1` to `#30`, are global. Setting low-numbered parameters
(`#1 = 30`) in blocks previos to the M98 call.
## Fanuc and rs274ngc sub call coexistence
Fanuc and rs274ngc sub block syntax styles are easily and
unambiguously differentiated in all three block types. However,
`O...`, `M99`, `M98` each needed additional somewhat inelegant
handling in `interp_read.cc` `Interp::_read()` to graft in syntax
parsing.
Though the syntax differences create no parsing ambiguities, during
conversion the two styles share nearly the same code paths, with
differences switchable by the detected O-word or call style. The
major addition to conversion is a section of code turned on for `M98`
in `Interp::execute_call()` that does most of the parameter
processing, `M98 L` loop logic, etc.
Additional checks ban mixing rs274ngc and Fanuc sub blocks within one
call/return cycle. They are meant to reduce confusion arising from
careless mixing and the unintended side-effects of style differences.
If there is reason to disable Fanuc subroutines, this may be accomplished
by placing `ENABLE_FANUC_STYLE_SUB = false` in the `[RS274NGC]`
section of the `.ini` file.
Signed-off-by: John Morris <john@zultron.com>
cradek
pushed a commit
that referenced
this pull request
May 13, 2016
This patch implements subprograms as defined with a bare numbered O-word, called with `M98` and returned from with `M99`. This common style of subprogram is used in Fanuc, Haas and other controllers. ## Implementation In essence, `M98` and `M99` are O-words. O-words are handled specially compared to M- and G-words, both when being read (e.g. parsed earlier in interp loop than other codes) and when being executed (e.g. own translation unit with functions for searching and seeking across g-code file blocks). Therefore, they are implemented next to other O-word code, and where possible they share the same read and execute flow. There is a major semantic difference compared to traditional rs274ngc subroutines: Execution starts at the beginning of the file and continues right into a program definition rather than skipping past. Such a program definition at the beginning of the file is the 'main program', although not treated specially by the interpreter, and `M98` may only call subprograms following the main program. In the interpreter's read phase, `M98` call and `M99` return are handled in `read_o()` at the same time as O-words in `interp_read.cc`. `M98` is handled much like `O call`. During execution, `M98 P1` is quite similar to `O1 call`, and they share the `Interp::execute_call()` function in `interp_o_word.cc`. Still, `M98` must be distinguished with the special `call_type = CT_NGC_M98_SUB` to signal to `execute_call()` and `unwind_call()` that parameters `#1` through `#30` are global. The call type is also used to prevent programmers from mixing e.g. `O sub` with `M98` and `M99`. When `M98` is followed by an L-word (repeat count), it maintains a loop counter in the parent context `m98_loop_counter` field, and special logic in `execute_call()` manages call return block location for iteration. An `M99` in the main program (top-level call stack) has a special meaning. There is no subprogram to return from, so instead it means to skip back to the beginning of the file and resume execution; in other words, loop endlessly over the program. In this case, `M99` is treated like an M-word handled by `read_m()`, and shares modal group 4 and `convert_stop()` with `M02` and `M30`. The interpreter cannot handle endless loops because it would queue canon commands indefinitely without a program end or a queue buster, and never issue them to task for execution. Therefore the interpreter distinguishes the following two subcases of the `M99` endless loop: - Task: During real execution of a program, an `M99` in the top-level context is treated like a queue-buster. The interpreter queue is flushed to motion (after queuing any link segments) before looping back to the program beginning. Task enables this special behavior by calling `interp.set_loop_on_main_m99(true)`. - SAI, preview, etc.: When not actually executing, an `M99` in the top-level context is treated like an `M30`, program stop. The assumption is that a single loop will be sufficient for non-execution use cases, such as to render a tool path preview or check the canon commands generated by a program. This is the default behavior, also explicitly set by calling `interp.set_loop_on_main_m99(false)`. ## Fanuc and other controller compatibility No changes to existing rs274ngc-style G-code compatibility are made. The `M98`/`M99` compatibility specifics: - `O....` != `O.... sub` - The bare `O....` marks the start of a main program or subprogram - Execution continues into program definition, whereas `O.... sub` routines are skipped - `M99` after `M98` == `O.... endsub`, except params are not restored - `M99` in main program - Execution loops back to beginning of file - `M98 P....` == `O.... call`, with differences: - `M98` passes params `#1` to `#30` into sub context - Params may not be passed in the `M98` block, unlike O-word call (e.g. `O.... call [...] [...]`) - `M98` calls have no return value - `M98 P.... L2` == `O... repeat [2]`, `O.... call`, `O... endrepeat` - The `OWORD_N_ARGS` feature will not work - Subroutines must follow main program - (After a bugfix, rs274ngc-style subroutines may also follow main program) - `M98`/`M99`-style subroutines may be disabled by placing `DISABLE_FANUC_STYLE_SUB = 1` in the `[RS274NGC]` section of the `.ini` file. ## Fanuc and rs274ngc sub call coexistence The syntax differences create no parsing ambiguities. During conversion the two styles share some code paths, where any differences are handled by the O-word (or M-word) type and call style. Additional checks ban mixing rs274ngc and Fanuc sub blocks within one call/return cycle in hopes of reducing confusion arising from careless mixing and the unintended side-effects of style differences. If there is reason to disable Fanuc subroutines, do so by placing `DISABLE_FANUC_STYLE_SUB = 1` in the `[RS274NGC]` section of the `.ini` file. Signed-off-by: John Morris <john@zultron.com>
3 tasks
This was referenced Jul 19, 2016
Merged
2 tasks
3 tasks
l29ah
pushed a commit
to l29ah/linuxcnc
that referenced
this pull request
Dec 27, 2017
hal_gpio_h3: allocate proper amount of memory
2 tasks
Closed
1 task
1 task
3 tasks
3 tasks
Closed
3 tasks
3 tasks
Closed
1 task
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is neccessary to compile linuxcnc with tcl/tk 8.6