Supporting multiple configurations on a single Duet

thwe

@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

dc42

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.

wcj97

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

ChrisP

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

zapta

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.

A Former User

@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)

zapta

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).

A Former User

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.)

dc42

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

sebkritikel

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

zapta

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

A Former User

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

dc42

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