FINAL (I hope) RRF 1.20 release candidate 4 and DWS 1.20RC1

okercho

Hi, just a cosmetic thing I've found (I just installed the RC4, so I didn't test prints yet), Z probe is being marked as "Type:
Unknown (8)" when P8 is selected in M558.

Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.20RC4 (2017-12-20)
WiFi Server Version: 1.20b10
Web Interface Version: 1.20-RC3

Oh, BTW, I installed it in this way:

Extracted SD, copied Web files
Turn printer on, upload firmware in settings. Choosed yes (I read after clicking that I should select NO)
Printer restarted perfectly.Wifi worked fine. Uploaded and upgraded wifi server. Selected yes when asked
Wifi didn't come back. Switched off and on printer by unplugging it
Wifi came back (and seems to be stable so far)

Regards!

str8up

Should the selections under Settings / User interface and List items remain after a printer on/off restart. Mine is reverting back to default.

dc42

@okercho:

Hi, just a cosmetic thing I've found (I just installed the RC4, so I didn't test prints yet), Z probe is being marked as "Type:
Unknown (8)" when P8 is selected in M558.

Thanks. DWC doesn't yet know about new Z probe types 7 and 8. I've alerted chrishamm.

totalitarian

Just to confirm the issue above, uploaded both files via DWC (wifi server and firmware) needed to power cycle the machine to get wifi back on.

dc42

Thanks. Perhaps this is an alternative to installing the WiFi firmware twice, which is what I did when it didn't work first time.

okercho

Hi there,

I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.

I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120

Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)

I still have the printer on, in case you want me to execute something on it.

Gosu

this version made the wifi module much more stable i still get ocassional disconnects but im always able to reconnect

Thanks a lot

dc42

@okercho:

Hi there,

I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.

I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120

Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)

I still have the printer on, in case you want me to execute something on it.

Can you get a Wireshark trace of an attempt to to connect the browser?

dc42

@Gosu:

this version made the wifi module much more stable i still get ocassional disconnects but im always able to reconnect

Thanks a lot

Thanks for the feedback!

okercho

Here you have it: https://www.dropbox.com/s/9z1pxu1v7rl1pd5/DuetWifiFiltered.pcapng?dl=0

I've filtered by source or origin equal the Duet IP, and I've confirmed before that the MAC address is the duet one.

First you can see some errors
then a ping (requests and replies, so the duet is there)
then I tried a curl to http://DUET_IP, with no success (curl: (7) Failed to connect to 192.168.1.120 port 80: Operation timed out)
then I tried with the browser, with same results
Nmap still says port is filtered.

Do you want me to execute something else before rolling restart the duet?

Regards

@dc42:

@okercho:

Hi there,

I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.

I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120

Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)

I still have the printer on, in case you want me to execute something on it.

Can you get a Wireshark trace of an attempt to to connect the browser?

dc42

Thanks! Please can you connect via USB and get a M122 report. Then send M552 S0 followed by M552 S1 and see if you can connect after that, giving it time to connect to the AP. If not, send M552 S-1 followed by M552 S1 and see if that is any better.

That's all, so restart after that.

okercho

Here you have it: https://www.dropbox.com/s/w4j58dw8nk8a3lu/DuetLog.zip?dl=0

You will find 3 files:

DuetLog-20171222: Contains the M122 report
DuetLog-20171222-2: Execution of M552 S0 and M552 S1. After the S1 the web was accesible again… until I disconnected Pronterface to avoid the tons of "aux: M408 S0 R110" (clicking in disconnect), in that moment, web stopped working (but duet still answers pings)
DuetLog-20171222-3: Execution of M552 S-1 and M552 S1. After clicking in "Connect" again, web came back again... however, after the S-1 and S1, log reported "incorrect password" and wifi never came back, even with a roll restart (after the roll restart it keeps saying wrong password).

I had to execute M552 S0 and S1 through panel due, and then it came back.

Makes sense to you?

Regards

@dc42:

Thanks! Please can you connect via USB and get a M122 report. Then send M552 S0 followed by M552 S1 and see if you can connect after that, giving it time to connect to the AP. If not, send M552 S-1 followed by M552 S1 and see if that is any better.

That's all, so restart after that.

dc42

If you were getting those aux:M408 reports from Pronterface, then a M111 S1 command has been executed at some point to turn debugging on. That could be responsible for the network issues too. Next time you get these issues, try sending M111 from PanelDue to report the current debug state. If any debugging is turned on, send M111 S0 to turn it back off.

okercho

Ouch!

Yes, my bad… when I updated to the RC, I enabled debugging in the config file... I've disabled it now.

Thanks a lot!

@dc42:

If you were getting those aux:M408 reports from Pronterface, then a M111 S1 command has been executed at some point to turn debugging on. That could be responsible for the network issues too. Next time you get these issues, try sending M111 from PanelDue to report the current debug state. If any debugging is turned on, send M111 S0 to turn it back off.

KeeganB

Ok, I just updated to the latest RC's on all three. Lets see how it goes!