Percentage of uploading gcode file is fixed at 100%
When I upload a gcode file, the percentage of the uploading doesn't change, it is fixed at 100%.
I made a video to show the problem.
Does anyone have this problem?
Can you share some more details of your setup?
What duet board? What firmware version? What DWC version?
Results of M122 would help.
Sure, my mistake..
Duet 2 Wifi
Duet Wifi Server 1.25
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2.2 running on Duet WiFi 1.02 or later Board ID: 0JD0M-9P6M2-NW4SJ-6J9FL-3S46N-9TU7M Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 23460 Dynamic ram: 73048 of which 60 recycled Never used RAM 15424, free system stack 101 words Tasks: NETWORK(ready,155) HEAT(blocked,294) MAIN(running,166) IDLE(ready,20) Owned mutexes: WiFi(NETWORK) HTTP(MAIN) === Platform === Last reset 73:00:00 ago, cause: power up Last software reset at 2021-02-18 22:39, reason: User, GCodes spinning, available RAM 15512, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x1c Aux0 errors 182,182,182 MCU temperature: min 30.6, current 33.2, max 44.9 Supply voltage: min 23.6, current 23.8, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 103188, standstill, SG min/max 0/1023 Driver 1: position 103188, standstill, SG min/max 0/1023 Driver 2: position 103188, standstill, SG min/max 0/1023 Driver 3: position 0, standstill, SG min/max 0/1023 Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2021-02-22 08:51:15 Cache data hit count 4294967295 Slowest loop: 113.47ms; fastest: 0.11ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 9.0ms, write time 426.3ms, max retries 0 === Move === DMs created 84, maxWait 159353166ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 193, completed moves 193, hiccups 206, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = 2 -1 -1 -1 Heater 0 is on, I-accum = 0.5 Heater 1 is on, I-accum = 0.3 === GCodes === Segments left: 0 Movement lock held by null HTTP is ready with "M122 " in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 428.77ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.25 WiFi MAC address 48:3f:da:79:34:48 WiFi Vcc 3.35, reset reason Power up WiFi flash size 4194304, free heap 24328 WiFi IP address 192.168.0.199 WiFi signal strength -66dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
oliof last edited by
I can't open the video, but I had this effect for a while, but then it went away. I assume it's either a caching issue or some other browser quirk because it fixed itself on a printer that didn't get any firmware or DWC updates.
jay_s_uk last edited by
i'd be very very surprised if you're uploading at 27.4mb/s over wifi on a duet board.
I think the progress of the upload is at fault here, not reporting the correct speed and percentage complete rather than being stuck at 100%
This is most likely a browser or OS issue. Either the OS sends the file too quickly without waiting for RRF to acknowledge the last packets first or the browser just sends everything in one bunch and does not report correct progress values.
Either way, the notification disappears again when the upload has finished so it's rather hard to address. It may look different with a different browser.
@jay_s_uk So do I.
@chrishamm I tried on my laptop and Firefox and Edge. Same problem on all browsers and devices.
Maybe it is causing by the wrong speed, but I have no idea how to fix it
Try creating a fresh SD card.
@Phaedrux I just bought a band new sd card, copy the DWC files downloaded from github and the configs file just copied from the old sd card. And the problems continues. Any other guess how to solve it?
And thanks for your time to supporting me
There are a couple things I can think of to try and narrow down the cause.
Try using incognito or private browsing mode on your browser and disable any extensions, see if that makes a difference.
Disable any antivirus protection you may have installed.
If neither of those make a difference you can try putting the Duet into Access Point mode where the duet creates a network SSID and you connect to it directly from your laptop wifi.