FanControl, my take on a SpeedFan replacement

[Adrenalina]

3 minutes ago, Rem0o said:

It will set at T1 speed, since T1 triggered the change, but then T2 never triggered it from T1. Step size has nothing to do with the hysteresis mechanism.

Stepsize is relevant in the following sense:  In the scenario I described, the small stepsize caused the speed to have not yet reached the T1 speed when the temperature increased from T1 to T2, and in this case I believe the hysteresis setting should be ignored and the speed should continue stepping toward the T2 speed.  With a large stepsize, the speed would reach and settle at the T1 speed before the temperature increases from T1 to T2, and in this case the hysteresis should not be ignored and the speed should remain at the T1 speed.

 

Based on your answer -- the speed will get stuck at the T1 speed in the scenario I described -- I hope you will implement the slippery slope behavior, so that there will be an extra condition that causes FanControl to update the target speed (and continue stepping toward it): the fan speed is still being stepped toward what the curve target speed would be if hysteresis were 0. (This condition is independent of the hysteresis setting.)  I imagine this extra condition would be easy and quick to code.  It wouldn't require any changes of the user interface.

[Tuupertunut]

May I ask why are you not open sourcing this? I'm asking because I don't see any good reason why someone would keep their free (as in no cost) software closed source. Often when people do this, they are under some false assumption about open source, such as that they would need to clean their codebase or accept pull requests.

[Rem0o]

3 minutes ago, Tuupertunut said:

May I ask why are you not open sourcing this? I'm asking because I don't see any good reason why someone would keep their free (as in no cost) software closed source. Often when people do this, they are under some false assumption about open source, such as that they would need to clean their codebase or accept pull requests.

Because I operate this as a donationware.

https://en.wikipedia.org/wiki/Donationware

[Rem0o]

Update 36

• Hide individual control cards
• Removed hide disabled fan control cards option
• Graph fan curve dialog tweaks
• Added disable storage sensors option

https://github.com/Rem0o/FanControl.Releases/releases/tag/V36

Enjoy!

[Tuupertunut]

1 hour ago, Rem0o said:

Because I operate this as a donationware.

https://en.wikipedia.org/wiki/Donationware

So do you feel like you would get less donations if it was open source? I know a lot of open source projects that rely on and get donations and I doubt that closed source would motivate people to donate more.

[RaazP]

On 6/29/2020 at 7:39 PM, Rem0o said:

Or is it that since the 2nd graph is much faster (1s vs 10s), you get a fast response at that specific threshold, but for the rest of the temperature range, the 2nd graph goes to 0, so the mix curve switches to the 1st graph, which is a much slower/smoother response? If that is the case, that's very smart! You get the fast threshold ("burst") effect for a very high specific temp, and a smooth linear one for the rest of the range.  Never thought of doing that, very nice!

 

In other words, instead of mixing different sensors, you are mixing response time depending on the temperature.

Just to report back:

Yes, that's what I did and thanks for calling it smart hehe. 

After I read that you have a completely different perspective I thought I might just need to change mine. 

So I went back to what fan behavior I want exactly and what fancontrol gives me to work with. 

Thought if I can't achieve it via temperature curves, I might be able to mix another parameter. 

 

Works very well since then! Very stable and steady fan speeds with some bursts when loading save games from idle or rendering a video without editing right before. 

 

Still adjusting here and there but it works very well to mix response times! 

[RaazP]

17 hours ago, Adrenalina said:

Stepsize is relevant in the following sense:  In the scenario I described, the small stepsize caused the speed to have not yet reached the T1 speed when the temperature increased from T1 to T2, and in this case I believe the hysteresis setting should be ignored and the speed should continue stepping toward the T2 speed.  With a large stepsize, the speed would reach and settle at the T1 speed before the temperature increases from T1 to T2, and in this case the hysteresis should not be ignored and the speed should remain at the T1 speed.

 

Based on your answer -- the speed will get stuck at the T1 speed in the scenario I described -- I hope you will implement the slippery slope behavior, so that there will be an extra condition that causes FanControl to update the target speed (and continue stepping toward it): the fan speed is still being stepped toward what the curve target speed would be if hysteresis were 0. (This condition is independent of the hysteresis setting.)  I imagine this extra condition would be easy and quick to code.  It wouldn't require any changes of the user interface.

To break this down, your thought is:

Hysteresis 20, response time 1s, stepsize 1

Linear fan control

 

50° at 0 seconds

71° at 1s

Fan speed goes up 1 step

 

2 seconds:

point on curve at 55°, temperature still 71°

Fan speeds are stuck since the difference is now only 16°, hysteresis not reached

 

75° at 3s

Fans still won't respond

 

77° at 4s

Fans will go up to the 57° point on there curve? 

 

So in theory you need to set the fans to the maximum for "target temperature minus hysteresis"?

 

With a big stepsize (50%), the fans would jump to their "correct" point on the curve though and won't get "stuck"? 

 

Anyway to give you a quick solution: just do what I did, create a second fan curve that hard limits the temperature via hysteresis and response time at minimum so if that get reached the fan speed goes definitely up. 

 

While I'm at it:

Stepsize per fan curve instead of per fan would be awesome! 

Would make my slow curve even smoother, while my upper limit can spin the fans up swiftly. 

 

But I'm happy as it is now anyway. 

[Rem0o]

2 hours ago, RaazP said:

So in theory you need to set the fans to the maximum for "target temperature minus hysteresis"?

Just to clarify, this scenario you mentioned is wrong. The fan curve will continue to go to the 71 degree point until there is a change from that 71 degree that is larger than the hysteresis. Even if it drops back to let's say 65, or go up to 75, it will still be at that 71 degree until the temp reaches 81 or drops back to 51 ( 20 deg hysteresis ). That creeping effect you are referring to doesn't exist.

[Adrenalina]

As Rem0o pointed out above, the behavior that RaazP described is not what FanControl does.  It's also not what I described in my example, where the fan speed gets stuck at an undesired speed and "slippery slope" behavior is needed.

 

So I trust Rem0o will not be sidetracked by RaazP's incorrect analysis of my example, and will continue to consider the need for slippery slope.  The pseudocode snippet below shows how easy I think it would be to include the slippery slope behavior.

[EDIT: Corrected a bug in my initial pseudocode: PrevStep must be set to ProposedStep at the end only if the step is actually made; else PrevStep must be set to 0.]

 

There are other names we could call it besides "slippery slope."  Perhaps "inertia" would be a better name, to suggest the fan speed% should keep stepping in the direction it has been stepping (assuming the next step will move it closer to the curve speed%) regardless of the hysteresis setting.  Another possible name is "zero sliding friction" to suggest hysteresis should not apply while the fan speed% is stepping toward the curve speed%.

 

As a coding technique, one could multiply the previous cycle's step (which may have been upward/positive or downward/negative or zero) by the proposed next step.  If the result is a positive number, this is the case when the proposed next step should be taken regardless of hysteresis, since in the previous cycle the fan speed% was stepped toward the curve speed%, which implies the fan speed% hasn't settled.  If the result is negative, the proposed step is in the opposite direction as the previous cycle's step, and nonzero hysteresis ought to prevent the step.  If the result is 0, then either the fan speed% had already settled somewhere (so hysteresis may prevent the proposed next step) or the fan speed% is already at the curve speed% and the proposed next step is 0.

 

Here's a snippet of pseudocode, in which the expressions highlighted in blue show a way to include the "inertia" behavior into FanControl:

Quote

//  Note: speeds and steps are percentages, not rpm.

ProposedStep = getcurvespeed() - FanSpeed

if ProposedStep<>0

   and (isallowedbyhysteresis()

           or PreviousStep*ProposedStep>0)  {

     //  Limit the step to STEPSIZE setting.

     if ProposedStep > 0  {

        ProposedStep = min(STEPSIZE,ProposedStep)

     } else {  //  The step is negative.

        ProposedStep = max(-STEPSIZE,ProposedStep)

     }

     //  Step the speed toward the curvespeed.

     FanSpeed += ProposedStep

     setfanspeed(FanSpeed)

     PreviousStep = ProposedStep

} else {

     PreviousStep = 0

}

 

Edited July 2, 2020 by Adrenalina
Fixed bug about setting PrevStep, as described; noted near the top that pseudocode is at the bottom; deleted a paragraph that basically repeated my previous messages; replaced STEPSIZE code with more efficient instructions.

[RaazP]

Thanks guys, I see now where I was wrong. 

Always good to learn! 

[Jean-Pierre57]

Thanks for the update 36

[Samfisher]

Oh man I love that this is development on this is still ongoing!  Tried it super early on but couldn't get it to work properly with my board, but might try this again tonight!  Friday night tinkering, that's the life.

[fray_bentos]

Sadly not detecting anything other than my GPU fan on a Z490 MSI Pro-A. Too new?

[Rem0o]

3 hours ago, fray_bentos said:

Sadly not detecting anything other than my GPU fan on a Z490 MSI Pro-A. Too new?

Yup, not interfaced yet. Send me your log in DM.

[Peterka31]

B450M Mortar Max + 3700X here.

The app looks awesome, yet for some reason doesn't want to control the case fans. It recognizes the RPM of CPU and Case fans too, but i can only control the CPU fan, not the rest. The % goes up, but the speed stays the same. I want to achieve a simple "switch to 100% fan speed" on click.  Dragon Center can control them from windows, but thats a bloatware

[Rem0o]

6 hours ago, Peterka31 said:

B450M Mortar Max + 3700X here.

The app looks awesome, yet for some reason doesn't want to control the case fans. It recognizes the RPM of CPU and Case fans too, but i can only control the CPU fan, not the rest. The % goes up, but the speed stays the same. I want to achieve a simple "switch to 100% fan speed" on click.  Dragon Center can control them from windows, but thats a bloatware

 

Sadly it looks like your chip ain't supported yet.

[Adrenalina]

The screencapture below appears to show a FanControl bug or two.  The Cpu/Gpu temperature is warm enough that the curve (lower left of image) should be in the 100% zone but the curve output is only 97% and its yellow dot appears to be displayed below the curve.  Also, the CPU Fan speed (upper left of image) is stuck at 96% even though hysteresis is set to 0.

 

[EDIT] I've attached a 30 second video that shows the behavior described above.  To make the cpu/gpu temperature go up and down, I used Avidemux to encode with an x264 codec and then paused the encoding.  The video attached below shows both the FanControl window and the Avidemux window so you can see when I started and paused Avidemux.

FanControl cpu fan speed bug - screen recording while x264 encoding started-paused-started (50 kbps 2020-07-09 08.49.07).mkv

Edited July 9, 2020 by Adrenalina
Added a 30 second video to show the bug in action

[Tido_III]

MSI X570A-Pro with Ryzen 5 3600

 

I've been using SpeedFan 4.52 - I know it's no longer supported but i liked the instant control on the GPU fan rather than messing around with the Amd Radeon application settings  which don't always seem to work or keep saved beyond current session (have a Radeon RX 570 8GB)

 

Really like the look of this app. Have just been playing around a little but not getting very far so far. Before i go any further, is the X570A-Pro supported?

 

It does seem to be detecting all my fans:

Fan 1 = Chipset Fan (I think). Although it's showing 100%, RPM is 0 and fan is not spinning (rarely spins anyway - I think the threshold is quite high for this fan)

Fan 2 = CPU Fan. (Arctic Freezer 33 Air Cooler)

Fan 3 to 5 = Front 3 LED fans (intake) plugged into Sys_Fan 1, 2 & 3

Fan 6 = I assume this is for Sys_Fan 4, which has nothing plugged in and in temps is showing as -1

 

fyi - I also have 4 other LED fans (1 bottom intake, 2 top exhaust, 1 rear exhaust) which are on an rf controlled hub so obviously wont show here.

 

Thanks

[Rem0o]

@Tido_III

 

Your board got a NCT6797D, which is supported!

 

From the top right menu, try to use the "match fan auto", then the "detect fan activation".  These should fill out your control cards with the RPMs and activation %. You can then hide the "speed" middle row of cards.

To start controlling speeds, simply select your created fan curve from the drop-down of the desired fan control card.

[slmklc]

Thanks for hard work, unfortunately not working on my asrock g41m-vs3. It only shows my GPU.

 

I sent the logs via dm @Rem0o

[Rem0o]

Update V37

 

• External temp. sensors: Create a *.sensor file in the app folder to create a temperature file sensor. See the Example.sensor file. You can update that file from an external source.

This hides a big refactor of the backend of the software, which was the main work, making it more modular, enabling new stuff like this.

 

Stay tuned and enjoy.

[Adrenalina]

I appreciate the new .sensor file feature in version 37.  It allowed me get rid of my complicated system in which a .bat script starts & stops separate copies of FanControl, and to replace it with a much simpler .bat script, which periodically runs smartctl.exe to read my external drive's temperature and writes the temperature to the .sensor file when the temperature changed.  A single copy of FanControl now controls both my internal fans and my external fan.

[Adrenalina]

Here's a discovery that I think is worth sharing: FanControl can make a pwm fan go to 0 rpm if the fan is set in the BIOS to DC mode instead of pwm mode.  I tested this with new ARCTIC pwm fans and two MSI motherboards (MSI X470 Gaming Plus and MSI B350 Tomahawk).  When the BIOS is set to pwm mode, the fan always spins and its minimum speed is about 240 rpm.

 

I don't know how many uses there are for 0 rpm, but it's useful for my external fan that cools my external hard drive, when the drive is cool enough.  I imagine it would also be useful in a system that has many case fans, so that one or more fans can be off when the computer isn't under heavy load.

[Ja50nK]

14 hours ago, Rem0o said:

Update V37

 

• External temp. sensors: Create a *.sensor file in the app folder to create a temperature file sensor. See the Example.sensor file. You can update that file from an external source.

This hides a big refactor of the backend of the software, which was the main work, making it more modular, enabling new stuff like this.

 

Stay tuned and enjoy.

Oooh. Could this be used for the Delta T scenario? Use the file to create a virtual sensor that equals Water Temp - Ambient Temp? Not sure how I would do that , but seems like a step in the right direction?

[Adrenalina]

Below is another screencapture that illustrates a FanControl issue that I mentioned a few days ago, where the output of a curve appears wrong.  In this screencapture, the curve that's misbehaving is the "C: SSD -> Mix" curve in the lower left.  The temperature of the ssd is 35C and the curve ought to output 26% according to the curve editor window, but the curve output is only 12%, as shown in the lower left.  In the curve editor, 12% corresponds to a temperature much colder than 35C. The yellow dot is far below the curve, presumably at 12%.

 

If this behavior is not a bug and is due to the hysteresis feature, then I think the hysteresis feature should be changed so that FanControl will not ignore a series of slow small temperature changes that sum to a significant temperature change. 

 

But I don't think this issue is due to hysteresis.  I've observed my cpu fan curve, which has hysteresis set to {0%,1s}, moving back and forth between speeds below what the curve calls for.  Clearly hysteresis doesn't stop FanControl from changing the speed, and it doesn't make sense to me why the speeds (and yellow dot) stay below the curve.