Problem with networking and DWC
-
@Phaedrux
Well, here is what I did: I gave the command M552 P0.0.0.0, and got an ok. I gave the command M552, and it came back with the report that the IP address was 0.0.0.0. If I understand how it's supposed to work, that should put the board in DHCP mode.Do I have to do something else to actually trigger the DHCP process, like a specific M command? I left it in that mode for at least 30 minutes, then did M552 again, but nothing had changed.
I didn't power cycle the board because I'm assuming the original IP it says it had (192.168.1.14) was coded in the config.g file, and if I power cycled, then that would be reasserted.
I guess I will go ahead and take the firmware to 2.05.1 for now, and then consider moving to 3.x.x soon. I need to have a better idea of how to prepare for a major change like from 2 to 3.
As for static IPs and headaches, yes I know what you mean. I have had good luck managing this small network with a combination of static & dynamic addresses. My general rule is if it's nailed down, screwed down, or to heavy to move, it gets a static IP. If it's mobile (especially mobile enough to go visit other networks :), then it gets a dynamic address.
-
@bjackson said in Problem with networking and DWC:
M552 P0.0.0.0, and got an ok. I gave the command M552, and it came back with the report that the IP address was 0.0.0.0. If I understand how it's supposed to work, that should put the board in DHCP mode.
Missing S1 and P0.0.0.0 is not needed unless you've previously assigned another address.
-
Ah yes. Well I issued M552 S1 P192.168.1.102. It came back and told me the network was enabled, and IP addresses (both configured and actual) were 192.168.1.102.
I tried to ping the printer from the computer, but no replies from the printer. I'm assuming that there is not a way to ping using the printer while interacting with the USB connection?
Other than try the firmware update, I don't know where to turn. This all seems straightforward enough, and should "just work". When it does not, I have to start suspecting hardware. Maybe it's just something with that little ethernet daughter board plugged onto the mainboard. I guess I could try another one of those perhaps?
-
On a fresh boot M552 S1 will enable networking and assume DHCP and should grab an address. Have you tried without the P.0.0.0.0 yet?
-
@bjackson said in Problem with networking and DWC:
Maybe it's just something with that little ethernet daughter board plugged onto the mainboard.
You could try reseating it.
Try a different cable? Different port on the router?
Straight connection to the PC without the router? If you do that and assign each an IP address you should be able to communicate. -
I carefully removed, inspected, and re-seated the ethernet daughterboard. No change. Everything looked fine mechanically.
I eliminated the router and connected the printer to the computer directly with a brand new and different ethernet cable. At that time, both devices had static IP addresses. The printer reported it was at .14, and the computer .101.
Pings still fail, and nothing come up when I point a browser there.
Everything you can see by visual inspection seems fine. Jacks & plugs engaging properly, link lights on both end lighting up. Even with the direct PC to printer connection, I do see occasional flashes of the activity lights on both devices, but what I see there does not seem to correlate with anything I'm actually doing (like executing a ping command).
I get the feeling that there's no actual network traffic happening to or from the printer. Without any actual connectivity, then the DHCP process can't work, and pings would of course fail.
This still makes me worry about hardware failure.
-
@bearer said in Problem with networking and DWC:
just put the firmware binary in the /sys folder of the SD card and run M997
I went to here: https://github.com/Duet3D/RepRapFirmware/releases/tag/2.05.1
From there I can download Duet2Firmware-2.05.1.zip
When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".
If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?
If I have that right, then I'll try it to see if it has any impact on the networking issue. Now, I think I'm understanding the the board I have is capable of running later versions (3.x.x) of the firmware, but getting from 2.05.1 to that is not quite so simple as getting to 2.05.1 was from where I started.
-
@bjackson said in Problem with networking and DWC:
When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".
If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?Correct.
-
@bjackson said in Problem with networking and DWC:
I do see occasional flashes of the activity lights on both devices, but what I see there does not seem to correlate with anything I'm actually doing (like executing a ping command).
would you be able to install wireshark on your computer and run it when the board is connected directly with a network cable to the computer?
the flashes could be compute doing regular broadcasts or the duet trying to obtain a dhcp lease, wireshark shoud be able to show you which.
@bjackson said in Problem with networking and DWC:
When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".
If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?Yes, that'll take care of the RepRapFirmware. To upgrade to 3.1.1 you'll need to repeat the steps with the adittion of getting both Duet2CombinedIAP.bin and Duet2CombinedFirmware.bin from of Duet2and3Firmware-3.0.zip and Duet2and3Firmware-3.1.1.zip., and run
M997after each set of files. (the extra steps compared to 2.05.1 is you need to first update to 3.0.0 and the inclusion of the Duet2CombinedIAP.bin file)Then to finish it off you should update the web interface by getting all the files from DuetWebControl-SD-3.1.1.zip and put into the /www directory on the SD card.
-
So far, I've been unable to get the board from 2.03 to 2.05.1. I copied three files from the software repository to the sys folder on the SD card. They were:
Duet2CombinedFirmware.bin
DuetWiFiServer.bin
iap4e.binPut the card back, powered up, ran M997 S0:1
I get the warning that the serial interface will be shutdown for a firmware upgrade, and that I should check back in 30 seconds. I gave it the time, and then gave the M115 command to see if the firmware level had changed. It still reports 2.03. Also tried a reset to see if that helped, but it did not.
Also, no progress so far on getting the networking to function. I really don't expect a minor firmware update to fix it, but I wanted to at least get started advancing the firmware.
-
Odd that the firmware didn't succeed.
Did you place those files in the /sys folder or the root? It should be in the /sys folder. Those files would already exist in the /sys folder for the current 2.03 version, so if you didn't replace them, when you sent the command to update, it may have just been using the same 2.03 version to flash.
DuetWifiServer.bin isn't needed as you have an ethernet board but it being there shouldn't matter.
Can you try one more time on the firmware update using M997 S0 only? The S0:1 would be for the main firmware and wifi firmware.
Can you list the contents of the /sys folder? Perhaps you're missing a different iap file.
On the networking front, wireshark would be a good test at this point.
-
On the matter of firmware:
OK, sure. Here's what's in the sys folder:
bed.g cancel.g config.g Duet2CombinedFirmware.bin, iap4s.bin
DuetWiFiServer.bin, homedelta.g iap4e.bin pause.g
resume.g sleep.g stop.g test1log.txt test2log.txt
test3log.txt test4log.txt tfree0.g tpost0.g and tpre0.gBTW, here is what's actually in test3.log.txt:
2020-05-21 14:46:40 Event logging started
2020-05-21 14:46:40 HTTP client 192.168.1.134 disconnected
2020-05-21 14:46:44 HTTP client 192.168.1.134 login succeeded
2020-05-21 14:47:14 Event logging stoppedThat seems to suggest that in testing it did communicate with a host that was at .134
I re-ran the firmware update command, this time with only the S0 after the M997. It still comes back stuck at 2.03 for some reason. I wonder if I really have the right content in the firmware binary. The file is named Duet2CombinedFirmware.bin, and reports a time stamp of 02/09/2020 @ 05:25. The files is 411,236 bytes, and 413,696 on disk.
On the matter of networking:
I got a different computer (just in case in some wild way that mattered) and continued testing. I installed Wireshark, fired it up, and executed "ping 192.168.1.14". That put some content in the Wireshark display, but I didn't see a single thing in the packet capture that was sourced from the computer. What I saw was a ARP request saying "Who has 192.168.1.14", but nobody replied.I have emailed Filastruder and asked for an RMA, starting with the little ethernet daughter board. I feel like I really need to try to do something to prove or eliminate hardware failure as a possibility.
-
Just to be sure you could download this one and place it in /sys and give it one more try.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2CombinedFirmware.bin
And just in case, grab these two iap files and place them in /sys as well, over write what you have in there already.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.03/iap4e.bin
https://github.com/Duet3D/RepRapFirmware/releases/download/2.03/iap4s.bin
What device is .134?
-
@bjackson said in Problem with networking and DWC:
I have emailed Filastruder and asked for an RMA, starting with the little ethernet daughter board. I feel like I really need to try to do something to prove or eliminate hardware failure as a possibility.
If we can't get it figured out, yes we will get it exchanged. It's just very rare for an ethernet to fail to connect for hardware reasons, though not impossible.
Could you provide some close up photos of the module and board area?
-
I obtained those three files and put them in the /sys folder, overwriting whatever I might have had with the same names. It still comes back from M115 reporting no change in the firmware version. After it recovered from the supposed firmware update, I checked, then I powered down the board, re-energized it again, and checked again. Still no change.
BTW, at this time, I don't have the printer power supply on. The board is being powered via USB. I presume that's enough power available to run the ethernet too?
As for device .134, I can only guess. I did not create those testlog files, but I assume somebody did who was doing final QC on the equipment before releasing it for distribution. I would assume it was a computer they used to test network connectivity to the board. It seems to say that it worked at one time.
I have attached a couple of photos. I even got one that actually caught the green activity light on the ethernet jack on for a quick flash. You can barely make out the orange glow from the link light on the other side of the plug retainer.
)
-
@bjackson said in Problem with networking and DWC:
The board is being powered via USB. I presume that's enough power available to run the ethernet too?
Normally it would be. Perhaps your supply can't keep up? Have you tried applying VIN yet?
@bjackson said in Problem with networking and DWC:
I assume somebody did who was doing final QC on the equipment before releasing it for distribution.
Yes, of course. I was being dense.
-
It was also suggested to me by someone far more on the ball than me that there might be an issue with auto negotiation, so see if your router/switch has the option of forcing the link to 100 full duplex.
-
Have you tried applying VIN yet?
Yes, I did try that. That doesn't change the behavior I'm seeing. The computer who's USB port is powering the board for these tests is a very standard Dell Optiplex 755 desktop machine.
I left things up over night and looked again at the packets that Wireshark had captured. All I'm seeing is IPv4 and IPv6 packets coming from the computer, and nothing coming from the Duet.
The auto-negotiation issue was considered. Right now, I'm using the super simple test environment of the computer connected to the Duet board with an ethernet cable. The router is not involved currently.
I went into the speed/duplex settings for the network card on the computer and experimentally set it to 100 half, and 100 full. Those choices did not work, but in fact made the error messages seen when trying the ping command to be more severe
I put it back to Auto. -
@bjackson Can you try the Duet again directly connected to your PC? Assuming the PC isn't connected to any other network, you only need to set the ethernet adaptor's IP address and subnet mask, and the Duets IP address and subnet mask. If the PC is connected to another network through another adaptor (WiFi or wired), you just need to make the Duet/PC network sufficiently different. See https://duet3d.dozuki.com/Wiki/Setting_up_networking_on_Duet#Section_Wired_direct_connection for full details.
Are you actually editing the config.g with the new settings, or typing them in through a serial console (eg YAT) over USB? The settings you used in your original post come from the standard SD card contents: https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/sys/config.g
I can't remember if changing network settings take immediate effect, or if it's better to disable the network, change the settings, then enable network. But it may be worth trying in this order.
Finally, check the SD card has a www folder, which should contain the files for the Duet Web Console (DWC). See here for the folder structure and contents: https://duet3d.dozuki.com/Wiki/SD_Card#Section_Creating_the_file_structure
Ian
-
@bjackson reading down from the top it looks like you have had the Duet Ethernet connect directly to you laptop by a network cable and both configured with 192.158.1.x IP addresses?
If you then connect in YAT and send:
M552 S0 (to disable the network)
then
M552 P192.168.1.14 S1 (to enable the network and set a fixed IP)The you should be able to pin 192.168.1.14 from your PC
If that does not work then please use this thread as a warranty replacement authorisation.
