Wipe tower issue with multiple independent extruders

[3dprintingworld]

Version

2.20+win/64

Operating system type + version

Windows 10

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

Muldex IDEX Duet RRF 3.3.1 (issue does has nothing to do with the printer)

Behavior

With a print that contains multiple independent extruders and the wipe tower is selected, when a layer is finished before the tool change, the active tool retracts then moves over the wipe tower and unretracts, then preforms the tool change.

I dont understand why after a layer finishes why it moves above the purge tower and unretracts. There is no reason to move above the purge tower with multiple extruders and the unretraction should not take place until after the tool change. I am told that it might have something to do with "Ramming" but I dont have the "single extruder mult material" box checked and have set the ramming settings and all MMU setting to zero.

If I turn off the wipe tower then the TC retraction acts properly. It retracts at the last move, then unretracts after the tool change when its in position to start the next layer.

[lukasmatena]

I think this is there more or less historically, from times when the wipe tower always rammed the previous filament. I don't remember all the details, but from what I do remember, it does not have a simple fix. The rules about retractions and about who does them (gcode generator vs wipe tower) are quite difficult to get right under all circumstances (firmware retractions, single / multi extruder printers, custom toolchange gcodes, wipe tower enabled / disabled and similar). It is definitely possible, but by far not a one line fix.

Does it cause any actual issues, apart from being there?

[3dprintingworld]

Seems like this action is for MMU and not independent extruders. If you dont have the MMU box checked, shouldn't this function go away?

The issue is oozing with independent extruders. I can remove the tool change retraction, so its not doing the long retraction for no reason, then add it to the tool change macro in Rep Rap firmware. The issue then becomes the point of unretracton.

If I do the tool change retraction via the macro it will unretract with the tool is in the parked position, which allows the chance for the nozzle to ooze from the parked position to the wipe tower. I can mitigate this by saving the last position at the tool change, then recalling that position before the unretraction, but that causes unwanted moves that move over the part.

[zmaile]

Using an IDEX printer myself with the wipe-tower feature, and can confirm it creates an ooze issue (which gets dragged into the print on toolchange).

A workaround seems to be disabling the wipe tower and using a draft shield/skirt. This is still sub-optimal though as it uses more filament, takes longer, and fails more frequently from bed adhesion. However looking at the generated g-code, it does retract/unretract at the expected times when using the draft shield.

I also currently use Klipper, which now that I think about it means I could used a macro too, but I suspect that isn't something applicable to all firmwares. A quick look at marlin 2.0 suggests it has the capability, but my printer manufacturer's firmware didn't have the compiled option set, suggesting it may be an uncommon setting.

EDIT:
Another workaround is to set the toolchange retraction length to 0, and put the following into printer settings > Custom G-Code > Tool change G-Code:

G1 E-5 F{retract_speed[current_extruder]*60} ; retract extruder
T{next_extruder}
G92 E0
G1 E5 F{retract_speed[next_extruder]*60} ; deretract extruder
G92 E0
G1 F{travel_speed*60}; set travel speed for next tool movement

[zmaile]

I thought about it more, and came up with some logic that would allow any type of multi-material printer firmware to work correctly, while still allowing configuration in the slicer:

1. move to wipe tower
2. retract the amount specified in the appropriate retract_length_toolchange: the tool-tip on this textbox should specify that this in addition to the firmware value
3. toolchange
4. move to retract tower again at travel_speed: this is for any firmware that has a nozzle offset but doesn't move to the new offset on toolchange
5. unretract retract_length_toolchange + retract_restart_extra_toolchange
6. resume printing the tower

This will allow any multi-filament type to work, whether it be manual/IDEX/dual-nozzle-one-hotend/solenoid-switched/whatever.

The upside is that a firmware with it's own retraction value can still work, but recompiling is not required just to increase retraction for a specific filament or printjob. The default value of retract_length_toolchange should probably also be changed from 10 to 0 to prevent over-retraction that may cause filament to leave the extruder's gears.

[Quas7]

one more wish for the behavior of the wipe tower generation would be to print skirt (and maybe brim) before the wipe tower.
Normally, the skirt is used to prime the nozzle and get rid of blobs. But in the current version, the tower is the first thing printed and sometimes fails because of missing priming for me.

[3dprintingworld]

It seems to print the skirt before the purge tower for me. It runs the skirt around both the tower and the part. It also starts the first layer of the tower wider than the rest incase it does not start extruding right away.

[Kachidoki2807]

I also have this problem, the default retract behaviour generate looong strings between the wipe tower and the parking position.
I used a method similar to @zmaile 's one as a workaround.

Moreover, in more generally speaking about the wipe tower with IDEX, since it need a very little amount of purge volume, it would be interesting to have other patterns with large footprint to improve the stability of the wipe tower. An hollowed tower for instance, or increasing the space between the lines. Currently I use a 5x5mm tower for small prints that is more than enough, but I have to increase this size for taller prints to avoid the wiggling of the tower.

[giPeteR]

I came up with kind of solution here. It's a few simple lines of Filament Custom G-code.

[lukasmatena]

Should be fixed in 2.6.0-alpha2. Feedback appreciated. Closing.