I don't know how to reopen an issue so i'm issuing it again:
I am developing a dual extrusion printer and I ran into the issue where one of the two heads (they are spaced 23.7mm from each other in the Y axis) is resting on the already printed object when the toolchange is happening.(I am using the ooze skirt, it's distance from the object is 2 mm) The nozzle that is above the already printed layers is melting those layers when the other head is heating up and the one above the print is cooling down. The delta temperature is set at -10. I tried with 0 delta temperature but then the oozing is too high to have a successful print. I was under the impression that when you enter the spacing between the two heads in slic3r, it will know how/where to park the printhead so both nozzles are outside of the skirt. at the moment this seems not to be the case. Is this a bug or is this normal behavior?
alexrj commented an hour ago
You need to enable the Ooze prevention for enabling such logic.
Alessandro Ranelluccialexrj closed this an hour ago
Nerveasy commented an hour ago
That's the one that raises the skirt to the top layer of the print right? I have done that but the head keeps parking 50procent of the toolchanges with one nozzle on top of the already printed layers. The distance between the nozzles is entered in slic3r in the extruder settings so slic3r should know the geometry of the nozzles?
So I as I stated in my first entry I am using the Ooze skirt/Ooze prevention which says that it will park the head outside the printed skirt on tool changes, but sometimes the head gets parked in a way that a nozzle stays inside the skirt and ruins the already printed piece.
I will post Gcode and Slic3s profiles, but I can only do that tomorrow as I am not at my work.
I am also experiencing parking not-outside-the-skirt with ooze prevention on. Using 1.2.5. After finishing with the second extruder, it places that extruder outside the skirt and leaves the first one inside the print.
Fixed test and implementation of ooze prevention standby points (wron…
…g test caused wrong implementation). #2103
Okay, this time I should have actually fixed it. Sorry.