It's out! RepRapFirmware 2.0 and 1.21.1 released

[SputnikOC3d]

OK so now a new wrinkle in the Acronym soup ... Sam3 / Sam4 ????

I really dont understand many of the notes put on these github docs and find them to be a bit challenging to follow.

Id like to use FW ver 2.0 here ... for my Duet Wifi [ Duet 2 ver Board ???? ]

My DWC Page tells me - I have this stuff:

=====================
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later [ so is that a Duet 2 or a Duet 1.02 ? ]
Firmware Version: 1.21 (2018-03-21)
WiFi Server Version: 1.21
Web Interface Version: 1.21

So am I needing files for a Duet 2 Board even though the DWC interface indicates a cryptic indicator of my Electronics version of 1.02 or later vs. Duet 2 ???

Apparently i need Duet2Combined [ why its combined and with what who knows ] yes / no ?

What wifi server version files do I need to upgrade to ? [ if any ]

Do I also need a New browser interface update aka DWC / a.k.a. Web Interface Version / a.k.a. DuetWebControl.1.???

Also if any of those other files in any combination are needed - how does one know ? As well if so, what order should they be installed.

[Phaedrux]

I agree it is fairly obtuse and complicated. An automated update system would be a boon.

You'll want the combined firmware, but if it won't take it might need to be renamed to match what you have installed already. ( I know... Complicated) this is due to the recent change which merged the duet ethernet and wifi firmwares. Hence combined.

You'll also want to grab the DWC file and the webserver file and the IAP files just in case.

Hope that helps. And hopefully the pain points of updates can be improved in the future.

[SnowCrash]

@phaedrux said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

I agree it is fairly obtuse and complicated. An automated update system would be a boon...
Hope that helps. And hopefully the pain points of updates can be improved in the future.

Well said, @Phaedrux, couldn't agree more.

In my view, the firmware update structure/mechanism of the Duet and its peripherals (DWC, PanelDue, etc) is way behind the product itself.

Especially given all the firmware updates that frequently come up (great job, @dc42!), I think significantly upgrading and consolidating this aspect ought to move way up high in the priority list (if that's not the case already).

[SputnikOC3d]

Thanks guys ... yeah I just punted and dl'd 3 main files [ as I dont use PanelDue ] and - installed ...

Guessed on the order... just did the main baords fw 1st then, wifiserver then DWC file.

[Phaedrux]

They can go all at once usually. Sometimes the main firmware takes a couple attempts.

Glad it worked out

[daprigoo]

I'm upgrading a Fisher delta with a 0.6 Duet from 1.09k to 1.21.1 and have a problem with the web interface. On the G-Code Files listing the green, blue and red icons are not being displayed next to the files, I only get a simple selection box.

This is the same on Firefox and Chrome browsers

I have used the DuetWebControl-1.21.1.zip from https://github.com/dc42/RepRapFirmware/releases/tag/2.0

[dc42]

Click the filename to print it, or right-click on the filename to get the other options. You can also select a number of files using the check boxes and then right-click on one of the filenames.

[daprigoo]

@dc42 thanks, I discovered this after going through the web interface and it's GIT site when the changeover seems to have been made in v1.17 - is this the standard interface now and the documentation is a bit out of sync?

[dc42]

Yes, the manual is a bit out of date - I'll try to get it updated.

[stevenrsearles]

So I'm about to try to update firmware from 1.18 to 1.21 which i believe to be the most up to date. As i completely messed up the last update and had to do it the hard way I decided to just ask the questions on how to do it rather than just end up asking how to fix it. I read on wiki that to update all files you have to do them in this order: DuetWiFiFirmware, DuetWiFiServer, DuetWebControl. which makes sense as thats what I botched up before, but reading on it said Sometimes we may do synchronised releases of firmware, where more than one firmware component needs to be updated at the same time to maintain compatibility. So would have to use this option or what would be the best way to make this leap. I'm assuming I don't have to do every upgrade I have missed and can just jump to the 1.21.

[Phaedrux]

@stevenrsearles you'll want to follow these instructions since you're still on 1.18.

There is also no reason not to upgrade straight to the 2.0 releases and skip 1.21

https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_If_your_Duet_WiFi_is_running_firmware_1_18_or_earlier

[stevenrsearles]

But that’s for the web control which on the list is the last to be upgraded if updating all firmware.

[dc42]

@chrisp said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

@dc42

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

I have tried to reproduce this issue before several times, without success. But if you make your config.g file available, I'll try once again.

Thanks, that would be great!
Below are two config file from two very different printers one uses an 06 board, the other uses an 85 board - the problem on both boards is the same. With any FW later than 1.19, the ethernet connectivity is broke. If a static IP isn't specified then the board constantly boot loops. If a staic IP is defined, the boards will boot but I still can't access the web interface either by printer name or IP.

I tried both config.g files but I was unable to reproduce the problem with either of them. Perhaps the DHCP responses from your router are different from mine.

I looked into when the problem seems to have started occurring, and it seems that it may be connected with an upgrade to a later version (2017-q2-update) of gcc. As the problem could have been triggered by a bug in that new version, I have now upgraded to an even later version (2018-q2-update). This later version spotted a buffer overflow in the netbios protocol handler in lwip (the TCP/IP stack used by RRF). I have fixed that buffer overflow. There is a small chance that it was responsible for the problem.

So please try firmware 1.21.2beta2 when I release it, which I hope will be later today or tomorrow.

[ChrisP]

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

I tried both config.g files but I was unable to reproduce the problem with either of them. Perhaps the DHCP responses from your router are different from mine.

I looked into when the problem seems to have started occurring, and it seems that it may be connected with an upgrade to a later version (2017-q2-update) of gcc. As the problem could have been triggered by a bug in that new version, I have now upgraded to an even later version (2018-q2-update). This later version spotted a buffer overflow in the netbios protocol handler in lwip (the TCP/IP stack used by RRF). I have fixed that buffer overflow. There is a small chance that it was responsible for the problem.

So please try firmware 1.21.2beta2 when I release it, which I hope will be later today or tomorrow.

Thanks for continuing to look into this. I'm sure I enebaled reply notifications, but I did't get anything so I've only just stumbled across this again.

I've just flashed 1.22beta2 (only because it's the latest that there) and I can now connect to the board again without issue... so far So unless this is just a one-off time that it decides that it's going to work, I'd consider this problem solved now - thanks!

[dc42]

I'm glad to hear that it appears to be solved. Looks like it was either that buffer overflow bug or a bug in last year's GCC that was responsible.

[garyd9]

@dc42,
I have a .gcode file that seems to completely defeat 2.01's filament and layer time estimations. While printing, through the entire print, both estimates were stuck at "n/a." (The file-based estimation showed up.) It's created with S3D 4.0.0.

One aspect of the gcode that might be causing some issue (at least for the layer estimation) is that S3S is configured to "combine infill every 2 layers." I'm not sure why a filament based estimation wouldn't show up.

The file is shared on my google drive here: https://drive.google.com/open?id=1Wq_3JAKMRS9GRUJFkHIiF5ROnubqkUEt

In case you need my printer config to make any sense of this, it's here: https://drive.google.com/open?id=1v9pR4ZOSNdoJxDbj4_IW-H9HO2PL0_oR

Take care
Gary

[dc42]

Thanks, please leave those files available for a while, until I get a chance to try them.

[garyd9]

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

Thanks, please leave those files available for a while, until I get a chance to try them.

@dc42, here's another one. There's nothing fancy going on with the slicing in this one. It's a simple 0.1mm on all layers, all the same S3D process, etc. The printer config hasn't changed (and those links should still be valid.)

https://drive.google.com/open?id=1k5iV9TFxFvLtPfjYRNsFEFccoK43vVHq

The only thing I see in common with the previous example (other than the fact that firmware 2.0.1 isn't showing a filament or layer time estimate) is that both are large (>64MB) gcode files.

The previous example finished printing just fine. This one is still printing (3h, 42m into the print.)

Take care
Gary

[dc42]

Thanks. This is on my list to investigate, but right now I'm rather busy getting things ready for the TCT show.

In the GCode Files page, does DWC show an object height and/or the amount of filament required for printing those files?

[garyd9]

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

Thanks. This is on my list to investigate, but right now I'm rather busy getting things ready for the TCT show.

In the GCode Files page, does DWC show an object height and/or the amount of filament required for printing those files?

I completely understand being busy! The files will sit on my google drive until you've had a chance to do whatever you need.

To answer your question, the "object height" and "filament usage" columns on the "G-Code Files" page show "n/a" for these particular gcode files.

However, the gcode files do print successfully.