[3.6.0-beta.4] DWC Connection

Leonard03

Hello,
I have a strange issue with DWC with this beta firmware in particular. The boars is a Duet2WiFi. The issue means if the printer is idle, no matter for how long, the DWC remains almost stable, but unusable (some reconnects during many hours)

The strange thing occur after starting a job. Regardless of the gcode file, after a couple of seconds in the job, DWC is starting a loop of disconnects and reconnects until the board is reset via the emergency button on PanelDue

I have installed all the relevant binaries/DWC zip from the 3.6.0-beta.4 release on GitHub

droftarts

@Leonard03 Is the PanelDue firmware up to date? It should be on 3.5.1: https://github.com/Duet3D/PanelDueFirmware/releases/latest

Ian

Leonard03

@droftarts Thank you for the fast replay!
Yes, my PanelDue is on firmware 3.5.1 and I'm using the max baudrate available. Seems to be more reliable

droftarts

@Leonard03 It's possibly your issue is similar to the one reported in this thread: https://forum.duet3d.com/topic/37545/mini-5-wifi-problem-revisited/. We have asked @rechrtb to look into it.

Ian

Leonard03

@droftarts You're right, it seems similar to mine. I'll wait then Thank you

Leonard03

Just an update:
I tried all stable versions of DuetWifiServer, versions 1.27, 2.0.0, 2.1.0, 2.2.0, 2.2.1 and this issue is the same. Tried now also in Access Point mode and still the same. But sometimes homing sequence, G32 and G29 are done and after DWC starts looping, sometimes right after a job is started.

The disconnect reason is almost always "service unavailable" but the fun thing is that he bed heater is shown, macros list is loaded and the left bar also is loaded

gloomyandy

@Leonard03 Have you tried increasing the number of retries in the DWC settings? That can sometimes help.

Leonard03

@gloomyandy Thank you for your suggestion. Tried to increase ajax retries from 3 to 20 but sadly with the same effect...

gloomyandy

@Leonard03 I think there have been some issues with systems that have a PanelDue, it might be worth disconnecting it just to see if that makes any difference or perhaps try putting it on the settings page as I think that stops it from talking to the board?

Leonard03

@gloomyandy Tried now both options. PanelDue on its setup page and disabling the comm port from config.g. Same effect.. After homing, DWC starts to loop

dc42

@Leonard03 have you tried 3.6.0-rc.1 ?

Leonard03

@dc42 Yes, now I'm running 3.6.0-rc.1+1 and is no difference..

Leonard03

Seems that I can provide additional information about this issue.
My printer has an Prusa MMU which I can disable from config.g. I can disable all the multicolor stuff, reducing the load of the MCU.
With MMU disabled, using only one tool, DWC keeps a stable connection during a job.
With MMU enabled, even if the job has no tool changes, DWC starts looping when tool 0 is selected, mostly after bed trimming and an adaptive mesh calibration. I can't determine when, but I suspect during tpre0.g.
This macro is "empty" if MMU is disabled.
The strange thing is that if when printer is idle and select manually the T0, works as expected.

dc42

@Leonard03 please provide your tool change files and any macro files that they call, also daemon.g if you are using it.

Leonard03

@dc42 Those are the relevant macros for a tool change: TC macros.zip.g
During a filament normal load, tpre0.g ends at line 24 and tpost0.g ends at line 25

gloomyandy

@Leonard03 Are you using daemon.g?

Leonard03

@gloomyandy yes, this is it:

if state.atxPower == true
	G4 S2
	if fans[1].actualValue == 1
		G4 S4
		if fans[1].rpm == 0 && heat.heaters[1].state != "off"
			M108
			M568 P0 A0
			if state.status = "processing"
				M25
			if state.currentTool != -1
				T-1
			M98 P"0:/sys/MMU Control/errQueueUpdate.g" A"HOTEND_FAN_ERROR"
			M291 P"Hotend fan not spinning. Check it for possible debris, then inspect the wiring." S1 T0

It should not affect anything about the job or tool changes

dc42

@Leonard03 your tpre0.g file and the macro files that it calls contain several "while" loops. To avoid using up lots of CPU time going round these loops over and over again, each loop should satisfy at least one of the following conditions:

Each iteration either executes at least one M291 command that waits for input from the user, or executes a G4 delay command with a reasonable amount of delay, e.g. one second
The maximum number of iterations executed is bounded and small

Some of your loops don't appear to obey this, e.g.

The loop in tpre0.g from line 16 to the end of the file appears to execute indefinitely under some conditions, e.g. if at line 27 global.statusFinda = 1 && global.statusBondtech = 1 and at line 30 global.errQueue[#global.errQueue-1] != "FILAMENT_ALREADY_LOADED", or if at line 105 global.statusFinda = 1 && global.statusBondtech = 0 and at line 108 global.errQueue[#global.errQueue-1]! = "UNLOAD_MANUALLY"
in file errQueueUpdate.g you have various loops that iterate through the elements of global.errQueue. Is the number of elements always guaranteed to be small, or might it grow very large?

I didn't find file errorAction.g in your zip file.

My guess is that one of these while-loops is executing repeatedly (perhaps while waiting for something to happen?) without a delay or a wait-for-input M291 command in each iteration, and that is causing the network task to be starved of CPU time. You may find it helpful to add an echo command at the end of any suspect loop bodies to help you detect unexpected repeat iterations.

Leonard03

@dc42 First, thank you very much for looking at my config.
Most of the time, that while true loops are never completed, so only one iteration is done if the filament is loaded without any problems or errors.
The reason for this is that tool change macros are hard to abort so those loops keep the user in one particular macro until a problem is resolved and carry on from that point.

@dc42 said in [3.6.0-beta.4] DWC Connection:

in file errQueueUpdate.g you have various loops that iterate through the elements of global.errQueue. Is the number of elements always guaranteed to be small, or might it grow very large?

I agree. Theoretically this array can grow very large. In practice, it never had more than let's say 10 elements. If a problem persists, I cand pause the job and resuming it will clear it.

@dc42 said in [3.6.0-beta.4] DWC Connection:

I didn't find file errorAction.g in your zip file.

I don't include errorAction.g because during normal operation it is not used, but here it is just in case: errorAction.g

~~Since this particular issue started from beta.4, I will try to find an earlier version of RRF to try my actual configuration without any modifications and report back~~

3.6.0-beta.3+3 (2025-02-03 10:56:36) works flawlessly
3.6.0-beta.3+4 (2025-02-10 09:34:09) don't I might missed this