FanControl, my take on a SpeedFan replacement

[wurmr]

20 hours ago, Rem0o said:

Update 31

 

• Changed host to Github for download, version check, updater and so on : https://github.com/Rem0o/FanControl.Releases
• Minor bug fixes
• Updated LibreHardwareMonitor

With Github, commit history will mean you will be able to browse any version you want in time.

Enjoy!

Nice, please tag github releases to make it very easy to browse and download.

[Rem0o]

25 minutes ago, wurmr said:

Nice, please tag github releases to make it very easy to browse and download.

That is the plan, give me some days to get it right, still trying to make the readme.md pretty 

[Adrenalina]

Hi again Rem0o,

 

I'm unsure whether you saw my edit of my most recent comment, in which I suggested an alternative to a command-line parameter (a new feature that would allow another app to control a fan's speed).  The following alternative should be much quicker to implement than a command-line parameter because it wouldn't require parsing the command line nor adding new structures to FanControl's user interface: Treat a text file like a temperature sensor.  Instead of using a command-line to set the fan speed, an app would overwrite the text file, and FanControl would periodically read the file if the file exists. (The user would set FanControl using its gui to link the text file "sensor" to the corresponding fan header, and to construct a control curve to map the text file's "temperature" content to the desired fan speed percentage.)

 

To minimize the implementation labor, you could require the text file to be located in the same folder as fancontrol.exe and have a specific filename of your choosing (something like "ExtTemperature.txt" where Ext means either external or extra).  The only change to the user interface would be the addition of a name representing the text file to the list of detected temperature sensors... a very minor change.

 

When you replied earlier, you didn't explicitly say you have no intention of implementing such a feature to allow another app to use FanControl to control a fan speed.  Could you let me (us) know whether you will consider it, or you considered it and rejected it, or it sounds like a good idea but other things are higher on your agenda, or it sounds quick enough to implement that you plan to do it in the near future?  Thanks.

 

[Rem0o]

6 hours ago, Adrenalina said:

Hi again Rem0o,

 

I'm unsure whether you saw my edit of my most recent comment, in which I suggested an alternative to a command-line parameter (a new feature that would allow another app to control a fan's speed).  The following alternative should be much quicker to implement than a command-line parameter because it wouldn't require parsing the command line nor adding new structures to FanControl's user interface: Treat a text file like a temperature sensor.  Instead of using a command-line to set the fan speed, an app would overwrite the text file, and FanControl would periodically read the file if the file exists. (The user would set FanControl using its gui to link the text file "sensor" to the corresponding fan header, and to construct a control curve to map the text file's "temperature" content to the desired fan speed percentage.)

 

To minimize the implementation labor, you could require the text file to be located in the same folder as fancontrol.exe and have a specific filename of your choosing (something like "ExtTemperature.txt" where Ext means either external or extra).  The only change to the user interface would be the addition of a name representing the text file to the list of detected temperature sensors... a very minor change.

 

When you replied earlier, you didn't explicitly say you have no intention of implementing such a feature to allow another app to use FanControl to control a fan speed.  Could you let me (us) know whether you will consider it, or you considered it and rejected it, or it sounds like a good idea but other things are higher on your agenda, or it sounds quick enough to implement that you plan to do it in the near future?  Thanks.

 

Well your whole idea would be kind of a hack and would break the current architecture. So to answer your question, I considered it, but rejected it.
The better idea would be to contribute to the HW library to support your external hard drive directly, which would then integrate like every other sensor. There is already a S.M.A.R.T reading for hard drives AFAIK, which is how other hard drive temps are read in the library.  However, without the hardware in hand, I won't be the one developing it, on top of the fact that I do indeed have way to many stuff to do.

[Adrenalina]

@Rem0o,

 

I don't understand how it would break the current FanControl architecture to treat a text file as another temperature sensor, since reading the content of a file doesn't seem significantly different from reading the content of a chipset, and reading files is ubiquitous in all programming languages.  Wouldn't it just mean adding a small amount of code to your sensors detection routine and your sensors polling routine?  The whole point of reading a temperature from a file instead of parsing command-line parameters was to blend more easily within your existing architecture.

 

I think what's lacking from the LibreHardwareMonitor library isn't support for my drive, but rather support for S.M.A.R.T. pass-through via SATA-to-USB bridges.  Some information about how to support it is at:
https://www.smartmontools.org/wiki/USB
and:
https://www.smartmontools.org/wiki/Supported_USB-Devices
(Note: Smartmontools is open source.  CrystalDiskInfo is also open source, and it too supports USB pass-through.)

 

In the Unix/Linux philosophy, it's not considered a "bad" hack to design apps that work with other apps (often using stdin & stdout pipes and/or command-line parameters) to accomplish user goals.  Building isolated apps is eschewed; it leads to a duplication of labor and discourages innovation.  An example of duplication of labor is adding support for chips to both LibreHardwareMonitor library and Smartmontools instead of just to Smartmontools.

[Rem0o]

On 6/4/2020 at 10:53 AM, Adrenalina said:

@Rem0o,

 

I don't understand how it would break the current FanControl architecture to treat a text file as another temperature sensor, since reading the content of a file doesn't seem significantly different from reading the content of a chipset, and reading files is ubiquitous in all programming languages.  Wouldn't it just mean adding a small amount of code to your sensors detection routine and your sensors polling routine?  The whole point of reading a temperature from a file instead of parsing command-line parameters was to blend more easily within your existing architecture.

 

I think what's lacking from the LibreHardwareMonitor library isn't support for my drive, but rather support for S.M.A.R.T. pass-through via SATA-to-USB bridges.  Some information about how to support it is at:
https://www.smartmontools.org/wiki/USB
and:
https://www.smartmontools.org/wiki/Supported_USB-Devices
(Note: Smartmontools is open source.  CrystalDiskInfo is also open source, and it too supports USB pass-through.)

 

In the Unix/Linux philosophy, it's not considered a "bad" hack to design apps that work with other apps (often using stdin & stdout pipes and/or command-line parameters) to accomplish user goals.  Building isolated apps is eschewed; it leads to a duplication of labor and discourages innovation.  An example of duplication of labor is adding support for chips to both LibreHardwareMonitor library and Smartmontools instead of just to Smartmontools.

I get your point, allowing external inputs opens up tons of possibilities for all kind of integrations, which can be really cool. However, I didn't designed Fan Control to go into that direction in the first place, not that I can't do it. Fan Control is just a fancy suit on top of OpenHardwareMonitor, it's only a front-end with some logic built-in. I want it to stay as simple and dumb as possible. Your suggestion would require some backend work on the side of OHM, which would be a new component to integrate. External I/O opens up so much more cases to support, answer email to and so on, which I don't want to get into right now. I think that I can be the judge of how hard/complicated a feature is to develop and maintain, since you know, I'm the developer of this software.

I am quite happy with the state of the software as of now, and I want to sit on it for a while, fix bugs and minor annoyances, before doing any further big changes.

 

I get quite a few requests, and I'm keeping track of them, yours included. If out of theses requests a pattern emerge and it makes sense for the software, I will look into it.

Frankly, you are the first to request external I/O, so you shouldn't expect me to dive straight into development. Consider your request in the backlog, but no more than that for now. I like your enthusiasm, but please give me time.

[Kaktuch]

Just telling, I was talking about external I/O for arduinto temperature sensors  So there is 2 of us. But I understand your point of view, in the future i will contact developer of OHM and ask him to integrate some kind of stupid I/O interface.

[Rem0o]

Update 32

 

• Cache system rework (default config will be loaded once after update)
  • Migrated some settings from the configs to the cache ( window position / size )
• Link button to release repo in left hamburger menu
• LibreHardwareMonitor update (Kraken X3 support)
• Minor bug fixes related to the dialogs

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

 

*Previous version still available in "release" section on Github

 

Enjoy!

[Mamonos]

Hello Sir,

 

thanks for the outstanding work.

 

I was wondering if you could add options to:

-Re-order fan control card (like drag and drop)

-Hide single fan cards for unused fan (I attached a picture as example; the second fan from the left is the GPU fan and since I am on liquid cooling I don't need to have it displayed).

 

Cheers

 

[Rem0o]

2 hours ago, Mamonos said:

-Re-order fan control card (like drag and drop)

You can do just that, simply click an empty portion of a card and drag it around.

2 hours ago, Mamonos said:

-Hide single fan cards for unused fan (I attached a picture as example; the second fan from the left is the GPU fan and since I am on liquid cooling I don't need to have it displayed).

In the left hamburger menu, hide disabled fan control cards. Enable the ones you want to control before.

[Mamonos]

20 hours ago, Rem0o said:

You can do just that, simply click an empty portion of a card and drag it around.

Thanks, I never realized that.

 

20 hours ago, Rem0o said:

In the left hamburger menu, hide disabled fan control cards. Enable the ones you want to control before.

I only control the fan sometimes so I would like to hide a card even if the other cards are not enabled, but it's not big deal now I just moved the unused one to the far right.

 

:)

 

[thomasck]

@Rem0o such a great improvement since 1st release! Congrats! I still using your software since then and it's going strong! Gonna donate some more as soon as I get back to work

 

I've got couple of questions, if you don't mind.

In the image bellow, in the 1st line, Top Fan Control is not showing any RPM, any workaround? And Second line there's the 1st speed indicator, which is from the GPU which does not have fans. Is there any way to remove only the Gpu RPM one?

 

 

Is there any way to make your software work with dell laptops?

[Rem0o]

5 hours ago, thomasck said:

In the image bellow, in the 1st line, Top Fan Control is not showing any RPM, any workaround?

You need to match it. Simply click the three dot menu of that control card, match fan, and click on the corresponding speed card.

Quote

GPU which does not have fans. Is there any way to remove only the Gpu RPM one?

As of now, you can't. However, you can click and drag it around to the end of the card stack.

Quote

Is there any way to make your software work with dell laptops?

The driver library I'm using only support a limited quantity of chips which common desktop motherboard manufacturer use. I guess laptop support could be added, but It doesn't seem like it's going this way anytime soon, see https://github.com/LibreHardwareMonitor/LibreHardwareMonitor.

[Adrenalina]

@Rem0o and cc: @Kaktuch: Would it cause a conflict to simultaneously run two instances of FanControl, each in a separate folder, each instance configured to control a different subset of the fans? 

 

Below I explain why I'm asking.  But first, some background information:

 

Since OpenHardwareMonitor/LibreHardwareMonitor doesn't yet understand USB pass-through of S.M.A.R.T. data and thus FanControl can't read the temperature of an external drive that's connected via a USB port, and since FanControl isn't yet designed to be manipulated by command-line parameters (or other kludges), I thought outside the box and came up with another kludge: A user could write an app that controls FanControl indirectly by manipulating Windows Task Scheduler:

1. Install several copies of FanControl, each copy in a different folder.  Give each copy of FanControl a different user configuration: set each configuration to run the internal fan header of the external fan at a different speed.
2. For each copy of FanControl, create a Windows Task Scheduler task that launches it.
3. To change the fan speed, an app would end the currently running FanControl task and start the FanControl task that corresponds to the desired speed. (In particular, I would write a custom .bat file that periodically runs Smartmontools' smartctl.exe utility to read the external drive's temperature, and runs the temperature-appropriate FanControl task.)

I don't know FanControl's starting and stopping behavior, in particular the transient effects and delays (if any) when a FanControl task is ended and a different FanControl task is started.  Assuming the worst, it makes sense to try to confine the transient behaviors to the external fan.  In other words, it makes sense to control all the internal fans using a continually running separate instance of FanControl, assuming two instances of FanControl can safely run simultaneously if the instances are configured to control different fans. Hence the question at the beginning of this comment. 

 

A related question is: What are the advantages and disadvantages of running two instances of FanControl simultaneously, each configured to control different fans?

[Adrenalina]

@Rem0o: The files in my FanControl folder add up to less than 10 MB of disk space, but FanControl occupies over 100 MB of ram while running.  Could it be made more efficient?  Perhaps some code and/or data isn't needed after initialization.

 

[Rem0o]

@Adrenalina

You can do whatever you want, but it was not made to be running running multiple instances, or being started / stopped like that. You are way out of scope and it's unexpected behavior. At that point, I don't really understand why you keep insisting on making this software something it isn't, but whatever.

 

As far as RAM and size, well, it's a .NET WPF app, so it loads a ton of framework dlls in memory. It's just not the most efficient framework, but that's what the backend library is based on and what I'm comfortable developing with. At startup, if you don't open the UI, it is way, way lighter. The UI library is really RAM hungry.

[Adrenalina]

@Rem0o: Thanks for the tip about reducing ram by not opening the UI. 

 

As for "making this software something it isn't," I'm trying to understand what it is and what it isn't by asking questions.  Is that bothering you?  It sounds like you're unsure what will happen if the FanControl task gets ended by Windows Task Scheduler, and it sounds like you're unsure what will happen if multiple instances are run (from separate folders, controlling different fans).  I guess that leaves it to me to find out by experimenting.

 

Another change from your "stock" configuration that I plan to try is to set the FanControl task to trigger at Windows startup rather than user login.  The purpose would be to control the fans even if a user doesn't login right away.  I expect it would run "hidden" -- no tray icon and UI unavailable -- if FanControl gets triggered at Windows startup, but if/when I need to see the UI, I could end the hidden task and manually launch it unhidden.  Alternatively, I could have a simple .bat task that triggers at user login, which ends the hidden FanControl task that triggered at startup, and starts a new unhidden FanControl task.

[Yrmio]

I just wanted to say thanks! This is a great piece of software and just what i needed. I've been using Argus for some time, but this looks and feels better for me + it is free. I am gonna make small donation tomorrow 

[Rem0o]

On 6/14/2020 at 6:13 AM, Yrmio said:

I just wanted to say thanks! This is a great piece of software and just what i needed. I've been using Argus for some time, but this looks and feels better for me + it is free. I am gonna make small donation tomorrow 

Thansk!

[Rem0o]

Update Version 33

 

• Updated LibreHardwareMonitorLib @https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/commit/988dcd58b3485412b6ce17bf03ac8e9757b54726
• Fixed memory leak

[secu9k]

Thank you very much for this flexible software. Sync curve works great, I use it to control case fans with stock GPU PWM. There was a time when people made custom cables to use only PWM signal from GPU fan to control other fans: https://forums.overclockers.co.uk/threads/pwm-controlled-case-fans-from-gpu-signal.18449722/#post-22938132

 

As an idea, maybe to add "Target" fan curve, when FanControl will auto adjust fan speed with lowest RPM (noise) to hold target temperature of control.

[Rem0o]

1 hour ago, secu9k said:

Thank you very much for this flexible software. Sync curve works great, I use it to control case fans with stock GPU PWM. There was a time when people made custom cables to use only PWM signal from GPU fan to control other fans: https://forums.overclockers.co.uk/threads/pwm-controlled-case-fans-from-gpu-signal.18449722/#post-22938132

 

As an idea, maybe to add "Target" fan curve, when FanControl will auto adjust fan speed with lowest RPM (noise) to hold target temperature of control.

Already experimented with a very slow and smooth PID control, but even then the response is so slow and indirect that it didn't make much sense. If you don't set a target temp "just right" for your system/cooling, it would simply hit the extremes ( min or max ). The code is still in there, but I disabled it since it is basically unusable. 

[WrenchViking]

I just wanted to say thank you for this software, as it does almost exactly what I've been looking for. The only issue I've run into is that it doesn't recognize the 5th PWM fan port on my system. It just doesn't show up and I'm not sure why. Other softwares, as well as the BIOS, recognize the fan port as being populated and read the RPM's without issue, but that fan doesn't show up anywhere in your software. My motherboard is an Asrock X570 Steel Legend Wi-Fi. It has a total of 6 pwm headers onboard. Only 5 are detected by your software.

My fan setup is this: 1 rear exhaust fan on a chassis fan header, 2 top fans set to exhaust through my radiator, connected to a CPU fan header via a y-splitter, 3 front intake fans, each with their own chassis headers. The bottom two read just fine and are linked to GPU temp, but the third one doesn't show up in your software at all.

 

I've also had an issue with the pump for my AIO not responding to your software. It's detected and the RPM's read just fine, but adjusting it in the software elicits no change anymore. When I first installed the software a while back, the pump would respond to the software, but now it no longer does. All headers are set to PWM control in the BIOS.

Any ideas?

[Rem0o]

8 minutes ago, WrenchViking said:

I just wanted to say thank you for this software, as it does almost exactly what I've been looking for. The only issue I've run into is that it doesn't recognize the 5th PWM fan port on my system. It just doesn't show up and I'm not sure why. Other softwares, as well as the BIOS, recognize the fan port as being populated and read the RPM's without issue, but that fan doesn't show up anywhere in your software. My motherboard is an Asrock X570 Steel Legend Wi-Fi. It has a total of 6 pwm headers onboard. Only 5 are detected by your software.

My fan setup is this: 1 rear exhaust fan on a chassis fan header, 2 top fans set to exhaust through my radiator, connected to a CPU fan header via a y-splitter, 3 front intake fans, each with their own chassis headers. The bottom two read just fine and are linked to GPU temp, but the third one doesn't show up in your software at all.

 

I've also had an issue with the pump for my AIO not responding to your software. It's detected and the RPM's read just fine, but adjusting it in the software elicits no change anymore. When I first installed the software a while back, the pump would respond to the software, but now it no longer does. All headers are set to PWM control in the BIOS.

Any ideas?

Each motherboard is kind of a different story, so I would try the different control mode for your fans in your BIOS and see if that makes a difference. As for your fan that doesn't show up, it's most likely a driver mapping issue. There are a ton of variety of a same chip, and in the driver library, they are all grouped together under a same file. Some chips have extra channels for fans compared to the other ones in the same chip family, and not all individual chips SKU have their very specific spec implemented, if that makes sense.  Send me the log ( three dot menu, copy log ) in DM, I will take a look.

[McsGone]

Hi, first of all I wanted to thank you for the time spent creating this app (or at least making it available to all of us).

I had been using Argus Monitor previously but it just had too many settings and configurations that I didn't even need in the first place, besides also behaving strangely with my Navi GPU fan curve.

Whereas your program is simple and intuitive.

I just wanted to ask you whether it'd be possible to implement a longer activation time for the fan curves, since right now the maximum is 15s which makes my CPU cooler rev each time I open up a program (temp spikes of 10C are a regular thing on Ryzen I guess).

With Argus the maximum activation time was 60s, which was perfect in order to not have the continuous revving whenever the CPU temp spiked for only half a minute or so.

Thank you!