@Phaedrux I uploaded the attached wifi server version and was able to upload a file afterwards. However, I was able to upload the .bin via DWC (which has been failing previously) so I may just be in one of the periods where I am able to upload. I will monitor over the next day or so and see if this wifi server version actually resolves the issues or not. I did not the load times are significantly longer, though that may be expected.

@gloomyandy I was about to reply saying nothing had changed, outside connecting an accelerometer well after the issues started, but I did double check and it appears my Unifi APs firmware was updated the day the issue started. I hope that isn't a cause of the issue as I really don't like the idea of rolling back networking firmware (which included security updates). In the meantime, I'm going to try connecting my board to my phones hotspot as the only way I have to eliminate my network from the equation.

I will update tomorrow with my findings on both of these items. Thanks for the help so far!

@Phaedrux said in Unable to upload files and DWC connection issues:

I didn't suggest it as a long term solution, just a test to see if the module is working correctly which it seems to be.

Understood; I agree the module appears to be working correctly and the issue is related to the firmware compatibility with my network.

Though, personally, I don't think it is unreasonable to expect a premium priced product which advertises web access to work on a major networking retailers platform. If I were running a homebrew or community based network solution, I would be more understanding of these types of issues, but not on a main stream, enterprise level network infrastructure.

I will work through the 2.1beta releases of the firmware to see if I can identify if/where a break happens. Thanks again!

I was able to set up access point mode and the connection seemed much more stable and uploading of files was successful and at expected speeds.

After this, I updated the wifi firmware back to 2.1beta6 and retested AP mode, with the same positive result. However, I don't consider this a viable solution as it requires disconnecting any control device from my regular network any time I want to do anything with my printer. Furthermore, I lose the ability to access my NAS where I store all my gcode files.

I did retest 2.1beta6 in standard mode and was able to connect and upload a few files, though these experienced the same speed and disconnect issues. And looking back in my original post I'm realizing I didn't fully explain the issue I was experiencing with uploading files. The failure mode is as follows:

• Select file(s) for upload
• Upload begins at standard transfer rates (350kb/s - 650kb/s)
• Upload progress stalls after around 100kb
• File upload fails and auto-retry kicks in
• Upload speed tanks to single digit kb/s, infrequently succeeding at these slow rates but more often fails after auto-retry threshold is reached
• DWC will sometimes disconnect during an upload attempt and the upload process dies as a result, at different points of the above process

From all I can see and have experienced, this appears to be a stability issue between wifi firmware after 1.27 and my Unifi network. If there is anything else I can try or assist with testing, I'll be happy to give it a go. As it is right now, this printer (my main machine) is so inconvenient to use that it's essentially out of commission.

Thanks in advance for the continued assistance!

@Phaedrux said in Unable to upload files and DWC connection issues:

@LuckyLuke said in Unable to upload files and DWC connection issues:

I'm going to try connecting my board to my phones hotspot as the only way I have to eliminate my network from the equation.

You can also test in access point mode where the Duet creates an SSID that you connect to. This would eliminate the unifi AP from the setup.

https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m589-configure-access-point-parameters

I will give this a try this evening, though I'm particularly keen on the idea of needing to disconnect my devices from my network (and internet) just to control my printer. Unless I am misunderstanding the process

The 1.27 version of the wifi server has technically worked to resolve the "ERR_EMPTY_RESPONSE" errors and inability to upload files; however, the loading times have skyrocketed to averages over a minute for DWC to load with a few instances of DWC never loading requiring a power cycle of the board to regain access. DWC now also frequently loses connection and reconnects itself after a few seconds. This is almost as frustrating as the original issue, though I am at least able to upload files.

@droftarts I am running the latest version of DWC "Duet Web Control 3.5.0-rc.2"

Again, appreciate all the help!

@Phaedrux I uploaded the attached wifi server version and was able to upload a file afterwards. However, I was able to upload the .bin via DWC (which has been failing previously) so I may just be in one of the periods where I am able to upload. I will monitor over the next day or so and see if this wifi server version actually resolves the issues or not. I did not the load times are significantly longer, though that may be expected.

@gloomyandy I was about to reply saying nothing had changed, outside connecting an accelerometer well after the issues started, but I did double check and it appears my Unifi APs firmware was updated the day the issue started. I hope that isn't a cause of the issue as I really don't like the idea of rolling back networking firmware (which included security updates). In the meantime, I'm going to try connecting my board to my phones hotspot as the only way I have to eliminate my network from the equation.

I will update tomorrow with my findings on both of these items. Thanks for the help so far!

I have run in to frustrating issues with DWC since upgrading one of my Duet 2 Wifi boards from 2.05.1 to 3.4.6 (currently running 3.5.0-rc.2) for accelerometer based input shaping. I followed the recommended upgrade path of 2.05.1>>3.0>>3.3>>3.46 and all was working well for about a week. After about a week of solid operation I was suddenly unable to upload any files, gcode or system. I then started experiencing connection issues with DWC where DWC would randomly lose connection and after refreshing the page it would return "ERR_EMPTY_RESPONSE". I would then have to power cycle the printer to be able to connect DWC again. I verified the board never lost connection to my network via my router, just DWC failed to maintain connection. Frustratingly, I am randomly able to upload files every now and then, but these periods are intermittent and I have not been able to identify a pattern. I also had issue making updates to my config.g file as the upload of the saved changes would fail and my config.g file disappeared entirely, necessitating pulling the SD card and loading it back on the card. Hoping the issue was just with 3.4.6, I upgraded to 3.5.0-rc1 to see if this resolved the issue, but the results were the same. RC2 was released shortly after and I upgraded to it hoping it would resolve the issues. Since upgrading to 3.5.0-rc.2 I have been able to isolate the "ERR_EMPTY_RESPONSE" to occurring when I have a DWC session open on more than one device (I used to be able to have sessions open on my phone, desktop, laptop simultaneously without issue). The file upload issue has persisted, along with few and far between periods of successful uploads. I have swapped multiple SD cards with the same behavior. I have another machine still running 2.05.1 firmware which does not have these issues, sessions stay connected and I have no issue uploading files.

Thanks in advance for any assistance, I've always enjoyed my Duet boards and the ability to control and upload files remotely, but these issues have made my machine so inconvenient to use.

1/8/2024, 12:49:26 PM	M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.0-rc.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2023-12-14 10:30:41

1/8/2024, 12:49:54 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-rc.2 (2023-12-14 10:30:41) running on Duet WiFi 1.02 or later
Board ID: 08DLM-996RU-N85T0-6J9FL-3SN6Q-1SV7R
Used output buffers: 3 of 26 (14 max)
=== RTOS ===
Static ram: 23084
Dynamic ram: 74916 of which 12 recycled
Never used RAM 15132, free system stack 184 words
Tasks: NETWORK(2,nWait,24.0%,221) HEAT(3,nWait,0.1%,328) Move(4,nWait,0.0%,363) MAIN(1,running,74.8%,751) IDLE(0,ready,1.1%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:01:24 ago, cause: power up
Last software reset at 2024-01-07 12:40, reason: User, Gcodes spinning, available RAM 12360, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 22.2, current 26.4, max 26.5
Supply voltage: min 24.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2024-01-08 12:49:53
Cache data hit count 2763525259
Slowest loop: 6.54ms; fastest: 0.20ms
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 2.5ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null
HTTP is idle 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
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 0 clear 271225
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 6.47ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1beta6
MAC address 
Module reset reason: Turned on by main processor, Vcc 3.44, flash size 2097152, free heap 31664
WiFi IP address 192.168.1.7
Signal strength -67dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

I will do so. Thank you all for your quick responses and assistance! Just goes to prove Duet is the best main board on the market, with an excellent community and support!

Yes, I do have a multimeter at hand (one benefit of being confined and working from home!). I was able to confirm continuity between the two pins of the 7.5A fuse holder. Looks like the 5V regulator is the culprit.

The 7.5A fuse does not appear to have any damage.

Which is the main 15A fuse? Is it the surface mount fuse labeled F1, behind the Wifi module?

Yes, the Duet was purchased new from Printed Solid on 5/7/20.