Network Port Not Working
-
@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.
-
@Phaedrux I don't know how the default standby temperature got added to my config.g, I don't think it's something that RRF-config did. It's too coincidental that that's the safe-probing temperature on my larger delta printer with Duet Smart Effector, even though this printer isn't a delta. May have gotten carried over somehow (although that delta printer doesn't actually use that setting in config.g). But there's reasons to set a default standby temperature without actually wanting the hotend to be set to its standby temperature on startup.
My point is mostly that there's a myriad things in config.g that might cause initialization to be delayed or never complete, and network port initialization should not be pre-empted as a result. The network port should be powered on as soon as it's possible to do so, whether it's ethernet or wifi.
-
