Network Port Not Working
-
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.
-
