Cura 🚀 - [4.6.2] No 'priming' on the first activation of the second extruder (with shared nozzle)

The Ender 3 implements a priming procedure (a line on the build plate) in its start g-code. You copied this to your custom printer which would make it prime the first extruder only. After all, the Ender 3 doesn't have a second extruder.

Cura makes it prime the second extruder as well automatically by printing additional contours around the brim/skirt with all used extruders. It's visible in layer view if you have distinctive colours:

There is also an additional method to prime, the "Prime Blob". However that requires an implementation of G280 which was something that the Ultimaker firmware engineers thought up and is not implemented anywhere else as far as I know. This is not available unless the g-code flavour is set to "Griffin".

Is it not creating that additional contour for you?

Ghostkeeper on 6 Aug 2020

No, no contour at all, as I'm using a raft, not a brim nor a skirt. Sorry for not having pointed this out initially.
If I select the first extruder for the raft, the second extruder gets selected only when it's his turn for the model, so the missing 'priming extrusion' causes some missing parts in the model.
If I select the second extruder for the raft, it gets selected earlier that the execution of printer's 'start G-codes (that in this case primes the second extruder), so the problem is the same, but affecting the first extruder and in particular the first layer of the outer shell of the prime tower.

Personally I would leverage the fact that Cura knows about the shared nozzle (it is configured in my custom printer), leave the initialization of both extruder/filaments to the start G-codes (the second loaded and then retracted by a known amount, the first loaded and then left there) and enable the 'prime' extrusion associated to each extruder switch also for the first switch.
Printing a skirt or brim with both extruders would not be needed anymore and the raft would start fully working.

sisu70 on 8 Aug 2020

There being no secondary prime for the raft is indeed a bug. It's been there for a long time. I think people never really paid attention because the raft isn't used very often. I'll see what we can do.

The start g-codes are currently not powerful enough to do priming. We'd need to have a separate extruder start g-code for the first layer or something like that. Besides, it's been part of the function of Cura itself to do priming (through the skirt or brim).

As a workaround, you can add something like this to your start g-code to make it prime with both extruders:

T1
M109 S{material_print_temperature_layer_0, 1}
G1 F600 E{switch_extruder_retraction_amount, 1}
G0 X1 Y1 F5000
G1 Y51 F1000
G1 F600 E-{switch_extruder_retraction_amount, 1}
M104 S{material_standby_temperature, 1}
T0

You will probably have to make adjustments to make it work with your two-in-one nozzle. I have little experience with those.

Ghostkeeper on 10 Aug 2020

Thank you for the feedback and for confirming the bug,
I fear that any change to the start g-code would not be enough, at least in combination with a two-in-one nozzle: even when 'priming' both extruders with the start g-code, one of them is necessarily retracted by some amount when the start g-code ends and control is passed to Cura. Would there be any side-effect in 'undoing' this retracion also on the first extruder switch (as already done for all subsequent ones) ?

sisu70 on 10 Aug 2020

I'm not sure what you mean.

With a multi-nozzle printer (what I'm used to) the material is retracted out of an inactive nozzle in order to prevent it from oozing and degrading. Side effect of undoing that retraction would be that it oozes and maybe clogs the nozzle.
With a shared nozzle though, it needs to retract the filament in order to make way for the other filament. So then undoing that retraction would make the other filament crash into your inactive filament, right? I'd expect it to cause grinding, cause the feeder to lose grip on the filament, and then cause the print to fail because it's not extruding.

Ghostkeeper on 12 Aug 2020

I have the same problem. I add the start and end g-code in the second extruder. Start g-code let the second extruder can fully load the filament at first time. But it results in that when change the second extruder, more loading filament at every time.
So I must add the end g-code to retract the filament. I don't know if there is a better solution.

PatrickNTPC on 12 Aug 2020

It's really hard to follow from a description like that. Do you have a snippet (or multiple) of g-code that indicates where it's going wrong?

Ghostkeeper on 13 Aug 2020

Thank you reply. My situation is like that when printing two filaments can`t load to nozzle at the same time. Assume that the location of filaments when printed is E=0. Before print I will load first and second filament to E=-100 (or first filament to E=0 and the second filament to E=-100).
Usually I set the second extruder E-100 at start G-code. When switching from the first extruder to the sencond extruder at the first time, there is a code "G92 E=0" at beginning. It will reset the location of the sencond extruder, so the second can't load to the E=0 when printing. My feeder likes the photo below.

My test model and g-code as follow
G-code: test.txt

Another question, M109 S190 have a waitting time. To perform the waitting time after nozzle move to the prime tower, is it possible that ? It's will improve oozing at model.

Sorry again for my poor description.

PatrickNTPC on 15 Aug 2020

My Cura builds have an additional prime all extruders used on initial layer setting which may do what you want. If you want to try my builds you can find them at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file there before using.

smartavionics on 16 Aug 2020

Instead of manually doing a retraction in the extruder end g-code, doesn't the Nozzle Switch Retraction work for you? It should assume that the secondary extruder starts in a retracted position, right?

Ghostkeeper on 17 Aug 2020

Yes, the secondary extruder must start in a retracted position.
Just switching to the second extuder at first time has this problem, it works well on other layer. Because CURA can't know the initial position of second filament. CURA assume that the position is E=0.

PatrickNTPC on 18 Aug 2020

Right, yes I see. It should assume that the secondary extruder starts in a retraction position, but CuraEngine assumes it starts at 0.

So for the past 6 months the "Shared Heater" function has basically been useless :disappointed: We should be more careful with accepting external pull requests for things that we can't properly test.

Ghostkeeper on 19 Aug 2020

So for the past 6 months the "Shared Heater" function has basically been useless

Well, people have been using it and this is the first issue related to that function that I am aware of.

smartavionics on 19 Aug 2020

We should be more careful with accepting external pull requests for things that we can't properly test.

Hahahaha, that's good!

smartavionics on 19 Aug 2020

OK, back to serious mode now, please tell me how having the shared heater feature enabled makes any difference to the retraction/priming behaviour given that all that feature does is suppress some temperature changes? if there's a bug here then it surely applies whether the heaters are shared or not?

smartavionics on 19 Aug 2020

Right, yes I see. It should assume that the secondary extruder starts in a retraction position, but CuraEngine assumes it starts at 0.

So for the past 6 months the "Shared Heater" function has basically been useless 😞 We should be more careful with accepting external pull requests for things that we can't properly test.

I think that just my nozzle of 3D printer has this problem of shared heater. Maybe the other 3D printer has a different design of the nozzle. So there is no such problem. Maybe there is a kind of function that can set the initial position of filaments.

PatrickNTPC on 19 Aug 2020

Cura currently always makes the assumption that the filament of every extruder starts at the nozzle. Or at least that it does after the start g-code and priming is done. With a shared nozzle that's not going to be the case. One filament has to be pulled out, while the other is printing. They can't both be at position 0. So one of them will be retreated back and for that one there is no way to properly align it with start g-code. The only ways to align it are with the firmware prime command (G280 - the "Prime Blob" setting) and with a skirt/brim. But for the skirt/brim the filament may be so far back that it'll remove the entire brim or something.

Now that I write this I realise that it's probably not as bad as I assumed this afternoon, because there are also printers with a shared heater but not shared nozzles. For those the feature will work correctly. Maybe that's what it was tested with when it was first implemented.

Ghostkeeper on 19 Aug 2020

Maybe that's why I was asked to provide a prime all extruders option?

smartavionics on 19 Aug 2020

We've discussed this with our team and the consensus was that we should hide this feature until a fix is made. By far the most printers that have multiple nozzles also have multiple heaters for it. For users with a shared nozzle this feature is expected to work, but not working now, which gives a bad experience. The feature is essentially just incomplete to the point of not working, and we try not to ship those.

Ghostkeeper on 21 Aug 2020

Hiding the shared heater function would be grossly hypocritical given all the other long standing under-performing features (e.g. the wall overlap compensation and the thin line/gap filling, just to mention 2).

smartavionics on 21 Aug 2020

I should explain better then. We are hiding it because we believe the feature as it is now provides close to 0% benefit but does cause harm (in this case failed prints) to those who try it. We are not deleting it as yet because there is a decent chance that it can still be fixed. It's similar to how the Multiple Buildplate feature is hidden at the moment.
As for Wall Overlap Compensation and gap filling, we have definite measurable proof that on the whole it improves the print quality, at least for all Ultimaker printers that we measured it for. As a result, we've enabled those settings by default there. Yes, there are still bugs with it, but for most common cases it works well.

Ghostkeeper on 21 Aug 2020

I'm very interested in a solution in Cura for this. I'm in the process of testing the same nozzle for the first time. I think these 2 to 1 nozzles will be very popular if Cura can control them correctly in g-code.

rrileypm on 22 Aug 2020

I'm back today from vacations and it is good to see that the issue that I opened has been quite clarified: sorry for not having been clear enough initially, it seems.
Two points:
1) would a split setting for 'shared heater' and' shared nozzle' (both among multiple extruders) work or at least help ?
2) from the first replies I had understood that also in case of split nozzles the inactive extruder was initially (but after priming)
retracted, in order to prevent oozing, so I cannot understand the doubts concerning a solution common to split and shared nozzles: in both cases the 'rollback of the first retraction after priming' is missing on the first switch to an extruder different from the first used one

sisu70 on 23 Aug 2020

from the first replies I had understood that also in case of split nozzles the inactive extruder was initially (but after priming)
retracted, in order to prevent oozing,

I was wrong. It's something that only the Ultimaker printers can do currently. The Enable Prime Blob setting makes sure that the filament is at the nozzle tip for the Ultimaker 3. The Ultimaker S5 unretracts through firmware upon first using the nozzle, which can be made accurate enough through its flow sensor. So Cura assumes the filament is in the nozzle tip, which is made true through the G280 command or by the firmware.

Ghostkeeper on 24 Aug 2020

I was wrong. It's something that only the Ultimaker printers can do currently. The Enable Prime Blob setting makes sure that the filament is at the nozzle tip for the Ultimaker 3. The Ultimaker S5 unretracts through firmware upon first using the nozzle, which can be made accurate enough through its flow sensor. So Cura assumes the filament is in the nozzle tip, which is made true through the G280 command or by the firmware.

Ok, then a solution common to shared-nozzle and split-nozzles (non-Ultimaker) would still be possible, wouldn't it ?
1) priming of one extruder (e.g. the Ender-3 way, by printing a line on the side of the bed)
2) known-length retraction of the primed extruder
3) priming of the other extruder (in the same way as the first one, but in a slightly different position)
4) known-length retraction of the primed extruder
5) on each following extruder selection, including the first one
a) rolling-back (same known-length) of the retraction that closed the priming sequences
b) printing
c) known-length retraction
In my understanding currently the main obstacle, apart the bug that we are discussing, comes from the fact that steps 1 to 4 are (or can be) implemented through start g-codes, while step 5 is managed by Cura's engine: this prevents safely sharing the same retraction/rolling-back length between the two parts (it can anyway be done unsafely, meaning that there is no enforcement for a common length)

sisu70 on 24 Aug 2020

Step 5 is not entirely managed by CuraEngine. You can add start/end g-codes there too. So that solution can currently be implemented entirely within the start/end g-codes. For example through the following pseudocode:

Global start g-code:

Prime the first extruder (like with a prime line).
Retract the first extruder a fixed length.
Prime the second extruder.
Retract the second extruder with the same fixed length.

Extruder start g-code, for every extruder:

Unretract the filament of this extruder with the same fixed length.

Extruder end g-code, for every extruder:

Retract the filament of this extruder with the same fixed length.

Then the knowledge of how far to retract for a filament switch lies entirely within the start/end g-codes and there is not a conflict with the other Cura settings.
However I understood that you'll then encounter the problem that material in the nozzle chamber must still be flushed to make the colour change complete. This is not a problem for other layers when using a prime tower, but on the first layer the prime tower is only printed with the extruder of the prime tower outer shell (to improve adhesion) so not used for priming, because Cura assumes that the nozzles basically start off primed. You can still just use a brim or skirt to flush of course, like I said in my first comment.

Ghostkeeper on 26 Aug 2020

Step 5 is not entirely managed by CuraEngine. You can add start/end g-codes there too. So that solution can currently be implemented entirely within the start/end g-codes. For example through the following pseudocode:

Well, I attempted relying on start-end g-codes only and in my first experiments I also switched off (or tried to) the following features in Cura’s settings:
a) retraction/priming on extruder switch
b) Z hopping on extruder switch
c) any plate adhesion option (neither skirt, nor brim, nor raft)
In the meantime I also upgraded to Cura 4.7 (while keeping the custom dual-extruder shared-heater printer definition that I had made with Cura 4..6.2)

First of all I needed to also change the global end g-code, in order to finally retract the last used extruder, so that I now leave the printer in a condition compatible with the global start g-code of the following print; skipping this step could lead to filaments mechanical collision inside the 2-in-1 hotend at the very beginning of the global start g-code (in case the last used extruder is not the same as the first primed one).

Then I successfully tested the set of 4 g-code fragments, but I'm still noticing a weird behaviour: only on the first extruder switch the printing head is moved to the X0 Y0 position (or close to) before the execution of the extruder end/start g-codes, while on the following switches something similar to a Z-hop is performed (but not on the first switch). I though I disabled Z hops and I don’t know how to prevent the move to X0 Y0.

Please note that I was printing a stack of tiles, each tile with a single extruder and alternating extruders from tile to tile: this means that the extruder switch was always done at layer change and all layers were single extruder.

Print quality was not 100% satisfactory, in my understanding because I could not manage to perform a quick enough retraction/unretraction (because of the unexpected movements that I described above) and so left the time for some oozing.

I still think that for proper support start/end g-codes are not enough, that a 'shared nozzle' flag is needed in addition to the 'shared heater' one and that, in case of shared nozzle, extruders first priming shall be explicitly managed, not as a result of some plate adhesion mechanism or as a result of prime tower implementation details.

sisu70 on 29 Aug 2020

Sorry, referring to my previous comment, the remaining issue with the Z-hop was resulting from a mistake by me in the configuration, as I had disabled it only for the 1st extruder.
On the other hand I confirm the other issue and checked that the position reached on the first extruders switch (but not on following ones) is the "layer start" one; the movements to that position and back are each wrapped by a retraction and an un-retraction (the ones protecting long movements), so they are transparent apart from the time lost (and the resulting oozing, in my opinion).

sisu70 on 29 Aug 2020

Jesus Christ... you delete the "shared heater" from the 4.7 version... all the Geeetech users... are completely leave alone or stuck with version 4.6.2 or forcing them to go to prusaslicer or superslicer.

ldiegos on 31 Aug 2020

Please note that I was printing a stack of tiles, each tile with a single extruder and alternating extruders from tile to tile: this means that the extruder switch was always done at layer change and all layers were single extruder.

This is a known bug with dual extrusion prints in general (not related to "Shared nozzle" or priming): https://github.com/Ultimaker/Cura/issues/5383 Please move that discussion there. There is a case broken sometimes when there are layers where CuraEngine thinks an extruder is used but it then ends up not using that extruder on that layer because e.g. the part is too small to print.

Can you summarize the changes that you'd like to see in Cura, @sisu70? It's quite hard to follow your various experiments. From my understanding, your original problem can be solved in start and end g-codes. Other print quality issues notwithstanding. No?

Ghostkeeper on 1 Sep 2020

Can you summarize the changes that you'd like to see in Cura, @sisu70? It's quite hard to follow your various experiments. From my understanding, your original problem can be solved in start and end g-codes. Other print quality issues notwithstanding. No?

Yes, my original problem can indeed be solved using start-end g-codes (including extruder-specific ones), but in that way I'm colliding with the "nozzle switch retraction" functionality (the descriptions of the parameters mentions "extruders switch" as well), that I need to disable.
So my criticism is towards the current implementation of the "nozzle switch retraction", at least in case of shared nozzle, that is only partial (no management of the initialization of the extruders) and affected by the issue of the missing retraction on the first switch.
In my opinion a solution not based on g-codes would be easier for the user and more manageable for future developments, so my suggestion is to improve the way different printers are described (a 'shared nozzle' flag would be needed in addition to the 'shared heater' one) and to address extruders switches management orthogonally from other functionalities (like plate adhesion and possibly prime tower as well).

sisu70 on 1 Sep 2020

👍1

I need to add that the current solution with gcodes has the drawback, when used along the prime tower, that the extruder switch sequence is executed with the printing head still over the model, before the movement over the prime tower, so I needed to hard-code a switch XY position in the extruder-end g-code.
In addition the problem with models with two (or more, I guess) extruders used on the first layer, when using the raft (or nothing) and the prime tower at the same time, is not solved (because the first layer of the prime tower is printed with one extruder only).

sisu70 on 2 Sep 2020

Right, that makes the issue a lot more clear to me.
It's hard for me to work on this sort of thing, because Ultimaker has no printers with such shared nozzles. What's more, it's never going to be accepted into the planning because there are other things to do that do benefit Ultimaker.

I still believe that the drawback you mention can be solved with proper machine_extruder_start_pos and machine_extruder_end_pos settings.

Ghostkeeper on 3 Sep 2020

Well, I see your points, but since some support for so-called 'custom FFF' printers is already there and the changes specifically needed for these 2-in-1 hotends look to me quite marginal, let me ask whether I could try contributing autonomously (I'm an experienced SW developer, but I have little experience with open-source projects).
In the meantime I will give look at your suggestion for machine_extruder_*_pos usage, thanks.

sisu70 on 6 Sep 2020

@Ghostkeeper I'm trying to understand this one. I'm posting her because my ticket was canceled issue #8294 when I asked why the checkbox for "share heaters" was removed. I was referred to discuss it here.

I have a similar issue to this - issue #8353 . I don't think the issue is "machine_extruders_share_heater". I think the issue is the prime tower. share heater is supposed to keep the temp from giving out according to @smartavionics . That barely has to do with the raft. No matter what method is used to keep the temps consistent, the raft, skirt, or brim will still not work efficiently to prime the second color (or even a, third, or forth (which I plan on working on next)). The prime tower also doesn't work well for me using a brim or a skirt. As I explained in my other post (not enough length to purge efficiently on small prints).

I don't see why the option for shared heater was removed. It turned out to work well for me. The only issue I have left is the prime tower. The tower just doesn't function for the initial layers. I don't see why this is a bug of a shared heater and not of the prime tower itself.

I have edited almost all of the files for a custom printer (base, variants, quality, etc) for about a week strait. I looked for where I could modify the prime tower but I couldn't find the source. I really wish I could get it working. I know 3d chameleon dose it with 4 colors. I don't want to have to try other slicers. Especially after all of the work I've done. Any help on modifying the first layer of the prime tower would be appreciated!

Also please bring back the checkbox, or at least please don't delete "machine_extruders_share_heater" from fdmprinter.def.json

B-rad888 on 9 Sep 2020

We'll not delete machine_extruders_share_heater from the users' profiles yet. The intent is to fix the feature, although it's hard for us to spend time on it. You said it worked for you, but as far as we know, Cura doesn't move the filament out of the way before pushing the second filament in. How did that work for you?

The priming when you're using a raft is indeed considered a problem. When you're not using a raft, the extra skirt line (with sufficient Minimum Skirt/Brim Length) is supposed to prime.

Ghostkeeper on 11 Sep 2020

@Ghostkeeper suggested I share my method for a 2 in 1 setup. I'm quite surprised this collision thing is an issue seeing how 3d chameleon solved it long ago and with Cura. It can also be seen by installing their setup and looking under their tool changing settings how it works. Either way I'll explain in hopes of proving there is nothing wrong with shared heaters, and that the prime tower has its flaws. This took an incredible amount of time to figure out myself (weeks) so I hope it helps!

It is important to understand that shared heater is only for keeping the temperature from changing. This should be enabled for a 2 in 1 out system, 3 in 1 out system, 4 in 1 out etc. I had to unhide and enable it for the time being unfortunately. It's not the job of shared heater to move filament. That is a job for extruder start and end g-code.

Next it is important to understand that filament should never be loaded into the hotend of a 2 in 1 out system at anytime except for when printing with the given extruder. This is unlike a single nozzle system where the filament is always loaded in the hotend until it's changed. For example, right now i have a 2 in 1 out hotend. Before printing, both filaments start -75mm away from the nozzle (before the Y splitter). After printing both filaments end -75mm away from the nozzle (before the Y splitter). Each is loaded into the hotend only when needed and in use.

Next it is important to not use the prime line in start g-code. My hotend moves to the start position coordinates, but does not print the prime line from the original ender 3 pro start g-code. This start g-code prime line does not work well for 2 in 1 out setups. This is because during preheat: the start g-code runs, then selects the proper tool only after the start g-code is finished. How can we print a line when the proper tool isn't identified or selected specifically? We can't and/or shouldn't. The start g-code for Extruder 1 runs after the start g-code for the machine so this is when we should begin to use it. Tool 1 should load the filament with extruder 1 start g-code, and unload it it with extruder 1 end g-code. As well as tool 2, 3, 4 etc (respectively).

Finally to reiterate, a good tool change start/end script is needed for each extruder. Extruder start g-code should load filament and Extruder end g-code should unload it. There is however an exception to this noted at the end of the process below in important notes (2).

To explain how it works:

To start the filament is loaded -75mm away from the nozzle for each extruder.
The printer gets to temp and moves to the start position coordinates just like ender 3. It does not print a prime line.
Start g-code finishes
Tool 1 is selected: Extruder 1 start g-code extrudes 75mm of filament. (basically nothing comes out, it just to loads it)
Print starts: brim/skirt acts as the prime line, as well as a purge for leftover colors. It begins the prime tower then first color
Tool 1 finishes: Extruder 1 end g-code unloads -75mm of filament. (basically goes back to -75 before the y split)
Tool 2 is selected: Extruder 2 start g-code extrudes 75mm of filament. (basically nothing comes out, its just to load it)
Print starts again: on skirt (layer 1) or prime tower (in later layers), then moves to print. (issues with layer 1 discussed at end)
Tool 2 finishes: Extruder 2 end g-code unloads -75mm of filament. (basically goes back to -75 before the y split)
a variation of this process (4-9) continues until the end

It is important to note:

Shared heater is needed. If you set standby temps to same as printing temps it will work only until the last layer of the second color. The temp shuts off on the last layer when switching to the second color (preventing the extruder from moving). That means the second color of the last layer does not print even though the print head is still moving around in the right area. It also means that the filament won't retract back to the filament start position (-75) when finished. Discussed in issue #8353 . Shared heater prevents this.

End g-code for the second extruder does not execute on the final layer. This means the filament will not move back to the filament start position of E-75mm. There is a workaround. The end g-code for extruder should be inserted into end g-code for the machine. No matter what tool is selected running G1 feedrate E-75 in the end g-code for the machine will move the filament back to the filament start position. This ensures the printer ends with no filament in the hotend and at the right position (E-75), ready for the next print. Again discussed in issue #8353
Using this method nothing will ever collide, and it is set up to print again when finished. However, when changing filament it should be loaded as close to the filament start position (-75) as possible to prevent extruder skipping, or under extrusion at the beginning of first use. This is easy to set with a clear bowden tube and a sharpie. Just load filament into the bowden tube to the line. after that it should stay in sync at the proper distance.
To set the line for loading: extrude filament until it comes out of the hotend. Then retract the filament slowly (1mm at a time) and note when it returns to a point before the y merger. That is how i got E-75mm for the filament start position.
It should also be obvious E-75mm only works for my setup. Each y merger is different and should be setup accordingly. similar to how a z offset is uniqe.
Major benefits to this system is: 1. Any extruder can start first with no issues, 2. Changing colors before prints does not require a heat up to remove the filament. 3. If printing only one color all other extruders can be disabled in Cura leaving whatever color and extruder active (less changing filaments between prints if color is already in the system) 4. Nozzle clogs seem to be less prevalent with proper retract settings which clean the nozzle out after every retract instance. 5. It's multicolor

I hope this helps the original poster and proves that "machine_extruders_share_heater" is not the problem. It is a valuable feature for custom printers with this setup to even work. Proper setup and knowledge is required to set up. However, this setting is exclusive for a custom/modded printer after all. There is no way to change shared heater to be the factor for moving filament, as I explained each y merger is different and has to be controlled as such with tool changing to the proper retract distance. There is no one size fits all solution that can be implemented or substituted in my opinion. Each solution and build is custom, while the method is the same. Shared heater was developed to do only that, share the heater. I know others need this feature as mentioned in other posts: issue #8255 #8350 , my posts, and also in issue #5770 when it was first developed. Please add the feature back. I know how to enable it for now, so it's not a big deal for me, but if it disappears in the future due to a misunderstanding of use it will be.

I still think the prime tower is the real problem here. I think it really should be improved. The bug is with the raft not purging on layer 1. If the prime tower worked as described in my other issue #8353 It wouldn't be a problem. There is more issues with the prime tower on layer 1 though. I did mention insufficient length as a downfall in #8353 on a 2 in 1 out system. Skirt length could be increased, but no matter how big the skirt is made only the outer 2 layers of the skirt are used to purge the second color. That's is not enough for me. Somehow its hardcoded like that. The skirt, prime tower and first layer are all printed by tool 1. After that tool 2 comes in and prints 2 lines around the perimeter of the skirt or brim. That's it. then it prints layer 1 of the second color. The prime tower needs to utilize the first layer to prime.

Furthermore, I'm working up to 4 colors soon which causes even more issues. To explain. Lets say I wanted a 3 or 4 color system. Let's also say I was printing a sign face down. Well the first color would work with the prime tower base, the second color might work with a bigger model and perimeter (still its just 2 perimiters), but what about the third color? Im assuming its just 2 more perimeters. If the prime tower functioned as described in issue #8255 this shouldn't be a problem. Currently it would leave the face of the sign messy and discolored. It may not be as big of an issue for other prints where the first layer is the base and not the face.

The prime tower in Cura really isn't set up optimally for future development by ultimaker, or other manufactures of anything beyond 2 colors (it still struggles with that in some cases), and there is also the raft issue. By fixing just the first layer of the prime tower like I suggested will not only solve the raft issue, but also promote future development in multi-color printing.

I would even suggest making an option for a solid block instead of just a cylinder. This is easier to purge every color on every layer if necessary for high quality and perfect transitions. the hollow cylinder is prone to tipping at greater heights. Also making the hollow cylinder into a solid cylinder is a guess and check method between prime tower size and prime tower minimum volume. When using the prime tower I need a solid cylinder because the length it takes to fully purge. Solid blocks are much better for quality, but also wasteful. However, those are just helpful suggestions to fix dual extrusion and make it better. I'm going to have to move on to a purge bucket for my needs in the meantime.

B-rad888 on 11 Sep 2020

👍1

Hi again,

From my point of view, shared heater has to be different between the Y hotends and the "mixer" hotends(but i doubt that the problem is this), because in the geeetech for example, we need to be able to push two, three or four filaments at the same time to mix all of them inside the heater block(is not a full mixing of course, but i like how it works).

I agree with B-rad888 in the fact that the filament change have to be done with the extruders gcodes and not depends on the shared heater itself.

When you remove the shared heater in 4.7, the last change from extruder 1 to 2, stops heating and drops the temp and the printing stops(prevent cold extrusion). When i overwrite the qml with the previous one(as FieldOfView sent me) everything returns to work perfectly.

I want to suggest to add the shared heater to the printers configuration it self, not as a global variable, so on printers that have problems like the Y hotends(as far as i understood), you will be able to delete it, but to the others like geeetech M and T series, the shared heater continues working.

I want to help you with my geeetech A10M and the mixer, but i don't have enough time to read everything at the github :( sorry.

I could try to install the new versions on one laptop and starts testing i don't promise to be as fast as you need.

But as other mates said, also for me the prime tower is so obscure to understand and waste a lot of filament, so i tweak the printer and cura to use the purge cube were more or less i tested that i can purge between 15mm and 30mm of filament when using black and other light color and only when a real change color is made.

Kind regards,
Luis.

ldiegos on 11 Sep 2020

It's hard for me to work on this sort of thing, because Ultimaker has no printers with such shared nozzles.

I want to help with this, but as i said, i'm unable to spend to much time... and ofcourse, ultimakers machines are the priority.

ldiegos on 11 Sep 2020

I read some confusion related to the 'shared heater' setting: I never challenged its implemetation and usage and I never suggested its removal/deactivation/hiding. Actually I simply suggested to complement it with a separate and additional 'shared nozzle' setting, so that each of the following classes of printer could be properly described and managed by the program in the 'custom FFF' context:

single extruder, single nozzle, single heater (1:1:1)
multiple extruders with multiple nozzles and multiple heaters (N:N:N)
multiple extruders with single nozzle and single heater (N:1:1)
multiple extruders with multiple nozzles and single heater (N:N:1)
multiple extruders with single nozzle and multiple heaters (N:1:N), if they do or will exist

In other words the three concepts (extruder, heater, nozzle) should be kept distict whereas I see some confusion between them in the current implementation of some functionalities.
In addition I'm still considering that the existence of the "extruder/nozzle switch retraction" functionality explicitly puts the management of extruders switches in charge of the program rather than g-code scripts, so their usage is a workaround rather than 'the solution'.

sisu70 on 11 Sep 2020

@sisu70 among the types of printers you listed, I think some classes don't exist, such as "multiple extruders with multiple nozzles and single heater (N:N:1)". But there is also distinction between mixing and non-mixing N-in-1-out hotends. Non-mixing ones require retraction of the current filament to the standby position before feeding and priming the next one. Mixing hotend doesn't need this (and it can mix, of course).

It is true though that it's not necessary to have this distinction in the printer options. Retraction can be easily done in extruder start and end gcode.

astax-t on 12 Sep 2020

@sisu70 I'm not sure what needs to be kept distinct. there are 3 types of hotends as far as I'm aware:

1 in 1 out - Has one heater cartridge per nozzle, requires standby temperature by default if there are multiple nozzles setup to eliminate oozing while idle and is what Ultimaker uses.

2 Mixing hotends - Has one heater cartridge, can extrude more than 1 color at a time, does not need standby temperature.

X# in 1 out - Has one heater cartridge, can only extrude 1 filament at a time, does not need standby temperature.

The only setup that needs standby temps is "1 in 1 out with multiple nozzles" in option 1. All other setups should not change temps at anytime until the end. Unless a standby temp is used during filament change/swap. Which is a feature I'm not really a fan of in most instances since that can prevent the extruder from moving when it needs to. However, it can be a safety feature for filament sensors though if left untended during a filament swap. This really leaves only 2 options for every circumstance:

Constant temps all the time, or
Standby temps during filament changes and/or while nozzle is idle.

In a 4 in 1 out setup we do not always use 4 colors. Some times we only use 1 color. The option to turn on and off shared nozzle is perfect for this. We can use the checkbox to remove shared heater in this case of single color printing. If a filament sensor triggers while unattended the nozzle won't stay on. If printing with multicolor it needs to be on. Having the setting static for a printer can be limiting. I think it should be up to the user to decide on their custom printer when this feature is appropriate. It should be accessible and easily changed. It should also be visible to verify when it is infect enabled or disabled.

B-rad888 on 12 Sep 2020

@sisu70 On second glance I think you are saying retraction for multicolor should be handled by Cura? I would have to agree with @astax-t

Retraction can be easily done in extruder start and end gcode.

It may not be intuitive, but it is a simple as pasting g-code from Thingiverse for most 3d printed y splitters. Also fine tuning the tool change code is essential for quality. The dual extrusion options in Cura are somewhat limited. However, I think it's asking a lot of the developers to make such a major change when custom start tool changing g-code is the best option. Ironically though you did manage to get the developers to remove one of the main features you need to get it working.

I would suggest just accepting things how they are for multicolor. It does work quite well in my setup. You can follow issue #8255 to re-enable shared heater, and hopefully the guide above that I posted helps as well.

B-rad888 on 12 Sep 2020

@sisu70 among the types of printers you listed, I think some classes don't exist, such as "multiple extruders with multiple nozzles and single heater (N:N:1)".

Agreed, that's the case for the N:1:N case as well (as I wrote).

But there is also distinction between mixing and non-mixing N-in-1-out hotends. Non-mixing ones require retraction of the current filament to the standby position before feeding and priming the next one. Mixing hotend doesn't need this (and it can mix, of course).

Agreed, then a proper solution would be to add a third flag to the 'custom FFF' template:
1) shared heater (to be restored in my opinion, just to avoid further non-productive debate)
2) shared nozzle (to be added in my opinion, as proposed since the beginning of this discussion)
3) mixing shared nozzle (to be added in my opinion, now that I become aware of the existence of such configurations)

Flags 1) and 2) should be independent (you could set any combination), flag 3) should be requested/considered only when flag 2) is selected

It is true though that it's not necessary to have this distinction in the printer options. Retraction can be easily done in extruder start and end gcode.

As already wrote here, it is true that it can be easily done (I did starting from scratch actually), but in my opinion that approach is colliding with the "extruder switch retraction" functionality", which is today existing in rev. 4.7 and it is providing sub-optimal results in terms of print quality and speed (in combination, for sure, with the other issues with the prime tower and plate adhesion options)

sisu70 on 12 Sep 2020

@B-rad888 I'm fully aligned with your considerations about temperatures and heaters, but ...

In a 4 in 1 out setup we do not always use 4 colors. Some times we only use 1 color. The option to turn on and off shared nozzle is perfect for this. We can use the checkbox to remove shared heater in this case of single color printing. If a filament sensor triggers while unattended the nozzle won't stay on. If printing with multicolor it needs to be on. Having the setting static for a printer can be limiting. I think it should be up to the user to decide on their custom printer when this feature is appropriate. It should be accessible and easily changed. It should also be visible to verify when it is infect enabled or disabled.

... I confirm that i see confusion among 'shared heater' and 'shared nozzle', so I confirm my proposal for properly separating them in the scope of printer description. The current (4.6.2, hidden in 4.7) flag should have been named "shared heater/nozzle)", but in that case the removal would have been justified, since the 'shared nozzle' part was and is only very partially implemented (the poorly implemented part is the 'nozzle switch retraction' functionality).

In addition, I'm convinced that with a proper implementation (not based on g-code scripting) you would not need to edit your printer definition each time you switch from a single-filament to a multi-filament print.

sisu70 on 12 Sep 2020

👍1

@B-rad888

Ironically though you did manage to get the developers to remove one of the main features you need to get it working.

I would suggest just accepting things how they are for multicolor. It does work quite well in my setup. You can follow issue #8255 to re-enable shared heater, and hopefully the guide above that I posted helps as well.

As a matter of fact I implemented the extruder start/end g-codes with cura 4.6.2 and reused the same printer definition as it was when I moved to 4.7, so I never lost the 'shared heater' functionality.

sisu70 on 12 Sep 2020

@sisu70 I'm trying to see your point. You don’t like the name of the function? Also you don't think you should have to make your own g-code for each tool on a custom/moded printer? Also you think the "extruder switch retraction" functionality" is poor?

The label isn't really relevant for shared heater. Shared heater only controls the temperature and is referred to as such with "heater." That's hardly a justification for removing a feature. The drop down even states: Weather the extruders share a single heater rather than each extruder having its own heater. Maybe a “requires custom extruder g-code” label might make it clearer. Like I said before it’s not the job of shared heater to move filament, so why include nozzle?

Also the developers aren't going to make anything special for anything Ultimaker doesn't make or need. Making a custom printer/moded printer is all on you. They aren’t going to spend time coding a solution so people can add dual colors easier. Shared nozzle won’t be a thing anytime soon with the printers they develop. I would still make my own custom g-code regardless. Every setup is way to custom to rely on one setting that would magically work on all y-splitters, and mixing hotends, while still supporting ultimakers separate nozzle setup.

I’m not sure what you mean by The "extruder switch retraction “functionality”. Is that the ”extruder switch retraction distance” in Cura? That should be set to 0 with custom g-code. Or, are you talking about the extruder g-code functionality as a whole? If so look at 3D chameleon’s setup and use something similar to that for retraction at the end of the tool g-code. It works well. You shouldn't get poor quality. Mine is absolutely amazing.

In addition, I'm convinced that with a proper implementation (not based on g-code scripting) you would not need to edit your printer definition each time you switch from a single-filament to a multi-filament print.

I don't need to. If you read my explanation above my setup works pretty flawless. In pretty much every way besides Cura's purge options. Switching shared heater is an option though. If I was going to do an embedded single color print, pause the layer height, and leave the house; I might disable it just to be safe, but I don't need to. It was nice to see it there and have options. I have it visible and enabled by default. That is ideal for my printer. My example was only pointing out the necessity and convenience of visibility. It shouldn’t be hidden. Cura just made us jump through more hoops to get what we need. Nothing was fixed, much more was broken than anything.

I will agree that dual extrusion in Cura does need a revamp on the purging tower/block issue though.

B-rad888 on 12 Sep 2020

@B-rad888

@sisu70 I'm trying to see your point. You don’t like the name of the function? Also you don't think you should have to make your own g-code for each tool on a custom/moded printer? Also you think the "extruder switch retraction" functionality" is poor?

So if you are trying, please read again the title of the discussion and the original description. Let me just clarify once more that the existence of the "nozzle switch retraction" functionality (yes, configured by means of the ‘distance’ and ‘speed’ parameters and also described in its tooltip as "retraction when switching extruders"), clearly means that the retraction / un-retraction do be done at extruder (and possibly heater, and possibly nozzle) switch time is supposed to be handled by the program rather than by g-codes scripts.

Nothing was fixed, much more was broken than anything.

On this I tend to agree, but as said I cannot complain too much as I did not suffer any practical drawback, since I didn't need to define a new printer when I moved to 4.7, I just reused the definition prepared with 4.6.2 and that kept the shared heater setting alive.

I will agree that dual extrusion in Cura does need a revamp on the purging tower/block issue though.

Also on this I tend to agree, even if I would extend the set of to-be-revamped functionalities to include the "extruder/nozzle switch retraction" one (in fact you are also needing to keep it disabled, by setting the distance to 0 and mimicking the same with the extruder start/end g-codes).

sisu70 on 12 Sep 2020

@sisu70 Yes I'm trying to help. I did write a very long and extensive summary of how to make it work.

The title is actually - No 'priming' on the first activation of the second extruder (with shared nozzle) . It's because your setup is wrong. You can't leave extruder g-codes blank. You can't just copy the Ender 3 g-code. I explained why. @PatrickNTPC had the same problem. You both are not doing it right.

There is a reason that a reputable company like 3D Chameleon does it just like I described. This is because that's how it has to work. Otherwise, They would have written the code as you describe and submitted it to Cura for implementation. Just like how Creawesome mod got integrated through a 3rd party and just like how shared heaters got integrated through @smartavionics .

The problem is what you are asking might possible, but it most likely will never ever happen. Cura is made by Ultimaker. They use 2x 1 in 1 out hotends for dual extrution. They have no interest or need in coding the functionality you are describing. The only way for you to get what you want is how I described.

Those settings should not be used for single nozzle setup, because fdmprinter.def.json is designed for Ultimaker dual extrusion with 2 nozzles. Everything else is modified off of that base file. Those settings are specific to Ultimakers setup. This is why we need to create custom printers, use shared heaters, add custom extruder g-code, set up quality profiles, variant files for the nozzles, etc.

This is why the Creality CR-X uses custom extruder g-code. This is why every printer currently in Cura with dual extrusion and a single nozzle uses custom g-code. While some mixing hotends rely on Marlin Firmware to do mixing. If it was going to change it would have changed long ago. Companies would prefer a plug and play experience just like you would like, but they can't. This is how it has worked for a very long time.

My setup took a very long time to make work. It is extremely difficult. I wish it was easier, but this is what I got myself into. It looks like you are going down the same path. Unfortunately there is no other way. I'am not opposed to more options and easier set ups. However, I can tell you now though, they have no incentive to rebuild the program to do that and they won't do it. I would bet a lot of money on it too.

B-rad888 on 12 Sep 2020

@B-rad888

@sisu70 Yes I'm trying to help. I did write a very long and extensive summary of how to make it work.

Well, you made a long and extensive summary on how to make it work good enough from your point of view.

The title is actually - No 'priming' on the first activation of the second extruder (with shared nozzle) . It's because your setup is wrong. You can't leave extruder g-codes blank. You can't just copy the Ender 3 g-code. I explained why. @PatrickNTPC had the same problem. You both are not doing it right.

I made it "right", but in my opinion that "right" is not as right as it could (quite easily) be.

There is a reason that a reputable company like 3D Chameleon does it just like I described. This is because that's how it has to work. Otherwise, They would have written the code as you describe and submitted it to Cura for implementation. Just like how Creawesome mod got integrated through a 3rd party and just like how shared heaters got integrated through @smartavionics .

I read this as "it is right because it is right". Not really convincing.

The problem is what you are asking might possible, but it most likely will never ever happen. Cura is made by Ultimaker. They use 2x 1 in 1 out hotends for dual extrution. They have no interest or need in coding the functionality you are describing. The only way for you to get what you want is how I described.

Well, I see support, in the program, for 'custom FFF printers' and I saw support for 'shared heaters', so for some reasons Ultimaker is interested in supporting functionalities that they are not implementing in their own printers.

Those settings should not be used for single nozzle setup, because fdmprinter.def.json is designed for Ultimaker dual extrusion with 2 nozzles. Everything else is modified off of that base file. Those settings are specific to Ultimakers setup. This is why we need to create custom printers, use shared heaters, add custom extruder g-code, set up quality profiles, variant files for the nozzles, etc.

I don't think that those settings (I guess you are referring e.g. to the nozzle/extruder switch retraction) are dedicated to Ultimaker printers, at least this is not formally stated anywhere. It could be true in practice, but then this introduces an inconsistency with the declared support for printers from other makers and for custom ones.
The 'shared heater' thing succeeded in some way before being removed (hidden) and please remember that we have been told that the removal (hiding) is a temporary one. I'm aligned with you that the removal/hiding did not improve the situation in practical terms, but formally speaking it helped in delivering a more consistent, even if reduced, set of features.

This is why the Creality CR-X uses custom extruder g-code. This is why every printer currently in Cura with dual extrusion and a single nozzle uses custom g-code. While some mixing hotends rely on Marlin Firmware to do mixing. If it was going to change it would have changed long ago. Companies would prefer a plug and play experience just like you would like, but they can't. This is how it has worked for a very long time.

Are you saying that you know that Ultimaker already refused integrating in Cura proper support (not through scripts) for shared heaters/nozzles ?

My setup took a very long time to make work. It is extremely difficult. I wish it was easier, but this is what I got myself into. It looks like you are going down the same path. Unfortunately there is no other way. I'am not opposed to more options and easier set ups. However, I can tell you now though, they have no incentive to rebuild the program to do that and they won't do it. I would bet a lot of money on it too.

They did accept external contributions targeting features that they don't market (e.g. shared heaters) and we are not talking about a large restructuring of the program, just additions of flags in the printers definition and the usage of those flags in a few spots in the code (without changing in any way the behaviour of the flags configuration corresponding to Ultimaker printers).

sisu70 on 12 Sep 2020

👍1

This thread has grown quite long, and I've been watching it closely.

I've played around with Cura 4.7...with my setup files working from 4.6.2...so I still have the shared nozzle feature intact.

I have one of these hotends:
https://www.amazon.com/gp/product/B07ZRJRRH7/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

I seem to have both extruders working individually, but I'm unable to make a 2 color print work.

As the title of this thread says, the second extruder won't prime on the first layer. I can't seem to get it to prime on any layer for that matter. I am also experiencing the cool down issue with the hot end.

I know you just can't copy and paste gcode from other printers and expect good results, but I'm at my wits end trying to figure out a way to make a successful print with 2 colors. I've tried several combinations of gcode...each of which has not fixed my printer.

I respect that Ultimaker provides Cura free, with a main focus on supporting their own products. However, I look at differently. Since Ultimaker has provided ways to customize their software to almost every printer setup, I feel there is a responsibility to add features they don't necessarily plan to use in their equipment. These 2 in 1 out hotends are very popular. They solve lots of problems we tinkerers encounter. I see the priming problem and the temperature issue as a bug in the software that should be corrected with whatever time is necessary to complete the software product.

In the meantime, if someone could take a look at the hotend I'm talking about (above) and offer any suggestions as to how I can configure my start and end gcodes for my machine and my extruders...I would greatly appreciate it. I built my machine from scratch. It's basically a CR-10 with this hotend. It prints great in one color.

I'm trying to work out the correct retraction distance through trial and error.

rrileypm on 13 Sep 2020

I will quote a developer @ghostkeeper from a different post:

Indeed the authors of the profile never added any second extruder. Cura doesn't know that it's possible. And if it is, it doesn't know the nozzle offsets, where to go to switch extruders, or how to switch. We don't have enough information to select 2 extruders, so we can't. To make this work, you'd need to add additional extruder definitions to Cura. We can't add these extruder definitions ourselves, since we don't have every printer on the market at the Ultimaker office, so we're really just dependent on community contributions to maintain those profiles.

Did I argue that it's unfair and demand to support my custom printer? Or did I find a solution for my custom printer to work? What you fail to understand is when you switch from a stock printer or start from scratch you become the manufacturer and developer. It is your responsibility to create and develop. If you find a solution great! If you share it with the community great! However, it is up to you to solve your own issues in the development phase. Cura is not the only slicer. You can try others but the situation remains. It's not their responsibility to develop a free software for you and your unique and custom printer.

@rrileypm
You guy's are free to mod away for your own needs. I provided a wealth of info on how to do it above. That is much more than I started with.

@sisu70
Since, it is so easy and necessary to do it differently that everyone else currently dose it. Please feel free to make the necessary changes and submit them to Cura. You seem to know what is necessary. I'm sure if it's as good and simple as you say they will be glad to incorporate it.

B-rad888 on 13 Sep 2020

Did I argue that it's unfair and demand to support my custom printer? Or did I find a solution for my custom printer to work? What you fail to understand is when you switch from a stock printer or start from scratch you become the manufacturer and developer. It is your responsibility to create and develop. If you find a solution great! If you share it with the community great! However, it is up to you to solve your own issues in the development phase. Cura is not the only slicer. You can try others but the situation remains. It's not their responsibility to develop a free software for you and your unique and custom printer.

Support for shared heaters/nozzles isn't (wouldn't be) dedicated to a specific printer model or maker, but was introduced in the context of 'custom FFF' printers; the same applies to the 'nozzle switch retraction' functionality, which is not dedicated to Ultimaker's printers and that is expected to work for any multiple-extruder printer.
Unfortunately the combination of the two functionalities (+ prime tower + plate adhesion) is/was buggy, so I think I was right in opening this bug report. As a matter of facts it has been recognized as a bug, even if the first, temporary, legitimate reaction (hiding of the shared heaters checkbox) is not the one I was expecting or wishing.
What you fail to understand is that I'm absolutely ready to contribute to a better implementation and I'm not expecting that Ultimaker necessarily give any priority to this issue.

@sisu70
Since, it is so easy and necessary to do it differently that everyone else currently dose it. Please feel free to make the necessary changes and submit them to Cura. You seem to know what is necessary. I'm sure if it's as good and simple as you say they will be glad to incorporate it.

I just compiled CuraEngine on my PC and I'm currently able to debug the code during Cura's usage ...

sisu70 on 13 Sep 2020

@sisu70 Really I still don't get the issue. Your setup just needs custom g-code setup and fixed. Everything works fine and the prime tower needs a layer 1 fix. I think this whole thing is kind of getting out of hand, and now we have a missing feature. I'm going to have to step out of the conversation now. I provided what I can. Good luck!

B-rad888 on 13 Sep 2020

Ok. I apologize if my expectations are too high on the developers. Cura has been my go-to slicer for years. I've tried them all. No other slicer even comes close to Cura in my opinion.

I studied the information above and tried several gcode scripts in start and end for both extruders and the machine.

In my case I can't control T1. When the machine changes colors T1 appears in the gcode...but the motor for T0 runs instead.

I need to troubleshoot the firmware for this I guess.

The solution I think on the Cura end is to somehow disable the cool down of the single hotend during color change. To me...the concept of a shared heater should logically assume that a cool down isn't desired. That's really all I'm asking for...so I don't have to edit every gcode script before printing to remove the cool down's.

rrileypm on 13 Sep 2020

I've done some more checking in Cura 4.7.1.

I have a 2 color print. A simple ring with 2/3 of the layers (top and bottom) with T0. I have the middle 1/3 with T1.

I saved the gcode and opened it in Notepad+ to look at it.

When it comes to the color change, it never switches to T1. It stays on T0 throughout the code. I put some flags in both start and end custom gcode places to search....and only T0 appears.

So now there is a problem with the actual extruder changes.

rrileypm on 15 Sep 2020

Skirt length could be increased, but no matter how big the skirt is made only the outer 2 layers of the skirt are used to purge the second color. That's is not enough for me. Somehow its hardcoded like that.

It's not hard-coded. It's extruding just enough to print the Skirt/Brim Minimum Length for that extruder, so I'd expect that increasing that setting will make it prime more.

Also making the hollow cylinder into a solid cylinder is a guess and check method between prime tower size and prime tower minimum volume.

It should be giving a warning colour if the volume would exceed the volume of the prime tower. However this warning seems to look only at the current extruder, not at the total sum of the volumes of all extruders. I've made an adjustment to that here: https://github.com/Ultimaker/Cura/commit/a1c3c44ed0dc81d5153df9e88087a6498a6d4b08 Thanks for pointing that out.

When you remove the shared heater in 4.7, the last change from extruder 1 to 2, stops heating and drops the temp and the printing stops(prevent cold extrusion). When i overwrite the qml with the previous one(as FieldOfView sent me) everything returns to work perfectly.

The interface element was removed, so the g-code should remain unchanged. It's also still in the settings list if you have the Printer Settings plug-in installed. The removal was a decision made in a meeting with the entire Cura team, not just me. It was like Sisu70 says done to give a better user experience. We realised that it would be annoying for an expert user that knew the risks.

I want to suggest to add the shared heater to the printers configuration it self, not as a global variable, so on printers that have problems like the Y hotends(as far as i understood), you will be able to delete it, but to the others like geeetech M and T series, the shared heater continues working.

It is currently part of the printer's definition. Not a global variable. Definition authors who know what they're doing can add it to their printer.

In a 4 in 1 out setup we do not always use 4 colors. Some times we only use 1 color. The option to turn on and off shared nozzle is perfect for this.

With a single-extrusion print, it shouldn't go to stand-by temperature, initial/final printing temperature at all, or go to 0 when an inactive extruder is no longer used, right? What's the harm in leaving it enabled then?

Cura is made by Ultimaker. They use 2x 1 in 1 out hotends for dual extrution. They have no interest or need in coding the functionality you are describing.

Also consider that I do have heart for Cura and its users and would like to help. I just can't justify spending time on it from my boss. If that's just a few minutes then nobody cares, but features like this would easily take me hours (considering the significant time to even read through this topic) and I can't properly test them on a printer either. Yes, Ultimaker doesn't like to spend time on helping users that don't pay for their printers, but if there's something that we developers can do that's not spending (too much) time but helps a great deal, then I think everyone is better off.

When it comes to the color change, it never switches to T1. It stays on T0 throughout the code. I put some flags in both start and end custom gcode places to search....and only T0 appears.

So now there is a problem with the actual extruder changes.

@rrileypm Maybe it's best to start a separate thread for that issue. With a project file and filled-in template, so that we can know exactly what your situation is and try to reproduce it.

Ghostkeeper on 15 Sep 2020

Putting the most important response in a separate message:

In addition I'm still considering that the existence of the "extruder/nozzle switch retraction" functionality explicitly puts the management of extruders switches in charge of the program rather than g-code scripts, so their usage is a workaround rather than 'the solution'.

Their intention is to allow configuring this distance by someone who doesn't know how g-code works or even what it is. Consider that the people in this conversation (or generally on Github) are all experts, but Cura needs to be able to allow non-experts to print properly as well. The great majority of our user base never goes as far as to adjust more than 4 settings. I'd argue that most users would expect the nozzle switch retraction to work properly for them, so that they don't need to meddle with the Machine Settings screen at all and don't need to understand g-codes. So yes, I'd think that having a shared nozzle would need to adjust how the nozzle switch retraction works. Specifically, it would need to make sure that the filaments don't collide.

I think herein lies the heart of this issue. You can work around the issue by disabling the retractions that Cura does and implementing your own. But you shouldn't need to.

Ghostkeeper on 15 Sep 2020

👍1

@Ghostkeeper

so I'd expect that increasing that setting will make it prime more.

Yes, but then I need at least half the bed for the distance around the perimeter to swap colors sufficiently. I also prefer using a brim. That's very wasteful for space and material. The best solution will be a layer 1 prime tower fix or purge bucket. I can't find where the prime tower is coded. I would make the changes. I have moved to a purge bucket until I can find it.

With a single-extrusion print, it shouldn't go to stand-by temperature, initial/final printing temperature at all, or go to 0 when an inactive extruder is no longer used, right? What's the harm in leaving it enabled then?

There is no harm. Turn it off on single color print for peace of mind with a filament sensor or layer pause, if you know it will be unattended for a long time. Who wants a nozzle idle at 205c during a filament runout while they are at the grocery store? Shared heater is not required for one color anyway so why have it on? No harm if it is on, but no harm if it's not on with bonus peace of mind. The option for visibility to switch does have benifits.

It was like Sisu70 says done to give a better user experience. We realized that it would be annoying for an expert user that knew the risks.

It doesn't provide better experience. Even @Sisu70 said it shouldn't have been removed in that same post. The setting is exclusive and required for all y splitters and some mixers. Now every user setting them up has to unhide it. That's kind of opposite of a better experience. More tickets will be created now asking how do i get the temp from changing, More tickets will be created asking where the feature is, and how do I activate it. What about those users who dont know about machine files? Before we would print y-merger, select shared heater, enter extruder g-code from thingiverse, done! Now we have to edit xprinter.json or edit MachineSettingsPrinterTab. That's a much worse experiance.

Their intention is to allow configuring this distance by someone who doesn't know how g-code works or even what it is. Consider that the people in this conversation (or generally on Github) are all experts, but Cura needs to be able to allow non-experts to print properly as well.

I tried to explain its not possible. Take the Creality CR-X. It uses
Nozzle switch retraction distance: 16
Nozzle switch retraction speed: 20
Nozzle switch retract speed:20
Nozzle switch prime speed: 20
It still requires custom start and end g-code for the extruders and still requires extruder definitions. The extruders have to know what to do.

A good setup does not use those retraction settings: They are 0 with custom g-code. for better quality. See 3D chameleon extruder g-code to see why.

Either way custom extruder g-code is required. nozzle switch retraction settings do not dictate proper operations for switching extruders. The operation is different from ultimaker to y mergers. So we need g-code to do it. We would need a completely different extruder operations set for y mergers under dual extrusion:

Y spliter checkbox ( for correct switching actions)
Shared heater (for stable temps)
Filament start position (From before y merger)
Extruder 1
Extruder 2 etc
filament retreat distance (To before y merger)
-with all the logic to make this work (if t0 starts at start position x move to x) etc (not fun for every possible option and config!)
-Due to order of operations: start g-code prime line would still not work, before extruder g-code operations
-Plus all of the other nozzle switch retraction speed settings already in place (They already work for it, see CR-X)

You can work around the issue by disabling the retractions that Cura does and implementing your own. But you shouldn't need to.

I still don't think everyone understands this. Everything is setup to work fine! The extruders have to know what to do. They need start/end g-code for the parameters I listed. Nozzle switch retraction needs no changes regardless. It's obviously compatible with the CR-X.

All Y-merger/ mixer installs should not have to suffer because some people think g-code shouldn't be required for extruder operations. It's like saying start/end machine g-code shouldn't be needed. The printer should just know what to do.

I suggest enabling shared heater, with a tag "Exclusive for y mergers, custom extruder g-code required." No "Fix" or one size fits all solution will ever be made. These y mergers are for custom printers after all. Why is it so absurd that custom g-code is required?

Yes I edited multiple times. It seems no matter how I explain it more info is needed.

B-rad888 on 15 Sep 2020

Thanks @B-rad888 . I tried many methods, and indeed this problem of loading filaments can be solved through G-code. But I must set 「Nozzle Switch Retraction Distance」 to 0, otherwise it will cause some errors.
About the problem of the prime tower, I tried to add the brim and to set「Bulid Plate Adhesion Extruder」to second extruder. It's seem good. The model and g-code as follow (cura 4.71 / enable extruders_share_heater ):

002.txt

PatrickNTPC on 16 Sep 2020

@PatrickNTPC Your welcome. I'm glad you figured it out! G-code is really the only way to go in my opinion. Every y-merger setup is extremely unique.

Also, Thank you, for the tip! I haven't tested it yet, but switching to Extruder 2 for the build plate brim or skirt seems to look promising while using a prime tower brim! This could solve the layer 1 fix I kept mentioning!

I do have a purge bucket working right now. It seems to reduce waste by at least 1/2 if not more, depending on the model. Also reducing print time by 1/2 depending on the model. I'm glad I got pushed in this direction looking for a solution to the prime tower.

This is all custom g-code as well. Just one more reason I support custom extruder g-code. It really makes me think now that an all in one y-merger solution might even be a bad idea. Next people would demand support for purge buckets with no g-code. lol

B-rad888 on 16 Sep 2020

I see customised [extruder] start/end g-code more as a crutch for when Cura doesn't properly support something, a very flexible but also difficult option to change. But if Cura claims to support something, it should support it, not needing other adjustments too. So I'm rather against adding a warning message saying you'll need to adjust the start/end g-codes manually when you enable a setting. Cura should adjust the start/end g-codes automatically for you. Preferably through CuraEngine.

Ghostkeeper on 17 Sep 2020

Technically Cura supports shared heater properly with no bugs. It's the extruders that aren't supported, which is a complement to shared heaters. These are 2 different feature sets. The message is just to alert users their setup will need additional configuration. If extruder support was a thing: The shared heater checkbox would still need a message instructing users to enable the correct extruder operations. Mixing hotends need shared heater, but different extruder operations than a 2 in 1 out setup.

G-code isn't a crutch for shared heaters or even used to reference shared heaters in anyway.
G-code is the only current option for extruder operations.

Also extruder operations can never be fully automated. The parameters for a 2 in 1 out setup will need to be manually input whether in g-code, or in Curas interface. Extruder operations are different for mixing hotends and need very different parameters to be manually input. Shared heater is a standalone feature which should be enabled for many different types of extruder operations. All of which need additional configuration; Whether it be g-code or manual inputs into the interface.

B-rad888 on 17 Sep 2020

Sorry for not having followed this up recently.
Looking at the most recent contributions here, I'm back to my first proposal:
1) rollback the hiding of the checkbox corresponding to the 'shared heater' flag
2) add a new flag (and checkbox) for 'shared nozzle'
3) introduce in the code specific support for shared nozzle, executed conditionally to the corresponding flag

B-rad888 would ignore the added flag/checkbox and re-use his current g-code scripts, others will enjoy the new (and better) support for shared nozzles on top of a fully working 'nozzle switch retraction distance' setting (to be renamed 'extruder switch retraction distance').

I had to suspend my learning of CuraEngine's code for a while because of lack of time, but I'm resuming: following code execution step-by-step by means of the debugger is quite effective for that purpose.

sisu70 on 25 Sep 2020

@sisu70 Technically I want the same thing as you.

Rollback hiding of shared heaters. Could even be renamed "turn standby temps off" for all I care or whatever works to calm the devs down. The feature is necessary. Removal just made custom printing with 2 or more colors impossible without custom .json files or manipulation of machine settings file. Contrary to the idea of making it easier for people.
2 and 3. I don't care if there are more options. I personally wouldn't use them, so they are really not something I need, but I'm not opposed to it being added. That doesn't bother or affect me.

The issue is the developers removed a necessary feature and have no intention on fixing anything. Prusa slicer is actually much better for dual color. They developed the MMU2 and don't have these issues. The slicer was developed for it. While Cura has to be hacked for it. Prusa slicer also has much much better purge options. I could make the changes to make a "shared nozzle" work. It wouldn't be a 1 click solution, and it would require multiple parameters to be input by the user and may be extremely complicated for all variations, but it would work.

However, it seems Cura only cares about Ultimaker. I could make it work, and Cura could toss it aside so ungratefully just like they did to @smartavionics and share_heaters.

It's funny because to print with dual color we have to: Do a mainboard swap, install dual extruders and hotend, create custom firmware, But setting up custom g-code is a bad experience for unexperienced users? I think we are all very experienced by that point. And this is why we lost it? I just want the feature reenabled. Whatever comes afterwards is fine with me, because it wont affect me.

It might be up to you though to save shared heaters and create "shared nozzle" all by yourself for free. Just for the chance to get shot down by Cura.

I'm almost finished with my drag and drop solution for Cura and all Creality printers with dual color. This includes three different setups: Prime tower setup, purge bucket setup, and purge mechanism setup. All with any number of extruders (up to 8). The shared heater checkbox would have made this more steamline. However, I feel soon enough the community will be much more opinionated about how Cura deems us incompetent over a checkbox and the necessity to reenable it.

B-rad888 on 25 Sep 2020

Howdy folks, popping in to leave my 2 cents.

I'm using a SeeMeCNC Artemis, with a Y-splitter into a shared heater and nozzle.
Everything was working in Cura 4.6 (forgot the exact version) when I had the "shared heaters" option checked.

I'm resetting everything up in Cura 4.7.1, and I don't have that "shared heaters" option as established earlier in this thread. I was planning on setting up my materials retraction with the extruder start and end gcode anyway, so I have "nozzle switch retraction speed" set to zero. Still trying to get it to work, I'm having a weird issue with a double retraction occuring - though I'm not sure if that's a personal gcode issue.
(EDIT - Found the issue, I have the Artemis setup to use RepRap flavor instead of Marlin, so I need to pop in a M83 along with my G91 to get both my positioning and extrusion into relative mode for my z-hop/retractions.)

The main issue, not sure if it was mentioned yet, is that after my second extruder (T1) finishes it's last layer, the T1 heater is turned off - AFTER the first extruder (T0) start gcode is called (T0 has it's last layer to print). I understand the logic, that if T1 is done printing, than turn that heater off. But, T1 and T0 have a shared heater and nozzle, so obviously there's an issue.

I can see a workaround by setting the print temperature in each extruder start gcode, but the issue is that T1 is turned off AFTER the T0 start gcode - which just seems like the wrong order of operations.

If I'm missing something obvious to solve this, please let me know.

Anyways, in my personal experience a feature that was working exactly as I expected it to was removed, and through a poor order of operations prevents a workaround as far as I can see.
I guess I can pick out that single line and delete it, not the biggest deal, just dumb, especially if we're following the logic that "people shouldn't have to know gcode to use Cura" or whatever. Another point to that is if people are messing with dual extrusion, they probably know a bit about gcode.

I've seen quite a few printers with a shared heater and nozzle, or products like what was linked above, that I would consider a "shared heater" option (even if it messed with retractions... which had a workaround) to be standard.

Alright, I guess that was probably more like three cents.

jackbrick101 on 4 Oct 2020

If I'm missing something obvious to solve this, please let me know.

I suggest that you locate in your file system the file hosting the definition of you custom printer and just add there the line for enabling the shared heater feature.
In my Windows setup the file is located in the "\AppData\Roaming\cura\4.7\definition_changes" subfolder of my user folder and is named as "_settings.inst.cfg".
You open it with any text editor and simply add a "machine_extruders_share_heater = True" line in the "[values]" section.

sisu70 on 4 Oct 2020

Ok, I'm back here after some digging in and experimenting with CuraEngine's code.
I still have to try it out with a real print, but at least in terms of produced gcode, that I visually inspected, it seems that I found the proper way in order to have the existing "extruder switch retraction" functionality fully working (so not to need any extruder start/stop gcode script at all).
As a matter of fact, that specific functionality (extruder switch retraction) is already fully working (Cura 4.7.1) and the wrong/incomplete part is the handling of the first start of each extruder: it seems to me that CuraEngine assumes that at "printer start gcode script" completion all extruders are not primed, but when an extruder is later selected no priming procedure is actually implemented and the assumption implicitly turns to 'primed and not retracted'.
This problem is currently (fully) worked around for single-extruder printers (like my original Ender 3) by means of a printer start gcode script that actually leaves the only existing extruder in the 'primed and not retracted' state.
The same workaround unfortunately cannot work for printers with multiple extruders and a shared heater, since only a single extruder can be in the 'not retracted' state at any given time.
So I temporarily modified the code and changed the initial assumption for each extruder from "not primed" to "primed and retracted by X mm" (which is a consistent state for my shared-heater printer) and updated my printer start gcode script in order to actually implement a matching status at script completion.
For the time being I hardcoded the assumed initial status for the extruders in the code, but for sure the best solution is to change the FFF customization support in the following way:
1) for each extruder add a description of its status at "printer start gcode script" completion, composed of a 'primed' flag and an 'initial retraction amount' value (to be also used as a lower bound for the "extruder switch retraction" parameter)
2) initialize CuraEngine 'assumptions' from those values in the printers description rather than in a hardwired/constant way

I will anyway test the hardcoded solution with some real prints as soon as possible.

sisu70 on 8 Oct 2020

If I'm missing something obvious to solve this, please let me know.

I suggest that you locate in your file system the file hosting the definition of you custom printer and just add there the line for enabling the shared heater feature.
In my Windows setup the file is located in the "\AppData\Roaming\cura\4.7\definition_changes" subfolder of my user folder and is named as "_settings.inst.cfg".
You open it with any text editor and simply add a "machine_extruders_share_heater = True" line in the "[values]" section.

Thanks for the suggestion, but no dice for me - now on the switch from T0 to T1 the hotend turns off, then turns back on after switching from T1 back to T0. This wasn't occuring before; only on the very last switch.
Weirdest thing is that I can't find a hotend command line in the gcode on the extruder switch - so I don't know how the machine is getting the command to turn off and on the hotend. The only other command I see is the T0 or T1 command that gets called when switching extruders - does this call some other subroutine?

When I remove the "machine_extruders_share_heater = True" from my definitions_changes, the gcode after slicing has a bunch more temperature M104's throughout, and I gain access to the initial and final printing temperatures, which disappeared when I had that in the definitions_changes - so I'm pretty sure I put it in correctly. I can find clear differences in the gcode and a difference in reality with that bit in or out.

(Let me know if it's better to start a different thread or something for this.)

After s'more testing:
I removed the "machine_extruders_share_heater = True", I changed all my temps (initial, final, standby, blah blah) to the same value, and the only extra M104 I see now is the issue-causing command from earlier (turning off T1 after its last layer finishes). I can easily find and delete that line (which is my current workflow), it's a dumb extra step and I'm hoping for this to get cleaned up (looks like sisu's dialing in the issue), but at least my machine is usable with my dual extruders again.
Just completed a successful print.

jackbrick101 on 8 Oct 2020

So my thread was closed about this, it seems that because so many people have a switching extruder and not a mixing like I have (geeetech a10t) I am now supposed to do all this nonsense. I'm sure I'm not the only geeetech user that is frustrated, I'm not sure if there are other mixing extruders. I can/could feed 3 filaments at once and it prints interesting colors/combinations that look awesome without grinding so switching from one to the other is not damaging in any way, shape, or form for me as the filaments combine in the heated chamber, not before. The newer iterations essentially crippled my printer and now maybe offer extensive workarounds. If the needs of many outweighs us mixing extruder people then so be it, but if someone could be so kind as to tell me the version BEFORE this issue and I will downgrade for the foreseeable future to a pre made multi color ability version. I will gladly disseminate this info elsewhere for my geeetech mixing crowd.

JChiBears on 12 Oct 2020

Just a reminder that my Cura builds still provide the shared heater option and I have no intention of removing it. You can find my last build at https://github.com/smartavionics/Cura/releases/tag/20200922.

smartavionics on 12 Oct 2020

Thank you! I wanted to try and minimize the "unique" versions of things to install but so be it I guess. In doing that though it offers Cura the option to just tell people "you don't like it, go trust this guy, we're done with that."
My most hated thing about 3d printers... learning a system then it becoming unusable without insane workarounds, like this.

JChiBears on 12 Oct 2020

I now tested with real prints and I'm satisfied by the quality that I can obtain, specifically to dual-colour same-material (and therefore temperatures) prints.
I made a number of small changes in Cura Engine's code and needed to patch the custom_extruder_N.def.json files (in order to enable the movement of the printing head far from the model during the extruders switch). So far I did not introduce the new (and in my opinion needed in addition the 'shared heater' one) 'shared-nozzle' flag in any printer definition files, but simply hardwired the appropriate variable/value (for my case) in the code.
One of the modifications that I made to the code is for printing the first layer of the prime tower with all extruders in case the (now hardwired) 'shared nozzle' flag is true and in case the adhesion type is 'none' or raft'.
In my opinion the main outcome is that with small changes like the ones that I made, support for shared nozzles can be obtained without the need for any extruder start/end gcode scripts (and independently from the 'shared heater' flag).
On the other hand I'm still needing a printer start gcode script, for (trying) setting up filaments positions in a known way (all retracted by a known amount) starting from an unknown status (I don't have filament presence sensors), but I still consider the whole approach very limited, since I need potentially extruding some material from each extruder in this phase, but in no way I can leverage material-specific temperatures from inside the script. Also in this case proper support should be ideally added in CuraEngine's code: one example could be adding an 'extruder reset' gcode script to be executed, for each extruder, after the 'machine start' one and after having set, from the code, material-specific temperatures. Or even better adding all the needed support inside the code.
In any case, even targeting multiple-colour same-material prints only, I'm currently missing two steps:
1) adding the 'shared nozzle' flag in the machine definition files (and possibly in the custom FFF printer wizard UI and configuration files)
2) submitting the changes for possible integration in the 'official' release

For both those missing steps I currently have no clue on how to proceed :-)

sisu70 on 12 Oct 2020

👍1

In order to be more clear I list here below all the changes that I made in CuraEngine so far:

Inserted a second selection of the (computed) initial extruder after printer start gcode script execution: this is needed because, in order to initialize all extruders, the script potentially needs to select different ones sequentially and in that case it is not capable (afaik) of autonomously restoring the one that it found selected and that CuraEngine expects to use first
Changed extruders initial status so that after printer start gcode scripts execution they are considered primed and retracted by a known amount; this is currently done blindly (and the amount hardwired to 50 mm), but would need to be conditional to the still-to-be-added 'shared nozzle' flag
Changed the logic for the first layer of the prime tower so that, in case allowed by a new boolean variable to be initialized from the still-to-be-added "shared nozzle" flag and in case of no adhesion method or raft method, all the extruders are primed (instead of only the outer one)
Fixed a couple of uninitialized variable that were causing the failure of a debug assertion (at least when in Visual Studio's debug configuration)

The 4 changes can be considered independent each other.

sisu70 on 13 Oct 2020

It seems that I now partially addressed the first of the two open points: I added a "machine_extruders_share_nozzle" setting (identical to the "machine_extruders_share_heater" one, name apart) in the fdmprinter.def.json and then derived a new definition (json file) for my modified printer, not to rely on the FFF printer configuration wizard (for the time being).
I then modified my code in order to conditionally enable changes 2 and 3 above.
I will complete the job by adding a further new setting for the initial "mechanically safe" retraction distance (to be actually implemented for each extruder by means of the printer start gcode script).

sisu70 on 14 Oct 2020

it seems that because so many people have a switching extruder and not a mixing like I have (geeetech a10t) I am now supposed to do all this nonsense.

The feature still exists as a machine setting, just not as a visible checkbox. If your printer always has this mixing nozzle it can be enabled in that printer's definition and then combined with proper start g-codes. Wasn't there the Geeetech A10M for that purpose?

Sounds like you have built the sort of solution that I think would be ideal to resolve this conundrum, Sisu!
4.8 is going into feature freeze shortly, so it's going to be difficult to get that in on time. But hopefully in a later release we can provide that option again then for people who modded their printers with a mixing nozzle.

Ghostkeeper on 14 Oct 2020

I finally added the new "machine_extruders_shared_nozzle_initial_retraction" in the fdmprinter.def.json template and modified my CuraEngine code in order to properly use it in case of shared nozzle.
I also tweaked a bit the definition (.json file) of my modified printer and tested the resulting status on the preview panel in Cura.
I will make few more tests with real prints and then I could try to contribute the code.

sisu70 on 18 Oct 2020

Hi, back here, again after some time since my previous appearance.
I actually tested with a few real prints my 4.7-based CuraEngine code, with the expected results.
I also tried locally merging my changes with more recent 'official' changes targeted to 4.8, but found issues that I attributed to the fact that I updated CuraEngine only, not Cura.
I now see that Cura 4.8 is out, so I will try on top of that base.
In case of good outcome I would need some assistance on how to 'push' my changes for review and integration.

sisu70 on 13 Nov 2020

Ghostkeeper, I am only slightly above the normal end user you mentioned in your previous posts. Here I am like the child that wandered into a university lecture for help.
"The feature still exists as a machine setting" so where/how can I enable that definition? Would that be part of the start gcode? If you mean enabled in my firmware I assure you it is and always has been using "Vert's" current stable builds and I modify for the A10T in VSCode.
I am not sure what you meant with the A10M? It is the 2 in 1 mixing, my "A10T" is the 3 in 1 mixing. Geeetech did include a Cura build on the SD card with the printer if that's what you meant. It was already over a year out of date in May so I didn't install because I wanted current Cura features and tutorials to go along with.
I am doing a live stream with Geeetech this week and any help would be greatly appreciated. As of now I am using Prusa slicer which does work for multiple colors but I have not attempted any mixing as I am not sure if it is capable either. I much prefer Cura.

JChiBears on 13 Nov 2020

I now see that Cura 4.8 is out, so I will try on top of that base.
In case of good outcome I would need some assistance on how to 'push' my changes for review and integration.

So, it works well on top of 4.8.0.
I had made all the changes and commits in my local 'master' branch and now pulled (merged) todays's status from the remote master branch, without compile-time or run-time issues.
I would need instructions on how to contribute the changes to the code (as simple as 'git push origin master' ?) and to the 'fdmprinter.def.json' file (which is out of this git).

sisu70 on 14 Nov 2020

Mmmmm ... I seem to understand that I should have 'forked' before starting changing my local code.
Now I did that fork and then created a remote branch (that I named "CURA-8148_extruders_switch_retraction_initialization").
As of now I have all my commits in the local master branch of the main fork and they are not at the 'head' since I pulled everything more recent.
I still need to figure out how to move/copy my commits from one fork/branch to the other one: can anybody here help ?

sisu70 on 14 Nov 2020

Maybe I managed to clean things up for the pull request, that I dared to advance :-)

sisu70 on 14 Nov 2020

An automated test is failing, I guess because of the official and not coherent version of the "fdmprinter.def.json" file used for the test, but not part of CuraEngine's repository.
I just opened a parallel pull request for that change in Cura: https://github.com/Ultimaker/Cura/pull/8772 .
I have no clue on how to link the two pull requests in order to fix the failing test.

sisu70 on 14 Nov 2020

In case of good outcome I would need some assistance on how to 'push' my changes for review and integration.

Seems you've discovered the method of creating a fork and a pull request on your own by now. Good job! This is the correct way. I'll help out with the automated tests and such in the thread for that pull request.

"The feature still exists as a machine setting" so where/how can I enable that definition?

Machine settings are a category of settings normally hidden in the settings list. You can reveal the category by installing the "Printer Settings" plug-in from the Marketplace. The setting is called "Extruders Share Heater" and will be in the normal list of settings (same as like Layer Height and Infill Density), not in the Machine Settings dialogue where it used to be. The functionality is still the same. If you've previously made it work correctly with the little checkbox in the Machine Settings window, this will work out fine for you.

I am not sure what you meant with the A10M?

The Geeetech A10M is a printer definition in Cura that enables that aforementioned hidden setting by default. This "printer definition" is what gets loaded when you add a printer and select the Geeetech A10M from the long list of 300 printers. I used this as an example, to illustrate that printer definitions can still change the setting even though the checkbox is gone from the interface. Most of the machine settings are not visible in the interface right now, and this became one of them.

Ghostkeeper on 17 Nov 2020

Hiding the "Shared Heater" feature makes CURA kind of useless to me.
I have 2 printers.
1 is a Prusa i3 MK3s, which I use PrusaSlicer for.
The other is an Ender-3, modified for dual extrusion.
Without being shared-heater aware, the GCode that Cura generates for my Ender-3 consistently tries to print at whatever the "standby" temperature is for the inactive filament.
I'm having to go back to 4.6 in order to use this printer.

myrlyn on 25 Nov 2020

Cura: [4.6.2] No 'priming' on the first activation of the second extruder (with shared nozzle)

All 85 comments

Related issues