Cura: should material presets override quality (general) presets? (/ or a bug report)

Created on 12 Nov 2016  路  21Comments  路  Source: Ultimaker/Cura

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

  1. material presets should in fact override general quality settings.
    OR
  2. there should be clear guidelines what settings go into material and what goes into general settings. however, for that the whole UI would have to be overhauled (three tabs instead of two as in: recommended/ custom material/ custom general tabs...)

thus, i conclude materials should override quality and that there is a bug.
yes?

Improvement

Most helpful comment

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.

All 21 comments

It is designed to work the other way around. This is the basic order of the profiles in Cura in single extrusion:

  • Current settings (shown with a reset button)
  • User-created profiles (also known as quality changes internally)
  • Quality profiles (like Normal, High, Draft, etc.)
  • Material profiles (PLA, Ultimaker CPE, ABS, etc.)
  • Variants (0.4mm nozzle, 0.6mm nozzle, or for other printers whether the heated bed upgrade kit is installed, etc.)
  • Printer definition (the JSON files), which has its own inheritance all the way down to fdmprinter.def.json.

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:

  1. If material settings override quality settings, you could not have different temperatures to compensate for the flow difference in the quality profile, to give an example. High quality nylon requires vastly different settings than high quality PLA, and some of these settings are things that would be set by a material profile too.
  2. This is also impossible. There are quite a few settings that are dependent on multiple factors. Speed is a good example. You can't achieve the same speeds with CPE+ as you could with PLA, but speed is an important parameter to tweak the print quality with as well. We decided to have separate quality profiles for each of the materials (high, normal, fast, draft for PLA, high, normal, fast, draft for ABS, etc.).

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

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.

  • Any settings associated with the Extruder e.g. Fan, Temp, Retraction (inducing Move the Z up), Speed of the Extruder moving around and the Bed Moving. i.e. z,y,z movement.
  • Bed temperature settings.
  • Any per layer adjustments associated with the above.
  • Filament Size

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

timherrm picture timherrm  路  3Comments

jellewie picture jellewie  路  3Comments

dstulken picture dstulken  路  3Comments

wi1k1n picture wi1k1n  路  3Comments

thopiekar picture thopiekar  路  3Comments