DuetWIFI migration
-
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.
-
Here's the IR Probe mount I made for the TrickLaser MetalMax effector along with my custom water cooled E3D V6 hotend and volcano. The clearances look closer in the photos, I'll put Kapton tape on the backside of the board t be safe but I think I'm ok. The mounting system can slide up and down (slots in the printed red mount) and forward back (a slot in the mounting ear on the red mount) so I can fine adjust the probe position.
Next step is to wire it up to the Duet WiFi and get it running.
-
It looks like you could trim the component wire stubs on the back of the board a little more.
One concern I have with that cantilevered sensor mount is that the plastic part only needs to soften and warp very slightly to change the relative heights of the sensor and the nozzle.
-
Thanks David, yes I did that and then Kapton tape. I'l keep an eye on the plastic part. It is mounted to aluminum - a big heat sink and it is very far away from the heater. Worse case I'll machine one in aluminum but I wanted to try this out quickly.
-
David, I seem to be missing something trying to setup the IR probe. I followed the instructions on your blog. That all went well. https://miscsolutions.wordpress.com/mini-height-sensor-board/
When I get to the part to test and configure the probe I do as you say:
heat the nozzle (and bed)
home
lower the head until the nozzle touches the bed (paper test)
issue G92 Z0 (and I see Z set to 0 in DWC)
raise head 5mm
issue G30 S1
the Z value I read off in DWC is 1.0mmI use this value to update my config.g:
M558 P1 X0 Y0 Z0 H5 F500 T12000
G31 P400 Z1.0And reload config.g when asked.
Now, I home and run auto calibrate. When done, it seems like my Z=0 is set about 1mm above the bed. What am I missing?
FYI: bed is PrintBite
-
Micheal, it's G30 S-1 you need to run to measuring the trigger height, not G30 S1.
-
Thanks David! Literally, in my browser looking at https://miscsolutions.wordpress.com/mini-height-sensor-board/ I see:
define that position as Z=0. Raise the head 5mm and remove the paper. Then send G30 S-
1 to probe the bed at that point without adjusting the Z height setting. Read off the Z
height and use that value for the Z parameter in your G31 command in config.g. PleaseI guess my mind saw the "-" and figured it was a continuation to the next line.
-
Thanks for pointing this out. I just checked, and I see exactly the same. I'll re-word the paragraph to prevent the text wrapping at that point. [Edit: I just did that.]
-
Minor thing but those of us with bifocals appreciate it!
Things are working well now. Starting to do some more complicated printing. So far so good. The steppers are much much quieter.
