tp: possible fix for non-zero current velocity when stopped #10
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
tpHandleEmptyQueue now explicitly sets status flags in tp and emcmotStatus to the appropriate defaults. This should prevent spurious non-zero values from appearing in current_vel and similar status fields when the motion queue is empty. This was likely an overlooked regression from 2.6 due to the major refactor introduced with the new trajectory planner.
…IO is not disrupted
|
Needs Signed-off-By. |
robEllenberg
pushed a commit
to robEllenberg/linuxcnc-mirror
that referenced
this pull request
Aug 25, 2015
2c88c39 Merge pull request LinuxCNC#13 from strahlex/mklauncher4 3afd7aa updating definitions for mklauncher 30ba664 added none to motion type to work with mkwrapper 0fa4107 updated mklauncher definitions 3a015e3 using index field for mklauncher 18e2954 updated definition for mklauncher 2a36b25 added definitions for mklauncher c950308 fix missing msgid in value.proto f9a759a Merge pull request LinuxCNC#12 from mhaberler/master 0a01fd2 object: add Vtable, Inst descriptions and msgid's 8ae9f49 HAL instantiation: update to new HAL objects, instance-related commands 9f35d82 proto definitions: add unique msgd options 9a4e3e0 README.msgid - about protobuf type id's and their usage 4f854b3 README.style: remove obsolete file d281116 nanopb.proto: bring in msgid changes from nanopb upstream 118f0e3 Merge pull request LinuxCNC#11 from mhaberler/prune-messages-for-nanopb 0674348 nanopb.proto: update to nanopb-0.3.2 5167bcb Merge pull request LinuxCNC#10 from mhaberler/prune-messages-for-nanopb 90beece message.proto: do not export mkwrapper messages to nanopb/RT git-subtree-dir: src/machinetalk/proto git-subtree-split: 2c88c39
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>
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.
tpHandleEmptyQueue now explicitly sets status flags in tp and
emcmotStatus to the appropriate defaults. This should prevent spurious
non-zero values from appearing in current_vel and similar status fields
when the motion queue is empty. This was likely an overlooked regression
from 2.6 due to the major refactor introduced with the new trajectory
planner.