kglovern
commented
1 year ago Hi,
It's already possible for the user to run any number of macros using the "Manual" strategy. We considered adding a specific macro run option, but the current workflow is a little more flexible since they aren't locked into a single macro and can pick and choose depending on their current need without changing preferences.
This also helps your listed disadvantage - since you can already have various macros set up and just run the relevant one.
crpalmer
hambudi
marcboivin
I see in git that you have a toolchange_revamp branch started and I'm afraid that you'll likely want to stay with that instead of my alternative proposal which also gives you more automated tool changes. But, there's no harm is throwing the idea out there... In
github.com/crpalmer/gsender/tree/toolchange-macro
I added another option for toolchanges: Macro (in addition to the existing Ignore, Manual or Code). When a toolchange is triggered, this macro is executed and can use M0 to pause as needed to prompt the user. For example, using a Shapeoko Pro with a BitSetter, my macro will move to predefined location and ask the user to insert a tool before probing the bitsetter to set Z and then resumes the program (Probe Tool macro).
Pushing the functionality to a macro vs. having gSender generating the gcode itself has the distinct advantage that you can easily customize what happens and you don't have to try to parameterize everything in the universe. You can still provide example macros to make it easy for a user to handle a simple toolchange.
The big disadvantage of the approach I took is that you have to edit macros to change the parameters (tool change location, probe location, feeds, etc). That makes it much less user friendly. To solve this problem, you could think about implementing some way to define all the global parameters and providing a friendly user interface for editing them.