if I remember correctly, in cura 2.1, material presets overrode quality presets (which could cause terrible situations as there was no material profile editor for non-coders)
based on my testing, in cura 2.3, material presets do NOT override quality presets.
example:
- basic 'normal' or custom quality preset has retraction_amount = 5mm
- ultimaker generic nylon has retraction_amount = 8mm
- right now, exported gcode when nylon is selected STILL has 5mm retraction amount
obviously, we need some way to switch settings base on materials....for cooling options (ABS vs PLA) and retraction (nylon vs TPU), and potentially even for speed (PLA vs TPU)
question is, how is this designed? how should it work in the first place? or is this a bug?
either
thus, i conclude materials should override quality and that there is a bug.
yes?
It is designed to work the other way around. This is the basic order of the profiles in Cura in single extrusion:
To determine the value of a setting, Cura starts from the top of this list and goes down to the bottom. This has some obvious problems. For instance, the temperature for each of the quality profiles is different since you need a higher temperature to print at higher speeds (to compensate for the higher flow). So it's then not possible to specify a temperature in the material profile, because the quality profile always overrides it. In the default profiles for the UM2 and UM3 this manifests itself in that if the user tries to duplicate and then modify the material profile, it very rarely has any effect. The same goes with the retraction settings in the default normal profile, I guess.
Your solutions are inadequate too, though:
We have two solutions for the printing temperature problem: Make a separate setting, a delta-temperature that can be set by quality profiles to compensate for flow. And to actually implement a flow-temperature relation so that the engine can adjust the temperature as needed by the flow rate. The second solution is more long-term than the first, but we have no data for how much the temperature needs to be adjusted then.
But in general this is probably one of the trickiest problems that Cura faces right now, as it shows that its profile system is way to complex but not powerful enough at the same time.
Very good summary @Ghostkeeper
IN FACT, I made myself a 'blank slate' completely empty Material preset, and have been using Quality presets only to control everything :-)
Cura 2.3.1 is the first one for which I'm trying to get some Materials ready (seduced by the colorful patches) and that's why I have so many questions now...
From user's perspective, one should have Materials and then apply Quality settings and be done.
From slicing perspective, every combination of Quality and Material is unique and ideally would be tweaked individually.
I do think that automatic temperature compensation within some range around the base value in relation to flow is the way to go. (First attempts at AutoTemp in Marlin were years and years ago - I haven't used it myself and not sure in what state it is.)
I like the delta temperature concept, too.
Maybe I'll do that.
Or maybe I'll make my material presets empty again.
Cura 2.3.1 is the first one for which I'm trying to get some Materials ready (seduced by the colorful patches) and that's why I have so many questions now...
Believe me, it's nice to have such tight and critical feedback and cooperation from the community.
The delta temperature is sure to be added for version 2.4.
The auto temperature is already added in version 2.1, and it was tested back then. However it is made invisible and unused because we have no good default values for the setting. We also have no prospect to get that data any time soon. That's why we decided to make a delta temp setting for now.
it's nice to have such tight and critical feedback and cooperation from the community
~ It's just as nice for us to be able to get stuff done!
Yeah, I already tried something like =round(material_print_temperature * 0.5) in the profile, but of course it does not work because of the the order of hierarchy here.
Looking forward to the deltas. I looked at the Ultimaker3 solution with tons of material presets and switching... and probably gonna wait for the deltas.
OK
Trying to wrap my mind around it and figure out what setting needs to go where so it works:

Is this correct?
The only real trouble I see (apart from the thing being complicated and inheritance error prone :)
is the fan control. This necessarily MUST be part of material presets, and yet the variables needed (max and min speed ...) are not actually supported in the XML implementation.
If I'm correct, than it's a request for enhancement I guess.
Here's another one, I have different fan configurations as variants in fact. this thing feels complicated. haha.
The fan speed can be set via the XML material profiles. The setting is called "print cooling" there. This is a full list of settings that can be set in the XML material profiles: https://github.com/Ultimaker/Cura/blob/master/plugins/XmlMaterialProfile/XmlMaterialProfile.py#L536
It gets translated to "cool_fan_speed" for Cura. In the interface that is the "Fan Speed" setting. It may get overwritten by the Regular Fan Speed setting in some quality profiles though.
@Ghostkeeper yes, I saw that, but here's the trouble:
(mentioned in https://github.com/Ultimaker/Cura/issues/1141)
in the short list of settings, there's only "cool_fan_speed"
but I desire "cool_fan_speed_min" and "cool_fan_speed_max" (and, ideally, more! like min layer time etc... )
Is this still an issue?
Certainly, see CURA-4016 and CURA-4253 in our internal tracker, Chris.
Any setting which is to do with the Filament. e.g.
It does sound like a lot. All these settings effect how the Filament performs.
The filament size excepted by the printer acts like a filter. You would only see filament which is support by the Extruder selected (defined by the printer definition) when selecting the filament for a print job.
This would allow two different Filaments loaded into a Dual Head to print correctly. e.g. Something made of Rubber and PLA.
When the software starts using the Rubber, it starts using the movement settings e.g. speed for Rubber or fan speed for Rubber or bed temperature for Rubber.
Maybe provide small test prints. To Help tune filament settings???
Versioning of Filament Settings. Maybe File name or in the file, so if a person save bad settings, can go back to the last good settings. Maybe save with a save description (need to be able to remove all versions of settings as well) The Filament Settings should be consider the Best Settings. And Quality/Speed should take an educated guess to make the print faster. Maybe display Filament Setting on the screen and the Quality Setting (print bigger layers and print fillings faster, print less fillings, print less shells) next to it in the main screen.
@ianpaschal Seeing that related issues are getting closed around now*, I'm curious and hopeful that this one will survive :-)
It does seem quite basic at some level - we have Material presets as a separate thing, yet we do not have the power to make them as useful as they should be.
It still seems strange to support Fan speed override, but without being able to set it dynamically (min and max fan speed...)
* Like the speed overrides thread.
@Ghostkeeper The two issues you've mentioned: one is "To do" and one is "won't fix". Shall we discuss today how likely it is if this is going to happen?
@filipgoc Yes, most people who frequent this repository have probably noticed I've been closing a lot of stuff. There's no way our team could reasonably fix or implement 700+ bugs and new features in a year, especially since new tickets are always being opened. For this reason it's important to make the distinction between stuff that is very critical but we can't fix, which gets left open but with an Unplanned label, and stuff that we just don't feel is critical enough to work, which gets closed. It can always be reopened and tagged with Unplanned if it turns out it's a serious on-going issue, but we have _got_ to be able to admit when something just isn't on our radar anymore rather than leave it hanging forever. In my mind that's even worse than closing stuff.
@ianpaschal Indeed. I agree that clean up and periodical priority re-assessment is necessary, and probably the reason Cura has been developing at an impressive rate! (That is to say, I was more _impressed_ with you closing things than worried.) I was just curious about a specific issue that had some personal importance to me, while of course it may not be widespread enough to make the cut now.
This is tied to progress in https://github.com/Ultimaker/Cura/pull/2333. This week that PR has finally seen some progress again from Ultimaker's side since the firmware limitation is now gone.
I don't think we'll implement material profiles overriding quality presets ever though. We chose an order and should stick with it. Maybe we'll find a better solution than the temperature deltas one day, but I think that once that PR is merged we should close this issue because the ordering of these profiles in the profile stack won't be inverted.
Tied PR is merged, original issue: poor docs, yes, but it behaves as intended.
original issue: poor docs, yes, but it behaves as intended
For the sake of annotating old threads for clarity: the original issue was not poor docs. The original issue was that arguably useful parameters like flow could not be defined as a part of the material XML definition. This was resolved by #2333 by adding a new namespace and allowing to define any parameter in the material XML.
It IS indeed resolved now. Yay. Read the PR for HOW to use this.
Most helpful comment
Believe me, it's nice to have such tight and critical feedback and cooperation from the community.