Labview does not close on a windows shutdown event.

[Dpete]

If an external event occurs, such as when my UPS tells the computer to shut down, Labview pops a messagebox that says something like closing this program will abort a running vi.  The close then stalls and windows reports this program is not responding and hangs until the UPS cuts power to the computer instead of shutting down proper.

How do you get labview to not open the box so that the shutdown can occur the way it is supposed to if the test system is unattended at the time of the shutdown?

[RavensFan]

Look at these threads.

http://forums.ni.com/ni/board/message?board.id=170&message.id=444393&query.id=966596#M444393

Calculating the System Power Source and Battery Information in LabVIEW

I'm using UPS's and their status shows up as a part of the Windows Power Monitoring when I have the communication cable set up between the UPS and the PC.

If you let your LabVIEW program monitor this status as well, then you can allow the LabVIEW program to shut itself down.  One thing I noticed with my UPS is that it occasionally goes off AC power and onto battery power for a few seconds.  So if you monitor the battery status this way, you may want to be sure it is on battery power for some minimum period of time before you initiate your program shutdown.  I think the UPS does something like click over once a day possible to test the battery or just cycle the contacts.

[Dpete]

Overall, I'm not that concerned about labview shutting down.  In a power failure, the load and unload robots are going off line instantly regardless.  My only concern is letting the PC portion to shutdown properly to try to avoid hard drive corruption.  The real purpose of the UPS is the line conditioning aspect of a full double conversion system after issues with a programmer not liking to be plugged into the same circuit run as a variable frequency conveyor drive. 

For me it would be less headache to suppress the vi message than have the overhead of a vi constantly polling the power status.  Even then it is as matter of when the UPS sends the shutdown signal.  If it does that before the vi polls and decides to shutdown, I am still in the same boat with software that does not respond properly to a windows generated event.

[RavensFan]

You could also have the VI initiate the shutdown of windows when it detects the UPS going on battery power rather than having the UPS software initiate the Windows shutdown.

[Dpete]

Well sort of.  I have the solution.  It seems that Eaton's software does not report to windows power management and does its own thing.  If I uninstall all of theirs, and let windows handle the UPS as USB HID compliant device, I can set hibernate mode on low battery and force close of non responsive programs from there.  I'll play some more tomorrow, and see if the vi you linked can read the battery levels if Eaton's software is uninstalled.  It is a bit frightening how their software hides the power options from windows.

[intvsteve]

When LabVIEW receives a message from the OS that Windows wishes to shut down (WM_QUERYENDSESSION), quite a lot happens in LV, including the prompt to save modified VIs, abort VIs, etc.

If you have a top-level 'master' VI that already supports a controlled shutdown, I would suggest having it implement a handler for the 'Application Instance Close?' filter event in an event structure. When you receive that event, LabVIEW is about to exit (whether specifically due to power going out, logging off, the 'Quit LabVIEW' primitive, VI server functions, whatever). Do *not* discard the event - but when you receive it, end your VI.

That is, implement that event handler as if you pressed a 'Stop' button on the front panel (not abort, I hope). This gives your VI the chance to stop the way you intend, which is better than just aborting it. If you have shutdown code, have it in a subVI that you call in that event handler, then have the main while loop exit.

The OS does have a timeout for an application to respond to this event. So if your shutdown takes too long, you may get the 'app not responding' feedback, and / or the Windows shutdown may be abandoned. That timeout may be configurable (check on MSDN), but of course your UPS also has some timeout after which it cuts power, too. (Likely a bit longer than the Windows timeouts to allow the entire machine to cleanly power down.)

In any case, I think that you can cleanly and simply address this with the appropriate event handling code in your main VI.

Best Regards,

[intvsteve]

A follow-up ... 

Perhaps in your case you do care that you're quitting because of a power issue, and need to behave differently than if someone just chooses Start>>Shut Down, in which case my previous suggestion is inadequate.

However, in most situations, I don't think it's necessary to tie into the power management Windows APIs to handle this. For example, I bet if you had a web browser, or Notepad open w/o changes to the text file, it shuts down just fine. Most apps could care less *why* the computer is shutting down - they just care that they've been told to go away because the computer wants to exit the current Windows session.

Chances are, once the UPS decides it really needs to shut down the computer, the OS ultimately broadcasts a WM_QUERYENDSESSION message anyway, simply because that mechanism has been around for ages, giving apps a chance to cleanly exit w/o adding code to respond to the ever-changing power managemente APIs.

Just wanted to check that you weren't perhaps adding complexity that you didn't need.

Best Regards,