DuetWiFiServer 1.22 released

[dc42]

I've released version 1.22 of DuetWiFiServer. You can find it in the updated RepRapFirmware 2.02 release at https://github.com/dc42/RepRapFirmware/releases/tag/2.02. It fixes a buffer exhaustion issue that became apparent with Duet Web Control 2. It may also help in other situations where the WiFi connection is unreliable and the problem isn't caused by poor WiFi signal strength.

[lolorc]

Hi,

looks like the tcp restransmission/tcp issues I had have gone.
But in the mean time I'm not able to complete any gcode upload, even the smallest gcode file get stuck at 81920 bytes transfered.
Been trying with curl/ftp, will try with http.

Last reset 00:12:54 ago, cause: power up
Last software reset at 2019-01-09 18:16, reason: User, spinning module GCodes, available RAM 6560 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 7.3ms, max retries 0

[lolorc]

i tried another sd card again, but that's not changing a lot.
no more retransmission/dup but a lot of tcp resets.

Last reset 00:17:42 ago, cause: power up
Last software reset at 2019-01-09 18:45, reason: User, spinning module GCodes, available RAM 6664 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 20
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 5.7ms, max retries 0

it's moving forward, I guess it's matter of time now.
in the mean time, i'll continue to upload my files through usb serial

[dc42]

The error code 4 means that output buffer starvation occurred at some time. This is most likely because you ran a command that produced a lot of output, over either the web or USB, and the consumer didn't read the data fast enough. This doesn't necessarily indicate a problem.

The error code 20 means it happened again, in addition you had an SD card timeout error. That suggests an SD card issue.

Which main firmware version are you running?

You may get additional WiFi diagnostic information if you connect a PC running printerface or YAT etc. via USB and send M111 S1 P14.

[SupraGuy]

Yay.

I had previously attempted to update to DWC 2.uh-oh. I was unable to connect to it at all after the update, and had to manually uninstall it from the SD card. Symptom was receiving a blank page in my browser with just the DWC title. (Tried Chrome, Firefox, and -- ugh-- MS Edge browsers, all the same result.)

After updating the WiFi server, and re-installing the same package (No changes to firmware otherwise) I was able to use the new DWC. I have a backup copy of the SD card from right before that, I will probably try using that this weekend to test that it was the WiFi server update that caused my problem. I'll also try it on my other Duet.

[lolorc]

Thanks for your answer David.
pretty sure nothing was connected to the usb port, and I've reduced the polling interval to 2s for the web updates. The sdcard was a new one, a THN-M302R0320EA I had for spare, kind of overkill for the duet I guess.
I'll be carrying my test on this week-end.
I've been able to upload a 500KB gcode at 2KB/s through ftp, that's some progress.
The tcp dups are gone, but I think the issue is still with the network stack rather than the sdcard. I've just powered my printer/duet on, I'm not able to fully load the web interface, a lot of connections reset by peer (by duet)
I've already have wireless debug on.
I've just activated network debug as well.

To make sure it's not a sdcard issue, would it be possible to diagnose upload issues without really writing to the sdcard ? a rr_null_upload or a virtual directory that write to /dev/null ?

[dc42]

See my previous post about how to get additional WiFi diagnostic information. The information is sent to the USB port, so you need to have something connected to it that can display it. If there is nothing to receive the data, turning on diagnostics may itself cause problems.

[lolorc]

my way to upload gcode files, my way to use my printer is to upload gcode files through usb with M559. Most of the time I have a program reading the usb serial port. There's no specific wifi debug messages.

And there's a huge change with latest dws, tcp retransmissions have been replaced by tcp resets, it's a lot more unusable.

[Eddiie]

Take your printer to a friend's house and test on their network. Curious..

[lolorc]

@eddiie just by upgrading dws, errors have changed from tcp dups to tcp resets. this is an issue with the firmware not with my network. I have devices connected to it, it works flawlessly with them...

from what I read here https://github.com/dc42/DuetWiFiSocketServer/commit/0d7fbff977eec9dc132825cdc75f26020e0136de it's still WIP.

I'd rather limit my duet wifi server to send 1 file at a time rather than having those bl**dy issues.

I'm using some sort of proxy that I have written to circumvent those issues. I have a rpi attached to the usb serial port, a simple python web server serves all the static files (that i have locally on the rpi), some rr_cmd are translated to gcodes sent through serial port, some are just proxied back to the duet wifi server.
At the moment that's my way to use my duet.

0 dc42 committed to dc42/DuetWiFiSocketServer

Version 1.22beta1

Changes for version 1.22.1 beta release. Projects LwipESP8266 and CoreESP8266 are also changed.

[dc42]

@lolorc, please can you follow up these suggestions that have already been made:

• Connect a PC via USB, enable WiFi debug and see if you get any debug messages when the errors occur
• Take the Duet to a friend's house and see whether it will work properly on another network. If it won't then perhaps the WiFi module is faulty.

[lolorc]

@lolorc said in DuetWiFiServer 1.22 released:

my way to upload gcode files, my way to use my printer is to upload gcode files through usb with M559. Most of the time I have a program reading the usb serial port. There's no specific wifi debug messages.

M111 P14 S1 has been in my config.g for months...

[dc42]

@lolorc said in DuetWiFiServer 1.22 released:

@lolorc said in DuetWiFiServer 1.22 released:

my way to upload gcode files, my way to use my printer is to upload gcode files through usb with M559. Most of the time I have a program reading the usb serial port. There's no specific wifi debug messages.

M111 P14 S1 has been in my config.g for months...

Yes, but do you have a PC connected via USB to receive the debug data? If you do then you should see some messages when the WiFi module starts up. If it detects a problem, you may see further messages.

You should most definitely not use M111 P14 S1 if you do not have a PC connected running a termninal emulator or Pronterface etc. to receive the USB data.

[lolorc]

I have a raspberry connected to the usb, reading the usb port all the time.
I can see the ssid list, and the connection getting successful, after that, there isn't any specific message, no error, no reconnection.
Same goes if I enable storage/network/webserver debug, I can see the connection, data being received from network, data being read/written from/to sdcard, but no specific error when the TCP connection is reset.

M111 P14 S1 is in my config.g because my rpi is always connected and reading the usb serial port as this is my only way to upload files with M559.

I also tried to unplug rpi + disable any log, I still have the tcp issues.

I'll check my sdcard cluster size this evening, and I'll try to reproduce with another AP, No need to move my duet to a friend, I'll use an android phone as an AP and will connect my pc to it. I'll do that with the sdcard I'm using atm, I'll do it again with the brand new sdcard I used last week to diagnose sdcard issues.

Will report back as soon as done.
This duet board is a replacement board I bought from T3P3 2 years ago after I shorted 24V and 3.3V...

[dc42]

This is what I get when I have a terminal session connected to a Duet WiFi and I use M552 to disconnect and reconnect while WiFi debugging is enabled. You should see something very similar, with ***** replaced by the SSID of your network.

m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.02+1 ELECTRONICS: Duet WiFi 1.0 or 1.01 FIRMWARE_DATE: 2019-01-15b1
ok
m111 s1 p14
Debugging enabled for modules: WiFi(14)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Move(4) Heat(5) DDA(6) Roland(7) Scanner(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15)
ok
m552 s0
ok
WiFi: state: 5 -> 0 (0)
WiFi: rm 0
WiFi: pm close 7
WiFi: del if0
WiFi: usl
WiFi: mode : null
WiFi module is idle
m552 s1
ok
WiFi: mode : sta(60:01:94:09:ae:34)
WiFi: ip:0.0.0.0,mask:255.255.255.0,gw:192.168.1.254
WiFi: add if0
WiFi: scandone
WiFi: ../src/SocketServer.cpp(353): found network ASUS_Guest1
WiFi: ../src/SocketServer.cpp(353): found network *****
WiFi: sleep enable,type: 2
WiFi: scandone
WiFi: state: 0 -> 2 (b0)
WiFi: state: 2 -> 3 (0)
WiFi: state: 3 -> 5 (10)
WiFi: add 0
WiFi: aid 2
WiFi: cnt 
WiFi: 
WiFi: connected with *****, channel 12
WiFi: dhcp client start...
WiFi: ip:192.168.1.125,mask:255.255.255.0,gw:192.168.1.254
WiFi module is connected to access point *****, IP address 192.168.1.125
WiFi: pm open,type:2 0

[lolorc]

@dc42
yes that's obviously what I've also been getting.

and this is what I get after I just powered on the printer and tried to upload a 25MB gcode file, which was obviously unsuccessful.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet WiFi 1.0 or 1.01
Used output buffers: 5 of 20 (15 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98612 of which 0 recycled
Exception stack ram used: 256
Never used ram: 6680
Tasks: NETWORK(ready,648) HEAT(blocked,1232) MAIN(running,3840) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:03:48 ago, cause: power up
Last software reset at 2019-01-14 11:06, reason: User, spinning module GCodes, available RAM 6592 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 7.0ms, max retries 0
MCU temperature: min 16.0, current 16.7, max 16.9
Supply voltage: min 0.5, current 0.5, max 0.6, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 2019-01-15 17:35:50
Cache data hit count 777694634
Slowest loop: 57.19ms; fastest: 0.06ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
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
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 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 ready with "M122" 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 ===
Slowest loop: 207.27ms; fastest: 0.08ms
Responder states: HTTP(0) 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 1
  WiFi firmware version 1.22
  WiFi MAC address
  WiFi Vcc 3.27, reset reason Turned on by main processor
  WiFi flash size 4194304, free heap 27448
  WiFi IP address
  WiFi signal strength -55dBm, reconnections 0, sleep mode modem
  Socket states: 0 0 0 0 0 0 0 0
  ok
  WiFi: MEM PBUF_POOL avail:␡Conns: 0:free, 1:free, 2:free, 3:free, 4:free, 5:free, 6:free, 7:free
  WiFi: IP xmit: 730 recv: 650 fw: 0 drop: 0 chkerr: 0 lenerr: 0 memerr: 0 rterr: 0 proterr: 0 opterr: 0 err: 0 cachehit: 0
  WiFi: TCP xmit: 521 recv: 623 fw: 0 drop: 0 chkerr: 0 lenerr: 0 memerr: 0 rterr: 0 proterr: 0 opterr: 0 err: 0 cachehit: 609
  WiFi: MEM UDP_PCB avail: 4 used: 4 max: 4 err: 0
  WiFi: MEM TCP_PCB avail: 8 used: 6 max: 8 err: 0
  WiFi: MEM TCP_PCB_LISTEN avail: 4 used: 2 max: 2 err: 0
  WiFi: MEM TCP_SEG avail: 16 used: 0 max: 6 err: 0
  WiFi: MEM ARP_QUEUE avail: 10 u␡MEM PBUF_REF/ROM avail: 10 used: 0 max: 0 err: 0

[dc42]

@lolorc said in DuetWiFiServer 1.22 released:

yes that's obviously what I've also been getting.

I'm sorry, that's not obvious at all, because you didn't say you were getting any debug information at all. Which led me to think that you were not monitoring the debug output.

Let's see what happens when you try using your phone as an AP.

[lolorc]

Hi,

Good news, it's not my esp as it's working flawlessly with my android ap.
So I guess I need to investigate what's going on with my cisco APs (2 of them, Multiples SSID, etc...)

Sorry for the noise,
Thanks for the patience and answers.

I'll report back as soon as I find something relevant.

[grizewald]

Would this buffer problem explain why I have been experiencing problems uploading files to my first ever Duet2 WiFi?

I've had various manifestations of the problem: once a failed save of an edit to config.g in the browser, several times starting an upload of a g-code file and then seeing the transfer stall after a couple of MB and then error out.

The first time I had trouble uploading a g-code file, rebooting solved the problem. The second time, even a reboot and immediate re-upload resulted in the transfer stalling and terminating with an error. When that happened, I shut down, powered off and put the SD card in my Linux laptop. I checked the file system on the card (and cleared the dirty bit) and read the entire card with dd without issue.

My hardware is a genuine Duet2 WiFi from duet3d.com in the UK. When I got to testing my new printer just before Christmas, I updated both the Duet and the PanelDue 7i that I have to the latest releases of their firmware when 2.02 was released.

Everything works fine except for these spurious file transfer errors.

[dc42]

@grizewald said in DuetWiFiServer 1.22 released:

Would this buffer problem explain why I have been experiencing problems uploading files to my first ever Duet2 WiFi?

It's hard to know for sure what conditions could cause the WiFi module firmware to run out of buffers, other than the condition that DWC 2.0RC2 was good at triggering. I do know that some users experienced more disconnects when we switched to the new WiFi firmware architecture, which is probably when the buffer exhaustion problem started. However, we also adopted the new SDK from Expressiv at that time, and that included some major changes including adjustments to the output power.

So I recommend that you upgrade to the 2.02a firmware bundle, which includes DuetWiFiServer 1.22. In particular, if you are already running DuetWiFiServer 1.21, then upgrading it to 1.22 is low-risk.