Argus Monitor plugin 1.1.0.1

[Ahnìon]

All right, so I got a reply from Udo at Argotronic. I'm afraid it's bad news, at least in the short term. Once the new API gets released though, if LeoDavidson or someone else makes a new plugin for it, it should be a lot more stable and I'm guessing potentially more extensive.

TLDR: No fix forthcoming, at least for now.

Here's the reply I got:

Hi,

I guess you are referring to the plugin I have created based on the sources by LeoDavidson and uploaded in this thread?

To be honest, there are 179 Downloads of this in well over one year and maintaining this plugin that was relying on our internal data structure is not very high on our priority list.

As you most likely know: making Argus Monitor is something we (2 HW/SW engineers) do in our spare time, as a hobby, next to full time jobs and families. So the time for it is very limited (I am writing this after having picked up my 2 kids from Kindergarden and before I have to prepare dinner for us ) and we have to focus on what most users benefit from. So, I personally can't keeping this up to date myself (if Leo wants he can contact us and I will give him the modified sources back, together with the information required to make it work for the current release).

There is a silver lining for those of you that were relying on this plugin though (which should basically still work, maybe with the exception of some values like GPU load). I am currently working on a new API that should be able to provide a stable interface to our data and that will be:

a) based on shared memory,

b) documented, so anyone with some knowledge of programming can access the information and

c) should be stable and not change frequently, even if the internal data structures inside Argus might required changing

Right now, the PlugIn you use is relying on the data we exchange with the sidebar gadget and as users request changes to this part of Argus, we might have to update this which in turn requires updates to the Rainmeter plugin. Not good, but currently the only way to go.

I can't tell when the new 'official' API is ready and we are working on some other major refactoring for 5.3 that will keep us busy, so it will not be in 5.3.01, but maybe in 5.3.02 (we are two guys working on this project, so we have to discuss and align when we can bring this and what the priorities of other tasks are).

Sorry for not being able to be of more direct help here, but this is as good as it gets for now.

Best regards
Udo

I wrote back and asked if I could post this e-mail to the forum, and got this reply.

sure, please quote/post my response. Also, if Leo (the OP of the thread) wants to, he can contact us again and I will provide the information he needs to adapt the current plugin to the new data structure.

In theory, it would have been possible to make this structure publicly available, but what prevented us from doing so was that this would have tie us to external dependencies as soon as someone would rely on this and we could not freely change it as soon as this would be required.

The release of an 'official' API will free us from that and would also help other use cases if someone wants to get to the data for any means she can think of.

Best regards
Udo

[AcidWeb]

Eh. No Argus Monitor updates for me then.

[argusmonitor]

Hi,

don't get me wrong. I like the Rainmeter plugin and I will do what I can to support it. Maybe Leo (OP of this thread) is still around and can pick this up again (it is his source I was using for the update after all).

I can also see how much effort it is and drop the DLL for you here (no promises though).

But right now my time for Argus Monitor is completely booked by other tasks (mostly making the synthetic temperature sources a lot of people were asking for). And adding support for new hardware.

And after all -- once there is an more or less official (and stable) way to access the data we collect, then it would be much easier to also get the Rainmeter plugin to work again. It would have access to more data and would not need updates once we change the communication with the Gadget.

Best regards
Udo

[Ahnìon]

Hi,

don't get me wrong. I like the Rainmeter plugin and I will do what I can to support it. Maybe Leo (OP of this thread) is still around and can pick this up again (it is his source I was using for the update after all).

I can also see how much effort it is and drop the DLL for you here (no promises though).

But right now my time for Argus Monitor is completely booked by other tasks (mostly making the synthetic temperature sources a lot of people were asking for). And adding support for new hardware.

And after all -- once there is an more or less official (and stable) way to access the data we collect, then it would be much easier to also get the Rainmeter plugin to work again. It would have access to more data and would not need updates once we change the communication with the Gadget.

Best regards
Udo

Here's hoping! I can always go back to running HWiNFO, but it feels kind of stupid to run two different hardware monitoring applications at the same time.

The generalised API really does sound like a great idea. Would that be accessible via WindowMessage or would it require hooking into the API by more direct coding?

[Ganthor]

Hi,

don't get me wrong. I like the Rainmeter plugin and I will do what I can to support it. Maybe Leo (OP of this thread) is still around and can pick this up again (it is his source I was using for the update after all).

I can also see how much effort it is and drop the DLL for you here (no promises though).

But right now my time for Argus Monitor is completely booked by other tasks (mostly making the synthetic temperature sources a lot of people were asking for). And adding support for new hardware.

And after all -- once there is an more or less official (and stable) way to access the data we collect, then it would be much easier to also get the Rainmeter plugin to work again. It would have access to more data and would not need updates once we change the communication with the Gadget.

Best regards
Udo

Thanks for the updates! I love how involved you guys are, especially if this is just a side project. I'll just run with 5.2.07 until the API is working or someone updates the plugin. As long as it all works (and it does) I'm happy

[argusmonitor]

The generalised API really does sound like a great idea. Would that be accessible via WindowMessage or would it require hooking into the API by more direct coding?

I am looking into something like shared memory. Up until now we wanted to make sure that Argus itself can be run without administrator privileges. This worked and everything closely tied to direct hardware access we did in our kernel mode driver. This changed when Nvidia introduced (more or less enforced) the need to run with admin privileges if you want to call into their fan control functionality. And this cannot be done from the driver (at least it should not), so we needed some workaround that parts of Argus run as admin. We implemented this and this will be in Argus starting with 5.3, bringing back fan control for Nvidia GPUs without the need to start Argus itself as admin.

To share data between processes, there is shared memory. This can be used by user mode processes without highest privileges, but to CREATE such a mapping, you need admin permissions. Now that we need this now anyway for the Nvidia GPU case, so we can also reuse it to create the shared memory mapping. So, I think of doing just that. Providing a shared memory region that any process can open and then also providing some means of synchronization (most likely a mutex in the Global\\* namespace) and we are good to go.
I could then define a structure to abstract all sensors (fan speeds/temps/load/synthetic temperatures/...) and provide arrays of those 'sensors' along with a cycle counter to make sure users can tell if the data is new. There will be no callback for the users to know when there is new data, but they could all lock the mutex, check if the cycle counter changed, extract the data and release the mutex (strictly speaking, checking the cycle counter can be done without the mutex as clients are only reading the data anyway).

I am currently in the process of defining the structure itself and writing the first tests.

In any case, I think I will be able to provide some sample code for users to just copy/paste in their project to be able to open the memory mapping and read the data. The rest is up to the author of the plugin, but it should then be fairly straight forward for anyone with basic to intermediate programming skills.

Just my mental draft at the moment, so things might change. But I think this will be easy and I hope someone will use it then to do something worthwile with the data -- like writing and maintaining the Rainmeter plugin.

[Ahnìon]

I am looking into something like shared memory. Up until now we wanted to make sure that Argus itself can be run without administrator privileges. This worked and everything closely tied to direct hardware access we did in our kernel mode driver. This changed when Nvidia introduced (more or less enforced) the need to run with admin privileges if you want to call into their fan control functionality. And this cannot be done from the driver (at least it should not), so we needed some workaround that parts of Argus run as admin. We implemented this and this will be in Argus starting with 5.3, bringing back fan control for Nvidia GPUs without the need to start Argus itself as admin.

This is good to hear. "Just run it as admin" isn't great practice, even though I can understand how developers get frustrated when stuck between Windows and third-party stuff (and then potentially legacy on top of that.)

Also great to hear that you guys are working to stay on top of the fan control bit. With SpeedFan essentially dead, Argus Monitor is the only sane option I've found for custom fan control, so it's heartening to see that it's being maintained.

To share data between processes, there is shared memory. This can be used by user mode processes without highest privileges, but to CREATE such a mapping, you need admin permissions. Now that we need this now anyway for the Nvidia GPU case, so we can also reuse it to create the shared memory mapping. So, I think of doing just that. Providing a shared memory region that any process can open and then also providing some means of synchronization (most likely a mutex in the Global\\* namespace) and we are good to go.
I could then define a structure to abstract all sensors (fan speeds/temps/load/synthetic temperatures/...) and provide arrays of those 'sensors' along with a cycle counter to make sure users can tell if the data is new. There will be no callback for the users to know when there is new data, but they could all lock the mutex, check if the cycle counter changed, extract the data and release the mutex (strictly speaking, checking the cycle counter can be done without the mutex as clients are only reading the data anyway).

I am currently in the process of defining the structure itself and writing the first tests.

In any case, I think I will be able to provide some sample code for users to just copy/paste in their project to be able to open the memory mapping and read the data. The rest is up to the author of the plugin, but it should then be fairly straight forward for anyone with basic to intermediate programming skills.

Just my mental draft at the moment, so things might change. But I think this will be easy and I hope someone will use it then to do something worthwile with the data -- like writing and maintaining the Rainmeter plugin.

Sounds practicable. I'm not much of a coder (I very barely understand what a mutex is) but if push comes to shove, I can see it being possible even for me to piece together a plugin that cyclically checks the data in the shared memory structure and makes it available to Rainmeter.

Thanks for clarifying!

[argusmonitor]

Hi,

I have checked the changes we made and this was mostly a shift in some IDs -- so I just adapted Leo's plugin to the new values and recompiled both DLLs (32bit/64bit). I am not sure if this will work as intended, but you may give it a try.

If it does not, then stick to the old version until Argus 5.3.02 is out that should (hopefully) be accompanied by the Data API to get to all values like GPU temperature, fan speeds, CPU temps, disk temps, fan PWM control values (if controlled by Argus), etc.

Best regards
Udo

PS: I am sorry but I am too stupid to figure out how to add attachments here. I uploaded the file on our website: Argus Monitor Rainmeter Plugin 1.3.0.1 (for Argus Monitor 5.2.08+)

[Ahnìon]

Hey, very cool! Thanks!

I tried it out, but while GPULoad now changes rather than being stuck on 50%, it seems to have the value from Hot Spot rather than Load. (NVidia GPU.)

I really appreciate your trying to fix the plugin. If you don't have the time to look further into it, I guess we'll just have to stick to 5.2.07 for now.

Fan access on the new NVidia drivers will still work on 5.2.07 as long as it runs elevated, right?



(If anyone wants to try the new version and has trouble installing it, the .rmskin file is a zip file, so if you just change the extension from .rmskin to .zip, you can open it and grab the new plugin version.)

[argusmonitor]

Thank you for the feedback. I might have time to take another look (apart from that I spend most of the free time on creating the data API). I was not aware HOW MUCH sensor data we have that would need to be made accessible.

In any case, I will check again later what might have gone wrong and re-compile the DLLs (I don't have Rainmeter myself so I can't really test it). But it is true, We added 3 potential new GPU temperatures (2 are available on new Nvidia GPUs) and this shifted the GPU load by those 3 places.

EDIT: yes, for driver versions 466.11+ you need to run Argus in elevated mode until 5.3.01 is out that will bring this functionality back also for those cases when Argus is running as normal user.

EDIT2: a brief look and I can see that the new indexes are used. Can you check if the Plugin you use has the newest DLLs and that they are used. I cannot think of any reason at the moment that could cause the values not being the correct ones as the indices are shifted as intended.