Right Extruder generates E0, Whereas Left extruder doesnt.

[eskeyaar]

Application version
Cura 4.7, happens in old versions too.
Platform
Win 10 x64

Printer
Mostly all printers.

Reproduction steps

1. Load the attached model, choose ultimaker s3 or any dual machines
2. Choose left extruder for base model and right extruder for top model
3. No Prime tower, skirt or brim enabled.
4. Generate gcode

Actual results

Maybe im wrong but why does the Left extruder when applied for top model, has E16 when starting to print over the right extruder base model , but when right extruder (E0) starts printing over the left extruder base doesnt have ? Both method of choosing extruder is without prime tower, skirt or brim enabled.
This results in few flow issues when right extruder starts printing on top of the left extruder.
Yes, using prime tower helps, but im trying to print without prime tower or with any bed adhesions.

Expected results
The Right Extruder should generate E16 when printing over the base left extruder model.

Project file
Attached Project file. UMS3_B2.zip

Is it the right way of printing ? or am confused my self?

Thanks

[rburema]

Note that M104 doesn't actually switch extruders/tools, it merely sets the temperature (at least for Ultimaker machines like the S3).

[eskeyaar]

No, not concerned with M104 actually. If you see second pic, where T1 switches, and I see it generates G1 F1500 E0,
Whereas in the first picture, it has G1 F1500 E16. Why does T1 Switch doesn't give E16 Value?

[rburema]

I see, I was distracted by the highlight, sorry.

Does this really cause underflow in a printed model, or are you basing that conclusion on the gcode itself?

[eskeyaar]

yes, i see underflow in the model for first few moves.

[GregValiant]

Within each snippet the code is correct. It's what goes on at the beginning of each file that bears on this.

In the bottom snippet:
When starting with T0, it starts out extruding as a single extruder machine would. When T1 is selected in line 5044 there was no prior Tool change so "Nozzle Switch Retraction Distance" never came into play for T1. At line 5044 T1 starts out at E=0 and the filament is un-retracted.

In the top snippet:
When starting with T1, it doesn't start with T1 but rather with T0 and then a couple of gcode lines later it switches to T1. That early-on nozzle change does kick in the "Nozzle Switch Retraction Distance" and at line 5060 T0 is at E=0 and the filament at a retraction distance of 16.

In either case, While the first nozzle prints, the second nozzle has been idling along and whatever prime distance is used, probably isn't enough to make up for any oozing that occurred as it waited it's turn. Adding a line that would insure some additional prime would seem to be necessary to make up for the lack of a prime tower.

[Ghostkeeper]

GregValiant is right. Indeed having a bit of priming would help here (the UMS3 does this by itself, but otherwise Cura can also just use a skirt or something).

And that borrows down deeper into this issue. Because the actual problem then is with the top snippet: Why does it start with T0, do basically nothing and switch to T1? Here's a snippet of the start g-code where the lower model was T1:

;END_OF_HEADER
;Generated with Cura_SteamEngine master
T0                                  ;start off with T0
M82 ;absolute extrusion mode

G92 E0
M109 S200                           ;Heating T0 to 200 degrees!
G280 S1                             ;Priming T0.
G0 Z20.001
G1 F1500 E-6.5                      ;Retraction, probably to prepare for moving to the start of the print.
;LAYER_COUNT:29
;LAYER:0
M107
M104 T1 S200                        ;Pre-heating T1.
M104 S185
M204 S625
M205 X10 Y10
G1 F600 Z2.2                        ;Z hop
;MESH:B1 (2).STL
G0 F1285.7 X180 Y180 Z2.2           ;Moving to Layer Start position. Should never really happen (a warning is put in the log about this).
G1 F1200 E-16                       ;Extrusion switch retraction.
G1 F600 Z2.2
G92 E0                              ;This here is what's causing T0 to start off with E16: Here it sets the formerly -16 position to be E0.
T1
G92 E0
M109 S200
M104 T0 S100
... ; and prepare to print with T1 where it actually needs to print something.

This may have something to do with there being no adhesion. When using a brim I'm not able to reproduce the problem any more. It's properly starting with the adhesion extruder then.

[eskeyaar]

Within each snippet the code is correct. It's what goes on at the beginning of each file that bears on this.

In the bottom snippet:
When starting with T0, it starts out extruding as a single extruder machine would. When T1 is selected in line 5044 there was no prior Tool change so "Nozzle Switch Retraction Distance" never came into play for T1. At line 5044 T1 starts out at E=0 and the filament is un-retracted.

In the top snippet:
When starting with T1, it doesn't start with T1 but rather with T0 and then a couple of gcode lines later it switches to T1. That early-on nozzle change does kick in the "Nozzle Switch Retraction Distance" and at line 5060 T0 is at E=0 and the filament at a retraction distance of 16.

In either case, While the first nozzle prints, the second nozzle has been idling along and whatever prime distance is used, probably isn't enough to make up for any oozing that occurred as it waited it's turn. Adding a line that would insure some additional prime would seem to be necessary to make up for the lack of a prime tower.

Thanks for the explanation, yes I do increase the prime distance yet I can see a little bit under extrusion.
So its a not kind of bug where prior Tool change so "Nozzle Switch Retraction Distance" never came into play for T1 for the bottom snippet?

@Ghostkeeper yes, when using brim it doesn't produce the problem, but in my scenario, I wish not to use prime tower or brim.
So the " Why does it start with T0, do basically nothing and switch to T1?" is also kind of problem? I thought maybe kicking of T1, do nothing and then switch to T0 for the bottom snippet, will ensure that I don't get under extrusion.

[GregValiant]

"...in my scenario..."
I find myself in that position a lot. It generally means I'm going to have to insert some custom Gcode to accomplish what I want for "this particular print". @Ghostkeeper is the professional here, but for myself (I am a simple user) I would not call it a bug. It is an oddity though and it is effecting "your scenario". Catching this ahead of time would require a level of Printer and Gcode awareness that 99.999% of us simply don't have. We would print the file, the under-extrusion problem shows up, and it's too late to fix that print. I had to stare at those snippets a long time before it occurred to me that the problem must be at the start of the file.
I think that without experimentation there is no way to know how much extra prime would be required. Knowing what we do now - I would say that in the top snippet, if line 5061 was G92 E-5, and in the bottom snippet line 5045 was G92 E-5 then the resulting extra 5mm of prime might be either: just right - or too little - or too much. I'm positive about that.

[Ghostkeeper]

Indeed the generation of the G92 E0 and the E16 is not a bug. It's simply how Cura likes to track E values across multiple extruder plans. The filament was retracted by 16mm for the extruder switch so it needs to unretract by 16mm to get started. It doesn't matter whether you do that with G92 E-16 and G1 E0 or just with G92 E0 and G1 E16. It's still just 16mm of movement. For the other extruder this doesn't happen because it didn't retract yet with an extruder switch.

What I do consider a bug though is that it unnecessarily starts with T0 even though it doesn't print anything with that extruder then.

[eskeyaar]

For the other extruder this doesn't happen because it didn't retract yet with an extruder switch.
@Ghostkeeper so how to fix this?

[Ghostkeeper]

As far as I'm concerned it doesn't need fixing, since the printer movements are identical either way.

[GregValiant]

Can we close this or is the situation persisting?

[GregValiant]

Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed?