Network Port Not Working
-
The network port on my Duet 3 6HC seems to have stopped working, and I'm super confused about what changed to make that happen.
When I plug a network cable into the Duet 3's network port, then plug the other end into a pi 4, nothing happens. No lights come on at either network port. It's like nothing is plugged in at all.
I know the pi 4's network port works fine, I can plug my laptop into it and it works as expected (lights come on, communication happens).
I've tried multiple network cables, all less than 3 feet in length, all different brands and grades. They all work with my laptop. None of them work with the Duet 3 (they used to).
The Duet 3 seems to work fine, it boots up from its SD card and does all the things it's supposed to based on the config.g file. But since I can't connect to it and it doesn't have a paneldue hooked up, I can't interact with it or issue an M122 command.
I tried powering the Duet 3 via the micro USB port (with int 5v disabled), and with the internal 5v converter enabled and no micro USB connected. No change.
edit: I tried plugging it into a network switch, no difference. Running firmware 3.2
edit 2: I tried the same SD card in a different Duet 3 6HC board that I have on hand, and its network port works fine. It's only the one on this specific board that appears to no longer work.
Here's the contents of config.g:
; Configuration file for Duet 3 (firmware version 3) ; executed by the firmware on start-up ; ; Power On M80 ; Turn on secondary power supply (24v) ; General preferences G90 ; send absolute coordinates... M83 ; ...but relative extruder moves M550 P"skgo" ; set printer name M669 K1 ; select CoreXY mode ; Network M552 P0.0.0.0 S1 ; enable network and acquire dynamic address via DHCP M586 P0 S1 ; enable HTTP M586 P1 S0 ; disable FTP M586 P2 S0 ; disable Telnet ; Drives M569 P0.0 S1 ; physical drive 0.0 goes forwards M569 P0.1 S1 ; physical drive 0.1 goes forwards M569 P0.2 S1 ; physical drive 0.2 goes forwards M569 P0.3 S1 ; physical drive 0.3 goes forwards M569 P0.4 S1 ; physical drive 0.4 goes forwards M584 E0.0:0.1 X0.2 Y0.3 Z0.4 ; set drive mapping M350 X16 Y16 Z16 E16:16 I1 ; configure microstepping with interpolation M92 X100 Y100 Z4000 E685:685 ; set steps per mm M566 X1800 Y1800 Z60 E1200:1200 ; set maximum instantaneous speed changes (mm/min) M203 X12000 Y12000 Z180 E3600:3600 ; set maximum speeds (mm/min) M201 X1500 Y1500 Z20 E1500:1500 ; set accelerations (mm/s^2) M906 X1300 Y1300 Z1300 E600:600 I30 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X-150 Y-150 Z0 S1 ; set axis minima M208 X150 Y150 Z325 S0 ; set axis maxima ; Endstops M574 X1 S1 P"io0.in" ; configure active-high endstop for low end on X via pin P M574 Y2 S1 P"io1.in" ; configure active-high endstop for high end on Y via pin P M574 Z1 S2 ; configure Z-probe endstop for low end on Z ; Z-Probe M950 S0 C"io7.out" ; create servo pin 0 for BLTouch M558 P9 C"^io7.in" H5 F120 T9000 ; set Z probe type to bltouch and the dive height + speeds G31 P500 X0 Y-52 Z2.5 ; set Z probe trigger value, offset and trigger height M557 X-140:140 Y-98:98 S35:24 ; define mesh grid ; Heaters M308 S0 P"temp3" Y"thermistor" T100000 B4138 A"Bed Heater" ; configure sensor S as type Y on pin P M950 H0 C"out0" T0 ; create bed heater output on pin C and map it to sensor T defined by M308 M307 H0 B1 S1.00 ; enable bang-bang mode (H) for the bed heater and set PWM limit S M140 H0 ; map heated bed to heater H M143 H0 S150 ; set temperature limit for heater H to S M308 S1 P"temp0" Y"thermistor" T500000 B4723 C1.19622e-7 A"1st Nozzle Heater" ; configure sensor S as type Y on pin P M950 H1 C"out1" T1 ; create nozzle heater output on pin C and map it to sensor T defined by M308 M307 H1 B0 S1.00 ; disable bang-bang mode (H) for heater and set PWM limit S M143 H1 S500 ; set temperature limit for heater H to S M308 S2 P"temp1" Y"pt1000" R2200 A"2nd Nozzle Heater" ; configure sensor S as type Y on pin P M950 H2 C"out2" T2 ; create nozzle heater output on pin C and map it to sensor T defined by M308 M307 H2 B0 S1.00 ; disable bang-bang mode (H) for heater and set PWM limit S M143 H2 S500 ; set temperature limit for heater H to S M308 S3 P"temp2" Y"thermistor" T100000 B4138 A"Chamber Heaters" ; configure sensor S as type Y on pin P M950 H3 C"out3" T3 ; create chamber heater output on pin C and map it to sensor T defined by M308 M307 H3 B1 S1.00 ; enable bang-bang mode (H) for the chamber heater and set PWM limit S M141 H3 ; map chamber to H M143 H3 S120 ; set temperature limit for heater H to S M308 S4 Y"drivers" A"Drivers" ; configure sensor S as temperature warning and overheat flags on the TMC2660 on Duet M308 S5 Y"mcu-temp" A"MCU" ; configure sensor S as MCU temperature monitor ; Fans, Pumps and Accessories M950 F0 C"!out4" Q2500 ; create fan F on pin C and set its frequency Q M106 P0 H4:5 L0.30 X1 B0.3 T35:50 C"Electronics" ; set fan P value. Thermostatic control is turned on M950 F1 C"out5" Q2500 ; create fan F on pin C and set its frequency M106 P1 S0 H1:2 T45 C"Water Pump" ; set fan P value. Thermostatic control at temperature T of heater(s) H M950 F2 C"out7" Q2500 ; create fan F on pin C and set its frequency M106 P2 S0 H-1 L0.35 C"Air Pump" ; set fan P value, minimum speed L, initial speed S M950 F3 C"out8" Q2500 ; create fan F on pin C and set its frequency M106 P3 S0 H-1 L0.35 C"Air Pump" ; set fan P value, minimum speed L, initial speed S M950 F4 C"out9" ; create fan F on pin C and set its frequency M106 P4 H1:2 T45 L255 C"110v Outlet" ; set fan P value. Thermostatic control at temperature T of heater(s) H M950 P5 C"out6" ; create output P on pin C M42 P5 S255 C"LED Lights" ; set output P initial value to S ; Tools M563 P0 D0 H1 F2 S"1st Hotend" ; define tool P 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 M563 P1 D1 H2 F3 S"2nd Hotend" ; define tool P G10 P1 X10 Y0 Z0 ; set tool P axis offsets G10 P1 R0 S170 ; set initial tool P active (R) and standby (S) temperatures ; Custom settings are not defined M207 S1.2 F3600 ; firmware retraction length (S) and speed (F) M376 H10 ; taper off bed compensation by H height in mm M572 D0 S0.03 ; pressure advance ; Miscellaneous M501 ; load saved parameters from non-volatile memory M911 S9 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss T0 ; select first tool -
Try connecting over the USB with a terminal program (like YAT on windows) and send M552 to confirm the network status.
-
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
-
@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.
