Mon Mar 18, 2019 9:39 am
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).
-
Attachments
-
- ImpossibleGears_V11v14.factory
- (113.53 KiB) Downloaded 35 times