Can I track a VI's execution from another VI?

[Pari]

Hi all,

Here is what I am trying to do.

I want to keep a track of an executable (written in Labview) and see if it is running or not. The reason being, I want to run a different VI (which migght be an executable written in Labview) ONLY WHEN the other VI is not running. So I was wondering if there is any way I can track a VI (see if it is running) before launching another VI.

In other words, When I try runnning This.vi, This.vi will go ahead and check if That.vi is running or not and if it is running it will pop up a dialog box, which says that u need to close That.vi before running This.vi. Further is goes ahead and runs This.vi only when That.vi is closed.

Does anybody know how to do it?
Thanks.

-Pari.

[Enrique]

VI Server.

Open a reference to This.vi using "Open VI Reference". Check the status of This.vi using the property "Execution:State", with a Property Node. Create your own routine based on the result (Opening a dialog if This.vi is running, etc.) Do the same with "That.vi".

Regards;
Enrique

[Rob Cole]

The problem there is if the VI has been built into an executable. The default mode is to run when opened. If you open a reference to it, it will open and run. If the executable is not in memory and resides elsewhere on the disk, you just get an error (which could tell you what you need).

Rob

[Pari]

Thanks Rob and Enrique.

Here is what is happening. I am trying to open a VI reference of a VI that has been built into an executable (FROM A VI). It shows me errors like, "LabVIEW: VI Reference is invalid" and ,"LabVIEW: File not found.
or NI-488: Non-existent board".

Do you know the possible reasons for this. I tried providing the "Open VI reference" with a string input (which is just the name of the window) and with the complete path of the VI of which the executable was built, but it does not like that.

Any suggestions?

I appreciate your help.

-Pari.

[Pari]

Hi everybody,

The executable that was built (which i am trying to track) was programmed in 5.0 and I am trying to call it from a VI which is programmed in 6.0.2.

Is this the problem? That is all I can think of because when I try and open a VI reference of an application written in 6.0.2, it works fine and the one written in 5.0 does not.

I figure that might be the problem.

Thanks.

-Pari.

[Rob Cole]

I have heard that the references are handles a little differently in LV6, but have had no experience with this. The only version that this company owns is LV6. It might be interesting to try saving it as a LV5 version (save with options from the menu) and see if the references get translated into a functional format.

Other than that, I haven't tried talking to stuff made on a previous version without opening the VI and "translating" it into the latest version.

Rob

[Dennis_Knutson]

The LabVIEW Windows utilities library contains a VI that lists all running tasks. Your executable should be listed their. You can download the library at http://zone.ni.com/devzone/explprog.nsf/webmain/EBF11DD1F0FEAEF3862566790072A983?opendocument&node=DZ53008_US.

[Pari]

Hey Dennis,

I tried to use the winevent.llb (Quit application.vi) but it gives me this error....

"Error 6006 occurred at PostMessage Master.vi.

Possible reasons:

This error code is not listed in the internal database, or you have wired a number that is not an error code (such as a DAQ task ID) to the error code input."

Any idea why this is happening?

I was also wondering about how to determine the windows rfnum(or ID) of a window.

thanks for your help.

-Pari.

[Rob Cole]

In the Windows Management VIs (winutil.llb) is a VI called "Get Window Refnum.vi". Give it the name of the window that you want the refnum for.

The error codes are listed on the last 2 pages of the documentation for the lvwutil32 package. Error 6006 is: window has an owner. The documentation on Quit Application states, "Note that the window to be closed must have no owner or parent window."

Sounds like you might be trying to close a window that is in use by another program. The LabVIEW windows utilities are working as advertised.

Have fun.

Rob

[Labviewguru]

Pari,

I will be slightly redundant in answering your question.

There are a number of ways to accomplish what you are doing. I would; however; suggest that you look at exactly what you are trying to do in making your decision. If your applications are related, as I suspect they are, then I would suggest either VI Server, or some other method internal to LabVIEW. If, as I suspect, you have related VIs built into Executables, then I would suggest a third alternative. If you create a storage variable (unitialized shift register, very similar to a global, but safer) that variable will be maintained to a certain value as long as you have a session of LabVIEW (Runtime) open. So, if you then call the same variable by opening another executable, you should b
e able to check the status of the variable. I have never actually done this, but it should work (please test first, you may create two copies of the variable if the runtime session is created twice.) I would suggest this as the best solution for two related executables. This is essentially a flag method, wherein a flag is set (usually a boolean, i.e. busy status) by one, and the other VI will read, and only set busy if it isn't already.

If they are unrelated, a call to VI server will work IF and ONLY IF you know the other VIs name. This is the best solution for unrelated VIs that you don't want to use a flag.

Using the list of running functions through windows is the solution you would use if your application doesn't meet the other two criteria. It is reliable, except that if your VI has a window name which is not predictable, you may not know the name (programmatically) of your resource. This method could however; determine if the LabVIEW runtime engine is running on the s
ystem. This method is appropriate if you have no idea what the other VIs name is.

Good luck