ni.com is currently experiencing slowness/issues due to ongoing maintenance.
Support teams are actively working on the soonest resolution.
ni.com is currently experiencing slowness/issues due to ongoing maintenance.
Support teams are actively working on the soonest resolution.
01-10-2012 01:07 PM
Just Microsoft Composite Battery.
03-19-2012 05:38 AM
Hi Phillip and Fellow LabView users.
Just want to say this example works nicely with Win 7 64 bit. ( we had to un-install the APC PowerChute as mentioned the earlier post)
Huge thanks for this. you have saved a lot of hassle
Regards
Chuck
12-02-2012 03:55 PM
Nickleback, or anyone else who can help,
Which version of the VIs did you use with Win7, 64-bit? Were you using LabVIEW 2012? I have tried all three with no success in 2012. I have checked everything mentioned in this thread (no APC software, never was installed,; correct battery listed; etc). I tried running them in their original form, saving in 2012, even creating a project and copying the files out of the library. All with no success. Nothing changes except the 'Charging' LED (which seems to work correctly.
Here is my system:
DELL Latitude E6420 Laptop
Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz 2.50 GHz
Windows 7 Enterprise 64-bit
LabVIEW Developers Suite 2012
12-02-2012 06:02 PM
12-02-2012 09:48 PM
RoyA,
I don't see any issues on my aforementioned Dell E6410, running W7 x64 - my code still works. However, I'm running under the LV2011 development enironment - not 2012. I don't have 2012 installed on this machine at present.
So it could be:
- a LV 2012 vs 2011 issue
- a rights/UAC issue (I am logged in with local admin rights)
- a problem with your .NET installation
- a problem with calling GetSystemPowerStatus from kernel32.dll on your platform
- something else I haven't thought of
Can you confirm what LV code you have and/or from where you got it? My code is still saved in 8.2.
It registers a .NET callback to get PowerModeChanged from Microsoft.Win32.SystemEvents
The actual callback VI calls GetSystemPowerStatus from kernel32, then posts the results to a LV user event.
Let me know what else I can try to diagnose this for you.
Dave
12-02-2012 10:19 PM
Dave,
Wow! Thanks for the quick response. Here is where I got the three versions of code I have tried:
First, most simple - http://sine.ni.com/devzone/cda/epd/p/id/439
Second, Notifier version - https://decibel.ni.com/content/docs/DOC-1154
Third, Events version - https://decibel.ni.com/content/docs/DOC-9256
All three work, somewhat, on my DELL Latitude D830 running WXP Pro with most recent patches, and LV 2011 SP1 f2.
By somewhat I mean the tank and the High, Low, Critical, and No Battery LEDs never change. The Power BOOLEAN and the Charging LED change properly. The Estimated Time updates, but has 'strange' numbers (like the following sequence 336:54:37 / 00:00:00, 848:55:14, 298:36:24 / 00:00:00, 298:36:12 / 00:00:00, 296:33:04 / 00:00:00, ...) Second number never changes.
Akso, when the UPS dies completely the Power BOOLEAN goes back to AC Power.
Thanks again.
Roy
12-02-2012 10:46 PM
My bad - I *AM* seeing issues similar to what you're reporting - I just didn't wait long enough.
I do an initial poll for current power status, which works. And if I pull and re-plug the DC power cord on the back of my laptop, events fire, so I see the changes in AC line status and battery charging state. But I am *NOT* getting events when the battery charge level changes. This used to work!
So I'm puzzled. Too tired to troubleshoot further tonight, maybe I can figure it out tomorrow. But at least I can confirm what you've observed.
Dave
12-03-2012 03:31 AM - edited 12-03-2012 03:36 AM
Hello Folks
I think this has moved on from the post I was going to leave as my humble offering doesn't do events but I will leave it any way as it may be of use.
Chuck
12-03-2012 06:49 AM - edited 12-03-2012 07:00 AM
Well I'm an old geezer still limping along on Windows XP and LV 8.6.1 (I do have LV2012 installed, just don't use it)
My example took the original polling example and registered for a .NET callback of PowerModeChanged. When the event occurs, the kernel32 GetSystemPowerStatus function is called to return the cluster of data containing the % values data.
Maybe you need to change the CLF Node in the PowerModeChanged to point to the correct version of kernel32 based on your OS and LabVIEW version? There are a couple of CLF nodes; one in the example, one in dotNET PowerModeChanged Handler.vi and one in dotNET PowerModeChanged.vi
12-03-2012 07:24 AM - edited 12-03-2012 07:37 AM
I just noticed that the original GetSystemPowerStatus cluster that I blindly saved as a typdef configures the BatteryLifeTime and BatteryFullLifeTime values as I32, but the M$ descriptions for this structure indicate DWORD (unsigned).
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373232(v=vs.85).aspx
Maybe the combination of the wrong data type in the cluster and 32 vs. 64 bit explains the strange values you are getting; especially if your UPS is large enough to let you run for in excess of 9 hours...
EDIT:
Help indicates the function returns -1 if time (secs) is unknown. So it must be I32. Maybe still something to do with 32/64 bit and selecting the correct instance of kernel.dll?