Cura: Supported skin fan speed override should also be possible to caclulate as an extra increase rather than an override.

[printingotb]

Is your feature request related to a problem? Please describe.
When printing for example PLA I may want the fan to increase from 50% to 100% but when printing ASA I may want it to increase from 0% to 33% instead.
For the PLA example, 100% is probably only beneficial.
For the ASA example, it would probably ruin the print if the fan speed becomes 100%.
If I instead set the fan speed override to be 25% to avoid trouble with high temp filaments and use that setting with PLA, it actually lowers the fan speed from 50% to 25%.
It would be great if I could set this value once and have it adapt in relation to the regular fan speed for different prints without needing to change it more than perhaps occasionally.

Describe the solution you'd like
-An option to add % units as an increase on top of the regular fan speed. This way I can set it to always become say 33% higher regardless of the material I am printing with.
This should obviously not turn on the fan if Print Cooling is disabled but I think it's best if it also doesn't activate if the fan is "turned off" by the user by setting the fan speed 0.

Problems I can imagine:
The relations between this and Regular, Maximum and Initial fan speed. My gut tells me it should be on top of regular fan speed with the possibility for the max fan to override this.
How this would look in the interface with variables possibly becoming larger than 100%. A check-box that tells Cura to treat the override as an increase, showing a yellow warning if it totals more than 100%?

Describe alternatives you've considered
-Adding a % of the Fan speed on top.
Problems I can imagine:
Same as above.

-Prevent the override from reducing the fan speed and settle with that.

Affected users and/or printers
Everyone wanting easy support removal with optimal surfaces over the supports.

Side-Note
Will add a feature request for the Bridge Fan speed to do the same if this becomes reality.

[Asterchades]

While not exactly what you're requesting, the "Material Settings" plugin can be used to add the Supported Skin Fan Speed setting to the Material Properties as well, allowing you to adjust it with the material rather than the profile (provided, of course, that you haven't adjusted the profile as well as that takes priority). It isn't calculated but at least it can be defined on a per-material basis.

This may also be usable in your other request since you could change the Bridge Fan Speed in the same way.

[printingotb]

Thank you for your reply.
I want to avoid using material settings for this as I want to be be able to share settings profiles with beginners (or anyone) without them needing to use customized materials together with my profile. Support settings are one of the most difficult things with 3D-printing and I believe this setting has potential to make it easier. If one isn't aware of it or how to use it, one won't benefit from it.
I'd really like to utilize the fullest range of Cura's settings in a way that they are helping without the user even needing to know about them.
If this request can't be met, I will simply have to leave this setting turned off in my profiles that I share.

[Asterchades]

It would be a preferable solution to your proposal, based on your requirements. I mean if you automatically set it to increase the fan by 33% then you'll wind up with your 50% PLA profile (which you presumably would share as a guideline) going to only 83%, but your (presumably) 0% ASA profile going up to 33% - the former being lower than your ideal value, the latter being higher than your suggested value. The option of course exists to make it proportional but then you'll run into a problem where a 0% base stays at 0% no matter how much you increase it as a multiplier.

That all having been said, it is technically possible to create a function-based value for such things. But it needs to be done at the printer level, not the print settings. And then it needs to be installed manually into the appropriate directory (eg %appdata%\Cura\4.8\Definitions in Windows). Some people have requested better integration of such things into the base UI, though, so it's something Ultimaker knows people are aware of.

[printingotb]

My thinking is that enabling it with a small increase is better than having it disabled. At the same time, a small increase prevents the cooling from going too high. I would test what the highest working increase is for all the common materials and set it slightly below that.

My last generic PLA profile has worked really well with at least PLA, ABS, and PETG with the user changing only temps, flow, retraction and cooling. I have had people tell me that they didn't think that their printer could print that well so I am doing something right with it.
The speed is set fairly low to work with most cheap printers and the user can increase it as needed. There's other time-saving tweaks in the profile that compensates.

Thinking more about it, there may still be too many hardware variables involved for this particular setting to have a fit-all fixed value. And having a very small fan speed increase may not be worth the risk of complications. The user will need to adjust the base cooling to match the printer's cooling solution anyway so a 33% increase will have a very different impact on different printers. A proportional increase would be the best then. If the user has cooling set to 0%, it's probably best if it doesn't turn on the fan as to avoid confusion when the user expects no cooling. The increase setting would then receive yellow a warning if the regular fan speed is set to 0.

But perhaps this setting would probably be most useful for my own profiles rather than for my shared profiles.
Can you change the fan speed override to ignore values that are lower than the regular fan speed?
.

That all having been said, it is technically possible to create a function-based value for such things. But it needs to be done at the printer level, not the print settings. And then it needs to be installed manually into the appropriate directory (eg %appdata%\Cura\4.8\Definitions in Windows). Some people have requested better integration of such things into the base UI, though, so it's something Ultimaker knows people are aware of. <

As in that I could add my own functions to settings values? So I could for example set "fan_speed_override" = (regular_fan_speed*1.25)+5?

[Asterchades]

Oddly enough, I've been trying to do much the same thing as you recently - just on the other side of the equation. I've been making a printer profile, instead of a print profile, but don't have access to ASA/ABS to test the effect of fan speed (100% fan on bridges has been doing wonders for PETG, up from a 20% base).

Can you change the fan speed override to ignore values that are lower than the regular fan speed?

As in that I could add my own functions to settings values? So I could for example set "fan_speed_override" = (regular_fan_speed*1.25)+5?

Yes. It's not as straight forward as a profile you can give someone a copy of and tell them to import it, but it isn't the most difficult thing in the world. This is what I've been doing, but as I mentioned it has to be done at the printer level rather than the print level. In other words the file gets put into the correct location, then you can add a new printer which includes all of those settings as defaults - complete with calculations.

The "correct location" will vary from system to system. Under Windows it is "%appdata%\Cura\\defintions\", OSX is "$USER/Library/Application Support/cura//definitions", and Linux is "$USER/.local/share/cura//definitions". needs to be replaced by the major version number of the Cura you're targeting (eg The current release of 4.8.0 goes into "4.8", while the previous 4.7.2 was "4.7" and so forth).

As to what the file needs to contain, and how it needs to be formatted? That's where it gets interesting. Best bet is to reference the existing profiles included with Cura. The master profile is here: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json (every single parameter is listed here) while you can see what changes might look like by taking a look at something like the Ultimaker 2 here: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/ultimaker2.def.json . You can choose to redefine every single value if you like, but probably want to at least inherit "fdmprinter" regardless in case you miss something.

To get your desired results you would need a line that states "support_supported_skin_fan_speed": { "value": "min([100, cool_fan_speed * 1.25 + 5])" },. The reason for the "min" statement is that Cura doesn't automatically sanitise its values, and if you try to set the fan faster than 100% it will simply refuse to slice.

If you adjust a setting and load Cura only to find it asking you to add a printer, you can use the log to find what went wrong. It should list a debug note shortly after the last pligins are loaded ("INFO - [MainThread] UM.Logger.info [123]: Loaded plugin ") stating what line, column, and file has a problem. It's almost always that trailing comma at the end or a missing quotation mark.

Small caution, though. I've been able to set just about everything with this but cannot get it to override the default material diameter, so it needs to be manually changed from 2.85mm if required. Also you need to either use a new print profile or the "Fine" default to get everything to match what you've programmed.

You can kinda see why people want the function ability built in to the UI. It really would be a lot easier. But you can also appreciate why Ultimaker hasn't, since it could be a nightmare to maintain and diagnose issues when it's in play.

[printingotb]

Thank you for this info! I will save this for when I have time to use it.

[Ghostkeeper]

There is an open feature request to allow entering formulas in the interface too: https://github.com/Ultimaker/Cura/issues/3856

It's not something we're really against, as long as the feature is hidden from users that don't understand it. But it's indeed such a big feature request that it gets pushed back on our backlog indefinitely and will probably take a long time before we get to it. Unless there is a push within Ultimaker from outside of the Cura team, maybe, but Ultimaker's target audience tends to play it a bit safer with the settings, keeping more to the defaults than the experts here on Github.