Communication with LabVIEW Run-Time Engine

[NadavC]

Hi all.

I have an application created in LabVIEW, and I built an executable file from it (Let's call it App1.exe).

While App1 is running it sometimes generates an exception and is aborted. The problem is that the Run-Time APP1.exe GUI remains open (Which is undesirable). I need a way to close it somehow. I realized that the only way to close it is from another application (Let's call it App2).This solution can be realized in 2 different ways:

1) App2 communicates with App1 and closes it if App1 is not alive. The problem is that sometimes App1 is simply working slowly because of system problems and I might shut it down even though It's still running

2) To somehow obtain from the Run-Time engine what's the state of App1. I think that this way is preferable but i don't know how to communicate with the Run Time Engine.

I'll appreciate any suggestions (Preferably with some kind of example code).

Thanks, Nadav

P.S. I'm using LabVIEW 8.2.1.

I have a cross-post in NI LabVIEW Forum:

http://forums.ni.com/ni/board/message?boar...ssage.id=244881

[LAVA 1.0 Content]

QUOTE(NadavC @ May 1 2007, 10:22 AM)

While App1 is running it sometimes generates an exception and is aborted. The problem is that the Run-Time APP1.exe GUI remains open (Which is undesirable). I need a way to close it somehow.

When I want the front panel to close on my exe vesions, I add this bit of code in my top level vi. I wire an error out to the outside of the sequence structure to keep from exiting prematurely. This has the advantage of NOT closing automatically if I'm in the development environment. I've had this for so long that I can't recall if someone gave it to me or if I recreated it from an example elsewhere. It uses the Quit LabVIEW function, which states that it stops all running VIs and ends the current instance of LabVIEW. Separate runtime exes should have their own app instance, so "app2.exe" in your case should continue to run...

http://forums.lavag.org/index.php?act=attach&type=post&id=5681

http://forums.lavag.org/index.php?act=attach&type=post&id=5680

[NadavC]

QUOTE(LV Punk @ May 1 2007, 02:58 PM)

When I want the front panel to close on my exe vesions, I add this bit of code in my top level vi. I wire an error out to the outside of the sequence structure to keep from exiting prematurely. This has the advantage of NOT closing automatically if I'm in the development environment. I've had this for so long that I can't recall if someone gave it to me or if I recreated it from an example elsewhere. It uses the Quit LabVIEW function, which states that it stops all running VIs and ends the current instance of LabVIEW. Separate runtime exes should have their own app instance, so "app2.exe" in your case should continue to run...

http://forums.lavag.org/index.php?act=attach&type=post&id=5681

http://forums.lavag.org/index.php?act=attach&type=post&id=5680

Thanks for the quick reply, however this does not address my problem. I need a way to close a LabVIEW Exe file that has been terminated brutally by some error that I can't register or handle. Assume that the Exe file stopped running and that the GUI is still open (But isn't running).

Nadav

[Jim Kring]

QUOTE(NadavC @ May 1 2007, 08:37 AM)

Thanks for the quick reply, however this does not address my problem. I need a way to close a LabVIEW Exe file that has been terminated brutally by some error that I can't register or handle. Assume that the Exe file stopped running and that the GUI is still open (But isn't running).

Nadav: If you can't trap the error programmatically and it Aborts execution of your VI, then you cannot exit LabVIEW programatically.

[Ami]

QUOTE(Jim Kring @ May 1 2007, 09:51 AM)

Nadav: If you can't trap the error programmatically and it Aborts execution of your VI, then you cannot exit LabVIEW programatically.

[uPDATE] I didn't read your initial post. You should be able to kill the task of the stalled application from an external app using WinAPI calls or from the commandline (taskkill).

Jim: I think Nadav is looking for a way to close the App1.exe (That stopped running) from App2.exe (That is still running). Something similar to a watch dog.

Update: Now I realize that he can close the App1.exe, but he needs to know if App1.exe stopped running.

Ami

[Aitor Solar]

QUOTE(Ami @ May 1 2007, 05:55 PM)

Update: Now I realize that he can close the App1.exe, but he needs to know if App1.exe stopped running.

He could implement an ActiveX / TCP / Shared variable communication with App1 from App2 and test it periodically. If it doesn't respond, abort it through a taskkill or similar. You can even reinitialize it from App2 to avoid lost time.

Saludos,

Aitor

[jpdrolet]

Try this:

http://forums.lavag.org/index.php?act=attach&type=post&id=5683

The VI Server is enabled in APP1.

Using the VI Server, APP2 detects Main.vi state and closes the panel if it not running (Idle). When an app has no front panel opened, it exits.

[LAVA 1.0 Content]

QUOTE(NadavC @ May 1 2007, 11:37 AM)

I need a way to close a LabVIEW Exe file that has been terminated brutally by some error that I can't register or handle. Assume that the Exe file stopped running and that the GUI is still open (But isn't running).

Are you running multiple instances of the same exe, or are these different exes? If App1 contains a brutal error that you can't register or handle, you're gonna have to modify that code somehow, so why not try to identify and fix the bug(s)?

If this is a legacy app that you can't touch (regulated or source is incomplete), then the suggestions (TCP/IP, Shared Variables, VI Server) are not viable; these require changing the App1 code. Your only choice seems to be forensic methods such OS calls (CPU load, memory usage) or file monitoring (data log file stops growing, exclusive lock on file).

If you can make small changes to App1 (but aren't prepared to find the root cause of the crash) then the various suggestions should work, but you might need to install and configure the Shared Variable or Data Socket Runtime engines. If you're deployed on multiple machines, this may require more administration and/or documentation.