Jump to content

VI running as an Exe or in Dev Enviroment?


Recommended Posts

For debugging and testing purposes, I would like to be able to have my VI programmatically tell itself if it is running as a VI in the Labview development environment or if it is as a built application?

Currently, I am using a simple case statement with boolean constant to control this feature.

John

Link to comment

QUOTE(jorourke @ Aug 27 2007, 02:42 PM)

For debugging and testing purposes, I would like to be able to have my VI programmatically tell itself if it is running as a VI in the Labview development environment or if it is as a built application?

Currently, I am using a simple case statement with boolean constant to control this feature.

John

John

try using the Application Property "App.Kind" wire that to your case(s)

Dan

Link to comment

QUOTE(jpdrolet @ Aug 27 2007, 03:25 PM)

Does it work when a VI with its BD is run by an application?

Don't use this method, use the one Jim posted. A developer can strip a BD from a VI that is still in the development environment! (Either I didn't reply fast enough or Jim and I replied at same time...!) I reiterate what Jim says.

Link to comment

QUOTE(Eugen Graf @ Aug 27 2007, 01:42 PM)

Or you can use the property "BD Size" and compare it with 0.

Eugen

This assumes that if a VI has no block diagram that it is built as an EXE. However, it is possible that the block diagram might be stripped and the code is running in the development environment. But, it is also possible that the code is running in the Run Time Engine and it has not been built as an EXE (so I'll admit that my solution is not fool-proof either). The only reliable way to tell if something is built is to perform some operation during the build process which only happens during the build process and check for that in the code. I use OpenG Builder to set Version Info (Version Number, Build Number, and Build Date) on a cluster of a VI's front panel (which is a fool proof-way to tell if the code is built). However, for the casual user, I believe that the check for App.Kind == Run Time System is the most reliable mechanism.

Link to comment

QUOTE(Jim Kring @ Aug 28 2007, 08:33 AM)

But, it is also possible that the code is running in the Run Time Engine and it has not been built as an EXE

How? Are you thinking about dynamically calling VIs?

The property is an Application class property, so it should return the kind of the application instance, not the specific VI which is executed (e.g. if you connect to a running EXE through VI server, you will get the development environment value if you use a local property node and you should get the RTE value if you use a reference to the remote app).

Link to comment

QUOTE(yen @ Aug 28 2007, 11:54 AM)

How? Are you thinking about dynamically calling VIs?

The property is an Application class property, so it should return the kind of the application instance, not the specific VI which is executed (e.g. if you connect to a running EXE through VI server, you will get the development environment value if you use a local property node and you should get the RTE value if you use a reference to the remote app).

You can use any LabVIEW executable to run project VIs (unbuilt source code) in the run time engine (just pass it the VIs paths as command-line arguments). This is a trick that I learned from Jean-Pierre Drolet, some time ago. If you want a degenerate LabVIEW executable, just make a copy of "<LabVIEW>\applibs\lvapp.lib" and rename it as "anything.exe".

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.