Crash after I´ve uploaded gcode file

Computiger

Doesn´t matter how big the file is. I tried 400kB till 3MB
If I reconnect I can download the file correct

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 1.21 (2018-03-21)
WiFi Server Version: 1.21
Web Interface Version: 1.21

[c]M122
=== Diagnostics ===
Used output buffers: 3 of 32 (32 max)
=== Platform ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21 running on Duet WiFi 1.02 or later
Board ID: ******************************************
Static ram used: 16152
Dynamic ram used: 100592
Recycled dynamic ram: 2040
Stack ram used: 1224 current, 4448 maximum
Never used ram: 7840
Last reset 00:55:25 ago, cause: software
Last software reset at 2018-03-31 12:09, reason: User, spinning module GCodes, available RAM 7864 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 4
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 13.1ms
MCU temperature: min 27.6, current 28.1, max 29.0
Supply voltage: min 12.3, current 12.4, max 12.6, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/170
Driver 1: standstill, SG min/max 0/135
Driver 2: standstill, SG min/max 0/140
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-03-31 13:05:21
Slowest main loop (seconds): 0.082620; fastest: 0.000046
=== Move ===
MaxReps: 2, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 236, MaxWait: 4219196864ms, Underruns: 0, 0
Scheduled moves: 11, completed moves: 11
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, 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 ===
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address ***********************
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 15824
WiFi IP address *******************
WiFi signal strength -38dBm, reconnections 0, sleep mode modem
Socket states: 2 0 0 0 0 0 0 0
=== Expansion ===[/c]

dc42

1. Which browser are you using?

2. Are you trying to upload or download a file? The title of this thread says upload but your post says download,.

Computiger

1. I use Firefox and Chrome. Issue comes on both of them.
But I don´t believe it is a issue in webbrowser. My 2nd printer with DuetWifi hasn´t that issue.

Only diffrent is the PanelDue. The printer whith the issue has a 7inch PanelDue Display. It was working good for about 6 weeks.

2. year some times I am a bit confuse. I tried to UPLOAD the file from my computer to the DuetWifi

dc42

One possibility is that the SD card is quite full and the cluster size is small, making finding free space to store the file take a long time. If that's the case then reformatting the SD card to use 64K clusters may help. See https://duet3d.dozuki.com/Wiki/Network_disconnections_after_uploading_large_files even though that describes a different symptom.

Computiger

I´ll try this

SD card isn´t full but has a cluster size of 32kB

[[language]]
M39
SD card in slot 0: capacity 31.91Gb, free space 31.41Gb, speed 20.00MBytes/sec, cluster size 32kb

dc42

If the cluster size is 32K that that's probably not the problem.

Does the problem only occur the first time you upload a file to the Duet after starting it?

resam

dc42:
My SD card is 4GB, and I couldn't get 64kb clusters. I would get the following error message on macOS:
[c]
$ sudo newfs_msdos -F 32 -c 128 -v DUET /dev/disk2s1
512 bytes per physical sector
newfs_msdos: 61432 clusters too few clusters for FAT32, need 65525[/c]

Feel free to add this to the wiki page:

If you are on macOS, the following command might work. Make sure to select the correct disk and partition!

# find the correct disk and partition
diskutil list
# format partition as FAT32 with 64kb cluster size, for 8/16/32GB SD cards
sudo newfs_msdos -F 32 -c 128 -v DUET /dev/disk2s1
# format partition as FAT32 with 32kb cluster size, for 4GB SD cards
sudo newfs_msdos -F 16 -c 128 -v DUET /dev/disk2s1

edit: updated commands

Computiger

I have tried to use a new sd card full formated with FAT32 64K with copied files from the old one.
Issue was still there after restart.
You are right its only occur after first start and after 10 or 15 minutes running

I´ve resolved the issue, I hope, as I deleted all G-CODE files in gcode folder.
Seems to work now.

Thanks David

dc42

@resam:

dc42:
My SD card is 4GB, and I couldn't get 64kb clusters. I would get the following error message on macOS:
[c]
$ sudo newfs_msdos -F 32 -c 128 -v DUET /dev/disk2s1
512 bytes per physical sector
newfs_msdos: 61432 clusters too few clusters for FAT32, need 65525[/c]

Feel free to add this to the wiki page:

If you are on macOS, the following command might work. Make sure to select the correct disk and partition!
# find the correct disk and partition
diskutil list
# format partition as FAT32 with 64kb cluster size
sudo newfs_msdos -F 32 -c 128 -v DUET /dev/disk2s1
# format partition as FAT32 with 32kb cluster size, for small SD cards
sudo newfs_msdos -F 32 -c 64 -v DUET /dev/disk2s1

With a 4Gb or smaller card you need to use FAT16 to have the option of 64K clusters. There would be no point in using FAT32 with 64K clusters on a small SD card, because FAT16 will do and it is more efficient.

resam

dc42: yes, but I think that's the way how I got my SD card from your factory.

dc42

Yes, the factory was supplying SD cards formatted to FAT32 with 4kb clusters. We have since changed to FAT16 with 64Kb clusters.

I am guessing that the -F 32 parameter in that command means FAT32, in which case you could use -F 16 instead.