Network connection problems
-
@lolorc: What's your signal strength? Does it work for you with only one device connected?
signal strength=-54dBm
It works for me with only one device.
I guess the crashes come from too much errors and retransmissions.
It would help to get real error messages instead of "exception", I'm looking at the source at the moment, I'm wondering how I could add debug statements in DWS (https://github.com/chrishamm/DuetWiFiServer) I'm not sure i can simply add Serial.println("DEBUG: BLAH"); I guess I need to have them parsed in RRF so they get displayed on the console.about having duetwifi working as a AP, it can be easily implemented in here : https://github.com/chrishamm/DuetWiFiServer/blob/master/src/RepRapWiFi.cpp
Have you tried to use another AP ? an android phone used as a portable hotspot for instance. (as I mention in
https://www.duet3d.com/forum/thread.php?id=455 I had weird issues with a cisco aironet 1130 AP, was working perfectly with my android phone before, now I'm testing a 1140 AP) -
[
It would help to get real error messages instead of "exception", I'm looking at the source at the moment, I'm wondering how I could add debug statements in DWS (https://github.com/chrishamm/DuetWiFiServer) I'm not sure i can simply add Serial.println("DEBUG: BLAH"); I guess I need to have them parsed in RRF so they get displayed on the console.hmmm looks like I might just have to populate ESP_COMMS to receive the Serial.println from DWS
-
@lolorc: What's your signal strength? Does it work for you with only one device connected?
It would help to get real error messages instead of "exception", I'm looking at the source at the moment, I'm wondering how I could add debug statements in DWS (https://github.com/chrishamm/DuetWiFiServer) I'm not sure i can simply add Serial.println("DEBUG: BLAH"); I guess I need to have them parsed in RRF so they get displayed on the console.
I agree, we need at least the program address that caused the exception to be able to debug this. Unfortunately, the core library for the ESP8266 is closed source. Even if the manufacturer wanted to open-source it, the FCC won't allow that.
I do have a major rework of the DuetWiFiServer code planned. I think it will be next after implementing babystepping in firmware 1.18 and finishing support for the Duet Ethernet (which is mostly working already).
-
Can you confirm if I connect to URXD1/UTXD1 (ESP_COMMS) I will get the access to the ESP serial and be able to get messages from the Serial.println in DWS to debug it ?
-
Can you confirm if I connect to URXD1/UTXD1 (ESP_COMMS) I will get the access to the ESP serial and be able to get messages from the Serial.println in DWS to debug it ?
Yes, that should work if you match the baud rates.
-
-
[[language]] Exception (28): epc1=0x4000bf0e epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000 ctx: cont sp: 3fff0510 end: 3fff07f0 offset: 01a0 >>>stack>>> 3fff06b0: 3ffe0031 3fff0790 3fff0790 4020bd1f 3fff06c0: 3fff1284 3fff0790 3fff0740 4020c00a 3fff06d0: 3fff1284 3fff0790 3fff09b4 4020842b 3fff06e0: 00000000 0000001f 0000001f 3fffbf74 3fff06f0: 0000004f 00000044 3fffbedc 0000000f 3fff0700: 0000000a 3fffc6fc 00000001 3ffef7bc 3fff0710: 3fffbec4 0000000f 00000000 3fffbe74 3fff0720: 0000000f 00000006 3fffbe4c 0000001f 3fff0730: 0000000a 3fffbe34 0000000f 00000003 3fff0740: 3fffbf0c 0000005f 00000050 00000000 3fff0750: 3fff09f0 3fff0840 3fff11b4 3fff07a8 3fff0760: 3fffdad0 00000000 0000000a 3fff3714 3fff0770: 402015da 00000001 00000001 3ffef7c4 3fff0780: 3fffdad0 000003e8 3fff09b4 4020945b 3fff0790: 3ffe9240 00000000 000003e8 00105ac9 3fff07a0: 3fff097c 3fffbe9c 00000000 40206c2c 3fff07b0: 3fffdad0 00000000 3ffef7bc 402097e3 3fff07c0: 00000000 00000000 00000001 40206bd5 3fff07d0: 3fffdad0 00000000 3ffef7bc 40206c00 3fff07e0: feefeffe feefeffe 3ffef7d0 40101a44 << <stack<<< 8="" 16="" ets="" jan="" 2013,rst="" cause:2,="" boot="" mode:(3,0)="" load="" 0x4010f000,="" len="" 1384,="" room="" tail="" chksum="" 0x2d="" csum="" v09f0c112="" <="" pre="">this is from one of my build, so I guess the stack trace won't be that helpful</stack<<<>
-
[[language]] Exception (28): epc1=0x4000bf0e epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000 ctx: cont sp: 3fff04f0 end: 3fff07d0 offset: 01a0 >>>stack>>> 3fff0690: 3fff1264 3fff0770 3fff06c0 3ffe964c 3fff06a0: 3fff1264 3fff0770 3fff06cc 4020c006 3fff06b0: 3fff1264 3fff0770 3fff0994 4020848c 3fff06c0: 00000000 00000000 00000000 3fffb9cc 3fff06d0: 0000000f 0000000a 3fffb9b4 0000000f 3fff06e0: 0000000a 3fffdad0 3ffef7a4 00000030 3fff06f0: 3fff9b3c 0000000f 00000000 3fff9b24 3fff0700: 0000000f 00000006 3fffbb54 0000001f 3fff0710: 0000000a 3fffbb3c 0000000f 00000003 3fff0720: 3fffb884 0000005f 00000050 00000000 3fff0730: 3fff09d0 3fff0820 3fff1194 3fff0788 3fff0740: 3fffdad0 00000000 0000000a 3fff36f4 3fff0750: 402015da 00000001 00000001 3ffef7a4 3fff0760: 3fffdad0 0000011d 3fff0994 4020945b 3fff0770: 3ffe9220 00000000 000003e8 0003fa5e 3fff0780: 3fff095c 3fffa044 00000000 40206c2c 3fff0790: 3fffdad0 00000000 3ffef79c 402097e3 3fff07a0: 00000000 00000000 00000001 40206bd5 3fff07b0: 3fffdad0 00000000 3ffef79c 40206c00 3fff07c0: feefeffe feefeffe 3ffef7b0 40101a44 << <stack<<< 8="" 16="" 24="" ets="" jan="" 2013,rst="" cause:2,="" boot="" mode:(3,6)="" load="" 0x4010f000,="" len="" 1384,="" room="" tail="" chksum="" 0x2d="" csum="" v09f0c112="" ~ld="" wait="" wifi="" <="" pre="">this is with 1.13 (ch fork)</stack<<<>
-
I presume epc1 is the program counter. Can you use the map file from your build to work out what function it is in? Also those 4020xxxx addresses on the stack look as though they may be program addresses, so again it would be useful to know what functions they are in.
-
@lolorc: Thanks for the investigation of the issue.
To me the whole wifi thing seems odd.
I wonder why so few people have problems if it is a software bug. -
@nokian:
@lolorc: Thanks for the investigation of the issue.
To me the whole wifi thing seems odd.
I wonder why so few people have problems if it is a software bug.I presume there is something about your network that is triggering the bug. Am I right in thinking that you had the board working properly with a different network, or was that someone else?
-
This is so crazy.
It connected to the web control without crashing.
I didn't change anything.Last time I tried three different access points but the server crashed each time.
EDIT: 06.01.2017 once again it worked fine but I get ajax errors quite often.
-
I can't upload large gcode files (>1MB). The web control gets stuck during upload.
-
@nokian:
I can't upload large gcode files (>1MB). The web control gets stuck during upload.
Do you get a new network connection message sent to USB when this is happens, with Reset reason = exception again? Perhaps it is the same bug.
-
Do you get a new network connection message sent to USB when this is happens, with Reset reason = exception again? Perhaps it is the same bug.
Probably not the same bug. USB serial is quiet during timeout. No server exception. I can reconnect immediately afterwards.
Can't even upload a 0.5MB gcode file without the upload getting stuck.
However I can find a part of the uploaded file in the web control afterwards.- not a signal problem because signal strength =-40dBm
- not a browser problem
-
That often happens to me too. Smaller files almost always work, but larger files get stuck in the middle and I have to try several times before it uploads completely. For very large files, the probability of getting an error during upload seems to approach 1, and I just give up. I'm running my Duet on a separate network from my main Wi-Fi; otherwise it barely works at all. Networking seems to be Duet's weakest point
-
What do you mean by larger files? I also experience this with files <500KB. Retrying doesn't help, although every try leads to a different upload percentage.
-
Please can those of you with WiFi file upload issues do the following:
1. Confirm that you are running DuetWiFiServer version 1.03-ch and DuetWiFiFirmware version 1.16 or later.
2. Connect Pronterface or another host program via USB, send M552 S0 to turn networking off, then send M552 S1 to turn networking on again. When the network connection message comes through to Pronterface, report the RSS it displays.
-
1. Confirmed!
Firmware Version: 1.17b (2017-01-07)
WiFi Server Version: 1.03 (ch fork)
Web Interface Version: 1.142. RSS (received signal strength) after M552 S1
signal strength=-42dBm -
Apparently this is not a problem many people observe…
As the wifi server is not crashing what could cause the upload to stop?@thomasf: What's your signal strength? Do you have the problem since the beginning?