DuetWIFI migration
-
Consider yourself luck Toddimus! It was a bit of a pain on non-windows (i.e. OS X) platforms to get set up properly.
-
I noticed a similar thing, but after the second try of re-uploading both the DuetWebControl.bin and DuetWiFiServer.bin and then running the M997 S1:2 and waiting for like 10 minutes (went to do something else and came back to it), it worked. I did a hard reboot of the Duet after the wait and then the web interface showed 1.11b-dc42.
I've tried everything I an think of and still no luck. Multiple re-uploads of DWC.bin and DWIFIS.bin and running M997, hard reboots, waiting, and still have the problem.
-
I noticed a similar thing, but after the second try of re-uploading both the DuetWebControl.bin and DuetWiFiServer.bin and then running the M997 S1:2 and waiting for like 10 minutes (went to do something else and came back to it), it worked. I did a hard reboot of the Duet after the wait and then the web interface showed 1.11b-dc42.
I've tried everything I an think of and still no luck. Multiple re-uploads of DWC.bin and DWIFIS.bin and running M997, hard reboots, waiting, and still have the problem.
Did you try knocking (or touching) on wood with your fingers crossed? That sometimes works for me.
-
Michael, please try the following:
1. Make sure that the M552 S1 line in config.g is commented out. If the WiFi module is not running the right firmware, it can make the main firmware unresponsive if you enable WiFi.
2. Install the new main firmware file DuetWiFiFirmware.bin. If the WiFi is not working, then I suggest you either use SAM-BA to do this, or copy it on to the SD card and send M997 S0 from a USB host program. You will need to reconnect the USB host program when the firmware update has completed. Then send M115 and check that the reported firmware version is 1.15-beta3.
3. Copy the new DuetWiFiServer.bin to the SD card if it isn't there already, and install it by sending M997 S1 from your USB host. After it reports success, send M552 S1 to enable WiFi. If it connects to your network successfully, it should reply with a connected message within a few seconds. Otherwise, after about 30 seconds it should reply with a message saying that it is running as an access point.
4. You can then try connecting via WiFi. If it doesn't work, then try re-installing DuetWebControl.bin by putting it on the SD card and sending M997 S2.
I believe I have covered all the firmware update procedures in the links at https://duet3d.com/wiki/Duet_Wifi_Wiki#Firmware, but please tell me if you think I have left anything out.
If you want to revert to previous versions, please note the following:
- The new DuetWebControl.bin should work with any versions of the main firmware and the wifi firmware
- The new main firmware 1.15beta3 works with both the original and the new DuetWiFiServer.bin
- The new DuetWiFiServer.bin will not work with main firmware prior to 1.15beta3.
HTH David
-
Thanks David. I've done everything up to step 4. I can connect but it constantly drops the connection within a few seconds. Once this happens, the web interface won't connect but I can run from paneldue. I'll go through your procedure verbatim from scratch. Can I use the .bin files on the CF that came with the card?
-
Yes you can use the .bin files that came with the SD card. What we do to program a new board is this:
-
use SAM-BA to put the main firmware on the board
-
connect Pronterface via USB (note that the M552 S1 command in config.g is commented out, so it doesn't try to start the wifi module)
-
send M503 to make sure the SD card is working
-
send M997 S1:2 to install both DuetWiFiServer and DuetWebControl
-
send M552 S1 to start WiFi
-
-
David,
So I started from scratch and followed the above to the letter EXCEPT I used the latest release you put on DropBox yesterday. I also made sure to disconnect USB and reboot the Duet between critical steps. My Pronterface log was clean:
[[language]] >>>M997 S1:2 SENDING:M997 S1:2 success Erasing 295248 bytes... Uploading file... 5% complete 10% complete 15% complete 20% complete 25% complete 30% complete 35% complete 40% complete 45% complete 50% complete 55% complete 60% complete 65% complete 70% complete 75% complete 80% complete 85% complete 90% complete 95% complete Upload successful Trying to connect at 460800 baud: success Erasing 3125248 bytes... Uploading file... 5% complete 10% complete 15% complete 20% complete 25% complete 30% complete 35% complete 40% complete 45% complete 50% complete 55% complete 60% complete 65% complete 70% complete 75% complete 80% complete 85% complete 90% complete 95% complete Upload successful >>>M552 S1 SENDING:M552 S1 WiFi server starting up DuetWiFiServer version 1.01 Flash size 4194304, free RAM 31512 bytes, WiFi Vcc 3.34V, host name: Maxie, reset reason: Turned on by main processor WiFi server connected to access point HackneyNet, IP=192.168.1.242 Upon success, I used an Incognito chrome browser so there was no cached cruft. It connected fine and I see that the firmware packages were updated:
Firmware Name: RepRapFirmware for Duet WiFi Firmware Version: 1.15-beta3 (2016-07-09) Web Interface Version: HTML: 1.11b-dc42, JS: 1.11b-dc42 Although it stayed connected a bit longer (30 seconds) I get the same AJAX communication error I've been getting:
Communication Error An AJAX error has been reported, so the current session has been terminated. Please check if your printer is still on and try to connect again. Error reason: timeout, retries 1 Once this happens I can't reconnect via the web interface, I get this:
Error Could not establish a connection to the Duet firmware! Please check your settings and try again. However, I can use PanelDue with no problems.
This is all very similar to the experiences I had helping test Christian Hammacher's DWC code earlier this year to eradicate the disconnect problems many of us were having.
–--
So my next step is to use the original binaries - I saw you posted on another thread about this. I'll also capture a network trace with wireshark. -
Ok, I've now started from scratch as per your post above David - installed the pre-production firmware via SAM-BA, etc. I then installed the pre-production DWC.bin and DWiFiS.bin. Pronterface reported all of this installed successfully. Once these were installed, I setup Wireshark to capture traffic to my Duet WiFi's ethernet address. I then enabled WiFi in Pronterface.
I then launched an Incognito chrome browser and connected. I verified that all the pre-production version numbers were displayed on Settings->General. I feel confident that I have successfully back-graded everything to the pre-production binaries. I then homed from DWC. It lasted longer but I got a timeout and was able to capture the entire episode from initial turning on the WiFi to the failure. Since we can't attach files here, here's a link to the Wireshark trace on my dropbox: https://db.tt/FcFk6ZiA
-
Note that when I capture network traces for my other Duets with external WiFi (TP-Link) I don't see any of the retransmissions and other issues seen in this trace. The printers sit next each other with very strong wifi signals to my router. I haven't had disconnects from any of the other 4 printers running earlier Duets with these TP-Links since helping Christian test his updates earlier this year that seem to have eradicated disconnect issues on that release.
-
An update, after letting the disconnected board sit for 5+ minutes I tried reconnecting (press the Connect button). It actually did connect but then disconnected within 15 seconds. I did not get a Wireshark trace but in the future I'll run Wireshark before any similar attempts.
-
Also if I turn off the WiFi server and re-enable it in Pronterface (M552 S0 / M552 S1), it recovers and allows me to reconnect (but then fails eventually again).
-
and here is my M122 dump after the above:
[[language]] SENDING:M122 Diagnostics Used output buffers: 1 of 32 (3 max) Platform Diagnostics: Memory usage: Program static ram used: -445744 Dynamic ram used: 57704 Recycled dynamic ram: 3016 Current stack ram used: 428696 Maximum stack ram used: 431780 Never used ram: 51548 Last reset 01:14:58 ago, cause: software Error status: 0 [ERROR] 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 Slowest main loop (seconds): 8.235451; fastest: 0.000000 Move Diagnostics: MaxReps: 3, StepErrors: 0\. Underruns: 0 Heat Diagnostics: Bed heater = 0, chamber heater = -1 GCodes Diagnostics: Move available? no Stack pointer: 0 of 5 macro is idle http is idle telnet is idle serial is ready with "M122" aux is idle file is idle Network Diagnostics: WiFiServer is running SPI underruns 0, overruns 0 Webserver Diagnostics: HTTP sessions: 0 of 8 -
Michael, thanks fort all the tests you did and for the Wireshark dump. The dump show thart there were no transmissions from the Duet after the last successful status request, except for the usual [RST,ACK] that closed the connection.
Please can you try again, but this time monitor the connected wireless devices in the status page of your wifi router. I need to see whether the Duet is still a connected device after the error occurs and you find you are unable to connect. You will probably need to press a Refresh button in your router's web interface to see the latest list of connected devices.
-
David, I posted this on another thread here but I think I discovered the problem was my network:
This is interesting, using some network monitoring tools and the admin console for my Verizon Quantum router I discovered that I had a few odd things going on on my network. Several devices which I could not identify were issuing a lot of packets and that seemed to be causing timeouts. Also, the Windows laptop that I VPN in into work was chewing up a lot of bandwidth. The Quantum router supports dual frequency but none of my devices were connecting the the 5GHz. So I created a new SSID for 5GHz and connect my lap worktop to it. Now, I haven't had a single disconnect in several hours from the Duet WiFi! And the Wireshark logs looks clean as a whistle.
However, to answer your question - after the disconnect, my router status page shows the Duet WiFi as disconnected. It was precisely because I was looking at the status page that led me to see the odd activity on my network as I worked through identifying each of the 28 devices connected! They add up quickly.
-
David, I have now updated to the latest package of files (1.15-b3 etc) and things are quite stable.
I aslo tested the DWC.bin that I built with the shell script I wrote and it works fine too. I think you can include it for further testing. I put a copy on my dropbox here: https://dl.dropboxusercontent.com/u/45673517/dwcspiffs.sh
cheers,
Michael -
I'm glad you solved it. I think I mentioned before in one of these threads that once the Duet becomes disconnected form the access point, it doesn't attempt to reconnect. That's why you had to stop and restart the wifi module in order to connect again. In the next release I'll add support for monitoring the connection status and attempt to re-connect if it becomes disconnected.
Thanks for the build script, I've added it t github.
-
Great, thanks David.
I'm commissioning one of your IR probes on this Rostock Max with the Duet WiFi. I can do head to head comparisons with the FSRs. But I've been chasing an issue with FSRs on this machine as I described in an email I sent a few days ago.
Like all things, there are tradeoffs. I like the simplicity of mounting FSRs and the fact that the nozzle tip is the probe, but the downside is the "force".
-
The important things to achieve when not using the nozzle as the probe are:
1. Reduce varying effector tilt with XY position as far as possible, because such tilt changes the relative heights of the nozzle and the probe. I now have a bulls eye spirit level mounted on the effector so that I can see any tilt.
2. Mount the probe as close to the nozzle as is safe and practical to do so, to minimise the effect of that tilt. That's why I made the IR sensor shallow enough to fit below the heatsink of an E3Dv6 hot end.
Probing with the nozzle itself has the advantage of not being affected by effector tilt - although effector tilt is a sign of geometrical errors that will cause calibration inaccuracies anyway. But I'm not sure I would want to probe my PEI-covered bed with a hot nozzle.
-
I'm almost done with my mount. I have a very non-standard setup with a CNCd effector and a modified E3D V6 that is water cooled and fitted with a Volcano. My mount is adjustable both up & down and in & out so I can dial in the position to optimize it. I'll post some photos once I have it complete.
Do you find the bulls eye spirit level is sensitive enough to show tilt?
-
The bulls eye spirit level was sensitive enough to reveal a tilt when the effector was close to one of the towers. The rods are accurately made to equal lengths, so I corrected it by rotating the carriage on the carriage truck.