Posts made by Leonard03

@dc42 Thank you very much for taking this issue in consideration! I had really low hopes that this can be fixed because I don't now how many users have this kind of setups and because I'm using the Duet 2.. well, I have no words Thank you again and congratulations for your efforts and for supporting the Duet 2 boards for so long!

@dc42 Thank you very much, that is wonderful news!

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

using your original approach of multiple extruders mapped to the same driver so that M701/702 work, I think you could work around the stall detection issue by including a M584 command in your tpost tool change files to repeat the mapping of the extruder number used by that tool to the driver. Don't repeat any other mappings in that M584 command, just that extruder. You may also need to repeat the M906 Exxx command.

Thank you for the suggestion, I might try it, but I prefer to wait for a more stable fix. Anyway, I added all the bits to manage an extruder stall detection to my configuration.
It is not something urgent, per say. I want to add this to my printer because sometimes, in a multicolor print, some filaments gets sometimes malformed tips that gets past the extruder and somehow they get jammed between extruder and nozzle, resulting in a perfect print with skipped layers from only one filament.

As a side note, regarding the events raised by the extruder stall: this behavior will be fixed or it will continue to work as it does now?

@dc42 I am really sorry for the dumb question.. but how to do this?
Seems like filament configurations are assigned per extruder, not per tool.
I know that this topic is getting all over the place and I really don't want bother you or to waste your time. Please let me explain what I tried after seeing the problem with virtual extruders, what works and what not:

From config.g, I will skip other bits (like initial temperatures and offsets because I don't change them so they are irrelevant here)
My actual setup is this:

M584 E3:3:3:3:3 ; this will give virtual extruders 0 to 4 and the D driver for tool definitions

M563 P0 D0 H1 F0 ; T0, extruder 0, driver 3
M563 P1 D1 H1 F0 ; T1, extruder 1, driver 3
M563 P2 D2 H1 F0 ; T2, extruder 2, driver 3
M563 P3 D3 H1 F0 ; T3, extruder 3, driver 3
M563 P4 D4 H1 F0 ; T4, extruder 4, driver 3

With this, stall detection don't work but filament configs do.
With this setup, in DWC each tool has its driver and extruded amount.
Every tool can have its filament configuration loaded (the "load filament" option)

I got the point you are referring, so I'm changing the above commands to this:

M584 E3 ; this will give only the actual extruder 0 and the D0 extruder for tool definitions

M563 P0 D0 H1 F0 ; T0, extruder 0, driver 3
M563 P1 D0 H1 F0 ; T1, extruder 0, driver 3
M563 P2 D0 H1 F0 ; T2, extruder 0, driver 3
M563 P3 D0 H1 F0 ; T3, extruder 0, driver 3
M563 P4 D0 H1 F0 ; T4, extruder 0, driver 3

With this, stall detection works, but filament configs don't.
Now, with this changes, DWC reports only one extruder (don't like it, but so far so good) and every tool has the ability to be assigned one filament config.

The problem with this approach is that assigning a filament configuration to T0, sets all tools to the same filament. If I change the filament for T2 lets say, it sets all tools again. As filament config as assigned per extruder, not per tool.

As a side note, I took a look at the M563 L parameter but with no luck.
I read the description of issue #1098 and is similar (might help in this case also) but is not the same. Then I try the do the stall detection the extruder is assigned only to driver 3 but the part with logical drivers stands up. "As a result the stall does not stop motion." This is also true for me. Might be related after all.

I had a look at filaments.csv and those are the results:
With the first configuration (my actual one)

RepRapFirmware filament assignment file v1 generated at 2025-03-28 19:23
extruder,filament
4,PLA Fillamentum Extrafill
3,PLA Fillamentum Extrafill
2,PLA SmartFill Glitter
1,PLA Fillamentum Extrafill
0,PLA Elegoo

With the testing config looks like this:

RepRapFirmware filament assignment file v1 generated at 2025-03-28 17:35
extruder,filament
0,_dummy

Here the assigned filament is always to extruder 0, regardless of any other tool being selected and asked to load the filament for it

@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