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

Leonard03

Hello everybody!
Can anyone please confirm that extruder stall detection works on 3.6.0-beta.3 or +1 on a Duet2 WIFi?

M915 P3 S-64 H10 or M915 E S-64 H10 should rise a stall event with virtually no movement, right?
Move command is G1 H1 E70 F600, extruder is a Bondtech BMG, around 415 esteps
Reducing motor current during this phase I tried from 10 to 80 percent
Acceleration 3000mm/min
Acceleration during homing move 1000mm/s

Leonard03

Remapping driver 3 from the extruder to an axis (V axis in my case) seems to rise the stall event. So it seems to be a bug with extruder stall detection in this version.
By the way, during a move, M122 shows that the extruder SG is not available..

Leonard03

I am sorry.. Only now I've seen on GitHub issue/feature request #930.
Is there any chance that this feature request to be part of rc.1 ? Or it will be implemented after 3.6.0 stable?

T3P3Tony

@Leonard03 its currently flagged for After 3.6.0. Once we have 3.6rc1 or 3.6.0 stable out we will have a better idea of what will be in 3.7.

Leonard03

@T3P3Tony Understood. Thank you for the clarification. I will wait

dc42

@Leonard03 did extruder stall detection work for you in firmware 3.5.x ?

dc42

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

dc42

I have updated https://github.com/Duet3D/RepRapFirmware/issues/930 with info on how to determine whether a G1 H1 E move was terminated by an extruder stall or not.

dc42 created this issue in Duet3D/RepRapFirmware

closed Feature request: when using stall detection filament loading (G1 H1 Exx) flag whether a stall occurred #930

Leonard03

I am sorry for the long time not saying anything. Sadly, even with the 3.6.0-beta.4 the extruder stall detection not seem to work. As stall detection is unavailable for the extruder.

I have this macro to test this:

M17 E0
M302 P1

M913 E40

T0 P0

M83

M915 E0 S-60 H10 R0 F0


var ex0pos = move.extruders[0].position
G1 E-1 F1200  ; small E move of more than 1 full step to ensure that the extruder is not stalled
G4 P250
G1 H1 E67
M400
if (move.extruders[0].position - var.ex0pos < 67)
  echo "Extrusion stopped by stall"
else
  echo "Extrusion completed without stalling"

echo "diff:", move.extruders[0].position - var.ex0pos
M915 E0


M913 E100

No mater the M915 parameters, if driver 3 (in my case) is assigned to an extruder, stall detection does not trigger. If the same driver is assigned to an axis (eg V) stall detection is trigger immediately without any move

~~By the way, for the M915 parameters, E0 sets the correct parameters but P3 don't~~

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.