Request support for Fixed Tool Sensor strategy between separate Gcode files

[rudderfeet]

I would like to utilize gSender 1.2's Fixed Tool Sensor support between separate Gcode files, because often I prefer to view each sequence as a separate set of movement commands for easier visualization and editing, instead of a single monolithic bundle.

I tried to "fool" gSender into doing this by programming a Macro with a single "M6" command that I would click at the end of one Gcode file before running the next, but that only raised a dialogue prompt and didn't follow the strategy set in Settings -> Tool Change -> Fixed Tool Sensor. I wonder if Macro M6 commands are not flowing through the same path as M6 commands executed from file?

[kglovern]

Ultimately the toolchange wizard is set up as a way to handle toolchanges within files, not between files.

What you're describing almost sounds like a job queue, which is something we're looking at for the future but don't have a definite date on.

Is there a reason you can't setup a custom macro that handles the automated portion that you can run between jobs?

[rudderfeet]

Hi Kevin. I'd challenge wither an M6 between files should be handled differently than an M6 from a Macro or even the console if a user has told gSender they want a specific strategy to be executed upon (any?) tool change command. At the very least, it might be useful to clarify on the Settings -> Tool Change screen that the user's preference only applies to intra-file M6es, but again, why not combine them? I'm struggling to imagine a use case when someone would want to send an M6 via Macro or console and only ever see a pop-up, when they've told gSender to use a fixed tool sensor, or a script.

Definitely I could also set up a custom macro that handles the automated portion, but wouldn't that be duplicative of what you (impressively!) engineered into the Tool Change strategy? I'm just thinking about the opportunity to reuse that work instead of having to maintain separate settings and code, with room for users to get things wrong.

[rudderfeet]

Here's a specific use case if/as it helps:

• For Carveco Maker to generate tool path files for the Longmill Mk2, the manufacturer recommends the "UGS GRBL (inch)" or "UGS GRBL (mm)" machine file translators, but unfortunately those do not support tool changes. Therefore, if a model uses multiple bits, one must export separate tool path files instead of a single one with an M6 command separating the bit sequences. This results in at least one file for the first bit (e.g. a rouging pass), and another for the second bit (e.g. a detail pass) and so on. As such, one cannot effectively use Carveco Maker for the Longmill and a Fixed Tool Sensor and leverage gSender 1.2+'s new built-in support for the sensor. There is a workaround by crafting one's own macro, but it would be great to use this new feature between Gcode files.

[SienciLabs]

@rudderfeet that's a good point, and is one we've realized exists. It's still a bit of a sticking point in the hobby space since I think on one hand things become much easier when all the toolpaths are in one file with M6 spacing them, but on the other hand this come with a downside of making the file size potentially drastically larger and also making the assumption that the machine firmware or sender supports tool changing. Because of this, many manufacturers went the route of splitting up the files and relying on the user to guide themselves on changing their own tools.

I totally agree with you though that introducing that guidance in the sender is a really powerful and useful thing. So one of the next things we need to figure out is how to handle multiple files as one singular 'job', but then if we went that route it would also be good to take 'merged' files and also split them up into their separate files. This can become a bit complicated, but I'm hoping that as the hobby industry matures and tool changing becomes more accepted as a part of the process of using hobby machines then we can come to a better agreement on where the responsibility will lie to handle tool changing and the file structure. Personally I'm hoping that we'll land on the Firmware handling the tool change procedure, with the sender just acting as the arbiter of the files and providing guidance and images on the tool changing

Idea also mentioned in #302 by @jdforsythe