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

[sisu70]

Application version 4.6.2

Platform Windows 10

Printer Custom printer (Creality Ender 3 with SKR1.4 board, Marlin FW 2.0, second extruder motor, 2-in-1 hothend with single nozzle) configured as

• 2 extruders with shared heater
• same printer start/end G-codes as Creality Ender 3
• empty extruders start/end G-codes

Reproduction steps

1. fully load the filament thorugh the first extruder and the hotend
2. partially load the filament thorugh the second extruder (cannot go down to the hotend, since the first filament is already there)
3. start printing a dual material model, with proper settings (including the 'prime tower')

Screenshot(s) not provided

Actual results

1. the hotend is properly 'filled' with the filament from the first extruder by means of the 'printer start' G-codes
2. apart from 'printer start' G-codes Cura simply assumes that the (first) extruder/hotend is ready for printing since the very beginning
3. when the time for the second filament/extruder comes, the first filament/extruder is properly retracted (as configured), but the second filament/extruder is not properly 'primed' inside the hotend
4. Cura assumes that the hotend is ready for printing with the second filament, but that's not yet the case
5. the first (many) mm of extrusion are not printed becasue the hotend needs to be filled with the second filament first
6. for the subsequent extruder changes the retraction of the 'previous' extruder is always followed by the 'priming' of the 'next' extruder, as expected/needed

Expected results I would expect a priming to occur also on the first activation of the second extruder, during step 3 above; this could need having initialized the second extruder as well by means of the printer start G-codes, for reaching a well-known status of both extruders (e.g. first extruder loaded and ready, second extruder properly retracted) when Cura 'takes control' of the printer

Project file not provided

Log file not provided

Additional information not provided

[Ghostkeeper]

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?

[sisu70]

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.

[Ghostkeeper]

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.

[sisu70]

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) ?

[Ghostkeeper]

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.

[PatrickNTPC]

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.

[Ghostkeeper]

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?

[PatrickNTPC]

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.

[smartavionics]

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.

[Ghostkeeper]

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?

[PatrickNTPC]

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.

[Ghostkeeper]

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.

[smartavionics]

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]

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

Hahahaha, that's good!

[smartavionics]

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?

[PatrickNTPC]

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.

[Ghostkeeper]

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.

[smartavionics]

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

[Ghostkeeper]

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.

[smartavionics]

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).

[Ghostkeeper]

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.

[rrileypm]

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.

[sisu70]

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

[Ghostkeeper]

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,

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.

[sisu70]

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)

[Ghostkeeper]

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.

[sisu70]

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]

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).

[ldiegos]

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.

[Ghostkeeper]

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?

[sisu70]

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]

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).

[Ghostkeeper]

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.

[sisu70]

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 machineextruder*_pos usage, thanks.

[B-rad888]

@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

[Ghostkeeper]

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.

[B-rad888]

@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:

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

It is important to note:

1. 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.

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

[ldiegos]

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]

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.

[sisu70]

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'.

[astax-t]

@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.

[B-rad888]

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

1. 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.

3. 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:

1. Constant temps all the time, or
2. 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]

@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.

[sisu70]

@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]

@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]

@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.

[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?

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.

[sisu70]

@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).

[B-rad888]

@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.

[sisu70]

@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).