[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

[rrileypm]

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.

[B-rad888]

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.

[sisu70]

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

[B-rad888]

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

[rrileypm]

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]

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.

[Ghostkeeper]

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]

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.

[B-rad888]

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

1. Y spliter checkbox ( for correct switching actions)
2. Shared heater (for stable temps)
3. Filament start position (From before y merger) Extruder 1 Extruder 2 etc
4. 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.

[PatrickNTPC]

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

[B-rad888]

@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

[Ghostkeeper]

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.

[B-rad888]

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.

[sisu70]

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.

[B-rad888]

@sisu70 Technically I want the same thing as you.

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

[jackbrick101]

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.

[sisu70]

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]

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.

[jackbrick101]

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.

[JChiBears]

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.

[smartavionics]

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.

[JChiBears]

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.

[sisu70]

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]

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

1. 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
2. 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
3. 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)
4. 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]

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

[Ghostkeeper]

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.

[sisu70]

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]

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.

[JChiBears]

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.

[sisu70]

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]

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]

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

[sisu70]

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.

[Ghostkeeper]

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.

[myrlyn]

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.

[sisu70]

Hi, back here three weeks after I requested pulling my code for addressing this issue: any development ? Would requesting pushing (or attaching here) the definition of my modified printer (definition that leverages the modified code) enable further testing by some people with a similarly modified Ender 3 ?

[sonoyuu]

I also have 2 of my printers that have 2 in 1 out hot ends. I had to resort to the Printer Settings add on in order to use them with Cura, as it will just pause forever on standby temp waiting for the hot end to reach operating temperature. Type in 2 in 1 hot end into Amazon, and you can see right away this issue is not going away. Can this issue please be properly addressed? I get you hid it for a reason, but that didn't make the problem go away, it created a new problem. Why after retraction of the first filament, can't the second one be fully loaded and then purge before proceeding? I mean seriously...this problem was first reported here 4 months ago, and it doesn't seem like it is a huge change to make.

[JChiBears]

I think this thread is dead, just like my $300 3 in 1 out mixing hot end printer. Ultimately Cura is made by Ultimaker, who does not have a multi filament hot end. It used to work many moons ago... I have a feeling that this is a designed flaw to make competitor's printers unpalatable/obsolete well before for the holiday season. Please, prove me wrong by adding back all the shared heater options and code. Add warning popups, ex: When you add an extruder(s) forcefully remind to tick the 'shared heater' "!DANGER! IF YOU USE MULTIPLE EXTRUDERS WITH ONE END YOU MUST CHECK THIS BOX!" Again when ticking the 'shared heater' option "THIS OPTION IS NECESSARY FOR MANY MULTI FILAMENT SETUPS" Finally warn when slicing if more than 1 filament is being used for "legal reasons" what a shared heater is. "!DANGER! YOU HAVE SLICED A MULTI FILAMENT MODEL. SEVERE DAMAGE MAY OCCUR! MAKE SURE YOUR HOT END IS CAPABLE BEFORE PRINTING!!!" Just saying, if you have multiple extruders you shouldn't need warnings... If you do, go back to single extrusion... I am willing to click away multiple warnings per slice if I can multi filament print again!!!

[sonoyuu]

JChiBears we do have the option of using a previous version of Cura, or installing the printer settings add on so you can see the shared heater option again. They removed the option because when it retracts E0, it doesn't prime E1, it just assumes the filament is at the nozzle. Technically we can go in and edit the gcode to correct this, but it would be nice if they made a fix for it.

[Ghostkeeper]

Wouldn't exactly call this thread dead. It's fairly active. As far as I'm concerned the ball is in Ultimaker's court now, due to sisu70's pull request. The current solution is that it has to be implemented by the designer of the printer definition (.def.json file) who also has control over the start and end g-codes, to make it work correctly together. Sisu's solution would make it possible to use it also for printers that are not among the 300 printer definitions that ship with Cura by default.

We have 70 open pull requests at the moment. Sisu's PR is not the only one that needs attention. And the attention that we can give is limited here as well, being pushed only by the programmers, not by planning from our PO. It's really difficult to process complex pull requests if there is a biweekly sprint planning and the scrum master asks why we're spending time on these at all. As a result, the easier the pull request is, the quicker we can handle it. We need time.

I don't know what legal system JChiBears is thinking of, but at least here in the Netherlands warning notifications hold extremely little value, especially if the warning is always given. People often ask us to create pop-ups for all sorts of cases. If we'd implemented all of them you'd literally have to click through a hundred of them on every start-up. They just serve to annoy users and people will still make the same mistakes with hardly a dent in the statistics. We had an example of exactly this a few days ago through a bug report.

[Andyman14159]

Hi, back here three weeks after I requested pulling my code for addressing this issue: any development ? Would requesting pushing (or attaching here) the definition of my modified printer (definition that leverages the modified code) enable further testing by some people with a similarly modified Ender 3 ?

I am running the same setup as you. Modified Ender 3 Pro with SKR board and 2 extruders, single nozzle. To solve the heater standby issue, I've re=enabled the function in Cura by going in to C:>Program Files>Ultimaker Cura>Plugins>MachineSettingsAction and editing the file MachineSettingsPrinterTab.qml in Notepad++. (In Cura 4.10) I moved the */ from line 371 up and placed it at the end of line 358, thus re-enabling the "Shared Heater" option. Secondly, for the big fish, to correct the issue of extruder 2 (T1) not priming during its initial use, I slice my file and note the very first layer that extruder 2 would activate. In my case it was "LAYER 4". Then I saved the gcode file and opened it in Notepad++. I did a quick CTRL+F to find "LAYER 4" and then find "T1" in the text gcode file and found where extruder 2 initializes for the first time in layer 4. I found the G92 E0 (reset extruder) and changed it to G92 E-56 because in my case, it is 56mm to load extruder 2. VOILA!! it worked perfectly. Now I know that may sound like a lot to accomplish, but you only have to do that one time for each file and if you get in the habit, it almost becomes second nature, very easy and works perfectly for me. No more missing layers. I hope that this will help someone like it did for me until a more official fix comes down the line.- AR

[Ghostkeeper]

I am running the same setup as you. Modified Ender 3 Pro with SKR board and 2 extruders, single nozzle. To solve the heater standby issue, I've re=enabled the function in Cura by going in to C:>Program Files>Ultimaker Cura>Plugins>MachineSettingsAction and editing the file MachineSettingsPrinterTab.qml in Notepad++.

An alternative to this is to install the Printer Settings plug-in from the Marketplace, which allows editing this setting in the main settings list too.

This issue has been fixed in Cura 4.9 by Sisu. There is a new machine setting "Extruders share nozzle" which can be enabled separately from "Extruders share heater", to disambiguate the case where not only heating commands need to be shared between the nozzles, but also the priming (as per this issue). And an initial retraction distance setting was added too. Thanks for the fix, Sisu!