MM3S/MMU2S Under-extrusion upon leaving wipe tower

[cjbaar]

Version

Any since MMU release (1.4+, 2.0+)

Operating system type + version

OSX

3D printer brand / version + firmware version (if known)

Prusa Mk3S 3.7.0, MMU 1.0.5

Behavior

I have had this issue since I first received the MMU2 last year. No recent software/firmware updates seem to have addressed it. Whenever the printer goes through the purge process after changing filaments, it either over-retracts or under-primes leaving the wipe tower, and the first extrusion is significantly low (several mm). This happens on every tool change, regardless of filament or layer.

Is there a setting for this in Slic3r PE? If so, I am not seeing it. There seem to relatively few settings for wipe tower speed, flow, etc.

[MalikDrako]

Copying my findings on this issue here

Version

2.0.0 with P2PP

Operating system type + version

Windows 10 64 bit

3D printer brand / version + firmware version (if known)

MK3S 3.7.2-2363 with Palette 2 6.1.5

Behavior

I am seeing the same thing @cjbaar is, underextrusion on the part being printed immediately after leaving the prime tower. There is no other underextrusion on the part that would point to a clog or jam. Measuring the affected region, I estimate there is 0.4 - 0.5 mm^3 less plastic than there should be on the first lines. (0.16 - 0.2mm of filament)

The "Retraction when tool is disabled" settings have no affect on the issue (they affect points in the purge block), and I don't see any other settings that look like they would affect it.

I do not see the issue with prints sliced in Cura and processed in Chroma, but that has other limitations which is why I switched to PrusaSlicer

This photo shows the issue on the side of a ~1mm thick part

[singultus]

Same problem here.

[lukasmatena]

We managed to reproduce the problem and will try to solve it for 2.2.0 release. Current release 2.1.0 is too close to try to patch it now.

[bynnek]

We managed to reproduce the problem and will try to solve it for 2.2.0 release. Current release 2.1.0 is too close to try to patch it now.

Was this ever resolved in version 2.2?

[vintagepc]

For the record I'm still observing this with 2.2.0-alpha2. The second toolchange does not perform a retraction according to the toolchange retract value. Rather, it inserts a normal retract and deretract, expecting the tool state to not be retracted for this one particular change.
I pulled this out of some example gcode with the wipe tower disabled and a custom toolchange comment. Full file available on request -

T3; RPM FROM 2
M104 S205 ; set temperature
M900 K20 ; Filament gcode
> G1 E-0.60000 F4800.00000 ; retract
M73 Q6 S23
M73 P6 R22
G1 X117.516 Y55.165 F6000.000 ; move to first skirt point
G1 Z0.200 ; restore layer Z
> G1 E0.58000 F1500.00000 ; unretract

Note the unretract in all subsequent toolchanges is correct:

T2; RPM FROM 3
M104 S195 ; set temperature
M900 K20 ; Filament gcode"
G1 X127.731 Y52.293 ; move to first perimeter point
G1 Z0.500 ; restore layer Z
> G1 E4.00000 F1500.00000 ; unretract

[ctso]

I am also experiencing this issue. Is there a known workaround other than just accepting that this is less than ideal?

[giPeteR]

I have a similar problem. It may be related to this one:
Multi nozzle / toolchange retraction issues #2710

[cjbaar]

FYI, I am using a custom build of 3.9.x firmware, and still getting the same issue.

[vintagepc]

FYI, I am using a custom build of 3.9.x firmware, and still getting the same issue.

That's not surprising since the issue is in the generated g-code, not the firmware.

[cjbaar]

Oh yeah. Duh :)
Well, anyway, slicer version is 2.1.0

[bubnikv]

Comment by @rtyr in Czech language, posted here for us to remember.

It may be, that there is a wrong order of retraction / deretraction performed when leaving the wipe tower.

[cjbaar]

That certainly looks much better. Do you have a translation of what the changes were? Is Roman changing a Slicer setting, or editing the g-code manually?

[bubnikv]

@rtyr changed the G-code manually.

[cjbaar]

Thanks @bubnikv. Does he explain where the change is made? Just wondering if there is something I could post-process

[rtyr]

default
purging on the wipe tower -> travel to the other side of the wipe tower (without retraction) -> retract -> travel to main object -> unretract -> print

modified
purging on the wipe tower -> retract -> travel to main object -> unretract -> print

The issue is imho caused by that unretracted travel move.

[cjbaar]

Thanks!

[buchvi]

So does this have any solution other than to manually search and delete the "travel to the other side of the wipe tower (without retraction)" lines in gcode? I tried that (using PrusaSlicer 2.2.0-rc2) and it works but with multiple toolchanges it's quite a pita.

[cjbaar]

Well I was thinking of trying to write a post-processing script, at least, to help with this. But still trying to parse the details of the g-code. If I understand what is being said, I think this is the section to focus on. The comments are my own interpretations. Can someone help me confirm that what we want is to go from this:

; CP TOOLCHANGE END
;------------------
G1 F23040                       ; max speed
G1 X90.812 Y153.125 E-0.76000   ; move to "other side" of wipe tower, while retracting
G1 E-0.04000 F2100.00000        ; leftover retraction ?
G1 Z0.400 F28800.000            ; prepare to move to main object
G1 X168.589 Y65.770             ; move to main object
G1 Z0.200                       ; prepare to print layer
G1 E0.80000 F2100.00000         ; un-retract
M204 S400                       ; max acceleration
G1 F1350                        ; max speed
G1 X168.589 Y61.634 E0.13999    ; resume printing object

to this:

; CP TOOLCHANGE END
;------------------
G1 F23040
G1 E-0.80000                    ; full retract
;;G1 X90.812 Y153.125 E-0.76000 
;;G1 E-0.04000 F2100.00000
G1 Z0.400 F28800.000
G1 X168.589 Y65.770             ; move to main object

[buchvi]

I think you aren't looking at the right spot in gcode. For me it works to remove just these lines:

G1  Y187.694  E0.0070
G1  X229.902  E2.6619
;;G1  X111.152 
; CP EMPTY GRID END
;------------------

for the first layer of the wipe tower (in this case the first layer is just one color). For the rest it usually looks like this:

G1  X111.152 Y196.481   E0.0098
G1  X229.902  E2.0759
G1  Y196.794  E0.0055
G1  X111.152  E2.0759
;;G1  Y196.481 
;;G1  X230.527 
M220 R
G1 F6000
G4 S0
G92 E0
; CP TOOLCHANGE END
;------------------

Sometimes there is only X movement, sometimes there's Y movement of just 0.001 on the same line as the X movement, sometimes the small Y movement is on another line. Sometimes it is even more complicated:

G1  X229.902 Y196.481   E2.0759
G1  Y196.794  E0.0055
G1  X111.152   E2.0759
;;G1  Y196.482 
;;G1  X230.527 Y196.481  
M220 R
G1 F6000
G4 S0
G92 E0
; CP TOOLCHANGE END
;------------------

But it's always the movement (or movements) withut extrusion just before the M220 command. Hope this helps! (Using 2.2.0-rc4 this time.)

[cjbaar]

OK, I ran some of my code through a simulator, and I see what you are talking about now. I've always noticed that when it is laying the purge lines, the last one always goes "backwards" along the Y-axis. This seems to be the move you are eliminating.

For my g-code, that first move after the official tool change end (with the E-0.76000 retraction) still seems extra, but I guess it doesn't hurt to move while retracting.

[lukasmatena]

@buchvi The original purpose of that move was to wipe the nozzle to prevent leaks after leaving the wipe tower. And it would probably work if there was a retraction before that. This was the wipe pulls material from the nozzle and this material is later missing on the model.

You removed the wipe moves, @rtyr moved the retraction before it. Both of these seem to solve the issue. PrusaSlicer should do one of these by default.

[nordurljosahvida]

I have a bunch of prints where from the beginning all the way to 48h of runtime the model is perfect but the tower keeps breaking seemingly of under-extrusion on non-sparse tower layers. the reason i need to then stop prints is collisions with completely broken towers. model, again, is perfect. this happens both with PLA over PLA and PLA over PVA, and only on non-sparse tower layers.

This is happening on both of my MK3S MMU2S.

CS says there's no way to change tower speed or vol_speed on tower. looking into p2pp now, but could this be related? A CS technician is literally printing one of my gcodes on his mmu2s as we can't seem to find a solution. tried increasing temps, lowering global max_vol_speed [although that affects the model too], and more.

Is anyone looking to implement tower speed values upstream in PS?

[lukasmatena]

@nordurljosahvida Please, do not clutter this issue, your problem seems to be different. Create a new issue and provide all necessary information (PS version, 3MF with config and so on).

[nordurljosahvida]

@lukasmatena sure, just trying not to open more than 1 new issue per day by making sure they're not related to existing ones.

[cjbaar]

I agree that the issue @nordurljosahvida is having would be different, though I have experienced it before. Unfortunately, I can't recall if I changed anything to solve it. Especially since, as you said, there aren't any parameters in slicer for controlling the wipe tower output.

[cjbaar]

Thanks to everyone here for the comments. Based on the notes from @buchvi, I created a quick python script that removes the extra moves at the end of wipe and grid sections. I have only tried it on one file so far, but I am currently 14 tool changes into a new print and the filament extrusion looks great. The script is posted here:
https://github.com/cjbaar/prusa-slicer-post-processing

[cjbaar]

UPDATE: My print just finished with about 135 tool changes. The bottom of the print looked fine. In at least the top layer (didn't watch them all), I did get a small bit of missing filament coming off the wipe tower, but only for 2/6 filaments. I may try a shot of using @rtyr method of moving the retraction if I can figure out how to code that.

[Danistra-Danstec]

I have the same issue and found the same solution regardless of this post. Thank you for the script! When I start the script I get an error

...\mmu-wipe-fix.py", line 34
print "Remove WIPE: {}".format(line)
^
SyntaxError: invalid syntax

I am not an expert of programming, so how can i use your script?

[buchvi]

I am no expert either, but I have found out that you have to use Python 2, not Python 3. There seems to be some difference in the way it uses the print command. (I have Python 2.7.17 and the script works fine.)

[Danistra-Danstec]

thanks for your quick response. Indeed it works with Python 2.

[cjbaar]

Yeah; I guess I am a bit behind on the python. I think version 2 is officially deprecated now.

[lukasmatena]

This issue should be fixed by e7ae26f. The wiping on the wipe tower is now consistent with wiping on model and extruder settings (meaning it can even be turned off). After testing the update it appears that the issue is gone and there is no additional problem such as excessive stringing etc.

If you are able to compile and test master, feel free to do so. Otherwise wait for 2.3.0-alpha1 release (which is getting close), and let us know if there is any issue regarding the reworked wipe tower wiping. In fact, any feedback is appreciated.

Closing the issue, it can be reopened if needed.

[cjbaar]

That's great. Thanks for the update, @lukasmatena