-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix position shift with MBL #4310
Fix position shift with MBL #4310
Conversation
308762c
to
ef4de2f
Compare
@epatel Note the main bug-fix here: We forgot to include the newly-inroduced As a bonus, I realized that MBL can handle a slightly finer grid – up to 9 x 9 – because the |
ef4de2f
to
68dce9c
Compare
5b7d77e
to
2030852
Compare
One thing. Removing the recursion is not good. I hope you test everything else to verify, my brain hurts trying to follow all changes. Below is one case that will fail when doing like that. When moving "From" to "To" the first split will be on the X boundary (B) because that will be the first "if" statement that gets selected, then split A is lost which would have been found by the recursion. |
Makes sense! |
69722c4
to
ab32a9c
Compare
I realize the changes are many, and I didn't have them well laid out. So I went back and re-did the commits in order of obviousness, leaving off the dropped recursion.
|
e1e7b8e
to
3af7e10
Compare
33c0c6f
to
3702987
Compare
3702987
to
493d30c
Compare
Addressing #4266
When MBL is enabled and a position is set with
G92
(or other functions —likegcode_T
tool-change— that reorient the current position) the destination ends of the mesh-split lines are calculated at the wrong positions. As a result we see strange moves after a tool-change when MBL is enabled.mbl.active
check so other line buffering is possible.mesh_buffer_line
always usesdestination
, use it as the targetmesh_buffer_line_to_destination
instead