It's out! RepRapFirmware 2.0 and 1.21.1 released

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.

dc42

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

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.

OK, that explains why the estimates are missing. Now we need to determine why the firmware failed to retrieve the object height and filament usage. Please run M39 and check the SD card cluster size. If it's less than 32K, then using an SD card formatted with 64K clusters (if 8Gb or less) or 32k clusters (if larger than 8Gb) may fix it.

garyd9

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

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

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.

OK, that explains why the estimates are missing. Now we need to determine why the firmware failed to retrieve the object height and filament usage. Please run M39 and check the SD card cluster size. If it's less than 32K, then using an SD card formatted with 64K clusters (if 8Gb or less) or 32k clusters (if larger than 8Gb) may fix it.

M39 ->
SD card in slot 0: capacity 15.99Gb, free space 15.50Gb, speed 20.00MBytes/sec, cluster size 8kb

I won't be able to physically get to the machine until this evening (6 hours from now.) I'll open the machine, pull the sdcard and reformat it then. I'll post back the results.

Edit: I'm a bit confused. You stated to use a larger cluster size for a smaller device?

dc42

With 8Gb and smaller SD cards, you can format them using FAT16 format with 64kb clusters. With >8Gb you are forced to use FAT32, which allows 32kb maximum cluster size.

garyd9

Windows 10, 16GB microSD card, FAT32, allows 64KB clusters. I'm formatting it to 32KB just to have a "known good" situation, but wanted to point out the possibility in case you were unaware.

garyd9

After reformatting, copying everything back on the card, I have:

M39
SD card in slot 0: capacity 15.99Gb, free space 15.51Gb, speed 20.00MBytes/sec, cluster size 32kb

However, still no object height or filament usage in the gcode files page. That being said, I'm wondering if the problem is the duet firmware or S3D's export of the gcode file. The reason I'm saying that is because I took a look at the end of the exported gcode file and found the normal "build summary" followed by a newline and then ~26 million NUL characters. (At least I think it's nothing but \x0 characters. I know the first 100 or so are \x0, and the last 100 or so are \x0, and the last one is in column position 26,556,136.)

I'm not familiar with that part of RRF's code, but it seems reasonable that the stats come from seeking to the end of file and rolling back a bit to look for the build summary.... and it also seems reasonable that it wouldn't seek a negative 26 million from SEEK_END. (I'm actually laughing as I type this.)

I'd report this as a bug to S3D, but I found out very soon after I paid them that their technical support is... bad. If I reported this, they'd likely respond that I should use more skirt layers, or clean my nozzle, or something else completely irrelevant.

So, please forgive me for wasting your time, but you can add this to your list of possible causes for the particular problem.

EDIT: Confirmed that the duet shows the proper values after deleting 26 million null characters. I also found this thread on S3D's forum: https://forum.simplify3d.com/viewtopic.php?t=8459

Take care
Gary

dc42

I'm glad you solved it. RRF seeks up to around 150kb back from the end of the file to search for the object height and filament usage.