Posts made by lolorc

https://forum.duet3d.com/topic/879/wifi-rant-alert/13
I have two cisco APs, I've disabled the 2.4GHz network interface on my a1140, letting only the 1600 two floors under working, it also works better !
I guess I'll find a way to get another a1600

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.

@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

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...

@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...

@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.

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.

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 ?

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

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

@dc42 said in Firmware 2.02RC6 released:

@lolorc said in Firmware 2.02RC6 released:

Hi there,

I'm still not able to upload files to my duet wifi, I'm using latest firmwares, duetwifiserver is still the old 1.21.
Still using cisco access points and linux computers, still loads of tcp dup, tcp retransmission, tcp window full...
and no single issue with a raspberry 10cm away connected to the same ap...

I guess it's not enough just to use a esp8266 and expect it to work in a lot of different environments.

I've been uploading gcodes and firmware through the usb serial port for a while now, not the end of the world...

Happy Xmas.

I'm sorry to hear you are having problems with WiFi connectivity. It may be that the ESP12S module on your Duet is faulty.

it may be, that something I haven't though about. the board connects to the access point fine, I'm able to use the web service, the issues happen when uploading files.
I burnt my first duet board, this is a my second one, it's true I have never encoutered this issue with the first board. but it was 20 months ago...
Have you ever heard of that kind issues that were related to the esp itself ?

Best wishes.

Hi there,

I'm still not able to upload files to my duet wifi, I'm using latest firmwares, duetwifiserver is still the old 1.21.
Still using cisco access points and linux computers, still loads of tcp dup, tcp retransmission, tcp window full...
and no single issue with a raspberry 10cm away connected to the same ap...

I guess it's not enough just to use a esp8266 and expect it to work in a lot of different environments.

I've been uploading gcodes and firmware through the usb serial port for a while now, not the end of the world...

Happy Xmas.

Ok make sense, I guess it could as well be configurable.
Anyway, since I've not been able to resolve my duet wifi issues, I have implemented this on my duet proxy. (network/http server done with a python daemon that communicates via usb serial)

this was happening with duet only powered from usb port.
Is it possible to prevent a print or to fail some gcode commands if there's no "main" power ?
Looking at the pause macro, It won't success without power, that's M112 I should have tried.

Hi,

weird issue,

started a print from web ui.
tried to pause it with M25 from serial
tried to pause from web ui
manage to get M122 :
http is doing "M25" in state(s) 0
telnet is idle in state(s) 0
file is doing "M190 S80" in state(s) 0
serial is doing "M25" in state(s) 0

now it's stuck, can't do anything from either serial or webui, can't reconnect to webui.

going to power cycle it...

Hi,

I will do, in the mean time it looks like there some network issues. Some network trace reveals a huge amounts of tcp duplicates.
It takes 45min to upload a 3MB gcode file...
I'm going to investigate this first. I know I already had issues with some old cisco access point, it might be related as well.

RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21 running on Duet WiFi 1.0 or 1.01

"WiFi module is changing mode"

Debugging enabled for modules: Network(1) WiFi(14)

I'm also getting this issue.
M552 S0/S1 doesn't change its status.

apart from connecting to the due port, that's all that I did.
Do know why, but I did exactly the same with 1.21, copied server, firmware and iap4e to sdcard, checked the size and did the M997 S1 then M997 S0. it worked;
it's probably my printer being cheeky with me because I'm not spending enough time with it…
panel due serial port still wired, i'll make sure I'll log everything in the future.

Thanks !

I'll try to connect to one of the real serial port then.
Because as I said in other post I've tried every combination with the filename.
When I do M997 it takes less than 30s to restart, it looks like the card simply reboots, so I guess there's a error message sent on the serial port I need to catch and report to you.

Hi,

Thanks for your answer.
as the title says, it's a duet wifi

I've just tried again, it looks like the duet reboots as soon as I enter M997 on the usb serial console.
now I get "Error: G-Code buffer 'serial' length overflow" when I connect again.
And I'm using screen to connect to it, I'm not sendind any command to the serial port.

When I do M997 S1, I see some messages

[[language]]
Trying to connect at 230400 baud:  success
                             Erasing 4096 bytes...
                                                  Erasing 233472 bytes...
                                                                         Uploading file...
          5% complete

```and so on…

when I do M997 S0 the board resets, the usb serial port is closed and I can't see any debug message.

I guess, I'm going to connect to the esp serial port or the the panel due one to see if I can retrieve more info.

anything else I could do ?