Network Port Not Working
-
M552
Ethernet is enabled, configured IP address: 0.0.0.0, actual IP address: 0.0.0.0 -
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956BA-NA3TN-6J9D4-3SN6N-KB8AU Used output buffers: 1 of 40 (12 max) === RTOS === Static ram: 149788 Dynamic ram: 56004 of which 24 recycled Never used RAM 153016, free system stack 183 words Tasks: HEAT(blocked,296) CanReceiv(blocked,927) CanSender(blocked,371) CanClock(blocked,354) TMC(blocked,53) MAIN(running,1082) IDLE(ready,19) Owned mutexes: USB(MAIN) === Platform === Last reset 00:05:12 ago, cause: power up Last software reset at 2021-02-10 11:55, reason: User, GCodes spinning, available RAM 114712, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 34.0, current 34.8, max 35.1 Supply voltage: min 0.1, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 0.2, current 12.3, max 12.6, under voltage events: 0 Driver 0: position 0, standstill, reads 41307, writes 11 timeouts 0, SG min/max 0/0 Driver 1: position 0, standstill, reads 41307, writes 11 timeouts 0, SG min/max 0/0 Driver 2: position 0, standstill, reads 41307, writes 11 timeouts 0, SG min/max 0/0 Driver 3: position 0, standstill, reads 41307, writes 11 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 41308, writes 11 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 41308, writes 11 timeouts 0, SG min/max 0/0 Date/time: 1970-01-01 00:00:00 Slowest loop: 0.20ms; fastest: 0.07ms === Storage === Free file entries: 8 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by Trigger HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is ready with "M122" in state(s) 0 Aux is idle in state(s) 0 Trigger is doing "M116 P0" in state(s) 0 12 0, running macro Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.00ms; fastest: 5726623.00ms Responder states: HTTP sessions: 0 of 8 - Ethernet - State: enabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages queued 543, send timeouts 1223, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 48 ok -
When and where did you purchase the Duet 3?
-
@Phaedrux printedsolid.com on October 5th, 2020
-
and to be clear, it worked fine until about a week ago. I thought my issue was with the pi 4 so I spent a week trying to figure it out from that end, only to finally realize that it was the Duet 3 all along that was causing the issue
-
It does seem like your ethernet port has stopped functioning.
Please contact Printed Solid and initiate a warranty exchange. Include a link to this thread as authorization.
-
@Phaedrux thank you!
-
@Phaedrux I really hope that US retailers are being restocked, because Printed Solid doesn't have any Duet 3 6HCs in stock and can't replace my defective board until they receive more. My main printer is out of commission for an unknown period of time.
-
More coming all the time. Hopefully it's not a long wait. Sorry for the inconvenience.
-
Maybe some software that checks and controls ports (for example VPN, [employee monitoring software]proxy) closed this port for its needs?
-
@BorisVivienne said in Network Port Not Working:
Maybe some software that checks and controls ports (for example VPN, employee monitoring software, proxy) closed this port for its needs?
It wasn't working in both direct-connect and network-connect situations. This was not a firewall thing. I'm sure I could've gotten around it by running it in SBC mode, but I run my boards in standalone mode.
-
@Phaedrux In retrospect, I don't think there was anything wrong with my board at all. I haven't received the warranty replacement yet, but I bought a new board from a different reseller in the meantime to get my printer back up and running right away, with the intention of using the eventual warranty replacement in a new project.
Surprise! It didn't work in the exact same way, either... (using the SD card from the old board that I deemed "defective")
Spent hours diagnosing the issue, and the problem is a really bizarre thing. Having:
T0at the bottom of config.g causes the network port to not turn on. Commenting out that line fixes the issue. I don't get it, I have T0 at the end of ALL my config.g files for every printer I own (I currently have 4 Duet-based printers), and this is the only time it's ever caused an issue. I wouldn't even consciously add T0 myself, but it's one of the RRF Configurator options, so it ended up in there at some point and got carried over into all my configurations. In this case, it's appropriate because it's a dual extruder setup. But why the presence of T0 is causing the network to fail is beyond me, and only with this specific config.g layout. Meanwhile, everything else on the board works fine. The fans come on at the right temps, and they respond to temperature changes as they should. The presence of T0 in this case only kills the network port.
If someone would like to try out the config.g file from my OP this time and confirm that I'm not on crack, please do.
-
That is very bizarre. Is there anything odd about that tool?
What happens if you manually send T0 after startup?
What happens if you use T1 instead?
What happens if you use T0 with the wiring for all the tool0 parts disconnected?
-
Everything from the print head is already disconnected. This particular printer is a WIP.
Sending T0 after the printer has started up causes an immediate heater fault, presumably because there's no heater connected. Same with T1. There's a M116 P0 in tpost0.g that gets triggered when T0 is run. Commenting it out prevents the heater fault from happening, and also allows the board to start up completely with the network port active, even with T0 present in config.g. So it looks like the heater fault caused by M116 P0 on startup might be breaking something.
The odd thing is that I started my diagnosis by temporarily using a known good config.g (the one from my delta printer) just to see if the network port would come on. That config.g file DOES have T0 at the end of it, and tpost0.g was always present with M116 P0 in it. Yet the network port worked fine. So the issue here might be a combination of my defined heaters/sensors and the M116 P0 that T0 triggers. Either way, I would never expect that to prevent the network port from coming on...
-
@GoremanX while networking parameters are often early on in config.g, I think it’s still the case that network is not initialised until config.g has finished being processed, so something seems to stop that happening. Do you ave anything in the T0 tool change macros? These usually require axes to be homed before running, but perhaps check tpre0.g and tpost0.g.
Edit: sorry, just saw your last post after I posted!
Ian
-
@GoremanX looks like it’s the combination of setting G10 P0 R0 S170 in config.g (S parameter is active temperature, are you okay with setting an active temperature from startup?), activating the tool, then setting a wait in a external macro, possibly with the tight tolerance. The heater fault probably causes the macro to stop, so it never returns to complete config.g and enable networking. What happens if you set G10 P0 R0 S0?
Ian
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
@droftarts You're correct. With my single-extruder printers, config.g contains
G10 P0 X0 Y0 Z0 R0 S0 ; set tool P axis offsets and set active and standby temperatures to SSo active and standby temps are set to 0 by default. but for this dual-extruder setup, RRF-Config gave me:
G10 P0 X-10 Y0 Z0 ; set tool P axis offsets G10 P0 R0 S170 ; set initial tool P active (R) and standby (S) temperatures(and its equivalent for P1)
So when I set a tool as active, its standby temperature becomes its active temperature. Again, there's no good reason for that to prevent the network from coming up. But M106 P0 in tpost0.g is basically just a "wait" command, so I guess the board sits there and waits for the temperature to be reached rather than finish booting.
-
@Phaedrux @droftarts Just to clarify, the default in RRF-config is to generate a tpost0.g that contains M106 P0 ("Wait for Temperatures to be Reached on Tool Change"). I didn't do that manually. Selecting the first tool is not the default, but it's a checkbox directly beneath that option ("Select the First Tool on Start-Up"). With those two options selected, setting the selected tool's default standby or active temperature to anything other than 0 causes the heater to require reaching that temperature before startup completes. That means the network port won't be turned on until that temperature is reached, which could be never, as in this case. Meanwhile, it's very difficult to know what's going on with the board since it can't be connected to via ethernet, despite the fact that the board is in fact initialized and functional.
Perhaps this could be prevented by changing the firmware so that the network comes up as soon as M540/M550/M551/M552/M586/[other network-related gcodes] have been read, rather than waiting until processing of config.g has been completed. The current behavior makes diagnosis a nightmare. I get that there might be network-related gcodes at any point in the file, but there has to be a better way to handle this than potentially locking up the ethernet port for minutes or even forever on startup.
-
I'm not sure how the config tool gave a standby temp of 170. I'm unable to duplicate that and as far as I can find there is no way to set it. Setting a temp or moving a motor in config.g is bad practice. Are you sure it came from the config tool?
-
@GoremanX said in Network Port Not Working:
Perhaps this could be prevented by changing the firmware so that the network comes up as soon as M540/M550/M551/M552/M586
I think the reason it's delayed is to allow time for the wifi module to initialize.
