Hey David, not sure what Rommie means, but I have similar experience with the latest stable.

Also when the thing doesn't work, it responds to pings and immediately closes telnet connections, so I have to hook up to USB to restart network.

You probably need to read instruction to upgrade from 1.18 — https://duet3d.com/wiki/Upgrading_to_DuetWiFiFirmware_1.19

Don't worry about not having the server, it was in the DuetWiFiServer.bin before, so you just need to create it. And you don't need leading [c]/[/c], it only means that the [c]www[/c] directory is on the top level of your sd card filesystem. So I guess in windows that would be [c]<drive-letter>:\www[/c]

P.S. Oh my, the post is old, but everyone started to answer after I did and finished before me ;-)</drive-letter>

Honestly, I haven't used ftp for years, so I don't remember all the details, but I think the [c]Unknown command[/c] may have to do with the full command [c]ls[/c] or [c]dir[/c] translates to (by the client). For instance, I have an habit of entering [c]ls -l[/c] even though I know I shouldn't. And after I do that, pretty much nothing works

[[language]]
ftp> ls -l
---> PASV
---> LIST -l
Unknown command.
ftp> ls
---> PASV
Unknown command.
---> PORT 192,168,4,14,230,94
Unknown command.
---> LIST

@chrishamm:

What board are you using and can you confirm that this bug is still present in David's new 1.19 release?

You can update the web interface by uploading the DWC zip file on the Settings page too. Recent DWC versions automatically unpack and upload the compressed files.

Thanks for the hint, I had no idea you can upload zip-file. But at any rate, I did solve it originally by being persistent and I had a backup plan of taking out sd card, but I do think the bug may need attention. And yes, I can confirm it's still present in 1.19, except for I didn't have enough patience to finally upload over ftp this time and fell back to uploading .zip file (thanks again). Though I did have uploads of various size, language.xml.gz is 62126, I had 60448 and 59576 uploads instead. My board is according to DWC "Duet WiFi 1.0". The rest of components are all "1.19". If there's more detailed information about the board available somewhere, let me know where to find it. It's relatively early board, I don't remember exact days, but not experimental or something.

I also tried turning debugging on (M111 S1), I suspected maybe some error accessing sd card or some such, but nothing was obviously wrong on the wire.

Let me know if I can be of more help diagnosing it.

I've just decided to update my DWC. And I normally use ftp to update DWC, because I'm too lazy to take out sd card. Previously I had no problems doing that, but today I experienced this:

ftp> put language.xml.gz
local: language.xml.gz remote: language.xml.gz
227 Entering Passive Mode (192,168,4,25,17,30)
150 OK to send data.
100% |*********************************************************************************************************************| 62126      548.59 MiB/s    00:00 ETA
226 Transfer complete.
62126 bytes sent in 00:00 (391.45 KiB/s)
ftp> ls
227 Entering Passive Mode (192,168,4,25,137,166)
150 Here comes the directory listing.
drw-rw-rw- 1 ftp ftp             0 May 30 2017 css
drw-rw-rw- 1 ftp ftp             0 May 30 2017 fonts
drw-rw-rw- 1 ftp ftp             0 May 30 2017 js
-rw-rw-rw- 1 ftp ftp         16909 Aug 15 2017 reprap.htm.gz
-rw-rw-rw- 1 ftp ftp           532 Jul 21 2017 html404.htm
-rw-rw-rw- 1 ftp ftp          5275 Jul 21 2017 favicon.ico.gz
-rw-rw-rw- 1 ftp ftp         60448 Aug 15 2017 language.xml.gz
226 Transfer complete.
ftp> put language.xml.gz
local: language.xml.gz remote: language.xml.gz
227 Entering Passive Mode (192,168,4,25,194,26)
150 OK to send data.
100% |*********************************************************************************************************************| 62126      564.26 MiB/s    00:00 ETA
226 Transfer complete.
62126 bytes sent in 00:00 (430.58 KiB/s)
ftp> ls
227 Entering Passive Mode (192,168,4,25,194,32)
150 Here comes the directory listing.
drw-rw-rw- 1 ftp ftp             0 May 30 2017 css
drw-rw-rw- 1 ftp ftp             0 May 30 2017 fonts
drw-rw-rw- 1 ftp ftp             0 May 30 2017 js
-rw-rw-rw- 1 ftp ftp         16909 Aug 15 2017 reprap.htm.gz
-rw-rw-rw- 1 ftp ftp           532 Jul 21 2017 html404.htm
-rw-rw-rw- 1 ftp ftp          5275 Jul 21 2017 favicon.ico.gz
-rw-rw-rw- 1 ftp ftp         60448 Aug 15 2017 language.xml.gz
226 Transfer complete.
ftp> put language.xml.gz
local: language.xml.gz remote: language.xml.gz
227 Entering Passive Mode (192,168,4,25,29,173)
150 OK to send data.
100% |*********************************************************************************************************************| 62126      510.75 MiB/s    00:00 ETA
226 Transfer complete.
62126 bytes sent in 00:00 (419.22 KiB/s)
ftp> ls
227 Entering Passive Mode (192,168,4,25,34,18)
150 Here comes the directory listing.
drw-rw-rw- 1 ftp ftp             0 May 30 2017 css
drw-rw-rw- 1 ftp ftp             0 May 30 2017 fonts
drw-rw-rw- 1 ftp ftp             0 May 30 2017 js
-rw-rw-rw- 1 ftp ftp         16909 Aug 15 2017 reprap.htm.gz
-rw-rw-rw- 1 ftp ftp           532 Jul 21 2017 html404.htm
-rw-rw-rw- 1 ftp ftp          5275 Jul 21 2017 favicon.ico.gz
-rw-rw-rw- 1 ftp ftp         62126 Aug 15 2017 language.xml.gz
226 Transfer complete.
ftp>

The file uploaded was shorter than the one I tried to upload. After a few attempts, though, it succeeded, which is scary. Admittedly, I first updated DWC and only now going to update Firmware, so this happened with 1.19RC1. So, if this is something known to be fixed, disregard it, otherwise it looks like a somewhat scary bug…

@Biggsis:

And another thing: I am using Interface Version 1.19 RC 1 but I liked the old BUTTON for "Print" a lot more than now having to open a context menu and select it from there.

Just click the filename.

This is not likely to be of any help, but my experience with bossa thing and duet 0.8.5 was very painful (Is that samba thing just UI for Bossa or completely different software?). It didn't work for me with 1. os x on macbook pro, 2. linux on raspberry pi, 3. linux on HP notebook, 4. windows on HP notebook. For various reasons, but I don't remember the details. It did work however with windows in the VMWare VM on the macbook pro… What I'm trying to say is that it seems to be very fragile…

BTW, the wiki page about unused pins https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins mentions M206 as a command to disable fan, which, I believe, is M106.

@dc42:

P3 was never officially supported because it is the I2C Data pin, now used to communicate with Duet expansion boards. Try another pin. For example, P60 = CS5 = physical pin 50 on the expansion connector.

P60 doesn't seem to do anything to CS5, though P61 does affect E3_STOP, so I'm fine.

@dc42:

P3 was never officially supported because it is the I2C Data pin, now used to communicate with Duet expansion boards. Try another pin. For example, P60 = CS5 = physical pin 50 on the expansion connector.

Thanks! That means having to remove bed, but at least I know why now

I tried to find what pins are officially supported, but IIRC all I found was "temporary" 0xff bitmask in "#if 1" block or something like that