Standalone Config Snippets
-
@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.
-
@deckingman Yep! I caught that! Just providing some flavor, I appreciate your input!
-
@luke-slaboratory I'd guess the ultimate would be to have tools defined by some sort of unique identifier (e.g a bar code or mac address type of thing) in such a way that the process of fitting or loading a tool would mean that the firmware could read the tool identifier and configure itself. Perhaps each digit of the tool identifier would refer to some aspect or characteristic of the tool.
It would be a more sophisticated and elegant expansion on my crude method of using switches which get triggered by "lugs" attached to the tool mount, which in turn load complete configuration files. Two lugs only give me 4 possibilities. One switch triggered is hot end A, the other switch triggered is hot end B, both switches triggered are hot end C and no switches triggered means no hot end fitted.
