Supporting multiple configurations on a single Duet


  • administrators

    I've been thinking about how to make it easier for me to investigate possible firmware issues on the forum. Each time I need to set up an SD card with the new config and homing files on it; or overwrite the existing ones on my bench system, but then I lose the old ones unless I back them up separately. So I've worked out a scheme to support multiple configurations more easily, and I wonder whether there are other Duet users who might find this useful.

    What I have in mind is that each configuration would be stored in a subdirectory of /sys on the SD card. There would be a new M-code to change the system directory from /sys to a specified subdirectory of /sys. After that, all system macro files would be fetched from that folder instead of /sys. Likewise any files in M98 commands that don't provide a full path.

    My master config.g file in /sys would then just contain two lines:

    Mnnn "/sys/xxxx" ; where xxxx is the subfolder I want to use
    M98 P"config.g"
    

    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?



  • This seems like a really great idea, especially for people who are tweaking settings a lot to fine tune behavior. I do this manually by saving entire config files with names like "config_original.g" or copying lines of text to track what settings I was using. It can be a pain, and certainly confusing.

    Would each file be called "config.g" still? I'm wondering if config.g could be the master config, but config1.g or config2.g could be in the same directory and hold the different settings that you could swap to with M98.



  • I also like this idea. I have not really a use-case right now but as @john already mentioned it could be handy when tuning and testing a lot. 👍



  • @dc42 Oh yes indeed!

    I currently do exactly what you have to do. That is to say, I have different configuration files for the 3 hot ends that I swap between - 3 colour 0.5mm nozzle, 3 colour 0.9 mm nozzle and 5 colour 0.5mm nozzle. And I've recently added another configuration which is 3 colour with an extra load balancing gantry. These are all backed up separately on a PC and NAS and I upload whichever I want to use to the SD card, but often forget to change the homing files as well as the config.g. So what you propose would be a great help in my usage case (but I'd still maintain and back up the files on my PC).

    Edit. @john's idea of naming config files as config1.g config2.g seems OK but it wouldn't address the issue of also loading homing files (unless these were also named using the same convention) so I'd prefer the same file name/separate folder approach.



  • I like this.

    My use case is being able to run simulations on an idle machine while another of different type is printing.

    What would really sign off this feature would be if one machine could collect the setup files from another on the same network. Guess that could help people building machines.



  • Potential gotcha for me would be making sure I edited the network config so I didn't run two machines on the same network name and mac.



  • Like that idea alot. At the moment I use a set of different SD cards with different configurations on, eg. 1) Small table- Bowden. 2) Large table-Bowden and 3) Small table-Direct. The trick is to remember what changes you make. Often use a text editor where file comparisons can be highlighted. It works with care but have still made ommissions due to last minute changes. By the way the printer is home made and is constantly being modified.

    Just an idea but how about a programmable set of buttons on a bootup menu to select which config to use?


  • administrators

    @doctrucker said in Supporting multiple configurations on a single Duet:

    Potential gotcha for me would be making sure I edited the network config so I didn't run two machines on the same network name and mac.

    You could set the network name (and MAC if you are running a legacy Duet) in the root config.g after the M98 command to call the other config.g.



  • 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:

    1. Clearly obvious indication of which configuration was currently in use
    2. Requiring at least 2 clicks/taps to change configuration (i.e. initial choice, then confirmation)
    3. 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.


  • administrators

    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


  • administrators

    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.



  • @wcj97
    M505 is listed as a valid code in the wiki, so I'm guessing the answer is yes.



  • 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 would might 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.)


  • administrators

    @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'.


Log in to reply