Supporting multiple configurations on a single Duet
-
Like @deckingman and others here, I would use it when swapping hot-ends (and sometimes their associated extruder steppers) on the same machine. Currently managing multiple config.g files by renaming them gets awkward.
I believe @FunBogMan is referring to adding features in DWC. I would also second this, but in conjunction would like to see:
- Clearly obvious indication of which configuration was currently in use
- Requiring at least 2 clicks/taps to change configuration (i.e. initial choice, then confirmation)
- Provide the option to change the color scheme uniquely to each configuration, helping to provide the information for #1.
Overall, this is a very handy potential improvement.
-
@plasticmetal Ooooh, I like all those ideas.
-
As we seem to be in brainstorming mode, what would work well for me would be the ability to by-pass the SD card altogether and access files or folders directly from my NAS. I do this with just about everything else - all my media (pictures, music, videos, TV shows etc) and most of my data so that I can access anything from any device, and from any location. I already manage all my printer related files (configs, gcodes, stl files, cad files etc) the same way so everything exists in a central reasonably secure location which is also backed up. So, if I could just point the Duet to a network path instead of the SD card, it would save me having to keep uploading the files I need. I wouldn't propose doing away with the SD because I can see cases where I might want to use the printer away from my home environment, and the ability to be able to use the printer in local mode will always be useful. Just a thought.........
-
I love this idea. I'm currently troubleshooting and am using Compare mode in Notepad++ to be sure I've got the differences fixed, and am labeling the config and homing files to keep track.
The printer is on the other end of the house from my PC so I'm doing a sneaker-net running back and forth with an SD card so I, too, would love to store on my NAS.
I can see some real advantages to having multiple files available.
@PlasticMetal and @deckingman make some compelling points, I agree it must be a multiple click change and color theme change is a great idea too.
-
I've implemented this and will test it later today. Hofstadter's law struck again - it turned out to be a much longer job than I expected, because of the possibility that one task could be building the name of a system file while the folder is being changed. Unlikely, but it could have resulted in a crash. This wasn't a risk if as I expect the new M505 command was used only in config.g, but experience tells me that some users will find other ways of using it.
I've done it so that firmware files and the IAP file must always be in /sys, but everything else is fetched from the folder set by M505.
DWC will need to be changed separately by chrishamm.
-
I am looking at building another machine, with a "quick-swap" tool mount and harness. One is a small spindle, one is an extruder, and I want to add a laser engraver at some point, so this would be good.
-
@dc42 said in Supporting multiple configurations on a single Duet:
To switch configurations, I would edit the first line in System Editor of DWC and allow it to restart.
Would anyone else find this useful? Does anyone have a better suggestion?
i would also very much welcome such a possibility
the idea with the subfolders is very practicable and creates organization
-
This is now implemented. I've put an internal build for the Duet WiFi/Ethernet and Maestro at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0.
-
@dc42 was looking at this thread and was curious if this feature got carried into the newest versions of RRF, most notably version 3.0 and on. I'm testing out the possibility of wiring 2 printers to a single board (mostly for testing purposes), and I've found that it was easy to just create a macro to change certain portions of the config while the secondary printer is being run, but things like homing files and the like aren't so easy. The separate directory as you've stated would make this much easier to implement.
-
-
This new config switch does not allow to switch between versions, right? E.g. 2.05.1 to the latest 3.
An easy way to switch version would be very useful. Even if it requires swapping SDs. For example, my printer currently uses 2.05.1 and I want to experiment with the latest version 3, but still be able to easily use 2.05.1 until I complete the transition.
-
@zapta said in Supporting multiple configurations on a single Duet:
This new config switch does not allow to switch between versions, right?
correct; i was going to suggest conditional g-code + M997 S0 but that would only work between different RRF3 if possible at all.
the "simplest" way
wouldmight be to use ftp support to change the SD card contents and bossa to do the flashing back and forth. maybe this bash script (temporary link as its work in progress) can give you some inspiration to the bossa part. (In testing from a Pi its 99%+ reliable so far, even with multiple boards) -
Thanks @bearer. I wish that the duet board would that all that work. Currently the configuration is way too complex IMO, with a bunch of binary files that need to go into different places and/or be flashed manually. Not to mention the PanelDue firmware that is released independently.
Ideally the entire release will be a single file that we place on the SD and upon boot, the Duet board will update whatever need updated such that the only authoritive state on the board and the paneldue are the wifi passwords.
(I recently cloned a printer and had to manually clone the board state, it was not smooth).
-
Its only too complex if skipping past major releases afaik, doing incremental updates through the major releases and the minor release at the end should work.; I also think I've read somewhere the PanelDue will be updateable from the Duet in the future (although if the SBC revolution and limited development for the PanelDue has an effect on that idk).
As far as I can tell the cloning could have been smooth if
-connect usb cable, send m587 with wifi key and ftp enable, get new_ip
-http to old_ip and enable ftp
-download all files from old_ip
-make changes to hostname and ip if needed. (in downloaded files)
-upload all files to new_ip
-run bossac with downloaded reprap binary
-send m997 s1, over usb, to update wifi
-send m587, over usb, with the wifi key again just in case this update was incompatible with the old internal structure.bossac solves the problem of skipping past major releases where file names may have changed. update from SD would break similarly as the current system if the file names (or content) changed, as they have.
(forgot to add: but, yes an ideal world would be nice. i'll settle for cobbling together a script or two for rare use cases and try to have the main functions of the firmware as ideal as possible until the developers are replicated in abundance.)
-
@zapta said in Supporting multiple configurations on a single Duet:
This new config switch does not allow to switch between versions, right? E.g. 2.05.1 to the latest 3.
An easy way to switch version would be very useful. Even if it requires swapping SDs. For example, my printer currently uses 2.05.1 and I want to experiment with the latest version 3, but still be able to easily use 2.05.1 until I complete the transition.
That's exactly the sort of thing that M505 is useful for.
-
@zapta said in Supporting multiple configurations on a single Duet:
This new config switch does not allow to switch between versions, right? E.g. 2.05.1 to the latest 3.
An easy way to switch version would be very useful. Even if it requires swapping SDs. For example, my printer currently uses 2.05.1 and I want to experiment with the latest version 3, but still be able to easily use 2.05.1 until I complete the transition.
I sorta started this process this morning. A preface - I have not tried reverting from the latest RRF3 back to 2.05.1
- I created a "2" and a "3" folder under /sys/
- I moved all relevant 2.05.1 files under the "2" folder (tpost, tpre, heightmaps, etc)
- I copied all 2.05.1 files I may want to use in RRF3 to the "3" folder
- I made a new config.g for RRF3 offline, and then uploaded it to the "3" folder
- I created/modified the original config.g under /sys/ to include the M505 command
- I upgraded to RRF 3.01-RC11 following the proper procedure
- Once upgraded, I changed the M505 in /sys/config.g to be "M505 P"3"" pointing to the new RRF3 config.g, while the original 2.05.1 is in the /sys/2 folder
- Tested the new config (obviously found some issues with the new config I wrote up
At this point, to revert to 2.05.1 and the old config.g, I should just be able to upload the 2.05.1 firmware, and change the M505 command to "M505 P"2"". Might not be the most convenient, but I think it should only take a few minutes and is straightforward enough.
-
@dc42 said in Supporting multiple configurations on a single Duet:
That's exactly the sort of thing that M505 is useful for.
Yes, M505 is nice but is still manual and still require collecting a bunch of matching release files and unzipping the www directory (?).
I think it feasible to have a seamless upgrade/board-replacement/printer-cloning. E.g. by releasing a single file, having M505 does the work conditionally (boot time and Flash wear concerns), and prompting the user for SSID and Password if not already on the Wifi module.
It will be a win for the users, a win for printers manufacturers, and a win for Duet support.
My 2c
Edited: 'seep' -> 'boot time'.
-
@zapta said in Supporting multiple configurations on a single Duet:
by releasing a single file
would only be fool proof if used with usb and bossa unfortunately. (i.e if something changes with the currently running firmware and in application programming code then it won't understand how to update); and then you're back to what I listed wrapped in a script with a bow.
-
@zapta said in Supporting multiple configurations on a single Duet:
I think it feasible to have a seamless upgrade/board-replacement/printer-cloning. E.g. by releasing a single file, having M505 does the work conditionally (seep and Flash wear concerns)
You can probably have RRF choose the correct sys folder already by putting this in config.g (caution: not tested):
M505 P"/sys/RRF3" ; select RRF3 folder if false M505 P"/sys/RRF2" ; select the RRF2 folder M98 P"config.g" M552 S1
RRF2 should ignore the "if false" and execute the second M505 command.