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

[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.

[dragonn]

Maybe add a warning/question? This helped my last time when I need to add a pause command into a running print.

[wilriker]

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

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.

I just ran M39 and got

SD card in slot 0: capacity 3.98Gb, free space 3.78Gb, speed 20.00MBytes/sec, cluster size 64kb

so my card is already formatted to the largest possible cluster size (it came this way I never touched it) and still I could reproduce @whosrdaddy's issue. Intersting why it works for @Dougal1957 with an even larger file though.

Just an idea: @Dougal1957 do you still have the stock SD card or do you maybe use a faster one? Also @dc42 do you know more details on the speed of the stock SD card?

[Dougal1957]

@wilriker Prob not I go thru cards quite a lot (take them out put them down and lose them lol) M39 gives

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

[appjaws]

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

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.

When uploading a laser file, which could be in excess of 30MB there is a large delay. I keep getting "could not fine end of file error".
For Laser files, the Object Height, Layer Height and Filament Usage are not required or recorded in the file, so the firmware will ever obtain the data.