[3.6.0-beta.4] DWC Connection

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

Leonard03

Guys.. found the macro that cause the disconnects..
Has nothing to do with the tool change macros, but with the mesh leveling macro.

Found the problem, but I don't understand what is wrong with it. bed.g and mesh.g are unchanged for a while and they worked very well..

This is bed.g and this complete without problems

; bed.g
; called to perform automatic bed calibration via G32

M106 S0

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28

G30 P0 X5 Y6 Z-99999
G30 P1 X287 Y6 Z-99999
G30 P2 X287 Y278 Z-99999
G30 P3 X5 Y278 Z-99999 S2

G1 X{(310/2)-sensors.probes[0].offsets[0]} Y{(310/2)-sensors.probes[0].offsets[1]} F6000
G30

And this is mesh.g that causes DWC to start looping:

; mesh.g
; called to perform automatic bed compensation via G29

var rmsMin	= -0.08
var rmsMax	= 0.08
var meanMin	= -0.08
var meanMax	= 0.08

var isOK = true

M116 H0	S0.2																					; wait for bed temperature with a tolerance of 0.2 degC
M106 P0 S0																						; turn fans off if active

M80																								; override ATX thermostatic shutdown 

M561																							; clear any bed transform
M290 S0 R0																						; reset babystepping

G32

G29 S0																							; Probe the bed

if move.compensation.meshDeviation.mean > var.meanMax && move.compensation.meshDeviation.deviation > var.rmsMax
	set var.isOK = false
	M291 P"Mean & RMS deviations too high" R"Mesh warning!" S1 T0
elif move.compensation.meshDeviation.mean < var.meanMin && move.compensation.meshDeviation.deviation < var.rmsMin
	set var.isOK = false
	M291 P"Mean & RMS deviations too low" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.mean > var.meanMax && move.compensation.meshDeviation.deviation < var.rmsMin
	set var.isOK = false
	M291 P"Mean deviation too high & RMS deviation too low" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.mean < var.meanMin && move.compensation.meshDeviation.deviation > var.rmsMax
	set var.isOK = false
	M291 P"Mean deviation too low & RMS deviation too high" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.deviation > var.rmsMax
	set var.isOK = false
	M291 P"RMS deviation too high" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.deviation < var.rmsMin
	set var.isOK = false
	M291 P"RMS deviation too low" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.mean > var.meanMax
	set var.isOK = false
	M291 P"Mean deviation too high" R"Mesh warning" S1 T0
elif move.compensation.meshDeviation.mean < var.meanMin
	set var.isOK = false
	M291 P"Mean deviation too low" R"Mesh warning" S1 T0
else
	set var.isOK = true
	M291 P"Auto calibration successful!" R"Mesh complete" S0 T4

G0 X0 Y0 F4800

if var.isOK = true
	M300 S2000 P500
	G4 P500
	M300 S1700 P500
else
	M300 S300 P1000

G29 S0 works ok
What's wrong with the mesh macro? I'm lost

dc42

@Leonard03 you could add a M99 command part way through mesh.g to quit the macro at that point, then see whether DWC still disconnects. Move the M99 command around until you have found the line that causes the disconnect.

Does mesh probing complete before DWC disconnects? I have a feeling that the M300 commands near the end might be triggering the problem.

You have a M80 command near the start. If this is because you sometimes have only 5V power applied when you start the macro then you may need to add a delay command after it, to allow the stepper drivers to be initialised after VIN power is applied but before any movement commands.