Easily Implemented Profile System Improvement

[kindaNobody 0]

I've been using Cura for a few months now and as I started printing various parts with different materials and requirements, my profiles got progressively more complicated, and it was easy to accidentally save part-specific settings into more general profiles, or leave some tweaks in a more part-specific profile that I would have liked to take back to a more general one.

 

I've also been a software developer for more than a decade and I have what I expect is a relatively easily implemented suggestion:

 

Additive profiles that allowed the easy reuse of groups of settings: Allow users to select multiple profiles (instead of just one at a time) such that application-specific groups of settings can be organized and selected a la carte. This would allow users to tweak settings related specifically to a material in one profile (Temperatures, Fan, Initial Layer speed), also have a general profile for fine detail (Layer height, Wall & Top Speed), and then even Part-Specific settings (Fill Gaps between walls, Generate Support, Support Angle), and then mix and match between profiles as required.

 

Go one step further and add a UI in the list that highlights a setting with conflicts (one setting that appears in multiple selected profiles) and allows the user to select which profile's setting to use, e.g., You've selected two profiles (ABS + Fine Detail) but your ABS Material profile calls out a print-speed, and you would rather use the speed defined in Fine-Detail.

 

I feel like this would not require changes to most of the current profile system - import/export and the profiles themselves are still fine.

 

I suppose one step further would be to save a selection of profiles within a profile. You would probably also want to update the 'discard or keep" dialogue to allow users to choose which profile to save changes to. I think that dialogue could be more intuitive than it already is even with extra functionality.

 

This would not be a breaking change. All existing profiles would still work, and you could still work out of a single profile the way your always did if you wanted.

 

If Cura already has then and I just haven't seen it let me know.

 

 

 

[nallath 1,120]

You're both right and wrong ?

 

The problem here is that you assume that quality has no interaction with material, but this is (unfortunately) not the case. The ABS normal profile is different from the PLA normal profile. It's actually so different that merely "stacking" quality + material together does not fully describe what needs to be done. Originally we started of with the exact approach you suggest, but we quickly had to diverge from that strategy as it simply wasn't enough.

 

 

[kindaNobody 0]

6 hours ago, nallath said:

you assume that quality has no interaction with material

 

I had an example that spoke to this:

On 5/10/2018 at 1:18 PM, kindaNobody said:

You've selected two profiles (ABS + Fine Detail) but your ABS Material profile calls out a print-speed, and you would rather use the speed defined in Fine-Detail.

 

...and then of course if neither was exactly what you wanted, you've still got the option to enter a third number. This might be somewhere in between the two saved settings and that's really useful because you can actually see what other profiles have saved (not just the currently loaded profile has) to base your new value on. The real trick to making this approach fantastic would be a UI to choose which profile new values should be saved into - preferably right there in the list of settings, not in another dialogue that pops up.

 

6 hours ago, nallath said:

Originally we started of with the exact approach you suggest, but we quickly had to diverge from that strategy as it simply wasn't enough.

 

You're saying that saving the entire list of settings wholesale without a way to build from multiple profiles (beyond just typing the differences in by hand) is more powerful than allowing users to add them together? I don't see how; you can still do everything the current implementation can with the additive approach plus bring in other profiles and reconcile the differences.

[nallath 1,120]

I think you misunderstood what I'm saying. I'm saying that you can't make one profile that says "High quality" and a "ABS" one and add them together. You actually need a profile that is "High quality ABS". In the example that you state, how would you handle the situation where high quality would state a print temperature of 200 and the ABS profile would state one of 250 (This is of course a weird example, but situations like this do arise).

 

It's not just about two numbers. Adjusting one setting is hardly ever possible. Take layer height for instance. If you *only* adjust that, you're going to have pretty poor quality, as others need to change with it. But not all of them need to change linearly, so predicting what they should be is rather hard (also; what do you do if one of the settings to change is an enum? Make a cut off point?)

Right now we have the following system; For the UM3 we have 3 stacks (Extruder 1, extruder 2 and the global stack). Each of these stacks holds a number of so called "instance containers" with a "definition container" at the bottom. For the extruder stacks the order is: "user", "quality_changes", "quality", "material", "variant", "definition_changes", "extruder_definition". For the global stack it's "user", "quality_changes", "quality", "variant", "definition_changes", "definition".

The basic principle we started of with was pretty simple. You just ask the top of the stack (eg; extruder) what the value of a setting is. The stack then asks each of it's containers (in order) what the value is. If the instance container doesn't know it, it moves down. The definition container in the global_stack has all the default values, so if no-one answers, that value is used.

But then we quickly ran into a bunch of issues; What to do if a setting that is only globally settable can be influenced by the material (eg; Bed temperature; You can only have temperature, but materials influence this). We added a thing called "resolve" that then accepts values from both stacks (thus breaking the notion that questions only flow down stream) and resolves them in some way.

We also found that in some cases, the value for a setting with PLA High quality needed to be different for ABS high quality, but only in the high quality of *those* two materials. You can't put them in a "generic" high_quality, as that would influence everyone and it also can't be placed into either of the materials (as that would influence the other qualities. We managed to fix this by introducing a "quality per material", which means that when selecting the right profile for quality, it first searches for a quality by type, material and variant (eg; print-core used) and then starts dropping those requirements if it can't find it (so it should end up with generic if no specific profiles are defined).

So what happens if a user enters settings in Cura? All settings that are changed, get added to the "user" container, depending if they are "settable_per_extruder" or not. If a setting is not settable per extruder, they get parked in the "user" container in the global stack.

 

If a user presses save, these settings get "merged" down one conainer (into the "quality_changes" container). This container is loosly linked to the quality container, but only by *type*. This means that if a user changes the material, the quality container of a stack changes, but it's type (eg; normal) stays the same (and thus, the quality changes also stay there).

In some cases we have functions defined for settings, which get evaluated every time one of the settings it depends on changes. But this is also a can of frigging worms, because it can't "just" use the value, as it should first use the resolve value and only if this is not set, should it use the value (and then special case that stuff if the "user" and "quality_changes" container in global has the setting set, as that means the user wants to override it)

 

[kindaNobody 0]

It sounds like there may be a Materials profile concept that I'm not using? That would get me closer to what I'm looking for; I'll look when I get home.

 

I still think it would be extremely useful to be able to save groups of related settings into their own profile, select zero to many profiles (I suppose these would be at the "user" level of the stack), and then reconcile conflicts then and there on the right side of the screen. I'm fairly certain the current "stack" implementation would not need many changes beyond making the top level user layer a collection, and extending the "settings" GUI to highlight settings with conflicts, then for the conflicted setting, allow users to select which profile's value to use, or enter another value. Seems like it could be implemented by adding another layer to the stack where selected profiles are pooled, and then compute them down to what is currently the user level so everything downstream can continue to work the same.

 

55 minutes ago, nallath said:

In the example that you state, how would you handle the situation where high quality would state a print temperature of 200 and the ABS profile would state one of 250 (This is of course a weird example, but situations like this do arise).

 

Above is the same as the example I gave with print speed. First, the trick would be to stop thinking in terms of having a single profile that defines all settings for the print. It probably doesn't make sense to store temperatures in a more generalized "Fine-Detail" profile, it's more likely this would be material specific (although it might be interesting to add a percentage change concept such that Fine-Detail could add 20% bed temp and take off 25% wall speed or something), but if the user did store it in both, and then the user selected two (or more) profiles that contained a value for the same setting, the user would need to reconcile the conflict... which doesn't have to be hard, show the user that the setting is in conflict in the list of settings (highlight it red and so on), show the values stored in the conflicting profiles (1 to Many, the user could select 5 profiles that all had print speed in them which would probably indicate poorly organized profiles), and allow the user to either checkbox the value from the profile they want, or simply enter their own value that would now be a more informed decision because they can see the range of values that were in the profiles they selected.

 

...as it is I find myself often trying to modify a profile that best matches what I'm trying to do, but switching between profiles to get values, writing them down, and hoping I don't forget anything (which I probably will) so I can go back the profile I'm trying to build and type them in... It's hard to believe I'm the only one. A big part of what I'm describing is really more about better handling and organization of saved settings. I recently found that I had been printing with a thin-wall setting (that would ignore tiny gaps) because it was accidentally saved in my base PLA profile for some print a while ago. ...if the workflow allowed user's to compartmentalize their settings into groups of settings that made sense together, not only would it be easier to get ready to print, it would be easier to notice odd settings as they wouldn't be in a nondescript wall of text, they would hopefully now appear in the list as color coded categories/groups of settings. You could possibly even allow experienced users to just leave all settings visible, because the ones you care about are at the top, color coded. ...and the ones you might  care about don't have to be disabled until you go to another screen to make them appear on the list.

[nallath 1,120]

The problem with making settings "grouped" like this, is that changing a setting can influence another. Take the following example;

There are 3 settings; A, B, C
Settings A's value = 1
Setting B's value = 2
Setting C's value = 3 if B == 2 else A

The profile could do the following things; Only Change A, but this, by default has no effect on B. If you suddenly merge another profile that does change the value of setting B, the changed value of setting A does have an effect on C (which might not be known to the user).

Other than that, i mostly see UX issues here. It's going to be hard to explain this to users.
 

[kindaNobody 0]

On 5/16/2018 at 3:59 AM, nallath said:

the changed value of setting A does have an effect on C (which might not be known to the user).

Sure, Cura already has to deal with this to some extent and warns on settings that are "Normally calculated  ... with an absolute set", the warning serves as a way to recalculate.

 

 Without trying to think through every scenario, the two that come to mind are:

1) User loads another profile that also contains A and B values -> Notify user that linked settings will be recalculated or offer to keep the setting.

2) A profile for some reason has a linked setting C that has an absolute value set (even though it doesn't have A and B values saved. -> Notify user that C will be recalculated or offer to keep the setting.

 

On 5/16/2018 at 3:59 AM, nallath said:

It's going to be hard to explain this to users.

 

The fun part about this is it doesn't have to be any harder to use than what's in place now. If you only load/select one profile, you have the exact same system in place today. Users can continue to work exactly as they do today. Make it harder for users to accidentally enable multiple profiles and I think UX is only improved. ...No doubt you'd want a warning the first time (or everytime) a 2nd profile is added that explains what's happening.

 

I agree, it's not a trivial project - although it would be funny if this is the only sticking point that comes up. It feels like a two week effort to me. It's hard to believe that OOP folks on the dev team wouldn't see the value here but I'm not seeing much excitement. Part of the problem I was having was not using the Materials configs - I think between that and just directly working with the cfg files I can improve my experience.

[nallath 1,120]

Oh, the initial part won't be hard. But then there is also the whole upgrading & project loading that comes in to play. Some of out developers still go into shell shock at the moment you mention either one of them.