LabVIEW
System flags - Labview 2009
Norbert already gave you some informations. The information you want to read are not a standard supported feature of Windows. As such they are only available on certain systems that support monitor services and APIs to access this information.
As far as HD is concerned you want to read SMART information from the HD controller. Windows does not really supply an API to query this information so you need to access the low level device with passthrough mode to access directly the SMART interface on the HD controller. This is fairly cumbersome and also slightly different for each type of HD interface IDE/SCSI/SATA/Firewire/etc. One way to query this information under Windows more generic is by using WMI but it's still not trivial and can fail for many reasons if the HD is not directly connected to the motherboard.
PC Temperature is anything but standardized. Each motherboard has it's own temperature sensors or none. Also many board manufacturers do not release any API to access this information. If they do it is always manufacturer specific.
Well Norbert gave you some information. I try to fill in more details but in general you should realize that what you want to do is at best a nightmare to do and at worst impossible.
HD information is available through the SMART interface on all modern HD controllers. However there is not really a standard way to access this information. The easiest is by using WMI on Windows to query some of the information. WMI however isn't exactly trivial to use, and rather poorly documented, so it is still a challenge. A lower level approach is by using the pass through capability of the device driver interface to HD devices and query the SMART information directly from the HD controller. This has the advantage that the SMART request and response blocks are well documented, but you access the Windows API on a very low level and tShere are subtle and difficult differences in the exact procedure depending on the communication path that is used (IDE/SCSI/SATA/Firewire/USB/etc) with some of them most likely failing to pass through the direct requests (USB being the most prominent case here).
PC information such as temperature and memory health is something else that is not standardized at all. While most boards nowadays use internally several temperature sensors (and CPUs have them too) memory health information is only available on specific high end boards usually used for high performance servers. It also requires specific memory chips with error correction.
All this information is then accessed by the BIOS to generate internal reports but it doesn't automatically mean that there is actually also an API to query this information from your OS. Typically only boards that are meant for industrial automation use do come standard with some driver API at least for Windows to access this information. This driver API is mostly in the form of a DLL, but it can be a challenge to get the documentation for it if you are not a large OEM who orders several x thousend boards in one go.
So while it all can be done (SMART by using WMI is probably the most promising approach) it is anything but easy and definitely not a write it once and use it anywhere solution. It requires in the case of board temperature and memory health specific hardware with manufacturer delivererd system drivers that have to be accessed through their DLL interface (which is completely different for every manufacturer). For SMART, while WMI is a promising option, there is also no guarantee that it will work, since the actual physical HD interface may be hidden from your OS by a RAID controller or other secondary interface such as USB, that does not support transparent pass through requests to the physical HD interface.
@Norbert_B wrote:
One important question came to mind:
Are you running PXI?
If so, which chassis and which controller?
Norbert
Interesting question. I would suppose NI has according drivers for their own PXI controllers. 🙂
The OP sounded however like he might be using a standard PC here.
Another reason why retrieving SMART information under Windows 7 might fail is that accessing devices directly, which is necessary to read SMART information with passthrough method, requires administrative privileges for the application in question. Not sure if WMI access is hampered in the same way, as WMI might not do the device request passthrough in the application context but instead in a seperate deamon that runs with system privileges.
This deamon would be a standard Windows service, of which you have about at least two dozen running even on a minimalistic Windows installation.
