Crash on tool change with sequential printing with Prusa XL

[davispw]

Description of the bug

With sequential printing, after automatically arranging the bed, the tool can crash on tool change.

I couldn't find an existing issue for this. If there's one already, sorry, and here's a repro case.

1. Prusa XL5T
2. Load model: https://www.printables.com/model/227852-strong-flying-propeller-pull-copter-no-supports
3. Select extruder 5 for the propeller and pull string; extruder 1 for other parts.
4. Enable Print Settings > Output Options > Complete individual objects. (Note, it instructs me to use the automatic Arrange function to prevent collisions. There is no warning regarding tool changes.)
5. Arrange bed
6. Slice

See attached 3mf and gcode. (This is print-order dependent; not sure how reliably one can repro from scratch.)

Actual result: crash on the tool change at the end of layer 213.

Aggravating issue: crash detection is disabled by default on new Prusa XLs because Phase Stepping is enabled by default during the guided setup process. Result is a dangerous default configuration (or at least, the implication of using these features was not clear to me).

In my case, the nozzle became jammed in the part for some time before the loud grinding noises drew a human's attention.

Expected results:

1. Collision detector should be aware of toolchange movements and warn in this case
2. Bed arranger should plan for toolchange movements
3. Or quick fix—warning when sequential printing is used with multiple extruders

Project file & How to reproduce

Flying Propeller - crash_0.4n_0.15mm_PETG,PETG_XLIS_3h24m.bgcode.zip
Flying Propeller - crash.3mf.zip

See repro steps above.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.9.1-rc2

Operating system

macOS Sequoia 15.3

Printer model

Prusa XL 5T, firmware 6.1.3+7898

[Jan-Soustruznik]

Hello, @davispw, thank you for sharing your case. I have created an internal issue (SPE-2719). We will try to fix it in one of the upcoming releases. Have a nice day!

[bbum]

@Jan-Soustruznik To confirm: There appears to be no support for multi-material printing with sequential printing.

Or, more specifically, if each object is printed with a different material, then the tool head change is not accounted for and the head will likely crash into prior objects when changing tools.

Furthermore, the head motion preview does not show the tool changes as they happen. I suspect that the sequential algorithm simply does not account for tool changes at all at this time.

Hard problem. If it is going to take a while to fix, I would suggest a priority update that disables sequential printing when multiple materials are used.

[jkoether]

I also had this issue running a 5T XL with Slicer 2.9.1, trying to print parts with different materials sequentially.

[ev0rtex]

I'm interested in following this because I just ran into problems today with my first attempt at using sequential printing. I'm using PrusaSlicer 2.9.2 with a 5T XL. My print is a multi-material print and using the automatic arrangement didn't indicate that there would be any crashes but in reality I had 2 crashes that I was luckily able to manually resolve without ruining my print. Both times were at tool changes where it happened.

I looked at my recordings of the print where it happened and it appears that tool changes aren't even accounted for properly when other objects have been printed already. The print order that auto arrange did involved printing objects from the back to the front which feels kind of the opposite of what I would do intuitively. Here's what happened in my two instances:

• First of 4 identical object was printed fine in the back left quadrant of the build plate and it had started printing the second object
• The first crash happened when it went to switch toolheads and the Z axis didn't move enough to provide clearance for the first object that had been completed - the toolhead just moved directly left and crashed into the right side of the first object when it tried to park toolhead 1. I removed the first instance of my object from the build plate and manually docked extruder 1 and let it continue.
• The second crash happened when it had finished the second object in the back right quadrant of the build plate and started on the 3rd in the front right quadrant of the build plate - it docked extruder 1 and went to pick up extruder 3 and crashed into the second object as it pulled the undocked toolhead out... again because the Z axis didn't move enough to provide clearance.

In my next attempt I will be seeing if changing the print order at least prevents the crashes - though I am having to separate the instances of my object since I can't find a way to change the print order for the instance list. I also am not doing automatic arrangement because that just goes back to printing the objects at the back of the build plate first.

[kurtgluck]

I had this same problem. This seems to be able to be worked around somewhat, by ordering the objects to be printed from FRONT to BACK.

[bbum]

I'm interested in following this because I just ran into problems today with my first attempt at using sequential printing. I'm using PrusaSlicer 2.9.2 with a 5T XL. My print is a multi-material print and using the automatic arrangement didn't indicate that there would be any crashes but in reality I had 2 crashes that I was luckily able to manually resolve without ruining my print. Both times were at tool changes where it happened.

It is only going to work by coincidence.

The tool path used during tool changes is not considered as a part of the sequential operations.

Thus, ordering from front to back or whatever may work some of the time for some parts, but it isn't a real solution

[ev0rtex]

It is only going to work by coincidence.

The tool path used during tool changes is not considered as a part of the sequential operations.

Thus, ordering from front to back or whatever may work some of the time for some parts, but it isn't a real solution

I definitely agree... it's only a workaround that happens to be sufficient for my current use case. There are many cases I can imagine where it will very much not be sufficient