filament change lag

So, I use slic3r 1.2.6 and I have two extruders.

Just before the extruder change, the material I'm changing from will stop from extruding for about five seconds despite the toolpath still being executed. It's like it's trying not to retract (?), wiping the nozzle along the useful part (??). But I would obviously have it retract and have my part solidly done.

Should I use some other slicing program? What's the best for dual extrusion?

You should be able to add retraction commands (and anything else you want) in the "tool change" custom G-code.

Dave

I can add to the gcode, but I can't tweak the gcode that slic3r has written but through slic3r params.

The problem is not that it doesn't retract, the problem is that slicer stops my secondary extruder, as it still works along its toolpath about five seconds before the tool change, and the printed part gets a nasty empty hole in consequence.

Edited 1 time(s). Last edit at 06/09/2015 02:09PM by Fuintur.

Have you examined the G-code that Slic3r outputs to ensure that the problem is in the G-code rather than your printer's firmware? Maybe run the generated G-code through a viewer (e.g. [gcode.ws]) to verify that the holes appear in the displayed model.

Dave

As far as I know, any gcode viewer displays the packed toolpaths (that were always right) but I do not know how to see if the extrusion amount matches what it should (that is not right). Do you know of any of such tool?

Ooh... I see. I'm emulating the extrusion width now, but the problem in the printed part doesn't show up in the gcode viewer. So it's supposed to be firmware. Okay. I'll ask somewhere at Marlin's place, I guess.

Edited 1 time(s). Last edit at 06/11/2015 06:31AM by Fuintur.

My pure guess is that the firmware is incorrectly stopping the extrusion when the tool-change G-code gets to the head of the input buffer rather than waiting for the previous (move) command to complete its execution. You might be able to fool it by putting a couple of moves right at the start of the tool change macro (e.g. change to relative, move X 5mm then X -5mm, then change back to absolute). Of course it is quite likely that my guess is wrong, but it may be worth trying.

While G-code viewers do not usually show extrusion width accurately, they do know the difference between a printing move (where there is at least some extrusion) and a non-printing move (no extrusion at all).

Dave

M400 or G4 S0 at the beginning of the tool change gcode would test that theory.

Quote
IMBoring25
M400 or G4 S0 at the beginning of the tool change gcode would test that theory.

Not if the bug was that the firmware prematurely executes non-move commands - in that case those commands would simply also be executed prematurely in quick succession. A non-printing move is safer because we know that the firmware completes a printing move before starting a non-printing move (else it would cause much bigger issues).

Dave