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

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

[dc42]

@appjaws, what is the exact message you are getting, and when?

[appjaws]

DWC just sits after the file has been uploaded until it fills each box with N/A.
The firmware is searching for this data when it doesn't need to for laser files.
The "could not find end of file error" appears randomly during printing.
I will see if I can nail the exact conditions later

Edit. The "could not find end of file error" appears when the print starts

[appjaws]

This is a screen shot at the end of the Laser print.

=== Diagnostics ===
RepRapFirmware for Duet version 1.22 running on Duet 0.6
Used output buffers: 3 of 16 (9 max)
=== System ===
Static ram: 44652
Dynamic ram: 41436 of which 4024 recycled
Stack ram used: 136 current, 6084 maximum
Never used ram: 2108
=== Platform ===
Last reset 03:27:56 ago, cause: power up
Last software reset at 2018-08-03 12:50, reason: User, spinning module GCodes, available RAM 1836 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 1071.5ms, max retries 0
MCU temperature: min 42.0, current 45.6, max 50.1
Date/time: 2018-08-03 16:48:52
Slowest loop: 1071.77ms; fastest: 0.09ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm: 79, MaxWait: 2429950ms, Underruns: 1012201, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 0, state: 4, listening: 20071c20, 0, 0

[adri84dj]

Good afternoon,

I do not know if it's my problem, but I've made a couple of impressions with this latest firmware and the latest version of DWC, and it seems that the number of layers does not match the printed layers. My two impressions have finished in 52 of 50 layers

Greetings.

[whosrdaddy]

@dc42:

it is inconsistent, it seems not to depend on filesize.
for completeness, this is my M39 output:

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

I did not have this problem on 1.21 firmware.