Standalone Config Snippets
-
@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.
-
Yeah - I have a few ideas on barcodes, UUID's, QRcode tools (airtag now? lol) but it seems the firmware would have to re-write itself regardless between tool swaps. Definitely on the agenda tho.
Good feedback. -
@deckingman said in Standalone Config Snippets:
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.
Is it possible to run a trigger macro with two inputs? Or do you have to read 'the other' trigger inside the macro and use 'if' conditions to finally start the right macro?
-
@o_lampe said in Standalone Config Snippets:
@deckingman said in Standalone Config Snippets:
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.
Is it possible to run a trigger macro with two inputs? Or do you have to read 'the other' trigger inside the macro and use 'if' conditions to finally start the right macro?
I haven't actually implemented this "hot end sensing" system on my printer yet. The hot end mounts have the lugs but I haven't yet fitted the switches to the carriage. However, I plan to use the same system that I use with the joystick jog control that I have fitted. This uses 4 micro switches and gives me movement in 8 directions depending on which combination of either one or two switches are closed. There is also a button that when pressed, gives my long moves (about 20mm) and when not pressed gives me short moves (about 0.5mm). So 8 move directions and two "speeds" (actually distances) giving 16 combinations from 5 switches. Essentially it's a single macro which uses conditional gcode to sense the status of the 5 switches. It runs a loop and repeats as long as one or more switches are closed. Here it is in it's entirety which should show how it works.
; ******Trigger 5 - Joystick lefgt,right, forward or backwards ******** ; IO Pin to switch connections J5=left, J6=Right, J7=Forward, J8=Backward if state.status != "processing" ; make sure that a print is NOT running G91; Set relative M400; wait for any moves to finish G1 F3000 ; set feedrate to 100mm/sec M118 S"Trigger 5 - Joystick" while sensors.gpIn[5].value=0 | sensors.gpIn[6].value=0 | sensors.gpIn[7].value=0 | sensors.gpIn[8].value=0 if sensors.gpIn[5].value=0; joystick left if sensors.gpIn[7].value=0 ; joystick left and forwards M400 echo "Left and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y-20 V-20 B-20 else G1 X-0.5 U-0.5 A-0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick left and backwards M400 echo "Left and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 Y20 V20 B20 else G1 X-0.5 U-0.5 A-0.5 Y0.5 V0.5 B0.5 else ; joystick left only M400 echo "Left" if sensors.gpIn[4].value=0 ; check for long move button press G1 X-20 U-20 A-20 else G1 X-0.5 U-0.5 A0.5 elif sensors.gpIn[6].value=0; joystick right if sensors.gpIn[7].value=0 ; joystick right and forwards M400 echo "Right and forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y-20 V-20 B-20 else G1 X0.5 U0.5 A0.5 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0; joystick right and backward M400 echo "Right and backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 Y20 V20 B20 else G1 X0.5 U0.5 A0.5 Y0.5 V0.5 B0.5 else ; joystick right only M400 echo "Right" if sensors.gpIn[4].value=0 ; check for long move button press G1 X20 U20 A20 else G1 X0.5 U0.5 A0.5 elif sensors.gpIn[7].value=0 ; joystick forwards only M400 echo "Forward" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y-20 V-20 B-20 else G1 Y-0.5 V-0.5 B-0.5 elif sensors.gpIn[8].value=0 ; joystick backward only M400 echo "Backwards" if sensors.gpIn[4].value=0 ; check for long move button press G1 Y20 V20 B20 else G1 Y0.5 V0.5 B0.5 else break else break
