Wipe tower blob crash mitigation

[agoode]

Description of the bug

Wipe tower blobs have been causing crashes and layer shifts for some time now:

Older posts:

• https://forum.prusa3d.com/forum/original-prusa-i3-mmu2s-mmu2-hardware-firmware-and-software-help/purge-tower-bumps-crashing-etc/
• https://www.reddit.com/r/FixMyPrint/comments/1ce2l3u/sloppy_wipe_tower_causes_collisions_and_print/

Newer:

• https://www.reddit.com/r/prusa3d/comments/1cuxy1d/new_mmu3_with_mk4_purge_tower_blobs/
• https://www.reddit.com/r/prusa3d/comments/1gf4sbu/wipe_tower_causing_collision_and_layer_shift/

I have been having a lot of trouble with some blobs recently that happen at different points in the print, even when reprinting the same gcode files, and I'd like to try to solve this with some changes to the wipe tower generation.

Some observations:

• Blobs are rare, but even one in a print can cause a crash and layer shift.
• Folks on forums suggest that changing parameters can help, but it's hard to know since blobs don't appear at the same time in each print.
• Blobs can appear just before or after an MMU filament change.
• When a misfeed happens, the MMU will usually retry (successfully!) but may end up making a blob. The rest of the system is tolerant to these kinds of transient issues except for the wipe tower implementation.
• When the nozzle is moving slowly during a wipe cycle and encounter a blob, the blobs do not interfere with nozzle movement, but can be converted into tall walls.
• Blobs that get pushed this way are several layers tall, so can cause problems for a long time.
• The nozzle can hit blobs and crash during the wipe cycle (during the fast moves), or during normal movement between parts.
• The tall walls are especially bad.

I'm also assuming that loads/unloads are going to be naturally nondeterministic, so no amount of dialing in of fixed parameters is going to solve the problem fully.

Some potential ideas:

• Since the nozzle doesn't crash when moving slowly, maybe we could do a kind of ironing step to make sure blobs are flattened before the nozzle leaves the wipe tower.
• We could route around the wipe tower during moves.
• We could move slowly over the wipe tower during moves.

I think some kind of ironing might be best. I don't know of other ways to handle the issue at gcode generation time, since blobs cannot be detected and reacted to during the print.

I'm attaching images of my latest print's wipe tower, which resulted in a pretty severe crash.

Project file & How to reproduce

blobbo.3mf.zip

The project file is attached.

Filament 2: Prusament PLA Gravity Grey
Filament 5: Printed Solid Jessie PLA Blue Moon

Printer: CORE One with MMU3 (enclosed)

I've just cleaned and tuned the printer and MMU3.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.9.2

Operating system

macOS 15.6

Printer model

CORE One with MMU3

[agoode]

I hope to dig into the slicer code and try a few things, but it will be a little while before I can do that.

[CappyT]

Following due to same issue

[agoode]

I made a PR (#14864) which may help mitigate this problem.

[CappyT]

Strangely enough I have this problem ONLY when I use the HF nozzle (specifically HF hardened nozzle, but i think also the brass would do the same).

Swapping to non-HF makes perfect purge towers.

[CappyT]

Update, after re-testing, even non-HF makes the nozzle crash.

(Using standard prusa test 5 color gcode for core one on printables)

[Ro3Deee]

Also the extruder pauses at the same spot every time to actually change the filament, so a blob forms there ...