Good morning everyone!

First of all, I would like to apologize to you. This was not an issue with RRF but with my own code... Thank you all for your help and support!

Just in case, @gloomyandy and @AndyE3D you were right about M118 in every file in MMU Control. But I has no chance seeing something unusual until I used logging.
@dc42 I am sorry for tagging you here and wasting your time.. was my fault, not RRF's fault..

The problem was elsewhere, right at the beginning, in tpostn.g.
There, were three simple calls: load the filament in the MMU, then in the extruder and last in the nozzle. If during those macros any error raised, the tool change macro continued showing a dialog (M291). But, it can also call errorAction.g which by itself loads the filament all the way to the nozzle, but being called from a "while" loop in tpostn.g, after errorAction.g the while loop was trying to load it again to the MMU. The log confirmed that:

2023-08-02 12:02:28 [debug] Finish: loadToBondtech.g
2023-08-02 12:02:28 [debug] Begin: idlerMove.g
2023-08-02 12:02:28 [debug] Finish: idlerMove.g
2023-08-02 12:02:28 [debug] Begin: loadToNozzle.g
2023-08-02 12:02:28 [debug] Finish: loadToNozzle.g     < here the duex.e2stop is configured as a filament sensor
2023-08-02 12:02:28 [debug] Begin: loadToFinda.g     < here the duex.e2stop is used to load the filament in the MMU
2023-08-02 12:02:35 [warn] Error: Pin 'duex.e2stop' is not free
2023-08-02 12:02:35 [warn] Error: G1: Failed to enable endstops
2023-08-02 12:02:41 [info] Event logging stopped

In tpostn.g adding a break statement to exit the wile loop solved this problem

Thank you again to all of you for your support!

For me at least, a 3D printer is the perfect companion for those who like to do electronic projects.

Electronics are my toys from when I was born, so this hobby persists to this day. Every project needs some kind of enclosure.

I'm thinking about an Arduino/Raspberry Pi. As these boards can interact with many peripherals, 3D printing is indispensable for that "professional" touch.

There are generic "project boxes," generic ones, injection molded. But it is something generic. As an enthusiast, I think that every project, custom and unique.

If in some shop I see something that catches my attention, most of the time in my mind comes an "I can do it better", for me at least.

For an enclosure for that board, sensors, lights, and everything else, it is one thing to mount it with double-sided tape (maybe), and it is another thing that every LED, sensor, and internal layout has its own nut, bolt, and its own place to be mounted to.

Another benefit of 3D printing in this area is the freedom to choose your own color schemes and different materials you can print (e.g., matte vs. glossy vs. CF).

I've seen very good projects done using generic components and plastic components, but in my opinion, those can't beat your personal idea, and the fact that this technology can really bring a thought to reality just as you imagine it.

Hello everyone!

I got a strage issue with my printer, after an 8 hours print, i got this error:

Sadly I cannot get a M122 report for two reasons:
In DWC with 3.6.x I cannot get an M122 report even if other comands works as expected
Over USB, I needed to do an emergency stop wich cleared the relevant report..

My board is a Duet 2 WiFi + Duex5 with MMU3

Anyway, I will upload my config files to google drive and update this post.
All that I have is the gcode and the aproximate layer height when the error occured

By the way, with beta 1 for only one print I got the exact same error, the next day I do a simulation wich completed as expected, printed the exact same gcode without any problems. So, seems to be a random issue wich I can't reproduce myself twice. I started a slightly modified print now to see how it goes

Thank you in advance, and any help is welcomed!

Update:
This is the gcode in question: Jack Case_STEC7_0.2mm_PLA_5h24m.gcode
The error occurred on layer 312 / Z height 62.40 most likely somewhere around line 117292 in that gcode

This is my config/SD card https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=sharing

@T3P3Tony Confirm no motion errors with the beta4

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