Standalone Config Snippets
-
One of the quirks about multi-tool setups is that we can't readily add/remove standalone config.g snippets without editing the main config.
That has to do with some config-related interdependence of commands. Here's an example.
M584, which sets the drive mapping, requires that you declare all extruder drives at once like this:
M584 E3:4:1.0:1.1Running M584 later in the config (let's say, to add a new tool), requires you to take what was already there and append to it manually like this:
M584 E3:4:1.0:1.1:1.2This interdependence prevents you from adding config snippets to add/remove a tool without modifying the main config. The result is that you have to know in advance how many tools you have or will ever have. The other quirk here is that electronics setups may differ on multitool setups--even on machines with well-defined electronics options like Jubilee. Someone might use Duet3 with toolboards while someone else uses the 3HC's. I would love to know if there's a way to dynamically offer standalone snippets of tool-related config.g's without requiring that folks edit the main config.
So here are my questions.
- for folks tweaking their machines often (like for multitool setups), does any sort of read-modify-write syntax exist? Something like:
curr_m584 = M584 curr_M584:1.2- Is there any effort to make dynamic config generation for swapping tools any simpler using resources of the optional Raspi?
Cheers--and thanks!
-
@poofjunior I'm sure there will be some sensible way to do this using the object model, variables and conditional gcode...
Alternatively you could just pull out relevant sections of your config (e.g. motors and tools) into a separate macro. You can then more easily edit the macro (and have several different ones) whilst getting your machine setup?
-
@engikeneer hmm having a way to just define the config as the object model would actually solve this problem! But AFAIK, there's no way to simply paste the object model in a text file.
Unfortunately, pulling out tool-related configs into a standalone macro doesn't work for the M584 reason mentioned above. In a nutshell, to add a new extruder drive, you need to know about the existence of all the others.
-
@poofjunior thinking about this a "read, modify, write" functionality could be either complicated or limited. In the example you showed it works for adding another extruder but not for removing one. A more general option would need to decompose the relevant commands into their various options, reference those, and then recompose them into a new, valid version of the command.
The object model route already has the configuration information individually referenceable (however it is not 100% complete yet, for example some M569 settings).
The information from M584 is there AFAIK, eg:
move.axes[0].drivers[0]
move.axes[1].drivers[0]
etc
and
tools[0].extruders[0]
tools[1].extruders[0]
etcNow there would no doubt be more work to sensibly iterate through the various parts of the object model and then assemble the commands you wanted to either add or remove a tools, also we still need to add some configuration settings to the object model, however that looks like a better approach.
Not sure if the gcode meta commands would need extending for this work, @dc42 will need to comment.
If you carried out the heavy lifting in an external plugin in DSF then that simplified the requirement to simply be that the OM reports all configuration options. The plugin could write specific configuration macros that the main config.g (which would then only a be a minimum config to get to the point the configuration macros) could be run. Getting really fancy the plugin could have a UI element to select the tools to be configured on next boot.
-
@t3p3tony Yeah to be honest, having an alternate means of configuring the machine by simply importing an Object Model would be slick. Since it's basically just a json dict or dictionary-like, being able to upload one could let us write custom WebUIs that simply output an Object Model as a text file. What's more, it could be hierarchical. So the machine could look for an object model file first; then patch it with individual commands from a config.g file if one exists. That would give you backwards compatibility.
I've been tempted to write a config generator script that figures out the order of commands and produces a config. From there it's not much work to wrap it with a couple webpages that enable dynamic tool adding/deleting. But that approach seems a bit backwards, since the Object Model already has the structure I want. There's just no way (AFAIK?) to import one from a file.
Thanks for looking into options on this!
-
I'm afraid those 'code snippets' will circulate in the forum and people will try to use them as 'copy/paste' in their machines. Wondering how big is the chance to screw up your printer?
It's easier IMHO to rewrite config.g than writing a custom WebUI? Or is there a usecase I haven't taken into account?OTOH I would like to see a Meta command to add or remove drives etc. like
M584 = {objectmodel_path} **plus** 0.4 ; plus or minus being a new Meta command or M584 = {objectmodel_path} **minus** 0.4 or M584 += ... -
We're looking to provide array-valued variables in the future, which would make this kind of thing easier. But for this particular use case I think it would make more sense to provide an alternative M584 syntax that allows an extruder number and driver number to be provided. We would then need to allow for the possibility of holes in the extruder numbering.
-
I would very much support this, not only for having specific config files for individual tools, but also just to have all the tool related config in one place in config.g
Ie, you could have the drive assignment, stepper config, speeds, etc all grouped by individual tools and make changing things much easier. -
@diamondback said in Standalone Config Snippets:
I would very much support this, not only for having specific config files for individual tools, but also just to have all the tool related config in one place in config.g
Ie, you could have the drive assignment, stepper config, speeds, etc all grouped by individual tools and make changing things much easier.There is always the option to use config_overrride.g. It's not ideal but might serve your purpose. Alternatively, one could group all those commands in a macro and call that macro from config.g.
Another option which is often overlooked is to have multiple configuration files and switch between them using M505.
-
Hmm, I suppose I'm looking for an easier way to quickly re-configure a machine. For the most part, that's a pretty rare thing to do, since most folks configure their machine once or occasionally when they upgrade/tweak hardware.
But for machines whose configurations can change frequently (tool changing machines that add/remove various tools), it would be nice to have an easier way to manipulate the machine configuration in a way that's not so highly interconnected.
I certainly can't ask the Duet project to support this kind of flexibility for hobbyists who want to switch tools on-and-off. But I do think that having a less-interconnected config.g or, higher level, an alternate api for changing machine configuration, would lower the bar for folks interested in playing with toolchanging setups. And I think that Duet supports tool-changing setups best so far.
If folks developing the Duet would be willing to consider something like configuring the machine via Object Model upload (via text file or other), I could jump on that API to build an abstraction that lets you easily add/remove tools. Otherwise, I'd probably look at using jinja templates to abstract the config-writing/editing process a bit more.
I'll keep my eyes peeled on project updates for anything that could make machine reconfiguration easier. In the meantime, thanks a bunch for chiming in!
-
@poofjunior said in Standalone Config Snippets:
Hmm, I suppose I'm looking for an easier way to quickly re-configure a machine. For the most part, that's a pretty rare thing to do, since most folks configure their machine once or occasionally when they upgrade/tweak hardware.
But for machines whose configurations can change frequently (tool changing machines that add/remove various tools), it would be nice to have an easier way to manipulate the machine configuration in a way that's not so highly interconnected.
................................................Did you see my reply to @Diamondback above re using multiple configurations and using M505 to switch between them?
I regularly swap between a 6 input mixing hot end (with 6 extruders), a dual input combined hot end (2 extruders but single nozzle), and a more conventional single input, single extruder hot end. Not only does each configuration use different extruders, but each one uses different speeds/accelerations/jerk settings/pressure advance and retraction settings. I also use different user and system macros.
Each hot end mount has "lugs" in different positions and on my to-do list is to fit switches or sensors which will detect whichever hot end is present at power on, and run a macro which will use conditional gcode to run M505 and point to the correct configuration file folder.
-
@deckingman said in Standalone Config Snippets:
@diamondback said in Standalone Config Snippets:
I would very much support this, not only for having specific config files for individual tools, but also just to have all the tool related config in one place in config.g
Ie, you could have the drive assignment, stepper config, speeds, etc all grouped by individual tools and make changing things much easier.There is always the option to use config_overrride.g. It's not ideal but might serve your purpose. Alternatively, one could group all those commands in a macro and call that macro from config.g.
Another option which is often overlooked is to have multiple configuration files and switch between them using M505.
Interesting, the M505 certainly sounds useful. Thanks!
-
@deckingman yeah; this is certainly useful, but I'm looking for something more general purpose.
On my end, I'm the maintainer of Jubilee and the Discord crew of folks building Jubilees or Jubilee-inspired machines. Jubilee is a toolchanger, so lots of folks approach building one with a custom tool setup in mind, but plenty of folks also share tool designs. I'm looking for something that can make the configuration readily adaptable to anyone's tool setup, not just mine. And then, on top of that, for folks sharing the same tools, it would be great to offer standalone snippets on the wiki or on Github that can stand separately from the machine configuration. High level, my ideal goal would be for anyone to be able to dynamically switch tool setups without ever having to touch a config.g file. Rather; there's some in-between abstraction like a GUI that automatically assembles the config for you.
-
@poofjunior Well it was just an idea that might work within the existing duet framework/ecosystem. Another approach might be to wrap all the tool specific commands in macros. These would effectively be the stand alone code snippets you mention,and which could be shared. There are numerous ways that macros can be called, including the use of tpre/tpost/tfree which are pretty much designed for tool changers. M3D used an approach on their quad machine whereby the entire configuration was broken into sections, each one contained within a macro. Their config.g did almost nothing except call other macros.
-
@deckingman said in Standalone Config Snippets:
@poofjunior Well it was just an idea that might work within the existing duet framework/ecosystem. Another approach might be to wrap all the tool specific commands in macros. These would effectively be the stand alone code snippets you mention,and which could be shared. There are numerous ways that macros can be called, including the use of tpre/tpost/tfree which are pretty much designed for tool changers. M3D used an approach on their quad machine whereby the entire configuration was broken into sections, each one contained within a macro. Their config.g did almost nothing except call other macros.
Isn't that exactly what is not possible atm? How would one define the relevant drive and set the drive parameters for the specific tool? Many of the relevant commands (like M584, M92, M350, etc) don't allow you to append new values to an already existing configuration, they only allow for a single monumental configuration.
Maybe I'm missing something, but how would one configure M584 calls in like 4 different files that add a new extruder drive each time rather than overwriting each other?
-
@diamondback said in Standalone Config Snippets:
Maybe I'm missing something, but how would one configure M584 calls in like 4 different files that add a new extruder drive each time rather than overwriting each other?
That's correct its currently not possible to do this with all the commands needed. As I said above it may be possible to read out the values from the OM for the existing configuration using gcode meta commands and then re-assemble them but the OM needs to be extended to have all configuration settings exposed.
-
@diamondback For sure adding new motors would be tricky. I didn't realise you wanted to do that. Do you use tool boards for each tool? That is to say, does each tool have its own dedicated expansion board and wiring? I haven't looked at the jubilee but my understanding was that the concept was to use common wiring and connect different tools to the same.
-
@deckingman No, I'm using a Duet Wifi + Duex 5 with E3D toolchanging hardware (custom frame and stuff though).
My primary use case would be two-fold:
- Being able to experiment with new hotends/extruders without having to mess up the existing, known-good configuration (commenting large sections in config.g kinda works but is very messy and easy to confuse)
- Having some non-permanently connected tools for special tasks that would be manually switched in when needed and have their own fully contained configuration.
Most of the functionality is already there to make this a reality, it's just these monolithic configuration commands that make it really inconvinient.
-
@deckingman There's the full range of options from RRF2 w/ D2+Duex to RRF3 with fully-kitted CAN systems. People have used hardwired tools, Quick Disconnect dumb tools, to toolboards via CAN. From a user standpoint, I like being able to swap tools as needed for specific jobs, and would appreciate the long-term QOL improvement of that. From Poofs point of view, (same here as active member helping out on the discord) if a User wants to build a non-standard tool, or add to the "baked in" config of just 2x tools instead of 3x or w/e - it would be nice to be able to update that on the fly without running into the issue of "ok, so not only do you have to define a new tool, but you have to go back and add extra motor outputs to your starting M584, Oh, you have a D3 toolboard? need to define it WRT the board's inputs, and reboot the system"... etc etc.
Would be nice to have a "add a tool" configurator as a plugin to make adding/changing tools a breeze on toolchanging systems.
-
@luke-slaboratory Sure, I understand the longer term goal. I was just trying to help by suggesting ways to achieve the objective with what's currently available.
