Initial extruder other than T0 causes an unnecessary switch

[stuartpb]

If I set up a print that only uses extruder T1 and never uses my T0 extruder at all, the T1 switch at the beginning of the procedure is preceded with a massive G1 F1200 E-16 retraction on the initial T0, which makes a very unpleasant noise from the stepper motor, as that filament is not able to move with a cooled-off hotend:

;FLAVOR:RepRap
;TIME:1074
;Filament used: 0m
;Layer height: 0.15
;Generated with Cura_SteamEngine 3.1.0
M190 S60
M104 T1 S200
M109 S0
M109 T1 S200
M82 ; absolute extrusion mode
; BEGIN START G-CODE
G90 ;  set positioning to absolute
G28 X Y Z ; home XYZ at default_value home feedrates
T0 ; home on the right extruder
G92 X0 Y0 Z0 A0 B0 ; define zeroes
M132 X Y Z  ; Recall stored home offsets
; END START G-CODE
M83 ; relative extrusion mode
;LAYER_COUNT:50
;LAYER:0
G1 F1200 E-16 ; <=================== !!!
T1
M109 S200
M107
G0 F1200 X6.54 Y4.837 Z0.3
;TYPE:SKIRT
G1 F600 X6.488 Y4.979 E0.00754
G1 X4.989 Y8.802 E0.20487
G1 X4.949 Y8.899 E0.00523
G1 X3.643 Y11.964 E0.16622
; ...etc...

Essentially, this code needs to recognize that the first extruder isn't one you need to "switch" to.

[stuartpb]

Indeed, now that I think about it, it seems like this assumption that the active extruder will be 0 will be even more of a problem in 3.2, as #640 sets the G-code to start with a T command switching to the real initial extruder.

[stuartpb]

The other way to fix this (short of initializing current_extruder to the start_extruder_nr in the GCodeExport constructor, which looks like it'd require significant refactoring?) would be to initialize current_extruder to -1, then add an else if (current_extruder < 0) {startExtruder(new_extruder); return;} here to initialize on the first call to switchExtruder.

[jackha]

@stuartpb Thanks for reporting and analysis.
Devs, see: CURA-4751

[Ghostkeeper]

This E-16 comes from putting the nozzle into parking position, because Cura assumes that T0 is active, heated up and the filament is in position for printing after the start g-code is completed.

There is an assumption there that T0 is active, which has been brought up before: Ultimaker/Cura#1819 and several other times that I remember. But barring that, I think assuming that the active extruder is heated up and brought in position to print is fair. Instead we'd rather need a way for the printer to say which toolchain is active at the beginning of a print, either via the printer definition file or an active (wifi/USB) connection. But this is much more complex.

Or did I understand your problem wrongly?

[stuartpb]

Yeah, no, I'm just describing that the problem is the slicer assuming the initial extruder of the routine is T0, which isn't necessarily the case (as mentioned here).

[s00500]

It would be great if this retraction could be turned off completly since it can be a problem for some printers

[diegopradogesto]

Our manager removed this from the planning. It won't be fixed soon.

[FalconFour]

This causes me a problem because I load one extruder with one material, and one with another... and the models I choose to print are using one extruder or the other - not both (I have no need/interest in dual extruding single prints). So when I start a print using only extruder 2, it goes through its start Gcode, then unexpectedly snorts back a whole length of filament and starts printing!

The resulting code:

   ;Put printing message on LCD screen
   M117 Printing...
   G92 E0
   G1 F1800 E-4
   ;LAYER_COUNT:140
   ;LAYER:0
   G1 F1200 E-16
   G92 E0
   T1
   G92 E0
   M107
   G0 F3600 X119.408 Y64.625 Z0.3
   ...

See how my start Gcode ends (after "Printing..."), then it goes on and makes an E-4 call, then an E-16? I'd been trying to debug why the printer primes itself (with my start Gcode), but then retracts and prints an empty brim for almost a whole minute. :(

No way to avoid this?