You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Snapmaker wastes a lot of time jogging that could be spent cutting. One thing that would help is bidirectional path construction.
Describe the solution you'd like?
Right now, if I tell Snapmaker to etch a path, it starts from the first point and goes to the last point, in order. This means that at the end of the path, it moves up, then moves back to the starting point, and moves back down. This wastes a lot of time that could be spent actually cutting.
Unless there's some concern about the CNC bit getting too hot or something, it would make way more sense for every path to be executed bidirectionally:
Perform the cut using the points in order.
Step down by the step-down distance.
If not finished, perform the cut using the points in reverse order.
Step down by the step-down distance.
If not finished, go to step 1.
This would reduce cutting time considerably for shorter paths, and should be relatively simple to achieve. It would also minimize the positional imprecision that can creep in from jogging, which can cause small bits to bind when doing deep cuts.
The text was updated successfully, but these errors were encountered:
🐞 feature request
Is your feature request related to a problem? Please describe.
Snapmaker wastes a lot of time jogging that could be spent cutting. One thing that would help is bidirectional path construction.
Describe the solution you'd like?
Right now, if I tell Snapmaker to etch a path, it starts from the first point and goes to the last point, in order. This means that at the end of the path, it moves up, then moves back to the starting point, and moves back down. This wastes a lot of time that could be spent actually cutting.
Unless there's some concern about the CNC bit getting too hot or something, it would make way more sense for every path to be executed bidirectionally:
This would reduce cutting time considerably for shorter paths, and should be relatively simple to achieve. It would also minimize the positional imprecision that can creep in from jogging, which can cause small bits to bind when doing deep cuts.
The text was updated successfully, but these errors were encountered: