Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released

[Dougal1957]

@dadiy thats not the latest version of DWC

[DADIY]

@dougal1957 1.21.2-dc42 was the that was on the Github with the firmware and its newer than on https://github.com/chrishamm/DuetWebControl so perhaps a pointer to the newer version would be helpful.

[dc42]

Try https://github.com/chrishamm/DuetWebControl/tree/dev.

[Dougal1957]

@dadiy https://forum.duet3d.com/topic/5485/duet-web-control-wishlist-notes-and-priorities/63 in the DWC Section of the forum

[whosrdaddy]

Found a new problem, "object height" is no longer populated since the latest firmware/DWC.

Slicer is the same as can be seen from the pic.
The only thing I have changed is upgrading DWC and the firmware to the latest available versions:

Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later + DueX5
Firmware Version:	2.01(RTOS) (2018-07-26b2)
WiFi Server Version:	1.21
Web Interface Version:	1.22-b3

[wilriker]

@whosrdaddy I just checked on my machine with same versions and I cannot reproduce it neither for existing nor for just now newly uploaded Gcode files. Though, mine are all sliced with Cura.

[whosrdaddy]

Ok, I sliced a smaller file and now I can see the object height. I suppose the firmware does not attempt to read the height for larger files?

[wilriker]

@whosrdaddy I just uploaded the largest GCode file I could find on my hard drive (just a little under 11 MiB) and it got the height correctly from it. I also checked the file and it does not contain a comment with object height, so RRF must have scanned for the last rise in Z.

Don't get me wrong, I don't wanna say you don't have a problem, just that I cannot reproduce it.

Could you try to slice the same source file with another slicer?

[whosrdaddy]

Well did as requested and it seems it has nothing to do with the slicer, used exactly the same STL files:

[wilriker]

@whosrdaddy OK, your file is larger than mine, so maybe there is a lower limit to this issue.

[Dougal1957]

@whosrdaddy Can you post the stl for the 2 that fail so we can try it? I have several file much bigger than those that are correct

[whosrdaddy]

Sure, you can download it from here:
https://www.thingiverse.com/download:3377042

[wilriker]

@whosrdaddy With this file I can reproduce your issue:

[Dougal1957]

@whosrdaddy this is what I get for that file

It's not easy to read cos this forum is re-sizing the image but my file is 3 times the size of yours but gives 8.2mm hight and 39.xxx mtrs of filament. the diff may be the amount of infill mind

[whosrdaddy]

so we established there is an issue, it's not the file size because you have a 31MB file.
Lets wait & see what @dc42 thinks about this...

[Dougal1957]

I Too am on the latest FW and DWC

[dc42]

The firmware has has to seek backwards through the file from the end to find the last Z move. With large files this can get very slow because of the way the FAT file system works, especially if the SD card is formatted using a small cluster size. So to prevent DWC timing out, recent firmware versions apply a time limit to this operation.

To speed up access and minimise the chance of reaching the time limit, format the SD card using the largest cluster size you can, which is 64kb for 4Mb cards and smaller (FAT16 format), and 32kb for larger cards (FAT32 format). Send M39 to find the current cluster size.

[whosrdaddy]

Thanks David, I understand now. It's not a big issue anyway, since I am currently printing non stop, I will try your advice later

[Qdeathstar]

I consider this to be a bug:

Now that you can upload g-code while you print, if you upload a file with the same name as the file you are printing, the print will switch from the file you were printing to the new file.

[dc42]

@qdeathstar said in Stable firmware 2.01 (Duet 2) and 1.22 (Duet 06/085) released:

I consider this to be a bug:

Now that you can upload g-code while you print, if you upload a file with the same name as the file you are printing, the print will switch from the file you were printing to the new file.

I'll add this to the list of things to fix. The firmware already checks for trying to delete a file while it is being printed.

EDIT: I just found it was already on the list, but low priority.