New DuetEthernet connection problems
-
I got my new duet ethernet in the mail yesterday, and it worked great as soon as I swapped the SD card from the old one into the new one. However, after a few hours of tinkering I am getting this error constantly now. I am unable to connect for more than 10 or so seconds at a time, even with the AJAX error retries turned up to 10 or more. I suspect it isn't truly connecting because the tools, axes, and other details don't seem to load into DWC properly and I can't send any commands or upload files via the DWC file uploader. I can connect and run most functions over USB though.
× Request Timeout
The last HTTP request has timed out. Please make sure the connection between your device and the board is not interrupted.
My DWC version is 1.20 and my DuetEthernet version is 1.21 RC2
I've tried downgrading but I'm not sure if I have performed the process correctly. I just copied old backups of my SD card back onto a spare card. That didn't work. My last option was hooking up the previous DuetEthernet to see if it will connect with the same SD card, which also failed.Any suggestions on where to go from here?
-
If you want to go back, go to 1.19 which is the stable one.
Make a new SD card using the RepRap configurator. This will make sure that the G codes generated will be understood by the 1.19 release of RRFW. Backup your current SD card contents before doing this.
https://configurator.reprapfirmware.org/Use one of the fallback procedures outlined here to downgrade your Duet if the normal procedure fails:
https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Usual_procedure
-
Perhaps you have an IP address conflict on your network? You should be able to ping the IP address of the Duet when it is connected and the network interface is enabled, but not when it is disconnected.
A bad network cable is another possibility.
-
I have seen a similar behaviour of DuetEthernet. When the board starts, it is pretty stable for long periods of time but if a config.g change requires a reboot, usually it is no longer available for long periods of times (sometimes I just left it unattended for 15-20 minutes), not even replying to PINGs.
The setup used static IP, outside the range offered by the DHCP server, and the router reports no IP conflict (a MikroTik router). The cable is Gigabit capable and tested with many other devices over long periods of time. Also, the cable has not been even physically touched during these problems.
The board came with 1.19 and I have successfully upgraded it to 1.21RC2, but the problems remained the same.
Sending over USB M552 S0 followed by M552 S1, although ended up with success and I could see in the terminal that the IP was theoretically correctly configured, the board remained most of the time unresponsive.
During all these problems there was no operation running and I really haven't gone too much beyond trying to configure the board and doing some jogging.
-
Did you try pinging the Duet from the PC?
-
I have connected the printer over USB in order to find out its assigned IP address and I can send commands. I haven't pinged it from the pc though. Would that be just the command line ping? I haven't tried anything yet with the network cable unplugged. I'll swap out the cable and see if that has any affect. I'll also use the configurator to make sure I haven't made some strange mistake in my g-code config file. I'll check back in on Monday.
-
As a resume of everything that I have tested related to LAN connection issues that I have observed:
- It always happens after an automatic reboot requested by, for example, a change of the config.g file.
- When it happens, the board no longer replies to PING, although it is a static IP and the router doesn't warn of any conflicts (the board is set as 192.168.1.200, DHCP range is .160-.191, all devices are below .160 except for some starting with .250.
- Connecting over USB and issuing M552 S0 followed by M552 S1 doesn't really bring back the connectivity. After M552 S1 I always waiting for the confirmation of the IP.
- Most of the times connectivity is available again after 15-20 minutes of not touching the board.
- During all these tests there is no "mechanical" interference with the board (touching LAN cable, moving things around, trying to re-plug the cable etc.).
- Sometimes, after M552 S1, the board is briefly available for 10-15s, like getting to the list of files in the /sys directory, and dies again when trying to open one of them.
- LAN connector LEDs are properly active during all this time!
-
If connectivity is restored after 20 minutes, that sounds like either an issue with router or other network devices, or an intermittent fault on the Duet Ethernet. If you connect the Duet directly to a PC or laptop using an Ethernet cable (you may need to use a crossover cable), does it work reliably?
Do the LEDs on the Ethernet socket of the Duet behave normally?
-
I will do tomorrow this test. As my PCs all have Gigabit ports, crossover cables should not be needed, normally!
The LEDs behave normally, but those are pretty low level (physical layer!, not aware of IP related problems, if any). And that brings me to the next potential problem - what if the Ethernet adapter is not properly programmed with the IP and whatever is also needed? Is there a way to check? Does the firmware any checks before reporting the status after M552 S1?Just while writing this message I decided to remove the Ethernet adapter from the Dues and check for poor solder joints, none found so that is good news. But why is the outer shield of the RJ45 connector connected to pin signal no. 8? On my board there is a HanRun HR911105A RJ45 connector with magnetics. That connector is designed for 100Mbps connections and pin 8 is internally connected to ground through a 75Ohm resistor and a 1000pF capacitor. Connecting it to GND may have unexpected effects on a 1Gbps network (my entire network is wired for 1Gbps, using FTP cables, thus having huge GND loops!). While this a non-issue for 100Mbps network switches/routers, I wonder what do the user with complaints have in their networks! As a side note, tomorrow I will test with a simple UTP cable.
Just saw that this is the reference design for the WIZnet 5500 chip. I'm more used to Gigabit magnetics!
-
Just wanted to report back saying that I got everything running again in DWC 1.20 and DE firmware 1.21 RC2. I wiped the sys folder after backing it up and recreated my config.g file from scratch using the online tool. I must've done something strange in my configuration that caused it to no longer connect.
-
Not all network cables are equal…
While I had the issues with the DuetEthernet I tried using several cables from the same batch. All of them successfully used with Gigabit capable devices (PCs, laptops etc.) and showing full transfer speeds. Today I had to connect, after a very long period of time, a 10/100Mbps only device and, to my surprise, I had the same issues that I have observed with the Duet. So I have looked through the pile of junk that I have around and found several more devices with only 10/100Mbps networking and found the same problem.
Luckily I also found around a cable from a different batch and now all the networking problems are gone.
-
I'm glad you both solved the problems. I've never heard of cables working ai 1Gb/sec but not at 100Mb/sec before!
-
Do you want a couple of "samples"?
The Windows/Linux devices that I used for further tests always properly negotiated the IP address with the DHCP server but they could not get even one reply from the DNS. So things are way weirder than I could even imagine. Most probably they will end up being recycled so I don't waste precious time when testing/using other devices not capable of Gigabit.
-
if you are in the UK then a sample would be good; otherwise the postage cost will get silly.
-
Sorry for the delay, but I had two rather long days!
Unfortunately I'm just few thousands km to the East of UK so shipping is way more than what's worth paying for a set of poor network cables. But I'm mainly a radio guy (professionally doing things like software radio and related to that) so I have a little bit of equipment here. So I decided to get the big guns into the battle.
A quick frequency characteristic of the cables, good vs poor ones, showed rather poor behaviour at low frequencies for the unusable ones. As Gigabit PHYs are a lot more advanced than 10/100Mbps ones, I presume they were able to overcome the problem, just!
But poor frequency characteristic in the lower frequency range usually indicates a fault in the copper wires. After a few bending cycles here and there and the cracks in the copper turned into actual breaks and the cables are now, a few of them, unusable no matter the network type. Most probably it was a problem with the batch of cable from the manufacturer, but trying to deeply understand a 50EUR problem, spending several days, is beyond any commercial reasoning so the whole batch will go for recycling!
All I can say for sure is the outer jacket of the cable showed no signs of mechanical abuse, either by pinching or pulling, so it might have been a batch of cable that was "good enough" during the factory tests, but useless after bending it a couple of times.
P.S. It was the only time I have bought ready-made network cables!
-
Thanks for the update. I use flat cat6 network cables purchased inexpensively on ebay. No problems with them so far and they are very flexible.
-
I presume UTP and not FTP or STP!
-
Yes, UTP in particular these http://www.ebay.co.uk/cln/kenable_ltd/FLAT-CAT6-Gigabit-Network-Cables/89021312013.
-
As I do a lot of radio monitoring stuff (hardware, software) even my keyboard and mouse are wired. And UTP cables tend to be quite noisy so everything in here is FTP or STP. Unfortunately that comes with a lot more rigidity if keeping the costs within reasonable limits!
