Problem with networking and DWC
-
@bjackson said in Problem with networking and DWC:
All symptoms are the same regardless of whether the gateway is set to .254 or .255
.255 is the broadcast address, so you'll have to stick with .254 for a gateway
what is missing is which network are you trying to connect from? if a network different than 192.168.1.0/24 I'm not sure the duet would work unless you ran NAT on the 192.168.1.254 gateway
board should respond to ping if everything is working properly.
i doubt updating the firmware will have any effect on the issue, but as you'll want to update to at least 2.05.1 you might as well; from 2.03 its just put the firmware binary in the
/sysfolder of the SD card and runM997can you have your router ping the Duet to rule out any issues with routing to/from the your client computer?
-
The bench setup is quite simple. It's a Netgear SOHO router with a public IP on the WAN port, and the two devices (the Duet board, and the computer) plugged into LAN ports. The computer is getting it's address by DHCP, and it currently resides at 192.168.1.100.
If things were working as hoped, I should be easily able to ping the .14 host from the .100 host. There is no way to starting pings from the router. The computer at .100 is getting out on the Internet just fine, so it's talking to the router and beyond.
I tried to get the Duet board to use DHCP as well, but I never saw that actually work. If it did, the board would probably be given the .101 address.
When this is all working, a static address is what is preferred.
It sounds like from what you said that the firmware in the board right now is not awfully old. Since I'm new to this board, I'd really prefer not to mess around trying to update firmware because I might brick something. Better to wait until I'm more familiar and confident with the hardware.
Are there any hardware jumpers someplace that I need to look at? With this thing "almost working", with the link & activity lights behaving normally and all, I also have to consider the chance that I just got a bad board.
-
@bearer
One other thing to mention:When I connect via USB using YAT, besides the firmware info line, I also get:
Executing config.g...Error: Bad command; FOR TESTING ONLY! Use https:/configurator/.reprapfirmware.org/ to generate configuration
Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is pr
Now all that my be normal enough insofar as I've done absolutely nothing yet to try and configure things for the printer. I have never yet even touched config.g
In fact, nothing is connected to the board yet except the USB cable and the ethernet cable.
-
The bench setup is quite simple.
oh, right "everything" is on the same router and subnet, sounded more complex, my bad!
indeed the .100 host should be able to connect to the .14 host; you shouldn't have to specify gateway on the duet.
@bjackson said in Problem with networking and DWC:
because I might brick something.
nah, worst case scenario you have to use bossa or sam-ba to recover over usb, but the chip has bootloader in ROM so unless you wire something wrong you can't brick the board.
Are there any hardware jumpers someplace that I need to look at?
no, the there is just he 5v enable and erase jumper, the latter you don't use unless you need to recover the firmware the first is in the correct position if the board works from Vin.
Bad command; FOR TESTING ONLY!
that just means you haven't replaced the config.g file on the sd card
/sys/config.gto be exact. it contains the factory default config used in testing the board, warning about heater 0 is because of the same.until you do go to https://configtool.reprapfirmware.org/ to create your own config you could strip out all but
M552 S1 P192.168.1.14from the config.g file (or justM552 S1if you want to try DHCP) -
If you let it use DHCP does it show up on the router? Ideally you would leave the duet in DHCP and then reserve the IP at the router end. Setting static IPs leads to headaches down the road.
Updating the firmware is nothing to fear generally. 2.03 is rather old at this point. 2.05.1 is the last in the line of RRF2 and is a good place to get accustomed to the firmware, but RRF3 is really the way to go due to the added flexibility and the fact that is where the development is now, so don't stay on old firmware too long, you'll just learn things you'll need to forget.
-
@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.
)
