Supporting multiple configurations on a single Duet
-
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.
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
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?
-
@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:
- 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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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.
