Tool change retraction not done on first layer

[mdavis1863]

After watching the printer and looking over Gcode, I find that my inactive extruder is leaking a lot on the first layer, and that this is because it doesn't do Tool Change Retraction on the first layer. My start script ends with the filament fully primed in both extruders. So as T0 prints, T1 leaks all over.

I cannot put a retraction on T1 at the end of my Start Script, because one of the first things S3D does when T1 becomes active *the first time* is to do a G92 E0. I tried placing a retraction of T1 at the end of my Start Script, and the first time T1 becomes active it still does a G92 E0, erasing any memory of that retraction. So that can't work.

Every other layer works perfectly using the numbers in the Tool Change Retraction area...the "Tool Change retraction distance" is applied before the tool becomes inactive, and when it becomes active again, the "Tool Change extra restart distance" is applied. This works for T0 and T1, back and forth. It is only the first time that T1 becomes active that it starts with a G92 E0, instead of starting with a G1 Exxx command.

Wouldn't it make more sense on the first layer to apply the Tool change retraction to T1 before T0 starts printing, and then un-retract when T1 becomes active for the first time? In other words, just like all the other layers? It doesn't work that way, which seems problematic.

Maybe I am missing something, but it seems like it has undesirable effect and I can't think of a workaround. Well, I guess I would hard-code these into the tool change script and not use the clickboxes for Tool Change retraction, etc. But I don't think that is a good solution.

[mdavis1863]

OK, I made some progress to work around this. But I think this is a bug and should be fixed. I am using S3D 4.1.1.

The only workaround I could get to generate correct Gcode is the following. My T0 is printing first, and T1 is idle first, so what is missing in the Gcode is a retract of T1, and then a priming of T1 when it is time for T1 to print. Here is a workaround assuming for example toolchange retract distance is -12 and toolchange prime distance is -0.5. These are both set at the bottom of the "Other" menu.

Using these values, the workaround is to put this towards the end of the Start Script, at a point when T1 is selected:

G1 E-12 ; retract T1

Then in the Tool Change Script, I put:

{IF NEWTOOL=1 && [current_layer]=1}T1 ;T1 is not yet selected at this point, so you have to insert this.
{IF NEWTOOL=1 && [current_layer]=1}G1 E-0.5 F600 ;extrudes 11.5mm to prepare for printing.

This works, and generated a successful print. However, one really odd thing: it does not work correctly if I use [toolchange_retract_distance] and [toolchange_prime_distance] instead of putting in fixed numbers. In other words, merely referencing these values by variable name instead of a fixed number alters the behavior of the slicer! As bizarre as that seems, it appears to be true. (*)

It suggests that variable names like [toolchange_prime_distance] are put in some kind of intermediate code, and then the slicer passes through and resolves these to generate Gcode, but it counts variable references that it resolves, and can actually behave differently depending on the status of those counters. The key point – these undocumented variable names are useful, but be aware that merely referencing a variable can alter the slicer behavior. To test this for any particular case, you can generate a factory file with a variable name reference, and one with a fixed number instead of a variable name, and then compare the Gcode files. The Gcode files should be completely identical, except for the header comments which repeat all the script text, and so literally contain whatever you typed for a script. The operational part of the Gcode should be exactly the same, if the variable reference is functioning as intended. If that is not the case, then you have encountered the same odd behavior I did, and might want to cease referencing that variable name.


(*) Let me explain exactly what happens for completeness, although it is not super interesting. First of all, one minor trick is that if you set these two values to -12 and -0.5 in the "Other" menu, then toolchange_prime_distance is not set to -0.5, but rather to +11.5. So the Gcode required for +11.5 instead of -0.5 is slightly different, like this:

{IF NEWTOOL=1 && [current_layer]=1}T1 ;T1 is not yet selected at this point, so you have to insert this.
{IF NEWTOOL=1 && [current_layer]=1}G92 E0.0000 ;reset so that +11.5 is the correct movement.
{IF NEWTOOL=1 && [current_layer]=1}G1 E[toolchange_prime_distance] ;extrudes 11.5mm to prepare for printing.

Well, this does generate correct Gcode and correct behavior at that point. BUT IT CAUSES A CHANGE IN OTHER GCODE ELSEWHERE. What happens is that the next time layer is changed, thousands of lines later, when T0 is ready to print, then T0 is not primed. The G1 E-0.5 that should appear thousands of lines later is missing. So extruder T0 would start printing layer 2 with the filament 12mm back up in the extruder, from the previous toolchange retract. So in other words, the code is intent on skipping a prime step, and if you manually insert one referencing [toolchange_prime_distance], it will delete a different prime step (for the other extruder) later in the Gcode. It tends to suggest that the referencing of [toolchange_prime_distance] by itself increments some kind of counter in the software, and then it gets confused thinking “oh I already did a prime movement” when in fact it had not. Trying to replace a previous missing prime movement caused the SW to delete a different unrelated later prime movement.

I know this is probably hard to believe. So I attach a factory file. There are hard numbers in the Start Script and Tool Change Script to manually do the retract and prime of T1 on layer 1, as described above. When this factory file is sliced with S3D 4.1.1, these extra inserted movements for T1 appear at line 301 (retract) and 1383 (prime). I am referring to lines in the text file, not “lines” in the Gcode preview pane. For example, I open it with Geany editor, and these are the text file line numbers. And note that line 2291 is the first prime of T0 after a layer change (i.e., the start of layer 2). It is :
G1 E-.05 F600.
But, if you modify the Start Script and Tool Change Script to use [toolchange_retract_distance] and [toolchange_prime_distance], instead of the hard numbers in this factory file, then you will find that the Gcode for T1 remains correct (i.e. the variable names do get filled in with the correct numbers in the Gcode, at the aforementioned lines 301 and 1383). But, now the prime movement at 2291 is missing! The first extruder command in layer 2 will be for extruder T0 and will be:
G92 E0.0000
This erases memory of the previous retraction. So layer 2 will start printing with the filament still 12mm back up in extruder T0 (causing that much of the layer to be "printed" with nothing coming out of extruder T0).

[mdavis1863]

I have posted much text, but the bug is really simple. With dual extruder, the Tool Change Retract and Tool Change Prime (i.e. restart) are not applied on the first layer.

Of course, you don't need to do a Tool Change retraction and prime for the first extruder on the first layer, because it starts extruding right away. But the slicer should do a Tool Change Retract followed by a Tool Change Prime for the second extruder to be used on that first layer. That is what is missing.

All the rest of my long post is just about working around this bug. The bug itself is simple. The title of the post says it all.

[S3D-Jake]

If you take a look at the CR-X's starting and tool change scripts you can see how to make sure that the second tool used on the first layer gets a tool change prime applied.

Starting Script

Code: Select all

G28 ; home all axes
G1 Z10 F600 ; raise Z axis
M190 S[bed0_temperature] ; preheat bed
M109 S[extruder0_temperature] ; preheat extruder
G1 X5 Y10 Z0.2 F3000 ; move to wait position
G92 E0 ; reset extrusion distance
G1 E90 F1500 ; load filament
G92 E0 ; reset extrusion distance
G1 X160 E15 F600 ; prime nozzle
G1 X180 F5000 ; quick wipe

Tool Change Script

Code: Select all

G92 E0 ; zero extruded length
G1 E-5 F1800 ; standard retract
G92 E0 ; zero extruded length
G1 X[next_position_x] Y[next_position_y] F[travel_speed] ; move to ooze shield/prime pillar
G1 E5 F1800 ; unretract
G92 E0 ; zero extruded length
G1 E-[toolchange_retract_distance] F[toolchange_retract_speed] ; toolchange retract
G92 E0 ; zero extruded length
T[new_tool] ; perform toolchange
G92 E0 ; zero extruded length
G1 E[toolchange_prime_distance] F[toolchange_retract_speed] ; toolchange prime
G92 E0 ; zero extruded length

Another way to enforce a prime of the second tool would be to cause the skirt to be several outlines long and select "All Extruders".

[miguelangel.nubla]

Another way to enforce a prime of the second tool would be to cause the skirt to be several outlines long and select "All Extruders".

I think you are looking at this the other way around. The problem is not that we don't have the tool primed on the first layer, is that the tool is already primed, retracted and ready to be un-retracted to use, but is instead used directly without the un-retraction.

I am also experiencing this problem.

I get why tool change should be treated differently in the first layer vs everywhere else, but
Why not last layer also? Why not on supports? Why not on dense supports?...
Is that the correct way to deal with that scenario?
That creates a problem where you need a different tool change for each case.

Ideally, tool change is handled by the firmware transparently to S3D from a simple call to T[n] (In my case I am using Duet3D tfree[n].g and tpost[n].g, and gcode has no way to check for layer number)

If a user/printer really needs the current behaviour (not retracting on the first layer because the tool is already primed) there is support for this without creating multiple tool change scenarios, and that is pre-retract on the start script(or on the tool change script), so when the tool is unretracted on the first layer everything is ready.

In short, the current behaviour prevents some users like me from doing this right altogether, while retracting on every layer the same would enable anyone to do tool changes their way, even recreate the current S3D behaviour.
Therefore this is a bug.