How to upgrade from 2.05.1 to 3.1.1?



  • I have a functioning Duet2 corexy printer which I want to upgrade from RRF 2.05.1 to 3.1.1 but am not sure how to start. My understanding is that I need to #1) upgrade the firmwares, binaries, etc and #2) upgrade my config files and macros.

    How do I do #1? I found these links https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview , https://github.com/Duet3D/RepRapFirmware/releases/tag/3.1.1 but couldn't find detailed instructions.

    This is my current configuration (and my SD card is already backed up):

    Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
    Firmware Electronics:	Duet WiFi 1.02 or later
    Firmware Version:	2.05.1 (2020-02-09b1)
    WiFi Server Version:	1.23
    Web Interface Version:	1.22.6
    

    Thanks.
    Z.

    Edit: I don't mind using Bossa if it simplifies the upgrade process.



  • Hi,

    You can go from 2.05.1 to 3.0.0 directly.

    Download Duet2and3Firmware-3.0.zip.

    Upload it to your Duet via the Duet Web Interface.

    Answer yes when it asks if you want into install the updates.

    If all goes well it will finish and reboot and you will be running 3.0.0

    Download Duet2and3Firmware-3.1.1.zip

    Upload it to your Duet via the Duet Web Interface.

    Answer yes when it asks if you want into install the updates.

    If all goes well it will finish and reboot and you will be running 3.1.1

    Now you can edit your configuration files and make the needed changes.

    I just did it for my three Duet boards and it was easier than I thought. I created a basic configuration using the online configuration tool. I downloaded the files and examined them with a text editor. It was fairly easy to spot the changes that I would need to make.

    I missed a few things at first, like a change to M106, but it didn't take long to sort things out.

    I'm very happy I took the time to upgrade to 3.1.1

    Frederick


  • Moderator

    The easiest way is to upload the entire zip archive for the 3.0 release and then for the 3.1.1 release. The 3.0 release is required as an intermediary step to update the programming files for the larger RRF3 binaries.

    https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip

    https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/Duet2and3Firmware-3.1.1.zip

    And of course you'll need a config file compatible with RRF3.

    https://configtool.reprapfirmware.org/Start



  • upload the 3.0 release zip, then the 3.1.1 zip as pr https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Upgrading_a_Duet_WiFi_Ethernet_Maestro_from_firmware_2_x_to_3_01_or_later

    you could skip the 3.0 step if you used bossa to load RRF 3.1.1, but would have to put the updated Duet2CombinedIAP.bin and DWC 3.1.1 on the SD card so i don't think either option is particularly faster, but not using bossa saves physical access to usb port/sd card*

    *) you could in theory upload IAP and DWC before running bossa to avoid needing to remove the SD card, but little room for errors in that procedure.

    edit: that took too long to type...



  • Thank you everybody for the response. I uploaded and applied the two zip files and now I think I am at 3.1.1 (still need to update config files)

    Board: Duet 2 WiFi (2WiFi)
    Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
    Duet WiFi Server Version: 1.23

    I wonder about the files in the sys and www directories (list below), do I have a lot of leftover from previous versions or is it more or less what I should have? Can I delete anything?

    Alternatively, is there a way to install RRF3 from scratch? This upgrade requires a lot of manual work anyway so I don't mind a little bit more.

    www and sys content

    $ find www sys
    www
    www/css
    www/css/Lumen.theme.css.gz
    www/css/._Lumen.theme.css.gz
    www/css/Superhero.theme.css.gz
    www/css/._Superhero.theme.css.gz
    www/css/United.theme.css.gz
    www/css/._United.theme.css.gz
    www/css/Slate.theme.css.gz
    www/css/._Slate.theme.css.gz
    www/css/dwc.css.gz
    www/css/._dwc.css.gz
    www/css/bootstrap.theme.css.gz
    www/css/._bootstrap.theme.css.gz
    www/css/Sandstone.theme.css.gz
    www/css/._Sandstone.theme.css.gz
    www/css/app.ab1d3899.js.map.gz
    www/css/app.db918b7e.css.gz
    www/css/app.c3eac487.css.gz
    www/._css
    www/js
    www/js/dwc.js.gz
    www/js/._dwc.js.gz
    www/js/app.ab1d3899.js.map.gz
    www/js/app.ab1d3899.js.gz
    www/js/app.289e2336.js.map.gz
    www/js/app.289e2336.js.gz
    www/._js
    www/favicon.ico.gz
    www/._favicon.ico.gz
    www/reprap.htm.gz
    www/._reprap.htm.gz
    www/language.xml.gz
    www/._language.xml.gz
    www/fonts
    www/fonts/glyphicons.ttf.gz
    www/fonts/._glyphicons.ttf.gz
    www/fonts/glyphicons.woff2.gz
    www/fonts/._glyphicons.woff2.gz
    www/fonts/glyphicons.eot.gz
    www/fonts/._glyphicons.eot.gz
    www/fonts/glyphicons.svg.gz
    www/fonts/._glyphicons.svg.gz
    www/fonts/glyphicons.woff.gz
    www/fonts/._glyphicons.woff.gz
    www/fonts/materialdesignicons-webfont.27cb2cf1.woff2
    www/fonts/materialdesignicons-webfont.043774d1.woff
    www/fonts/materialdesignicons-webfont.9bfeb985.ttf.gz
    www/fonts/materialdesignicons-webfont.e971abae.eot.gz
    www/fonts/materialdesignicons-webfont.2dcce271.woff
    www/fonts/materialdesignicons-webfont.3e2c1c79.eot.gz
    www/fonts/materialdesignicons-webfont.a323c28e.woff2
    www/fonts/materialdesignicons-webfont.e7dec9c5.ttf.gz
    www/._fonts
    www/html404.htm
    www/._html404.htm
    www/dwc.json
    www/index.html.gz
    sys
    sys/stop.g
    sys/._stop.g
    sys/sleep.g
    sys/._sleep.g
    sys/DuetMaestroFirmware.bin
    sys/Duet2CombinedFirmware.bin
    sys/._Duet2CombinedFirmware.bin
    sys/resume.g
    sys/._resume.g
    sys/config.g
    sys/._config.g
    sys/retractprobe.g
    sys/._retractprobe.g
    sys/DuetWiFiServer.bin
    sys/._DuetWiFiServer.bin
    sys/homez.g
    sys/._homez.g
    sys/RepRapFirmware.bin
    sys/mode_normal.g
    sys/tpre0.g
    sys/._tpre0.g
    sys/tfree0.g
    sys/._tfree0.g
    sys/pause.g
    sys/._pause.g
    sys/bed.g
    sys/._bed.g
    sys/heightmap.csv
    sys/homey.g
    sys/._homey.g
    sys/homeall.g
    sys/._homeall.g
    sys/config_g.swp
    sys/homex.g
    sys/._homex.g
    sys/dwc2settings.json
    sys/tpost0.g
    sys/._tpost0.g
    sys/iap4s.bin
    sys/mode_stall.g
    sys/deployprobe.g
    sys/._deployprobe.g
    sys/iap4e.bin
    sys/filaments.csv
    sys/Duet3Firmware_EXP3HC.bin
    sys/Duet2CombinedIAP.bin
    sys/Duet3_SDiap_MB6HC.bin
    sys/DuetMaestroIAP.bin
    sys/Duet3Firmware_MB6HC.bin
    sys/Duet3Firmware_TOOL1LC.bin
    


  • @zapta said in How to upgrade from 2.05.1 to 3.1.1?:

    Can I delete anything?

    you have at least 3 different versions of DWC, and a selection of binaries from old versions and different boards.

    simplest way to clean up DWC is to enable ftp or pull the SD card delete /www and replace with a freshly extracted DWC 3.1.1 (you may want to keep dwc.json as I believe some DWC settings are stored here)

    The only binaries you need are Duet2CombinedIAP.bin, Duet2CombinedFirmware.bin and DuetWiFiServer.bin

    the files that start with ._ seems redundant as well

    Alternatively, is there a way to install RRF3 from scratch?

    optionally clear out the SD card, get new config, RRF release and DWC from the config tool by selecting
    Get the latest stable Duet Web Control version and
    Get the latest stable RepRapFirmware version in the last step. you already have the firmware loaded in flash, so all that remains is the SD card that can be reconstructed from the files from the config tool.



  • @bearer said in How to upgrade from 2.05.1 to 3.1.1?:

    optionally clear out the SD card...

    I cleared the SD card and repopulated. Does this file structure look right?

    $ find www sys
    www
    www/css
    www/css/app.c3eac487.css.gz
    www/css/._app.c3eac487.css.gz
    www/favicon.ico.gz
    www/fonts
    www/fonts/materialdesignicons-webfont.a323c28e.woff2
    www/fonts/materialdesignicons-webfont.2dcce271.woff
    www/fonts/materialdesignicons-webfont.e7dec9c5.ttf.gz
    www/fonts/materialdesignicons-webfont.3e2c1c79.eot.gz
    www/index.html.gz
    www/js
    www/js/app.289e2336.js.gz
    www/js/app.289e2336.js.map.gz
    sys
    sys/bed.g
    sys/config.g
    sys/config.json
    sys/deployprobe.g
    sys/homeall.g
    sys/homex.g
    sys/homey.g
    sys/homez.g
    sys/pause.g
    sys/resume.g
    sys/retractprobe.g
    sys/sleep.g
    sys/stop.g
    sys/tfree0.g
    sys/tpost0.g
    sys/tpre0.g
    sys/Duet2CombinedFirmware.bin
    sys/Duet2CombinedIAP.bin
    sys/DuetWiFiServer.bin


  • Moderator

    @bearer said in How to upgrade from 2.05.1 to 3.1.1?:

    the files that start with ._ seems redundant as well

    Lemme guess, opened the SD card on a Mac?



  • @zapta said in How to upgrade from 2.05.1 to 3.1.1?:

    I cleared the SD card and repopulated. Does this file structure look right?

    looks good to me (https://duet3d.dozuki.com/Wiki/SD_Card is a little outdated with respect to RRF3.1.1)



  • Thanks @bearer.

    I am now in the process of commissioning the various functionalities, one at a time. This will take some time.

    One problem I noticed is that when issue emergency stop from the PanelDue I get an error message like the one below (with a few other numbers, not just 255). The emergency stop work well otherwise, and when I issue it from DWC I don't see this message on the PanelDue.

    Any idea what it is? Never encounter it before with the older RRF. Upgrading PanelDue from 1.23.2 to 1.24 didn't help.

    Edit: my config files are here https://github.com/zapta/misc/tree/master/hevo/duet3 (still a work in progress)

    77d75f1e-a951-45cd-a2a2-e834a2b6fff5-image.png



  • @zapta said in How to upgrade from 2.05.1 to 3.1.1?:

    Error: Bad command: 205

    From the looks of it RRF thinks it receives a command 205 which isn't valid g-code.

    I'd look over configs and triggers for syntax errors or linebreaks on the loose.

    (just to verify, you're getting the same message on USB/WEB right?)

    edit: cloned git and no results when grepping for 205 so thats odd. could you have gotten a bonus config-override.g that is misformatted? would be interesting to know if it comes before or after the e-stop (i.e. in config.g or not). I'd add some echo to the top and bottom of config.g and look at the USB console.



  • @bearer said in How to upgrade from 2.05.1 to 3.1.1?:

    (just to verify, you're getting the same message on USB/WEB right?)

    Not getting it on the WEB, just on PanelDue when issuing the command from PanelDue. Didn't try the USB connection, will give it a try, including with planted messages.

    BTW, I got also other codes, not just 255. E.g. 204, 44, 247 so I think it's at lower level than just bad gcode in a file.


  • Moderator

    Can you send M98 P"config.g" in the console and report any errors? I'm guessing that's where the bad command is coming from. It's showing up on the paneldue after an emergency stop because the board is up and running when you issue it and the paneldue is able to catch the error which otherwise might get missed on a cold boot.



  • @Phaedrux said in How to upgrade from 2.05.1 to 3.1.1?:

    M98 P"config.g"

    When I issue this command from the DWC I don't see the error message, just this which looks normal:

    7/28/2020, 4:38:43 PM M98 P"config.g"
    HTTP is enabled on port 80
    FTP is enabled on port 21
    TELNET is disabled
    Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 262C
    Warning: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 528C

    I also hooked a logic analyze to the duet's tx/rx lines to the paneldue and it seems that it's the paneldue sends the bad command which results in the error message. Will try to describe it here, hopefully it's clear.

    This is the dump from the logic analyzer. TX=duet->paneldue, RX=paneldue->duet.
    capture.csv

    At one point, after issuing the restart, the paneldue sends this and gets back the error 198 message. The actual number changes, not always 198.

    Any idea what the problem is? Am I the only one that experience it?

    1.179844000000000,RX,N (0x4E)
    1.180016000000000,RX,1 (0x31)
    1.180189000000000,RX,2 (0x32)
    1.180361000000000,RX,0 (0x30)
    1.180534000000000,RX,' ' (0x20)
    1.180706000000000,RX,M (0x4D)
    1.180879000000000,RX,1 (0x31)
    1.181051000000000,RX,1 (0x31)
    1.181224000000000,RX,2 (0x32)
    1.181396000000000,RX,' ' (0x20)
    1.181569000000000,RX,; (0x3B)
    1.181741000000000,RX,'240' (0xF0)
    1.181914000000000,RX,'15' (0x0F)
    1.182086000000000,RX,* (0x2A)
    1.182259000000000,RX,1 (0x31)     <---
    1.182431000000000,RX,9 (0x39)     <---
    1.182482000000000,TX,{
    1.182604000000000,RX,8 (0x38)     <---
    1.182656000000000,TX,"
    1.182776000000000,RX,\n (0x0A)
    


  • @zapta said in How to upgrade from 2.05.1 to 3.1.1?:

    I also hooked a logic analyze to the duet's tx/rx lines to the paneldue and it seems that it's the paneldue sends the bad command which results in the error message. Will try to describe it here, hopefully it's clear.

    was worried about when the bad commands varied and wasn't present in any file. does it do the same if you only connect power and no rx/tx to the paneldue?



  • @bearer said in How to upgrade from 2.05.1 to 3.1.1?:

    does it do the same if you only connect power and no rx/tx to the paneldue?

    I will give it a try, assuming it will let me issue a Stop without being able to connect to the duet.

    I think this is the relevant code, and it seems that the data the paneldue sends after the 0xf0 0x0f is corrupted.

    https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UserInterface.cpp#L1671



  • Just don't see how updating RRF would affect the PanelDue firmware; interesting issue if nothing else:/



  • @bearer said in How to upgrade from 2.05.1 to 3.1.1?:

    Just don't see how updating RRF would affect the PanelDue firmware; interesting issue if nothing else:/

    One explanation is that the PanelDue behaved the same but RRF2 didn't detect and response to the bad command, for example if it took longer time to reboot. (this is a speculation). I may try to restore RRF2 and look again with the logic analyzer.


  • Moderator

    4 wire or ribbon cable for the Panel?



  • @Phaedrux , 4 wires.


  • Moderator

    I might try a different 4 wire cable. I had some bad command and the panel being stuck on "connecting" occasionally and it turned out to be a bad 4 wire cable. I also braided the replacement since it runs along with some stepper wires. Haven't had an issue since.



  • @Phaedrux said in How to upgrade from 2.05.1 to 3.1.1?:

    I might try a different 4 wire cable.

    The problem was very consistent. I just reverted my printer to RRF 2 and the problem disappeared. I will check tomorrow with logic analyzer if the transmission from the PanelDue is corrupted the same and possibly RRF2 is just more tolerant somehow.



  • @Phaedrux, I use a logic analyzer to capture the duet/paneldue serial traffic under RRF2 and RRF3. In both cases the results are very consistent, with same hardware, same cables, etc, always works cleanly with RRF2 and always giving an error message with RRF3.]

    Looking at the capture signal, RRF3 behaves differently from RRF2. With RRF2, the duet lets the paneldue sending the entire M112 message with no response, with RRF3, the duet response immediately with an error message.

    https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UserInterface.cpp#L1674

    This is how it looks under RRF2:
    e5f57cbd-f414-4c76-a71a-029cb2bb22b9-image.png

    And this is under RRF3
    955d379e-5b0b-4ffd-ab06-b1e980adb70c-image.png

    This is from the rrf3.csv, it shows how the the duet response (TX) before the paneldue completes its transmision (RX):

    3.274821000000000,TX,1
    3.274994000000000,TX,}
    3.275168000000000,TX,\n
    3.476848000000000,RX,N (0x4E)
    3.477020000000000,RX,4 (0x34)
    3.477193000000000,RX,9 (0x39)
    3.477365000000000,RX,3 (0x33)
    3.477538000000000,RX,4 (0x34)
    3.477710000000000,RX,' ' (0x20)
    3.477883000000000,RX,M (0x4D)
    3.478055000000000,RX,1 (0x31)
    3.478228000000000,RX,1 (0x31)
    3.478400000000000,RX,2 (0x32)
    3.478573000000000,RX,' ' (0x20)
    3.478745000000000,RX,; (0x3B)
    3.478918000000000,RX,'240' (0xF0)
    3.479090000000000,RX,'15' (0x0F)
    3.479263000000000,RX,* (0x2A)
    3.479435000000000,RX,2 (0x32)
    3.479608000000000,RX,5 (0x35)
    3.479685000000000,TX,{   <<-- RRF3 doesn't like the M112 message
    3.479780000000000,RX,5 (0x35)
    3.479858000000000,TX,"
    3.479953000000000,RX,\n (0x0A)
    3.480032000000000,TX,s
    3.480205000000000,TX,e
    3.480378000000000,TX,q
    

    This is the corresponding section from RRF2:

    4.297585000000000,TX,1
    4.297759000000000,TX,}
    4.297932000000000,TX,\n
    5.048296000000000,RX,N (0x4E)
    5.048468000000000,RX,1 (0x31)
    5.048641000000000,RX,8 (0x38)
    5.048813000000000,RX,8 (0x38)
    5.048986000000000,RX,' ' (0x20)
    5.049158000000000,RX,M (0x4D)
    5.049331000000000,RX,1 (0x31)
    5.049503000000000,RX,1 (0x31)
    5.049676000000000,RX,2 (0x32)
    5.049848000000000,RX,' ' (0x20)
    5.050021000000000,RX,; (0x3B)
    5.050194000000000,RX,'240' (0xF0)
    5.050366000000000,RX,'15' (0x0F)
    5.050539000000000,RX,* (0x2A)
    5.050711000000000,RX,1 (0x31)
    5.050884000000000,RX,9 (0x39)
    5.051056000000000,RX,6 (0x36)
    5.051229000000000,RX,\n (0x0A)
    // 1 sec later, per the 1000ms in the source code
    6.050462000000000,RX,N (0x4E) 
    6.050635000000000,RX,1 (0x31)
    6.050807000000000,RX,8 (0x38)
    6.050980000000000,RX,9 (0x39)
    6.051152000000000,RX,' ' (0x20)
    6.051325000000000,RX,M (0x4D)
    6.051497000000000,RX,9 (0x39)
    6.051670000000000,RX,9 (0x39)
    6.051842000000000,RX,9 (0x39)
    6.052015000000000,RX,* (0x2A)
    6.052187000000000,RX,4 (0x34)
    6.052360000000000,RX,2 (0x32)
    

    Any idea why the RRF3 doesn't like the M112 message and responds immediately instead of waiting for the M999 ?

    rrf2_capture.csv

    rrf3_capture.csv



  • @zapta said in How to upgrade from 2.05.1 to 3.1.1?:

    Any idea why the RRF3 doesn't like the M112 message and responds immediately instead of waiting for the M999 ?

    i think the 0xf0 0x0f is a special case to reset immediately without getting stuck in the queue; so the difference must be in how RRF3 reacts to this? time to put up the bat dc42 signal?


  • Moderator

    @dc42 is away on vacation until next week, but I'm sure he'll find this interesting.


Log in to reply