[FR] Fan speed multiplier

[VanessaE]

This is Slic3r merill-merge branch, commit d5dd3c55.

Is your feature request related to a problem? Please describe.

I suppose you could call the following a problem...

Consider a scenario where someone has three printers, each placed such that they happen to be exposed to significantly different environments. For example, there might be two printers on opposite ends of a long desk in the user's workshop or computer room, with a window, A/C, or open doorway near one of them, and a third printer set up in the hallway closet.

Going on the assumption that they are all well-built, properly-calibrated, and of approximately equal performance, then apart from their mechanical limits, the only thing that should differ between these example machines is their part cooling performance, at least in theory. That machine that's in the closet would generally need the highest fan speeds, the one sitting near the window/door will probably need the lowest speeds, making the one at the other end of the table the "normal" or "baseline" machine.

My two printers' cooling behavior differs in exactly that manner, as one is enclosed, the other is open to the air.

To account for differing cooling behavior from one machine to another, the user needs to have one filament profile for each printer and color/material combination, or some document they can refer to in order to adjust the cooling settings to suit the printer.

I think this is wasteful, prone to error, and just plain a pain in the butt. :laughing:

Describe the solution you'd like

I would prefer to only need exactly one filament profile for each material/color -- it should be the job of the slicer to adapt the user's fan settings to suit the printer, since the difference in cooling behavior between two machines simply isn't going to vary.

I had in mind a fan speed multiplier, presented as a decimal value with 1.0 being the default. This would be analogous to a filament's extrusion multiplier, but this value would be specified in the user's printer profile, so that it can change according to the printer in use.

I figure a decimal value would avoid people confusing this parameter for an actual fan speed.

Example behavior:

Assuming a normal range of 0-255 for the M106 command, and rounding the speeds to the nearest integer...

If some feature in a print has a fan speed of, oh, let's say 25% (64), and the proposed fan multiplier in the printer profile is, let's pick a random setting of 1.20, that puts the fan at 30% and the command written to g-code would be M106 S77.

Going the other direction, suppose a feature has an initial fan speed of say, 60% (~154), and the printer profile specifies a fan multiplier of 0.9. In that case, the final fan speed would be 54%, thus M106 S139.

One could argue that this multiplier should also be applied to the "Enable fan if layer print time is below" and/or "Layer time goal" settings, but I'm not sure that's really needed.

In any case, a multiplier would allow the slicer to alter the cooling behavior to suit the printer, without further user intervention. Some of us can barely remember how to load filament as it is. :smile:

Describe alternatives you've considered

I've been doing the whole duplicate-profile-and-modify routine, as mentioned above. I have 2 printers and about 30 different filaments, all of which are usable on both machines. That's a bare minimum of about 60 filament profiles.

Imagine someone who has even more filaments and several printers... duplicating filament profiles of course does work, but that becomes unsustainable very quickly. When the time comes to tweak a filament profile, that change would most likely need to be reflected in all of the other-printers' duplicates as well (for example, if the diameter of a particular material/color changes from one spool to the next).

[kc8rwr]

What if there was an option to set a "cooling factor" instead of an actual fan speed percentage. When cooling factor is used it would be taken into account, along with an ambient air temperature sensor to calculate a fan speed percentage. Of course that means the printer has to have an ambient air temperature sensor. I am thinking that is basically the same thing as enclosure temperature, which firmwares already support. I'm just calling it that because to use this feature one would have to add a temperature sensor even to printers that have no enclosure, then just configure it the same as if it were an enclosure temperature sensor.

[supermerill]

I added a "temp offset" in the extruder, I guess it's fair to also add a kind of fan offset/ratio/percentage

But i agreee that all that stuff should be on the firmware side. If a printer need more cooling, or need more heat, then the correct option is imo to add the offset in the printer firmware config.

[VanessaE]

But i agree that all that stuff should be on the firmware side

Well I can kinda agree with that... if a command were provided to change the ratio, then an in-firmware implementation could work, and that command could go in the printer profile's start g-code.

But problem with that is there are many firmwares out there, but just the one Slic3r. Putting it here is easier. :smile: Besides, if it were in the firmware, it wouldn't be possible to extend it to scale the time-related settings I mentioned, since only the slicer knows those.

(Nevermind Cura, KISS, S3D, and whatever else there is... they don't count. :stuck_out_tongue:)

[supermerill]

I checked and there is a fan offset in the extruder section ... since 2020-09

[VanessaE]

Oh you're right! I rarely ever look at that page since both of my printers are single-extruder. That said, the value there is additive, or so it says, but I had in mind a multiplier.

[supermerill]

I can modify it to be a float or % But I have a bit of a philosophical problem about what should be the right thing to do:

• A % is an added offset and the float is a ratio (near 1)
• The float is added to the fan speed and the % modifies the speed by this percentage

I tend to move all ratios to % field (like for bridge_ratio), but there is still some (like extrusion_pultiplier), so I think the second is more in line with the current GUI. But is it the most intuitive?

[VanessaE]

I tend to move all ratios to % field (like for bridge_ratio), but there is still some (like extrusion_pultiplier), so I think the second is more in line with the current GUI. But is it the most intuitive?

Well... if it helps, in other fields, neither a percent nor a ratio is actually all that intuitive when it's being applied onto something that is itself a percentage, and those with power use that to confuse the peons (and more). It's why things like "25% off!" sales work. :confused:

That said, "out there" in the real world (yes, it really does exist :smile:), folks talk of "percentage points" (or simply "points") when they mean to add or subtract some raw figure to an existing percentage.

Consider:

Maybe percent values are best used on things where the base value is some known unit -- a bridge is a cylinder whose radius is the nozzle diameter and its length is the length of the move, extrusion flow on any other print move is based on the rounded rectangle maths on the Slic3r website, etc.

Conversely, a multiplier or decimal ratio makes more sense when the base value is an unknown unit -- fan speed is a percentage, since that's effectively what firmwares need^[1], so all we can do is multiply against that.

Bottom line:

I have no freaking clue which is more intuitive to most, so go with your gut. :wink:

---

[1] Okay, it's usually 0-255, but since virtually no motherboard can sense fan RPM, that and the mass airflow will vary from one printer to another, given the same raw value.