Posts made by Leonard03

@dc42 The MMU is basically a multiplexer. It has no extruders assigned to it. Just moving 3 axis (UVW) to send filament from the selected slot (defined as a tool) to the extruder. It feeds filaments from 0-4 to the same direct dirve extruder.
After that tool change, it disengage the filament and the extruder goes to print with the loaded filament.
I can get away defining only one extruder with the M584. In this case, everything works as expected, but the downside is that i can assign only one filament config to all MMU slots.

@dc42 said in [3.6.0-beta.3+1] Extruder stall detection:

it looks like you have set up every tool has its own extruder.

I think so. Every tool has its own extruder, but all extruders are using the same driver (3) and the same physical extruder

@dc42 that is exactly my setup

M584 X0														; set drive mapping for X axis
M584 Y1														; set drive mapping for Y axis
M584 Z2:4													; set drive mapping for Z axis (dual independent)
if global.MMUmode = true
	M584 E3:3:3:3:3											; set drive mapping for virtual extruders
	M584 U5													; set drive mapping for U axis (MMU selector)
	M584 V6													; set drive mapping for V axis (MMU pulley)
	M584 W7 R1 S1											; set drive mapping for W axis (MMU idler)
else
	M584 E3													; set drive mapping for extruder

and

; Tools
if global.MMUmode = false
	M563 P0 D0 H1 F0										; define tool 0
	G10 P0 X0 Y0 Z0											; set tool 0 axis offsets
	M568 P0 R0 S0 A0										; set initial tool 0 active and standby temperatures to 0C

elif global.MMUmode = true
	M563 P0 D0 H1 F0										; define tool 0
	G10 P0 X0 Y0 Z0											; set tool 0 axis offsets
	M568 P0 R0 S0 A0										; set initial tool 0 active and standby temperatures to 0C

	M563 P1 D1 H1 F0										; define tool 1
	G10 P1 X0 Y0 Z0											; set tool 1 axis offsets
	M568 P1 R0 S0 A0										; set initial tool 1 active and standby temperatures to 0C

	M563 P2 D2 H1 F0										; define tool 2
	G10 P2 X0 Y0 Z0											; set tool 2 axis offsets
	M568 P2 R0 S0 A0										; set initial tool 2 active and standby temperatures to 0C

	M563 P3 D3 H1 F0										; define tool 3
	G10 P3 X0 Y0 Z0											; set tool 3 axis offsets
	M568 P3 R0 S0 A0										; set initial tool 3 active and standby temperatures to 0C

	M563 P4 D4 H1 F0										; define tool 4
	G10 P4 X0 Y0 Z0											; set tool 4 axis offsets
	M568 P4 R0 S0 A0										; set initial tool 4 active and standby temperatures to 0C

Those are from my config. But for some reason, sharing the extruder between tools messes something up

@dc42 Found the problem. Is about M584 E3:3:3:3:3. Virtual extruders give this problem.
Reducing this to M584 E3 and redefining all five tools to use extruder 0 works.
In my setup I use virtual extruder so I can use different filament configurations per MMU slot.
Virtual extruders affects even M302 command to deny cold extrusion. Sending a 'G1 H1 E20' with the nozzle at room temperature still works even if a the warning is rised in dwc

Now using 3.6.0-rc.1+3
Well.. got now an update:
Using only X Y dual Z and the extruder.. MMU/Multitool and UVW axis disabled extruder stall works!

@dc42 said in [3.6.0-beta.3+1] Extruder stall detection:

for clarification: extruder stall detection does work for the purposes of using an extruder stall to load filament using a G1 H1 Exxx command. Such a use of stall detection does not raise an event.

Seems like the extruder can rise an stall event indeed. Tried now and worked using the R2 parameter in M915 command. This is not only good. Is perfect!
Works together with the macro you wrote in the issue #930

Now, similarly as in one of my previous thread.. what`s wrong to use more then X Y Z?
In my case means disabling the MMU/Multitool setup and the UVW axis

Now even extruding using the DWC extrude/retract buttons are rising an stall event. Wow..

@dc42 I'm sorry.. I tried to calculate the value but failed.. my apologies
My configuration is this:
Steps/mm for the extruder is 415
Microstepping at 16x
Using G1 H1 F600, 10mm/min, right?
The response from `M915 P3 is:

M915 P3
Driver 3: stall threshold 7, filter off, full steps/sec 210 (8.1 mm/sec), coolstep 0, action on stall: raise event

Reducing H from 210 to 10 gives (0.4 mm/sec)

@dc42 Thank you for revisiting this problem. The sad part is that the extruder is assigned only to the driver 3. I use a macro that remaps the drivers just before that, but at the end, it splits them apart again. V axis on driver 6 and extruder on driver 3. But this seems that don't mater. Running my test macro from above right after an fresh start yields to the same problem.
But if I use the driver 3 for an axis instead of an extruder, stall detection works.
a side note, during a long move, in a M122 report, driver 3 as the extruder report its SG value as not available

Is there any update for this?

@dc42 Confirm the problem is solved!
Thank you for the help and support! Your work is really amazing

@dc42 Thank you

Found something in Chrome console, if helps in any way..

My settings are this:
Number of maximum AJAX retries: 3
Time to wait between AJAX retries (ms): 250
Update interval (ms): 250
Retry threshold for file transfers (KiB): 350

@dc42 Yes, now I have 3.6.0-rc.1+2 (2025-03-15 15:41:04) with the same results.
But at tis point, I can confirm that the G1 H1 Exx ignores the M302 command

@dc42 Tried now. Verified in DWC editor and Notepad++ there were not strange characters, but redo it anyways, but with no success..
Tried commenting out all the if else statements, no luck,
Tried commenting out beeps at the end, no luck,
Tried to add a M400 in combination with G4 S3 between G32 and G29 S0 first, and after the mesh after. no luck either

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

What type of Z probe are you using?

I have a BL Touch
This is its configurtion, if this helps:

; Z-Probe
M950 S0 C"!exp.heater7"										; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H4:2 F240:120 T9000 A20 S0.01			; set Z probe type to bltouch and the dive height + speeds S0.005
G31 P500 X-27.4 Y-28.6 Z2.00								; set Z probe trigger value, offset and trigger height
M557 X8.0:285.0 Y21.6:279.4 P10								; define mesh grid

This problem occurs only with the MMU or multiple tools/axis enabled
With only one tool defined and no U,V,W axis defined, there are no issues with the connection. All works fine

@dc42

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

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.

Adding the M99 between G32 and G29 S0 (at line 20) works. After that, DWC starts looping.

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

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

Yes, the mesh always completes and the disconnects seems to occur at the end of the macro, but again, G29 S0 sent alone from the console works with no problems

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

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.

That M80 I use mainly to override the M81 S1, but I agree, I will change it to make it safer

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 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

@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 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

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 Yes, now I'm running 3.6.0-rc.1+1 and is no difference..

@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