[3.6.0-beta.3+1] Extruder stall detection

Leonard03

Another update.
I don't know if is relevant for this issue or not but an observation. Using the macro above, even if cold extrusion is disabled and heater is below minimum extrusion temperature, extruder motor still executes the move, even if DWC report the error "Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault"
RRF 3.6.0-rc.1+1 (2025-03-07 09:35:55)

dc42

@Leonard03 have you tested extruder stall detection in RRF 3.6.0-rc,1+1 or rc.1+2 (available at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0) ?

Leonard03

@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

Leonard03

Is there any update for this?

dc42

@Leonard03 I've just re-tested it on Duet 2 and it is working for me. However, I discovered that stall detection can fail if you use M584 to map both an axis and an extruder to the same drive. For example, if I map both Y and E0 to the same drive in a single M584 command, then I can't get the drive to stall when I do a Y homing move. The reason is that the driver has recorded that it is handling the E axis (because E is processed later than Y in the M584 command), so when it stalls, it registers that the E drive has stalled instead of the Y drive. G1 H1 E moves do stop correctly when the drive stalls.

If I then send a M584 command to map Y to the same driver, then the drive records that it belongs to the Y axis; so G1 H1 Y moves stop on stall but G1 H1 E moves don't.

Does this explain the issue you have experienced?

I have created https://github.com/Duet3D/RepRapFirmware/issues/1098.

dc42 created this issue in Duet3D/RepRapFirmware

open Stall detection issues when a drive is used by both an axis and an extruder #1098

Leonard03

@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

dc42

@Leonard03 one other thing to check is that when you send M915 P3 the minimum fullsteps/sec that it reports and the corresponding speed that it reports immediately after that in brackets match, taking into account the configured microstepping and steps/mm.

Leonard03

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

Leonard03

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

Leonard03

@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

dc42

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

In my setup I use virtual extruder so I can use different filament configurations per MMU slot.

Thu usual approach would be to use M563 to define a separate tool for each filament slot. Tools can share extruders.

Leonard03

@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

@Leonard03 it looks like you have set up every tool has its own extruder. Is that really the case, or do they all use a common extruder? Or do you have a single common extruder close to the hot end, and an individual extruder for each filament spool to feed filament into the MMU?

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

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

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.

No, you can define multiple tools using the same extruder and each tool can have a different filament configuration.

Leonard03

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

@Leonard03 although the documentation for M700/701 says filaments are assigned per tool, I've taken a look at the code and it does appear that it uses a mixture of per-tool and per-extruder assignment. This obviously isn't suitable for filament switching systems that use a common extruder. We'll look into why it was done this way and what we can change.

dc42

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

Alternatively you could put these M584 and M906 commands in your filament loading macro file.