Feature Request: Add fan speed changes to 'Height Range Modifier' modifications.

[ayerlock]

Version

2.2.53

Operating system type + version

Windows 10 Pro v2004 build:19041.450

3D printer brand / version + firmware version (if known)

Voron v2.4/Klipper

Behavior

Currently 'Height Range Modifiers' only allow changes to 'Print Settings'. I am working on printing spheres and on the lower levels of the sphere I need to disable 'Print Settings' -> 'Perimeters & Shell' -> 'Overhangs' -> 'On perimeters' -> 'As bridge' due to the fact that on external perimeters on the low end of the sphere, it introduces artifacts due to the modified bridge flow.

• I cant modify the bridge flow to 100% as that negatively affects my normal bridging.
• Bridging allows for alternate fan/cooling settings under the 'Filament Settings' tab which I need on the lower half of the sphere's external perimeters so they do not sag. The best way to solve the problem would be to allow the modification of Fan Speed during a specific section of the print (the lower half).

Is it possible to add Fan Speed modifiers based on height?

This is a feature request.

[supermerill]

#934

[killdaclick]

Any chance for this very usefull feature in any future version?

[CCS86]

I would really love this feature too.

Certain layers could definitely benefit from less cooling to improve the bond at a critical point in the model.

Certain objects may also globally require more or less fan.

[Physicator]

Same here, preferably also including the "layer time goal" parameter. This is one of the main reasons I frequently have to switch back and forth between SuperSlicer and Ideamaker (the latter still offering better control but much worse info / analysis tools).

BTW, great overall work and progress so far!

[psi-4ward]

+1 !!

[limefrog-the-genuine-one]

I'd like to see this feature also.

[supermerill]

note: currently, you have to define a second filament, add an extruder, set your printer to single extruder mmu, and then switch to the second filament with via the (+) in the right slider. Yes, it's a hassle. Yes, the feature is useful. No, it's not easy to add.

[limefrog-the-genuine-one]

@supermerill

Well yes, seems to be a hassle. But I look quite a bit further for this feature: To make the percentage of the fan speed dependent of the absolute height of the object or the relative height within the declared modifier, having it increasing or decreasing smoothly between two declared values - not with a step function. Doing the change smoothly should avoid too abrupt changes of the surface appearance.

the same thing I'd like to propose for printing speed, since doing the change smoothly will avoid abrupt changes of the surface appearance even more than fan speed (appreciated as a general modifier over all speeds. And no - I don't use the Base speed with percentage modifieres. It is quite a pain to calculate the absolute speeds you get out of there because of the confusing dependencies - maybe it is another feature request to enter just absolute speeds and let the slicer calculate the percentages in the background - then just tune the Base-Speed to alter all speeds accordingly).

Just to explain one of my my use cases: I'm printing very tall and slender parts (height more than 500mm, area below 750 mm²) so I'd like to reduce speed continuously over the complete height to reduce impact/friction to avoid knocking over my parts. I observed problems when traveling across already finished infills within the same layer, when moving to the next part. So the traveling speed should be included also (would like to see the print head leaving the part via the shortest way to the perimeter and moving to the next part without crossing more than that's perimeter, staying outside any other parts while traveling - kind of inverse version of the existing 'not crossing perimeters' function which keeps the print head within the part).

And yes, this is off topic here - but just because we are in contact now, i have another proposal: Regarding to the infill pattern 'Support Cubic' - having a minimum sparse factor to set also, would make it much more versatile.

On the other hand I can see the lack of the German translation - maybe i can assist here. I'm not a programmer but I'd like to offer my help in revising the translation.