Fix two related travel move bugs - #513
Open
jeffc wants to merge 2 commits into
Open
Conversation
This file contains hidden or 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
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.
Let me know if you want me to separate this out into two PRs for the two bug fixes:
Bug 1
Update travel moves that are entirely within the part boundary (eg, going from the end of one cutting layer to the beginning of the next) to perform a small (0.1mm) "hop" up, then a rapid in-plane travel, and then finally a rapid move back to the previous z height before starting the plunge move.
Before (large step-down and step-over in order to make the visualization clearer):
After:
Note that instead of moving at "plunge speed" from the innermost ring of the last layer directly to the outermost ring of the next, we now fast-move up 0.1mm and then over to the plunge point before plunging straight down. (hence the stacked plunge lines on the right side of the screenshot
The code for this is in two different places due to the structure of the nested conditional.
Bug 2
Moves between concentric offsets in an area clear operation were previously getting omitted as fast moves (
G0), meaning that we were doing a (relatively short, usually) travel-speed move through uncut material. Notice in the first screenshot how the lines between each concentric circle are blue (travel speed), whereas in the second screenshot they're green (cutting speed). We only force cutting speed if we're making a small move with a zero or insignificant-but-negative Z delta, otherwise we leave it alone.