Preventing PCs from sleeping or hibernating

[Ben_Manthey]

Have you ever had a PC go to sleep while running a LabVIEW program? It doen't end well, the DAQ crashes and it's a pain to recover from.

Your PC doesn't sleep or go into screen saver when watching a movie, now you can do this with a LabVIEW program. 

I've added a document to the NI Developer Community that explains how to do this. But I think some community discussion here is also welcome. 

Please let me know what you think.

[RTSLVU]

Your VI's could come in handy on machines that have Power Options locked out by your administrators.

[aleclspin]

I guess I'm not really sure what the use of this is when sleep or hibernate settings can be set by the user in Windows. Would programmatically moving the mouse a very small amount occasionaly not also prevent sleep mode? Seems like a complicated solution to a simple problem.

EDIT: RTSLVU brings up an excellent point. I suppose I hadn't thought of that particular situation.

[Bob_Schor]

Bravo!  I just tested your Demo under Windows 10, and while I didn't wait long enough to see if my PC would sleep (I've already tried to turn that off with the Power options), it didn't crash or give me an error message ...

Since you are sufficiently knowledgable about some of these Windows internals, is there something similar that controls the "Screen Lock" timeout?  Our ISD people decided that "an Idle PC is the Devil's Playground" and (on some, but not all PC's) put in place a forced "lock the PC" after 15 minutes of "inactivity".  Imagine the "surprise" of the investigator testing a patient using custom-written software, a test that runs 20 minutes with no User interaction (all the interaction is the Subject, being monitored by DAQmx), and having the system "lock" on them.  Oops.  Talk about a dangerous situation.  Your "temporarily prevent this stupidity" code could (literally) prove to be a life-saver ...

Bob Schor

[RTSLVU]

---

@aleclspin wrote:

I guess I'm not really sure what the use of this is when sleep or hibernate settings can be set by the user in Windows. Would programmatically moving the mouse a very small amount occasionaly not also prevent sleep mode? Seems like a complicated solution to a simple problem.

---

As I said above, Power Options can be locked out using Windows User Policies.

All our desktop workstations are set to "Power Saver" power profile (One of the hassles of being a "green" company) and the users do not have the rights to change it, not even the screen saver timeout, that's company policy. 

[Ben_Manthey]

I think that setting the type to 'Power Request Display Required' will prevent locking, but I really don't know. As with most Windows DLL calls it's poorly documented enough that I'm not sure. Should be pretty easy to to test. 

[RTSLVU]

This does not seem to work on Windows 7.

It seems to not detect Windows 7 as Windows and goes to the default case instead.

Or maybe I was wrong and it can not get around User Policies

[BowenM]

I have no problems running it in Windows 7 64 bit SP1.  Out of curiosity, does this affect screensavers?  You might want to update it to do so if it does not.  

Edit:  "You could also use 'Power Request Display Required' to prevent the screen from turning off or going into a screen saver."  ... it helps if I actually read your post.  Good work!

[Ben_Manthey]

Ahh, I forgot to mention that you need to open Demo.vi from the project so it will sucessfully detect the OS. Sorry for the trouble. 

EDIT: I updated my document to talk about this requirement. I suppose you could just remove the OS==Win case stuff to solve the problem too. I wanted it to not work at all on other OSs though.

Thanks,

—Ben

[rolfk]

Juast a little bug:

In Power Create Request.vi, you create a memory pointer to pass an unicode string to the PowerCreateRequest() Windows API. After that API returns this pointer should be deallocated with DSDisposePtr() to avoid a memory leak.

Alternatively you could leave away that pointer creation altogether by using the MoveBlock call to retrieve the actual pointer value from the LabVIEW array handle returned from the second MultibyteToWideChar function. In fact the whole string handling in that VI is a bit murky. You should really use the return value of the MultibyteToWideChar() as length indicator, if <=0 the function failed, otherwise it indicates the number of 16 bit character code points including the terminating NULL character. Using that you could at least leave away the entire Byte Swap, Typecast and String Length nodes.

Also a HANDLE in Windows is technically always pointer sized so you should configure the Call Library Nodes accordingly and make the handle control an U64.

Changing the Conditional Disable Structure to "TARGET_TYPE==Windows" will make it also work when used outside a project.

Note that the passing of the 64bit "Pointer" in the structure like this only works by the virtue of several conditions here. Most importantly because it's the last element in the cluster. On 32 Bit LabVIEW this pointer is really just a 32 bit value. Since this runs on an Intel x86 CPU which uses Little Endian or LSB (Least Signficant Byte) first, the excessive 32 bits from the LabVIEW 64 bit pointer just trail over the end of the data structure as the function sees it. If other eleemnts would follow in the structure one would need to create two distinct structures, one for LabVIEW 32 bit and one for LabVIEW 64 bit, as otherwise the offsets of the element after that pointer wouldn't be correct anymore on one of the platforms. Another lucky feature of this structure is that the layout doesn't cause alignment issues either since the two elements in front of the string pointer add up to 64 bits, so that the pointer is always properly aligned to 64 bit,