Context Question: Per-Model-Settings - why not support all settings?

[filipgoc]

Hi!

I'm curious what is the reasoning for not supporting all settings in the per-model-settings?

Why limit the users of what they can do?

It's not like it's going to be more overwhelming then the regular power-user views.

Cheers.

[filipgoc]

PS: Use-case - I want to change retraction for a specific model that would benefit from it. Why would this not be allowed?

[fieldOfView]

There are some settings that would be intrinsically impossible or at least "hard" to implement. Eg changing the printing temperature between models; would printing have to pause until the hotend reaches the right temperature? And where would it wait (not above the model, because that would leave marks). Layer height would be very hard to implement as a per-model-setting without causing collisions between the head and already printed layers.

A number more settings should be available when printing sequence is set to One at a Time, see this PR: https://github.com/Ultimaker/Cura/pull/3154

Having said all that, I don't know why changing retraction settings is not available for per model settings.

[filipgoc]

I hear you. Of course, some settings like layer height could make literary impossible gcode....

... I don't know why changing retraction settings is not available for per model settings.

Right. Retraction gave me pause because that's not something I can easily hack in text editor (unlike changing temperature for one. Maybe with M600 for good measure, maybe without.)

Right. When I have a minute, I'll try to comb through the settings and see if some jump out at me something potentially desirable. To move this into a constructive critique phase.

[Ghostkeeper]

Always a good thought experiment what would happen if you were to allow "Print Sequence" to be settable per object. Or build plate temperature. Minimum layer time? You're always going to have some settings where setting it per object doesn't make sense.

Some things, like retraction, are not settable per object because they happen between objects. Same goes for travel speed. Eventually we could allow this (falling back to the per-extruder travel speed or something) but jury's still out on the UX of this change.

For some things, like Layer Height, it is theoretically possible but technically difficult due to our architecture.

We're trying to allow as much as we can feasibly implement.

[filipgoc]

@Ghostkeeper You make good points as always.

I'm thinking that making this as universal as possible may be just a black hole of exceptions without a specific use case. However, I do see the use for being able to modify material related settings specifically. Let's focus on that maybe, it's actionable:

There are really only TWO kinds of settings, or about seven if we count all the retraction related things, that I am missing.

Maybe this is a more fruitful way to think about this!

Specific settings I am missing in Per-model-settings that don't seem to be too tricky to allow.

• Cooling options
  • Fan speed
  • Why not? Being able to force higher fan speed for a particularly bridgy or overhanging model makes sense for example, while I don't want to sacrifice bonding strength on other models. Since many of the algorithmic options for fan control are base on layer time, then having the option of forcing a higher flow for a specific model would make sense.
  • Other cooling options like Minimum time per layer would make no sense to implement of course.
• Material options
  • Flow, already implemented
  • Retraction options
  • I hear your argument on retraction happening between models, but I think a simple solution is to use the retraction of the last model (model A) when moving between models and switch to the new one once within the confines of the model B. This feels natural.
  • Retraction distance would be useful. Some models just need higher retraction beyond the default, while I don't want to strain the filament and risk grinding and clogging unnecessarily.
  • Similarly, why not allow retraction speeds, prime amounts, minimum travel, retraction count, window.
  • retract at layer change makes no sense
  • enable retraction sort of makes sense in very niche cases, but it's counter-intuitive. This can be handled by retraction distance being 0 if really needed.

[filipgoc]

PS: One specific use case I have is to print rubber bottom or top on top of PETG or another material. It bonds perfectly. (I just insert a filament change command in a text editor.)

Having control over retraction would allow me to turn it off for the rubbery parts, while still printing PETG as it needs!

I hope this makes sense.

I'll totally make a tutorial on this and praise Cura for it's power retraction handling if this gets implemented :-)

[Ghostkeeper]

Fan speed can totally be done. I've considered this before. I think the choice was made originally because the fan needs to accelerate a bit on old printers. Maybe the implementation could be a bit involved but I foresee no real problems.

I think a simple solution is to use the retraction of the last model (model A) when moving between models and switch to the new one once within the confines of the model B. This feels natural.

Like I said, I'm not sure about the UX of this then. It may feel natural to you but to some users it would not. For instance, the reason why you might want to increase the retraction distance is because you really, really don't want blobs on the surface of model B. Then you'd have to adjust the retraction distance of model A in order to get a better surface for model B. This goes for retraction distance, speeds, prime amounts, minimum travel and enable retraction.

Maximum retraction count and window is a bit of a special case because this window spans multiple objects very often. Even if the UX can be decided on, it's just not technically possible unless you'd go into weighting based on the print time it spends on each model, etc.

Retract at layer change would be technically feasible if it wouldn't be changing layers outside of objects. It almost always change layers while printing an object, except that it could also do that while printing support...

[filipgoc]

---

@Ghostkeeper you make me think that adding a new (very much power user) option to tweak the retraction between models only would not only solve this issue, but add ad a very interesting super power for special cases in printing in general.

It's easy to see how retractions within a model could be quite small, while retractions when moving between models should be comparatively longer.

I know there's some experiments on also pro-longing retractions based on distance traveled while retracting... maybe this adjustment could become part of this possible future function?

[Ghostkeeper]

I would think that an inter-model retraction is no different to the hardware than an inter-part retraction. If it is different because the travel distance is longer then we should let it depend on that.

Retractions also happen when you're moving in for a tool change which is completely different again since the nozzle will hang there for minutes while the other nozzle is busy printing.

[filipgoc]

Right, of course. Once it depends on distance traveled, then no need for a special 'between models flag.'

Another thought experiment I have here is that in the end retractions should be by volume and not by distance. Of course you can get around this by having a separate profile for each layer height and nozzle diameter (/ line width)... but it just makes it hard to make reasonably behaving univeral-ish preset.

This is equivalent of changing temperatures depending on layer heights and nozzle diameters - in reality what we care about is volume extruded. More volume equals higher temperature.

At some point you mentioned that you're experimenting with temperature deltas as a solution. Maybe we can have that sort of solution for more settings. Retraction delta. Extra prime amount delta (this one for sure!), etc.

Tool change should have it's own gcode scripts; trying to have it follow the same rules as general printing could skew everything.

[Ghostkeeper]

We have a setting that indicates the minimum distance before it performs a retraction which is not quite as good as what you're asking for, but a whole lot easier to understand than a setting that indicates some multiplier of the length of a travel move. Because of that I'd vote against making an additional setting to modify the retraction distance depending on the length of the travel move.

Another thought experiment I have here is that in the end retractions should be by volume and not by distance. Of course you can get around this by having a separate profile for each layer height and nozzle diameter (/ line width)... but it just makes it hard to make reasonably behaving univeral-ish preset.

Well, the GUI doesn't support this, but when you're creating profiles by modifying the CFG files you can put formulas in there. You could say that the minimum distance before a retraction is triggered is equal to line_width * temperature / 2.5mm or something.

At some point you mentioned that you're experimenting with temperature deltas as a solution. Maybe we can have that sort of solution for more settings. Retraction delta. Extra prime amount delta (this one for sure!), etc.

The delta printing temperature setting was a workaround in order to be able to set different temperature per quality level but still allow the user to modify the temperature in the material profile. We don't think it's a particularly good workaround and would rather not add more of those.

Tool change should have it's own gcode scripts; trying to have it follow the same rules as general printing could skew everything.

It does have its own g-code scripts! The settings are called extruder_end_gcode and extruder_start_gcode. ~These are not exposed in the GUI but the designer of a printer definition can set them if necessary.~ They are in the GUI!

[fieldOfView]

The settings are called extruder_end_gcode and extruder_start_gcode. These are not exposed in the GUI

Eh? They are exposed in the Machine Settings.

[filipgoc]

Eh? They are exposed in the Machine Settings.

They totally are. Didn't notice that tab when it got added.

This thread is becoming a throve of information.

[filipgoc]

@Ghostkeeper Indeed. I like the idea of coding in some relationship for the extrusion dependent on the temperature/line width/layer height. Thanks for the idea. It does indeed open up a lot of options...

[Ghostkeeper]

The fan speed per object was rejected by our change control board. We think its use case is too small to spend time on it for now.

That's the last of the proposals in here that was yet unhandled.

[Schleichmichl]

I have a different use case why all settings (that are logically possible) should be available in the per object model: Currently, I'm setting up my new printer and I would really appreciate having retraction distance, coasting, etc. available, as I would like to see different setting and their consequences!

One side note to distance depending retraction length: That would be great! I never understood why this is not default, as the choosen distance is only valid for one distance on a certain speed. That beeing said, the perfect solution would be a retraction that is depending on how long the nozzle is moving in mid air! Not distance, the amount of ooze depends on time!

[osterac]

I have also used per-model settings to speed along calibration. If you are using the "one at a time" print sequence option, the changes only need to be applied between models, not once every layer per model. Would it be easier to support more per model settings if they were only supported when using the "one at a time" print setting? Thanks

[nallath]

Theoretically, yes. But it would also mean that we would need to add a new layer of complexity for us to diffrentiate between settings that could be changed when one at a time is active and in per object.

[fieldOfView]

add a new layer of complexity for us to diffrentiate between settings that could be changed when one at a time is active and in per object

As far as I remember, that layer is already there. The problem was that CuraEngine did not support it. https://github.com/Ultimaker/Cura/pull/3154 was merged, but subsequently unmerged because of it.

[Ghostkeeper]

The complexity layer was originally in CuraEngine, which is why #3154 was thought to be possible. It started from CuraEngine since we saw there from the code structure that basically every setting except Print Sequence was re-loaded for every mesh group. That's why we introduced meshgroup level settings which was what #3154 was based on.

However once it was in place we realised that the per-extruder settings were overriding the per-meshgroup settings. This makes sense, because if you print a mesh group with PLA and ABS you'd want part of the mesh group to be printed at 190C and part at 230C. That's important. However that also meant that most of the per-meshgroup settings were overriden by extruder settings. So you could add them in the interface but it had no effect. Only for global settings.

It's not so much as a problem with development time or complexity imo, but more of a problem with requirements. You need each extruder to have its own temperature, but you also need to adjust global settings that override them. Those two requirements bite. I think the complexity that Nallath mentioned lies in a possible solution to add a new layer in the setting precedence of CuraEngine, but the problem goes very deep really.

[bleeep808]

Sorry if I'm missing something, but aren't things more simple than that? (Seeing this from a 4.7.x perspective). Since a) we can pick any option we want as general print configuration and b) we can pick select options, including Flow, for example, as a per-model setting, why can't we then implement all settings and more specifically retraction distance and speed—the one I'm looking for as well for printing a bunch of stringing test models, printed in a per-model sequence. In this specific case, the code complexity and structure for moving to another model then switching to a new extruder speed and distance value should be comparable to switching to the next model with new flow rate (which implies a new extruder speed too, anyway). Isn't it so?

Oh, but I just found a temporary solution! :-D In Extensions > Post Processing > Modify G-Code > ChangeAtZ 5.2.1(Experimental), I select the Trigger type as Layer (rather than height), and below are those options for retraction! If print sequence is "One at a time", each model starts at a specific layer number (even if touching the build plate), so the behaviour is there and proves to be realistically implementable, since it is already implemented somehow! :-D

In conclusion, I'm quite happy with the alternate way, so I don't know how important and easy it is to implement it within the per-model settings. It also makes my comment possibly less relevant, but I guess still useful...

UPDATE 2/9/2020: I just tested the "One at a time"-sequenced ChangeAtZ for retraction settings, and it didn't work. I tested and it worked within a given model, but between them while printing one at a time. (Version: 4.7.0)

[Ghostkeeper]

why can't we then implement all settings

To be clear, for the front-end this is no problem at all. The problem is the slicing engine. Here is an example of the line where it determines whether or not to do a Z hop (the retraction settings are cached in a RetractionConfig object so it's a bit harder to see; this is a better example).

https://github.com/Ultimaker/CuraEngine/blob/e87dbcfa41d24d4722230a48cbf5b168975c6cf6/src/LayerPlan.cpp#L399

This gets the setting from the current extruder. It wouldn't know which mesh to get this setting from since it's called from various places, including when it's travelling between meshes. As such the mesh can't be provided as a parameter. We could track the current mesh (currently we only track the current mesh name), but then it still won't work for travels between meshes, or e.g. travels between supports.

In general our code requests the setting from the most specific setting set available. But if a piece of code is made for support, helper structures or things between meshes, then it won't work for the per-object settings.

I just tested the "One at a time"-sequenced ChangeAtZ for retraction settings, and it didn't work. I tested and it worked within a given model, but between them while printing one at a time. (Version: 4.7.0)

Indeed this feature was removed again a while back (4.3 or so?), since the setting retrieval in CuraEngine didn't resolve this properly. The information in this ticket is a bit old. It is theoretically possible, but currently it doesn't behave correctly if we allow this in the front-end. Here's why:

• CuraEngine currently requests most global settings (like Build Plate Temperature) from the current mesh group. In all-at-once mode there is only one mesh group so that is fine. In one-at-a-time mode there will be multiple mesh groups and the entire slice is repeated for that mesh group, so that's why those global settings could change per-object in one-at-a-time mode in theory.
• However the per-extruder settings (like Travel Speed) are requested from an extruder object. The extruder settings are made to override the mesh group settings. So if there is an extruder override there (e.g. because the material profile changes it) it uses that setting. With multiple mesh groups, the extruder settings keep "moving" on top of the new mesh group.
• The previous implementation would put global settings in this mesh group, which would sometimes work. But if anything in the per-extruder settings overrides it it would use that instead.
• We also can't move the mesh group settings to override the per-extruder settings because then the per-extruder settings don't work any more if there is a mesh group setting in all-at-once mode.

So to fix that we'd need to make the order of overrides depend on the Print Sequence setting. It can be done, but it's a bit risky (it might change the interpretation of all settings) and maybe a lot of work.

[bleeep808]

Thank you for your explanations. My programming skills are basic, so I couldn't help with a solution to that problem. I wonder how other slicers do on that front...

[jeremysalwen]

I read through the description above as to why this is a difficult problem. Is it possible that one of the following approaches could work as a workaround?

1. Remove all settings from the extruder that we want to override per-model (as I understand it, if they are not set by the extruder, it will fall back on settings lower in the stack?)
2. Make many fake copies of the extruder, one for each mesh group, so the settings can be overridden through settings on the extruder. (but ultimately the copies of the extruder all correspond to one physical extruder?)

These might be too ugly to implement directly in cura, but perhaps I could implement them as a hack in a plugin?

[Ghostkeeper]

That would also require changes to CuraEngine to get the setting from the correct settings object though, as I think you've seen in your PR development.

The routines that need the settings currently don't know yet which object they are working for in all cases. This might also be different within the same travel move. For instance, if one object has the avoid distance set to 3mm and another to 1mm, then combing needs to take the different offsets into account. When working for a specific object we tend to pass on the object where possible, but the routines that are currently not object-specific are the ones where the settings are not settable per object.

[traviselam]

Just throwing my 2 cents into this. Having the experimental coasting settings in the per model settings would be a really handy feature when attempting to perfect your z-seam with new filaments on small test models. Thanks guys!

[rburema]

FIY: Finally got around to the PR (should not have taken this long, sorry). At least some of the retraction settings will be per-model in 5.3 (as long as this also passes QA).

(So, no coasting yet for example, leaving this issue open for discussion.)

[MoppelMat]

FIY: Finally got around to the PR (should not have taken this long, sorry). At least some of the retraction settings will be per-model in 5.3 (as long as this also passes QA).

(So, no coasting yet for example, leaving this issue open for discussion.)

I really appreciate your efforts on this so far. The only thing I (and a few others) are missing is retraction distance on that per object mod. We want to use it to tune easily for the best without the need to print 10 tries. Just in one go, select the right one and be done. It would be great if you could add the retraction distance to the list. those seem to work in 5.3.0: