FanControl, my take on a SpeedFan replacement

[Adrenalina]

Is it okay if I post a small .bat file here to show one way that people could use FanControl's new .sensor feature?  It's an infinite loop that uses smartctl to read the temperature of a usb-connected external drive, and when the temperature changes it's written to the .sensor file.  It's less than 20 lines of code (not counting the helpful comments).

[Rem0o]

5 hours ago, Adrenalina said:

Is it okay if I post a small .bat file here to show one way that people could use FanControl's new .sensor feature?  It's an infinite loop that uses smartctl to read the temperature of a usb-connected external drive, and when the temperature changes it's written to the .sensor file.  It's less than 20 lines of code (not counting the helpful comments).

Create a new thread and link it in a single post, that's fine.

[MagicTeePee]

Hi, love that you made this as it was exactly what I was looking for!

Only issue is, I can only control 3 out of my 5 fan connectors (4+cpu_opt), even though the others are being shown with the correct fan speed .

I have a Gigabyte z170x UD3 with an IT8628E which I believe is supported

Is there something I could do or am I just out of luck?

[Rem0o]

3 hours ago, MagicTeePee said:

Is there something I could do or am I just out of luck?

This chip is mapped generically, so only the 3 default fan controls are mapped.

[SCOTT968]

On 8/31/2019 at 1:01 PM, Rem0o said:

______________________________

Version updated date: 11/07/2020

 

New version include OTA update with versioning.
Make sure you have at least such version to get future updates!

 

Current update version: 37
 

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

Direct Download

______________________________

 

To run at startup: use the included cmd file

 

"Register_Startup_Task.cmd"

______________________________

 

Tutorials:

 

 

 

 

 

______________________________

       TLDR

______________________________

 

I built a new custom UI on top of OpenHardwareMonitor with additional features, mainly linear fan curves with custom temperature sources.

 

______________________________

     STORY

______________________________

 

As you guys may know, SpeedFan is sadly not updated anymore, so newer boards are not detected properly. 

 

The main feature I used was the custom fan curves with custom temperature sources. I used it to bind my case fans speed to the hottest component of my PC, my GPU. 

(My BIOS only supports CPU temperature as a temperature source for the PWM fans).

 

I searched around for an alternative software with this particular feature and only found a paid option (Angus Monitor).

 

However, I also came around this:

https://github.com/openhardwaremonitor/openhardwaremonitor

https://github.com/LibreHardwareMonitor/LibreHardwareMonitor

 

The first link is an original project which could be downloaded here https://openhardwaremonitor.org/, but just like SpeedFan, the project is not updated anymore.

However, thanks to the code base being open sourced, there are a couple of active branches, LibreHardwareMonitor being the best one I found, supporting my MSI Z390 Edge AC board and being updated regularly.

OpenHardwareMonitor is divided into two parts, an API to interact with your hardware ( CPU, RAM, Fans... ) and a UI. The existing UI is a HWMonitor clone that allows to set a manual fan speed to any fan, but no temperature/speed fan curve here.

( sigh )

 

So I decided to make my own lightweight application with the OpenHardwareMonitorLib API, and here is what I got so far...        

 

Current features:

• OTA update
• Multi-config support with quick-switch from tray icon
• Dark/light mode + colors
• Graph fan curves
• Linear fan curves
• Flat fan curves
• Mixed fan curves
• Sync fan curves
• Custom name for each fan / curve / control
• Material UI ( thanks to http://materialdesigninxaml.net/ )
• Smooth fan speed transitions
• Custom temperature source
• Automatic or manual matching between your controls and fan speeds
• Activation% (dead zone) for each fan
• Saves your current configuration and reload it on startup
• Board support is updated whenever the API gets an update!

 

Please note that this is a small personal project. It works great for my needs but I didn't test it on a hundred different motherboards. Take it as it is. If it works on your current setup, well you got your fan control situation sorted at least until you change your motherboard!

 

If you want to help me out a bit or give me feedback, I included some links/button in the left hamburger menu out of the way to send me an email

or to pay me a  ... or .

 

I will also keep an eye on this thread to see how it goes.

 

Confirmed compatibility list from members

  Reveal hidden contents

AsRock H97M Pro 4
ASRock Steel Legend B450M

Asrock Z390 Mini-ITX

Asus Strix Z270G

Asus maximus ranger VIII 

ASUS MAXIMUS IV GENE-Z 
 

Gigabyte X470 Aorus Gaming 7

Gigabyte Z370 AORUS Gaming 5 (rev. 1.0)

Gigabyte X570 Gaming X

MSI MPG X570 GAMING PLUS

MSI Z390 Edge AC

MSI B450 Gaming Pro Carbon AC
MSI B450 Tomahawk MAX

MSI X470 Gaming Plus Max 

 

Enjoy!

Hi, can you post some information about setup? Almost nothing happens when I open the application. I get a FanControl icon on the tool bar and 2 icons in the tray, but I cant bring up the UI.

[Ja50nK]

More information than the comprehensive setup videos contained in the massive first post you helpfully quoted?

[Adrenalina]

On 7/16/2020 at 2:24 PM, Rem0o said:

Create a new thread and link it in a single post, that's fine.

Okay.  Here's a link to a new topic related to FanControl:

 

[Adrenalina]

Using FanControl's new .sensor feature, I did some experiments to try to understand FanControl's hysteresis algorithm... exactly how it uses the "temperature change" and "seconds" values when deciding what to do.

 

To prepare for the experiments, I stopped the .bat script that writes my external drive's actual temperature to the .sensor file, and I opened the .sensor file with Notepad.  I set the fan curve as shown in the screencapture below, with hysteresis set to {10C, 20s}. The 20 seconds was long enough to allow me, after saving the .sensor file, to re-edit and re-save the file before 20 seconds elapsed. 

 

Experiment 1:  Initially, the .sensor file contained 33 (the actual temperature of the external drive).  I overwrote the 33 with 66 and saved the file.  FanControl waited 20 seconds before the fan speed began to increase (toward 100%).  This delay is presumably explained by the 20 seconds value in the hysteresis setting... it causes FanControl to ignore the temperature change for awhile, even though it was a large change. (This delay is not necessarily what users would want.  To me it makes more sense to delay responding to small temperature changes than to delay responding to large changes.)

 

Experiment 2:  I overwrote the 66 with 33 and saved the file.  Then I quickly overwrote the 33 with 60 and saved the file again, less than 20 seconds after the previous save.  FanControl ignored the two temperature changes -- the speed remained at 100% -- presumably because the net change within the 20 seconds period was only -6C, and 6C is less than the 10C hysteresis value. (This kind of behavior is presumably what users want hysteresis to do, although not necessarily for such large temperature changes.)

 

Experiment 3:  This was a series of observations.  First I overwrote the 60 with 52, saved the file, and observed for more than a minute.  The fan speed remained at 100%, as expected since the 8C change was less than the 10C hysteresis.  Then I overwrote the 52 with 44, saved the file, and observed for more than a minute.  The fan speed remained at 100%, even though the 16C net temperature decrease (from 60C to 44C) exceeded the 10C hysteresis. (This is understandable since the decrease was gradual -- taking more than 20 seconds -- but my hunch is that this is not what most users really want since 16C exceeds the 10C hysteresis setting.)  Then I overwrote the 44 with 36 and saved the file.  After 20 seconds, FanControl began reducing the fan speed toward 53% (which matches the fan curve).  This speed decrease was a surprise since the 8C decrease from 44C to 36C was less than the 10C hysteresis.  After another long wait, I overwrote the 36 with 44 and saved the file.  About 20 seconds later, the fan speed began climbing to 100%.  This was another surprise, for the same reason: 8C < 10C.

 

Experiment 4: (This was prompted by the surprises in experiment 3.)  I overwrote the 44 with 20, saved the file, waited until FanControl eventually reduced the fan speed to zero%, and waited some more.  Then I overwrote the 20 with 30, saved the file, and waited, and the speed remained zero% in accordance with the fan curve.  Then I overwrote the 30 with 38 and saved the file.  After 20 seconds the speed began to climb to 77%, even though the 8C increase was less than the 10C hysteresis.

 

I hope Rem0o will provide a clear explanation of FanControl's hysteresis algorithm, so we can know what to expect.

 

Here's the screencapture of the fan curve used during the experiments:

 

[Rem0o]

Update 38

 

 

• Updated LibreHardwareMonitorLibrary
• Fixed Graph fan curve bug"

[Adrenalina]

4 hours ago, Rem0o said:

• Fixed Graph fan curve bug

Which one?

[Rem0o]

3 hours ago, Adrenalina said:

Which one?

A UI one. The small dot indicating the current curve position would not update properly in some circumstances. 

[Adrenalina]

@Rem0o:  Do you have any plans to deal with the hysteresis issues?  I've written several messages about them, but there have been no replies.

 

Issue 1. See Experiment #3 in my July 18th message for details. To summarize: With hysteresis set to 10C, FanControl didn't reduce speed after two 8C decreases, then reduced speed after a third 8C decrease, then increased speed after an 8C increase.  The behavior appears inconsistent... sometimes FanControl responded to an 8C change, and sometimes it didn't.

Issue 2. Based on the terse & scattered documentation of FanControl's hysteresis, my understanding is that FanControl has been designed to ignore a gradual series of temperature changes that are each less than the hysteresis setting.  That seems unwise when the series of temperature changes sum to a net change greater than the hysteresis setting. (It's like the proverbial frog that doesn't jump out of a pot of water slowly brought to boil: https://en.wikipedia.org/wiki/Boiling_frog )  The proper goal of hysteresis is to ignore a series of changes that sum to a small value (a value less than the hysteresis setting).  When the sum is small, it's because some of the changes were in opposite directions.

 

Issue 3. The delay when responding to a large change of temperature.  Some users may want this delay no matter how large the change, because they're more disturbed by the brief increase of fan noise than by the effect of large temperature spikes on the cpu's lifespan.  It would be better to provide the users a choice, so that some users (like me) can have the hysteresis delay apply only to small changes of temperature, and have a quick response when there's a large change of temperature.

 

Issue 4. "Sliding friction" (a.k.a. "lack of slippery slope").  When the fan speed is already being stepped toward what the new target speed would be if there were no hysteresis, then the hysteresis shouldn't apply; the target speed should be updated. (Also, stepping should be stopped or reversed if the next step would take the fan speed further from what the new target would be if there were no hysteresis.  I haven't yet tested whether FanControl does this right and I don't recall discussing it previously.)

 

There may have been another hysteresis issue, but if so, at this moment I don't recall it.

 

An alternative scheme to consider is to base hysteresis on the difference between the fan speed and the fan curve speed, instead of on temperature changes.  The basic idea would be to ignore small differences between the two speeds, and start stepping the fan speed toward the fan curve speed when the difference becomes significant. (Once stepping has begun, continue stepping while the next step will reduce the difference, even when the difference is small... "no sliding friction.")  An advantage of basing hysteresis on speed difference instead of on temperature changes is that the user has more control over speed differences since the user defines the curve.

[Rem0o]

On 7/25/2020 at 9:44 AM, Adrenalina said:

@Rem0o:  Do you have any plans to deal with the hysteresis issues?  I've written several messages about them, but there have been no replies.

 

Issue 1. See Experiment #3 in my July 18th message for details. To summarize: With hysteresis set to 10C, FanControl didn't reduce speed after two 8C decreases, then reduced speed after a third 8C decrease, then increased speed after an 8C increase.  The behavior appears inconsistent... sometimes FanControl responded to an 8C change, and sometimes it didn't.

You were playing around the upper bound of your curve, which is 40 deg on your screenshot. The hysteresis will be ignored when you are out of bounds ( > your maximum point or < your minimum point ). Also, the temperature delta will be computed from the last temperature that triggered a change. If you go from let say 50 to 41 but the curve is still flat at that point, the last temperature that triggered a change will still be 50, not 41, so any temperature delta will be Absolute(T - 50), hence why it seemed like a 8 deg change triggered the curve, when in fact it is computed the delta from the prior temperature.

Quote

Issue 2. Based on the terse & scattered documentation of FanControl's hysteresis, my understanding is that FanControl has been designed to ignore a gradual series of temperature changes that are each less than the hysteresis setting.  That seems unwise when the series of temperature changes sum to a net change greater than the hysteresis setting. (It's like the proverbial frog that doesn't jump out of a pot of water slowly brought to boil: https://en.wikipedia.org/wiki/Boiling_frog )  The proper goal of hysteresis is to ignore a series of changes that sum to a small value (a value less than the hysteresis setting).  When the sum is small, it's because some of the changes were in opposite directions.

That's not right. See above. The delta is computed from the last temperature that triggered a change. So if the temperature increases by steps of 1, it will eventually trigger the curve once the delta from that last temperature is bigger than the hysteresis setting, for at least [Response time value] consecutive seconds.

Quote

 

Issue 3. The delay when responding to a large change of temperature.  Some users may want this delay no matter how large the change, because they're more disturbed by the brief increase of fan noise than by the effect of large temperature spikes on the cpu's lifespan.  It would be better to provide the users a choice, so that some users (like me) can have the hysteresis delay apply only to small changes of temperature, and have a quick response when there's a large change of temperature.

That's not a supported scenario for now. You can use a mix curve (MAX function) to mix different response time, like a 1 second curve that goes from 0 to 100% from 74 to 75 deg and another normal linear curve with a slow response. That mix would then quickly ramp up to 100 if the temp exceeds 75, and follow the slow curve otherwise.

 

Quote

Issue 4. "Sliding friction" (a.k.a. "lack of slippery slope").  When the fan speed is already being stepped toward what the new target speed would be if there were no hysteresis, then the hysteresis shouldn't apply; the target speed should be updated. (Also, stepping should be stopped or reversed if the next step would take the fan speed further from what the new target would be if there were no hysteresis.  I haven't yet tested whether FanControl does this right and I don't recall discussing it previously.)

That I think I already answered you, but in the actual design the step time is bound to the control itself while the hysteresis is bound to the curve, like the UI suggest. The curve is not aware of the control(s), so it can't take a decision based on a step parameter of a single control. For that, the step parameter would have to be moved into the curve, but that's a different approach at that point.

[Adrenalina]

@Rem0o:  Thanks for the additional info about how FanControl uses the hysteresis temperature and time settings, in particular that the temperature delta is relative to the temperature that triggered the most recent speed change, and the time setting is consecutive seconds that the temperature delta must exceed the temperature setting.

 

Regarding issue 1, I still don't understand why the 8C temperature increase from 36C to 44C at the end of experiment #3 caused the speed to increase.  Your explanation didn't mention that part of the experiment.

 

Regarding issue 2, I guess I misunderstood our earlier discussion about whether the fan speed can get stuck.  I'll need to think again about the issue in the light of the additional info you provided.

 

Regarding issue 4 (sliding friction), the stepsize isn't directly relevant to issue 4, so I don't think it matters that the curve doesn't know the stepsize.  However, the *direction* of the most recent step behavior -- up, down, or none -- is relevant to issue 4, and I take your point that the fan curve doesn't know the direction either. 

 

I'm wondering why hysteresis is part of the curve.  It could be part of the fan control or it could be a separate object.  Regardless of whether hysteresis is part of the curve, it could presumably be designed so it can get data from a variety of objects.  Similar to how a fan control gets curve speed from a curve, and a curve gets temperature from a sensor.  In addition to getting temperature from a curve or sensor, a hysteresis object could be designed to get speed% from a fan, a variety of data (including speed%) from a fan control, and curve speed from a curve.  Curves and fan controls could be designed to get data from a hysteresis object (perhaps a true/false value that indicates whether the hysteresis authorizes a change of speed).  Since objects can expose get() methods, I think access to other objects' data isn't a hard problem.  The more difficult & interesting problem would be to figure out how to take advantage of the wealth of available data: useful hysteresis algorithms.

[Rem0o]

16 hours ago, Adrenalina said:

Regarding issue 1, I still don't understand why the 8C temperature increase from 36C to 44C at the end of experiment #3 caused the speed to increase.  Your explanation didn't mention that part of the experiment.

44 is out of bound in your curve, that is, it is a larger value than your last point, which is 40. Hysteresis is then ignored.

[Fuzzyy]

Thank you for this! My evaluation period has expired on Argus monitor so I decided to give this a go. 100% Satisfied, great job!

EDIT: I use ASUS TUF B450 PLUS GAMING mobo, working fine

[AK33]

On 8/31/2019 at 3:01 PM, Rem0o said:

______________________________

Version updated date: 19/07/2020

 

New version include OTA update with versioning.
Make sure you have at least such version to get future updates!

 

Current update version: 38
 

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

Direct Download

______________________________

 

To run at startup: use the included cmd file

 

"Register_Startup_Task.cmd"

______________________________

 

Tutorials:

 

 

 

 

 

______________________________

       TLDR

______________________________

 

I built a new custom UI on top of OpenHardwareMonitor with additional features, mainly linear fan curves with custom temperature sources.

 

______________________________

     STORY

______________________________

 

As you guys may know, SpeedFan is sadly not updated anymore, so newer boards are not detected properly. 

 

The main feature I used was the custom fan curves with custom temperature sources. I used it to bind my case fans speed to the hottest component of my PC, my GPU. 

(My BIOS only supports CPU temperature as a temperature source for the PWM fans).

 

I searched around for an alternative software with this particular feature and only found a paid option (Angus Monitor).

 

However, I also came around this:

https://github.com/openhardwaremonitor/openhardwaremonitor

https://github.com/LibreHardwareMonitor/LibreHardwareMonitor

 

The first link is an original project which could be downloaded here https://openhardwaremonitor.org/, but just like SpeedFan, the project is not updated anymore.

However, thanks to the code base being open sourced, there are a couple of active branches, LibreHardwareMonitor being the best one I found, supporting my MSI Z390 Edge AC board and being updated regularly.

OpenHardwareMonitor is divided into two parts, an API to interact with your hardware ( CPU, RAM, Fans... ) and a UI. The existing UI is a HWMonitor clone that allows to set a manual fan speed to any fan, but no temperature/speed fan curve here.

( sigh )

 

So I decided to make my own lightweight application with the OpenHardwareMonitorLib API, and here is what I got so far...        

 

Current features:

• OTA update
• Multi-config support with quick-switch from tray icon
• Dark/light mode + colors
• Graph fan curves
• Linear fan curves
• Flat fan curves
• Mixed fan curves
• Sync fan curves
• Custom name for each fan / curve / control
• Material UI ( thanks to http://materialdesigninxaml.net/ )
• Smooth fan speed transitions
• Custom temperature source
• Automatic or manual matching between your controls and fan speeds
• Activation% (dead zone) for each fan
• Saves your current configuration and reload it on startup
• Board support is updated whenever the API gets an update!

 

Please note that this is a small personal project. It works great for my needs but I didn't test it on a hundred different motherboards. Take it as it is. If it works on your current setup, well you got your fan control situation sorted at least until you change your motherboard!

 

If you want to help me out a bit or give me feedback, I included some links/button in the left hamburger menu out of the way to send me an email

or to pay me a  ... or .

 

I will also keep an eye on this thread to see how it goes.

 

Confirmed compatibility list from members

  Reveal hidden contents

AsRock H97M Pro 4
ASRock Steel Legend B450M

Asrock Z390 Mini-ITX

Asus Strix Z270G

Asus maximus ranger VIII 

ASUS MAXIMUS IV GENE-Z 
 

Gigabyte X470 Aorus Gaming 7

Gigabyte Z370 AORUS Gaming 5 (rev. 1.0)

Gigabyte X570 Gaming X

MSI MPG X570 GAMING PLUS

MSI Z390 Edge AC

MSI B450 Gaming Pro Carbon AC
MSI B450 Tomahawk MAX

MSI X470 Gaming Plus Max 

 

Enjoy!

I'm haveing an issue where my frount fans won't turn off. 

 

I have a asus ROG b450-f gaming motherboard and a ryzen 3700x any help would be appreciated.

[Adrenalina]

8 hours ago, AK33 said:

I'm having an issue where my front fans won't turn off.

How about posting a FanControl window screencapture that shows the controls and curves associated with the front fans?

 

Are the motherboard's BIOS settings for the front fans set to "DC" mode or "PWM" mode?  How many wires do the front fans' cables have?

 

In general, people seeking help should say not only what isn't happening, they should also describe what IS happening, since that information provides clues that narrow the possibilities.

[WoodDK]

Just found your software and LOVING IT!!!

I am on a asrock Fatal1ty B450 Gaming K4 MB (with a ryzen 3600) - and for some reason in the bios and in the asrock fan software the CPU TCTL = 0 (N/A in bios)

all other software sees the Tctl just fine...

so found your software and its working like a charm (took my 20 minutes including watching your youtube videos to set it up as I want it

 

One question - My GPU is a asus ROG-STRIX-RTX2070S-A8G-GAMING with 3 fans - groupped in 2 fans controls (one with 1 fan and the other with 2 fans).

 

These fans are not shown / found in your software - is this just how it is (read something some where to the extent that those cards has new api for fans)  - or am I (as a noob regarding your software) missing something ?

 

included logfile from fancontrol

 

PS hardware info kan see/monitor the fans

 

Just found the issue in github  so ignore my post  

 

If libre ever get around to looking at it ping me for test if needed  

fancontrol log file.txt

[Adrenalina]

Because the source in "sync" curves is a fan control, FanControl allows the user to construct circular definitions.  For example, a user can set curve Sync1 as the source curve in fan control Fan1, and can set Fan1 as the source control in Sync1.

 

When definitions are circular, which is updated first: the sync curve or the fan control?  My hunch is that, each second, FanControl updates all curves (sync and non-sync) before updating any fan controls.  If this is correct, to avoid an infinite recursion bug each sync curve update would use the speed of the sync curve's source control as it was a second ago.  That would imply there's a one second delay in sync behavior.

 

When designing the sync curve object, why was the choice made that the source speed for each sync curve shall be a fan control instead of a curve?  Did that choice unnecessarily introduce a one second sync delay, as well as unnecessarily allowing circular definitions?

 

FanControl appears to detect when the user attempts to construct circular "mix" curves (unless a sync curve is part of the circle).  In the simplest case -- Mix2 is curve A in Mix1 and Mix1 is curve A in Mix2 -- FanControl pops up a "loop detected" message, but then after the user clicks the Ok button the two curves display the circular definition and the mix appears not to fully operate according to the circular definition.  For a more complicated case -- Mix2 is curve A in Mix1, Mix3 is curve A in Mix2, and Mix1 is curve A in Mix3 -- FanControl detects the loop and the mixes appear to operate to some extent, but not always predictably.  I assume the order of construction determines which subset of the circular links are functional.

 

FanControl didn't detect a more complicated loop: Mix2 is curve A in Mix1, Mix3 is curve A in Mix2, Sync1 is curve A in Mix3, Fan1 is the source control in Sync1, and Mix1 is the source curve in Fan1.  Also, this loop sometimes behaved quite unexpectedly: There was a period of time when all three mixes and the fan showed 91% even though all of the B curves were less than 91%. (All B curves have zero hysteresis, all three mixes' functions were set to MAX, and the offsets in Fan1 and Sync1 were set to 0.)  I didn't test a simpler loop: Fan1 is the source control in Sync1, Mix1 is the source curve in Fan1, and Sync1 is curve A in Mix1 (and some ordinary curve is curve B in Mix1), but my guess is that FanControl won't detect this loop.

 

Would any useful functionality be sacrificed if the user is not allowed to choose sync curves as A or B sources in mix curves, and the source in sync curves is a curve instead of a fan control?

[Adrenalina]

This is a question about the order in which FanControl evaluates curves each iteration (in other words, each second):  Does FanControl take care to evaluate the A & B curves of a mix before evaluating the mix?

 

I think the answer is No.  When I performed tests of circular definitions (which I wrote about two days ago) I noticed the speeds of mix curves could lag a second behind the speeds of their A or B curves.  The lag accumulated to two seconds when a mix curve had another mix curve as its A or B curve.  In the experiment that had Mix1, Mix2, Mix3, Sync1 and Fan1, the lag was three seconds in one of the mix curves, two seconds in another of the mix curves, etc.

 

Here's a simple example to illustrate the lag caused by incorrect order of evaluation.  Suppose Mix2 has Graph1 & Graph2 as A & B curves, and Mix1 has Mix2 & Graph3 as A & B curves.  If FanControl evaluates Mix2 before Graph1 and/or Graph2, Mix2 will lag a second behind Graph1 and/or Graph2 because the evaluation of Mix2 will use data from Graph1 and/or Graph2 that's a second old.  Similarly, if FanControl evaluates Mix1 before Mix2, Mix1 will lag a second behind Mix2.  Combining these two results, Mix1 will lag two seconds behind Graph1 and/or Graph2.

 

To avoid unnecessary lags, FanControl should evaluate A & B curves before the mix curve they're in.  Part of this prescription is simple: FanControl could evaluate all graph (and linear) curves before mix curves.  The other part -- evalating Mix2 before Mix1 when Mix2 is an A or B curve in Mix1 -- is less straightforward but shouldn't be hard to do.

 

Another way to accomplish the correct evaluation order would be recursive evaluation, in which a curve or control calls upon each of its sources to evaluate themselves:

Quote

method obj.eval() {

    //  Note: To facilitate the following 'if' condition, at the start of

    //            each iteration every obj's NotYetEvaluated property

    //            must be set to TRUE.

    if self.NotYetEvaluated {

        self.NotYetEvaluated = FALSE

        for each source in self.Sources {

            source.eval()

        }

        //  Now that all of the obj's sources have been evaluated,

        //      it's time to evaluate the obj:

        self.evaluate()

}   }

 

If there are no circular definitions, I think this recursion would ensure no lags.  If a circle exists, I think lag can't be avoided. (I recommend FanControl someday be enhanced to prevent any circular definitions, not just warn about mix loops.)

[Adrenalina]

Is there a reason why a fan control speed would stay 1% less than its source curve speed?  The fan control offset is 0%, so the offset doesn't explain it.  Hysteresis couldn't explain it, if my understanding of hysteresis is correct, because hysteresis is an internal property of the curve and the fan control sees only the source curve speed. (Also, the curve's hysteresis is set to 0%.)

 

The behavior is shown in the attached screen recording, which is about 30 seconds long.  The curve speed is steady at 28% and the fan speed is 27%.  About halfway through, I manually raise the fan control's activation speed temporarily to force the fan speed to 0%, and after restoring the activation speed the fan speed returns to 27%.

FanControl bug - fan speed 1% less than curve speed (2020-08-02 05-32-02).mkv

[pinx]

Great work ...

 

AMD Ryzen 5 3600, all core 4200 MHz @ 1.2V
MSI X470 Gaming Plus Max

XFX Radeon RX 5700 XT THICC II Ultra @ 2160MHz 1.2V

 

[Rem0o]

5 hours ago, Adrenalina said:

Is there a reason why a fan control speed would stay 1% less than its source curve speed?  The fan control offset is 0%, so the offset doesn't explain it.  Hysteresis couldn't explain it, if my understanding of hysteresis is correct, because hysteresis is an internal property of the curve and the fan control sees only the source curve speed. (Also, the curve's hysteresis is set to 0%.)

 

The behavior is shown in the attached screen recording, which is about 30 seconds long.  The curve speed is steady at 28% and the fan speed is 27%.  About halfway through, I manually raise the fan control's activation speed temporarily to force the fan speed to 0%, and after restoring the activation speed the fan speed returns to 27%.

FanControl bug - fan speed 1% less than curve speed (2020-08-02 05-32-02).mkv 213.44 kB · 1 download

Looks like a rounding disparity. The actual number underneath is a floating point. Also, the number on the control card is the readout from the control sensor, whereas the curve is the "instruction". A small disparity which rounds to 1% on the display is nothing to worry about.

[Adrenalina]

8 minutes ago, Rem0o said:

the number on the control card is the readout from the control sensor

Thanks.  I assumed the displayed number is the "output" of the control card -- in other words, the speed that the control card (tried to) set -- and thus should equal the output of the source curve.  Displaying the value of the sensor is probably the better choice, if only one of the two values may be displayed.  One more item to include in a FAQ someday?