[3.6.0-beta.4] DWC Connection
-
@Leonard03 have you tried 3.6.0-rc.1 ?
-
@dc42 Yes, now I'm running 3.6.0-rc.1+1 and is no difference..
-
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. -
@Leonard03 please provide your tool change files and any macro files that they call, also daemon.g if you are using it.
-
@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 -
@Leonard03 Are you using daemon.g?
-
@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
-
@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 30global.errQueue[#global.errQueue-1] != "FILAMENT_ALREADY_LOADED"
, or if at line 105global.statusFinda = 1 && global.statusBondtech = 0
and at line 108global.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. -
@dc42 First, thank you very much for looking at my config.
Most of the time, thatwhile 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.gSince 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 back3.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'tI might missed this
-
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 -
@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.