Moved from Duet 0.6 to DuetWiFi - first impressions

roboduet

Today I received package with beta-board and replaced my Duet 0.6 (by Replikeo).
I'm using Kossel Mini from builda3dprinter with David's 1.14beta1 firmware version because of terrible "effector dance" bug.
Board connected by thick copper wires to 12V 30A LED PSU, I'm using 2.5A 1.8uH 200 steps/rev Wantai 42BYGHW811 steppers.
Also I'm using David's IR probe.

Just first impressions:

Pros:

My printer now is VERY-VERY-VERY quiet with default 1/16 microstepping and 16x interpolation, I'm happy!
Moire pattern on the surface is much less visible then before.
I'm able to set higher current for my 2.5A-rated steppers (but they get hot and now I'm worry about MiniKossel's PLA corners).
Easy upgrade process (both hardware and software), just about ~30-40 minutes.
Now I'm able to connect all my fans and control them programmatically (incl. awesome thermostatic mode for hotend fan).
Ability to monitor voltages and temperatures. Now I'm know that voltage floats from 11.5 to 12.2 volts on the board side.
WiFi - less wires.

Cons:

My hotend cooler is very loud and now I'm hear sounds of play in traxxas rod ends, in planetary gearbox of extruder motor and so on.
Lack of FTP is very disappointing. I used FTP access all the time both for gcode upload and for editing configs and I was happy.
Lack of ethernet. WiFi is cool feature and I understand that CPU-hungry web server code can be moved to ESP8266, but I still prefer stable and predictable behavior of ethernet in my noisy environment.
DuetWebControl is loading very slowly both in Firefox and Chromium (also in mobile FF), up to 30-50 seconds to full load.
Upload speed to default (provided with beta board) SD card is only 192-195 KB/second on 12 MB file, haven't yet tried my older card from Duet 0.6 board.

Also just after disabling motors (M84) I'm not able to home printer again, it just shows me this two messages: "Attempt to move the head of a delta printer before homing the towers", after few minutes of standby I'm able to home printer again.

Also I want to notice that default configs lack of Z parameter in M350 X16 Y16 E16 I1 command.

UPD: also I noticed less deviation in autocalibration results. I don't know what happened but now deviation shows 0.024-0.027 (16 points, 3 factors - S3) instead of previous repeatable 0.03-0.05. It seems like just "effect of new board", but maybe better microstep positioning and higher stepper current.

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