Moved from Duet 0.6 to DuetWiFi - first impressions

dc42

Hi roboduet, thanks for your report.

A few comments:

Although FTP was nice to have, you can upload gcode files through the web interface, and edit config.g in the web interface. It's on my list to allow editing of bed.g in the web interface too, but in the mean time you can edit a copy on your PC and upload it through the web interface.
Your page load time is much longer than usual. Mine is 10 seconds in Chrome from start to connected. Also your file upload speed is much lower. My guess is that you have a poor WiFi connection. Is the Duet WiFi a long way from your router?
Is the M84 issue reproducible? I can't test it here right now because I am running experimental firmware that isn't quite right yet.
I've taken action to correct the M350 config line in future shipments. Omitting the Z parameter in this instance doesn't matter because it defaults to x16 with interpolation anyway.

roboduet

Hi, David!

It seems that I'm the only who missing FTP, never seen any messages regarding FTP from other users. So I will try to get used to this option (uploading and editing via http).

About M84 - yes, I'm able to reproduce this. I'm using 1.14beta1 firmware. Here is sample logfile (from bottom to top), please take attention to 8-second delay between G28 command and this two error messages:

[[language]]
10:25:46 M122
Diagnostics
Used output buffers: 2 of 32 (4 max)
Platform Diagnostics:
Memory usage:
Program static ram used: 13040
Dynamic ram used: 59968
Recycled dynamic ram: 720
Current stack ram used: 2728
Maximum stack ram used: 3552
Never used ram: 53792
Last reset 00:01:12 ago, cause: software
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
SD card interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 32.6, current 34.8, max 38.8
Supply voltage: min 11.8, current 12.0, max 12.2
Slowest main loop (seconds): 0.011997; fastest: 0.000103
Move Diagnostics:
MaxReps: 3, StepErrors: 0\. Underruns: 0
Heat Diagnostics:
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
GCodes Diagnostics:
Move available? no
Stack pointer: 0 of 5
macro is idle
http is ready with "M122"
telnet is idle
serial is idle
aux is idle
file is idle
Network Diagnostics:
WiFiServer is running
SPI underruns 0, overruns 0
Webserver Diagnostics:
HTTP sessions: 1 of 8
10:25:34 Attempt to move the head of a delta printer before homing the towers
Attempt to move the head of a delta printer before homing the towers
10:25:26 G28
10:25:24 M98 P/macros/Turn motors off
10:25:20 G28
10:24:37 Connection established!

About WiFi connections and upload speeds - I'm using Mikrotik RB2011UAS-2HnD 2.4GHz router located in half meter from board in direct visibility. Router stats shows me from -39 to -41 dBm RX/TX signal strength, 72Mbps Tx Rate, 54Mbps Rx Rate.

Also it seems that this is unrelated, but I had some bad experience with esp8266-based home automation project due to thread-blocking waiting for TCP ACK packets after each data packet sent out from esp chip. Windows-based hosts can delay TCP ACKs up to 200ms. They using Arduino core for ESP8266 WiFi chip (https://github.com/esp8266/Arduino). Seems like you using the same project for WiFi server firmware.

In any case I will try later to debug this issue using browser's developer console, use Wireshark to sniff TCP packet data and ACK delays and so on. Also I will try to use my older microSD card from Duet 0.6 board there upload speed was much faster.

dc42

Does your "/macros/Turn motors off" file contain anything else apart from the M84 command? Also, please post the contents of your homedelta.g file.

roboduet

Turn motors off file contents:

[[language]]
M84

Homedelta.g contents:

[[language]]
; Homing file for RepRapFirmware on Mini Kossel
G91							; use relative positioning
;******* Change F500 in the following line by F5000 when you are finished commissioning
;******* Change 320 in the following to a higher value if your Kossel has taller towers
G1 S1 X320 Y320 Z320 F3000	; move all carriages up 320mm, stopping at the endstops
G1 S2 X-3 Y-3 Z-3			; move all carriages down 3mm
G1 S1 X6 Y6 Z6 F250			; move carriages slowly up 6mm, stopping at the endstops
G1 Z-5 F2000				; down a few mm so that we can centre the head
G90							; back to absolute positioning
G1 X0 Y0 F2000				; centre the head and set a reasonable feed rate

Also it isn't macros-related. This happens even if I manually enter M84 followed by G28 gcode commands using DWC gcode console:

[[language]]
11:58:25 Attempt to move the head of a delta printer before homing the towers
Attempt to move the head of a delta printer before homing the towers
11:58:16 G28
11:58:15 M84
11:58:12 G28

roboduet

As for WiFi issues it seems for me that I was right then I said about TCP ACK delay problem with ESP8266 library that you used.

I used Wireshark to log packet data from and to ESP8266. I'm experiencing exactly the same problem with delayed TCP ACKs.

ESP8266 sends next TCP packet with small amount of data and blocks thread until TCP ACK received. On opposite side windows host receives next TCP packet with data, then waits for ~200 milliseconds and only then sends ACK packet on timeout because of TCP delayed acknowledgment

ESP8266 library problem description: https://github.com/esp8266/Arduino/issues/922

I can upload screenshot of Wireshark with this 200ms delays, but I don't understand how to attach picture to this post without uploading it to another sites.

drmpf created this issue in esp8266/Arduino

open Request Event Driven (non-blocking) WiFi socket API #922

dc42

I've just tested M84 followed by G28, and it always works for me. But I am running a beta of firmware 1.14.

Your log file shows a 9 second delay between sending the G28 and getting the error message. So I am guessing that the last G28 tried to home but failed, then the normal G1 command at the end of homedelta.g would provoke that message.

Are you by any chance using an unusual driver mapping, by including X Y Z or E parameters in some of your M569 commands? I think I may have spotted a bug in 1.13 and earlier in those circumstances.

roboduet

No, I'm not using non-standard driver mapping and so on. I have 3 drives connected to X, Y, Z and extruder drive connected to E0.

Can it be that M84 disables steppers and then G28 tries to home without enabling them again?

UPD: Maybe this can help: I'm using this firmware instead of 1.13b because of "effector dance": https://www.duet3d.com/forum/thread.php?pid=260#p260

dc42

It must be something like G28 not enabling the motors, or enabling them at the idle current instead of full current.

Please can you try version 1.14 beta 2 at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware-1.14b2.bin - but be ready to hit the power switch if anything goes wrong. I've only done one print with it so far.

roboduet

Thank you, 1.14b2 fixed M84+G28 bug for me.

Should I stay on 1.14b2 or revert firmware back to 1.14b1 until 1.14 released?

Have you seen my post about WiFi TCP ACKs?

dc42

I have just found a big in 1.14b2, it sets the wrong motor currents. So please revert to 1.14b1 until I have tested 1.14b3.

roboduet

Oh… I'm printing now with 1.14b2 and my motors are very hot. Is it possible to change currents without stopping print?

dc42

I did see your comment about TCP ACKs. I made some substantial changes to the Arduino ESP8266 http server code, pending the complete rewrite that I mean to do, to get a decent performance out of it. The underlying TCP/IP stack is Lwip, the same as we use on the wired Duet. So I don't think there is an issue with delayed ACKs, but it will be interesting to see what your Wireshark trace reveals.

roboduet

About ACK delays: 192.168.0.2 is my windows7 pc, connected by ethernet directly to my router. 192.168.0.28 is DuetWiFi beta board, connected to the same router.
I added "Delta time" column - it's time difference between this and previous packet. As you can see, windows delays sending ACK's up to 200 milliseconds almost after every packet received from duet.

roboduet

File upload process:

roboduet

Example of Wireshark logs for the same main page (GET /) for Replikeo's Duet 0.6 with 1.09r-dc42 firmware. No delays at all. Board connected to the same router as DuetWiFi. I'm using the same W7 PC.

DWC loads very fast.

dc42

It does appear to be the case that the Duet WiFi is waiting to receive the ACK for a packet before it sends the next one. Whereas on the Duet, it's quite happy to send two packets without waiting for the first one to be acknowledged. Perhaps Lwip has been configured differently.

One of the items on my firmware list is to do a total rewrite of the web server and its interface to Lwip. I'll probably base it on the code we use in the wired Duet. I'll look at the effect of delayed ACKs when I do that.

roboduet

David, is the source code for the Duet's WiFi module (DuetWiFiServer.bin) available for download?

dc42

The code is in my github repos CoreESP8266 and DuetWiFiServer. But I don't have it building correctly under Eclipse yet

roboduet

Thank you for making your source code freely available : )

I'm not very familiar with ESP8266 programming, but it seems for me that call stack looks very close to this:

Web Server calls [c]RepRapWebServer::send()[/c] to send page contents to connected client
Function above calls [c]RepRapWebServer::sendContent()[/c]
Function above calls [c]WiFiClient::write()[/c]
And function above calls [c]ClientContext::write()[/c]. This function uses [c]delay()[/c] call to wait for TCP ACK received:

[[language]]
				if (last || will_send == room)
				{
					DEBUGV(":wr\r\n");
					tcp_output( _pcb );
					_send_waiting = true;
					delay(5000); // max send timeout
					_send_waiting = false;
					DEBUGV(":ww\r\n");
				}

There is a lot of complains about this behavior as I said before:

https://github.com/esp8266/Arduino/issues/922
https://github.com/esp8266/Arduino/issues/1027
https://github.com/esp8266/Arduino/issues/1430
https://github.com/esp8266/Arduino/issues/1577

And so on.

drmpf created this issue in esp8266/Arduino

open Request Event Driven (non-blocking) WiFi socket API #922

rogerclarkmelbourne created this issue in esp8266/Arduino

closed Slow performance of FSBrowser on Chrome and Firefox #1027

nouser2013 created this issue in esp8266/Arduino

closed Again: TCP server performance completely unuseful #1430

nouser2013 created this issue in esp8266/Arduino

closed Tracking down that darn "delayed ACK" (200ms) bug... #1577

GBCues

It is a little known fallacy with WiFi that a stronger signal always makes a better connection.
Try tuning your Access Point down so that your Duet only sees -60 to -72. What happens is that the AP is "shouting" so loud that it can't "hear" the Duet talking back. This is a common problem in business WiFi with Apple products. The Apple products are designed with a low output strength to conserve battery strength.
This is an easy fix and may explain why you and DC42 are not seeing the same behavior.
Of course, it may not, but it's worth a try.