Extruder assignment for files with multiple colors or materials, with virtual extruder support for mixing

[Patola]

Currently, the workflow for printing a dual extrusion object in Cura is the following (from modelling to bed):

• You model the thing clearly separating the parts for each extruder, maintaining the same coordinates for the thing as a whole. In Blender, for example, you could do that by using different workspaces for the pieces.
• You can also use software like meshmixer to separate-paint a one-color / one-material object in two objects
• You save one STL (or 3MF, OBJ etc.) file for each part.
• You open the two parts in Cura.
• You assign different extruders for them.
• You "merge" them so they use the same coordinate references and make up the whole object.
• You print them and get the dual extruded part from the table.

I think this workflow is inadequate. To start with, some file formats like X3D, 3MF and AMF already have metadata for both materials and colors, which could be used to differentiate extruders and would make the workflow from modelling to printing much more straightforward. Part of the blame comes from Uranium, which seems to use pure mesh data (no materials or colors) for the parts in Cura.

This is more critical as the FFF 3D printing market seems to be heading very quickly to multi-extruder printing and even mixing. Two major part vendors already sell mixing hotends: e3d cyclops and reprap.me Diamond:

http://e3d-online.com/Cyclops - 2 filaments, one nozzle http://www.reprap.me/diamond-hotend.html - 3 filaments, one nozzle

I have both of them, and they are very difficult to use properly. The reason? No slicer is actually prepared to make use of their features. What you end up doing is post-processing the gcode to add the different colors or mixing. In particular, you have to use very new features in Repetier Firmware and Marlin to use the mixing, resorting to virtual extruders:

http://reprap.org/wiki/Repetier_Color_Mixing https://github.com/MarlinFirmware/MarlinDev/pull/361

This eases the color mixing procedure a bit, but it puts a lot of responsibility on the slicer. For one, is has to support virtual extruders - which makes the current workflow of cura completely awkward for this, you would have thousands of extruders and would have to assign a very small part to each one of them.

Other slicers are also receiving requests for that feature, e.g. slic3r: https://github.com/alexrj/Slic3r/issues/3456

Or even have implemented it already, e.g. vozelixer: https://all3dp.com/voxelizer-experimental-image-mapping/

So I think Cura also needs to deal with this possibility.

This text is just to expose the problem. Next I will try and think of a possible suggestion to fix it.

[Patola]

I just realized that this feature requests has two different tasks:

• automatically assign extruders to materials and/or colors of imported files; and
• mixing support with virtual extruders

Should they take part in the same bug report? Or should I open yet another?

[Ghostkeeper]

They can be in the same Github issue as far as I'm concerned. We have a separate issue tracker internally where it would need to be split into smaller chunks of work, but for Github issues we have no such requirement.

A third task that probably needs to be done is to be able to adjust or at least sort of visualise the mixing.

I don't expect Ultimaker's developers to help with this any time soon, since it is quite a large amount of work, and bears no gain for printing with Ultimaker's printers. But of course we'll help whoever attempts this, and perhaps there's some free time to be spent too.

[fieldOfView]

One complication is that support for creating colors by mixing will have to be implemented in a way that it does not break for printers that cannot mix colors, and/or have only one or two extruders.

The case for having only one extruder sounds pretty straightforward: just ignore the colors and print in the color you have, like a black&white 2d printer. But what should happen if you have a dual extrusion printer with red and yellow PLA inserted, and you load a model with green, blue and purple vertices? Should it not print anything at all (because the right materials are not available)? Should it make assumptions on using colors to replace the absent colors?

[nallath]

Asigning extruders directly from file (read; 3mf files) is something that is on our roadmap.

Mixing is something that I don't see us working on in the near future, for the reasons listed by @Ghostkeeper

[Patola]

Thank you all for the comments. However, I am looking forward even beyond colors, that why I also mentioned materials. I actually see colors as just one particular case of materials, with three (RGB) or four (CMYK) optical components. But I think that with mixing capabilities an undefined numbers of indexes will be available. If you have one rigid material and one flexible material, you will have different grades of flexibility vs. rigidity on your print depending on how you mix it. If you have an opaque material and a transparent material, you will have different grades of translucence. This just for two mixing extruders. Extending this to three or more gets even more involved. I also understand that this structuring of data regarding materials vs. colors does not match most file formats and modelling tools, though. Maybe this is too much to ask from developers regarding the current state of slicing algorithms, but since the 3d printing ecosystem is progressing so quickly, I think it will sooner than later become an issue quite worth of concern.

[fieldOfView]

I share your dream of mixing material properties, but there will have to be a lot of development in materials. Different materials are going to have different printing properties that won't mix easily. Printing temperature is an obvious one, but retractions (at different amounts) are going to lead to subtler issues, where one material retracting might pull the other material(s) along with it. I hope there will be a lot of development in the years to come, eg with sets of materials that are highly compatible.

On the modeling front you are also going to need some work done for true mixing. Most modellers only describe surfaces and encompassed volumes. If you want to do internal gradients you will need some sort of internal geometry too.

It is very good to dream up solutions for all this, and I for one would be proud if Cura is part of making that happen, but for the time being the Ultimaker engineers first have to get Cura working for the current state of technology.

[Patola]

@fieldOfView Yes, but I also do not want to keep dreaming only. Refactoring the code years later is much more work (and thus less likely) than preparing in advance. Also, there is a motto in software engineering that you create the data structures then the code for it, not the other way around. Maybe there is something that can be done in the code now to prepare for these features? I understand that the core of handling this is in Uranium, structure MeshType, isn't it? There is not a lof of documentation for Uranium yet so I am not sure. Maybe some new metadata could be integrated, and then the interface could automatically assign a material or two to that new metadata.

[awhiemstra]

UM/Mesh/MeshData.py is the main file containing the mesh related properties. Ideally, we would have functionality to assign metadata and arbitrary vertex attributes to it. Right now it is a very static data structure which already fails when dealing with more complicated rendering scenarios as those also need arbitrary vertex attributes. This will of course only solve a small part of the picture, you would also need to communicate this to the engine (pretty simple) and then change the engine to make use of it (pretty hard).

On another note, after reading #1020 I just realized that doing gradients should ideally be done as a more advanced form of per-object settings. This would enable the function for all settings, not just color.

[BagelOrb]

I already made an (outdated) branch in CuraEngine with an implementation of black n white gradient printing, but using alternating black and white layers with alternating offsets to let one color come forward more. The problem is that the branch is horribly outdated and probably cannot be merged anymore. Moreover, the implementation was quite hacky.

Multicolor printing is far easier than material property mixing, because the color is only used for the outside, while property mixing requires some inference about the inside of the model.

I hope we can convince management that this form of gradient printing is one of the most innovative awesomenesses to fix next, but I'm afraid they won't be as receptive ^^

With that feature in place the diamond nozzle hopefully won't be that difficult to support.

I suggest you make a new issue about automatic assignment to materials. This thread is already quite busy.

[guysoft]

These guys claimed to have written a plugin: http://www.thingiverse.com/thing:1664880

Can anyone make sense of this? (I have a cyclops here, can test things)

[nallath]

It's a cura 15.04 post processing script.

[guysoft]

Can you figure how to use it?

What does Extruder T() mean? What do Serial S0 S1 and S5 mean? Mix Hight seems to be preset to 0.1.

I guess Proportion P0 and P1 is how much is extruded from each nozzle.

I am not sure what the settings are:

[guysoft]

Ok, I figured how to use it.

1. Set Mix height to when to start mixing
2. Set S1 to 1 (it builds the Gcode right like that).
3. Set P0 and P1 to the proportion you want for the extruder (if you have 3 there is a 3-extdruder option). That should give you an option to switch mixing on the go, at least vertically.

On Marlin, I had to set the setting #define MIXING_EXTRUDER Make sure you are using an updated version that has the feature.