Running LabVIEW VIs on MAC OS X using LabVIEW runtime engine.

[Hasan-Baig]

Hi All,

I have a question regarding running LabVIEW VIs on MAC OS X using LabVIEW runtime engine.

The specifications of system environment are:

Operating System: Mac OS X EI Capitan v10.11.2 

LabVIEW Professional Development System 2014

LabVIEW Runtime Engine 2014

Problem:

I developed a LabVIEW application (on LabVIEW professional development system 2014) which generates and run another LabVIEW VI. Lets say the main application is "A". When user select specific option on "A", a new VI is generated (say "B.vi") and open in RUN mode. When I close "B.vi" and try to open it externally directly from where it is located, it doesn't open. Double clicking on "B.vi" prompts up a dialogue box with the following message

"There is no application set to open the document "B.vi". Search the App Store for an application that can open this document, or choose an existing application on your computer. 

I couldn't locate installed LabVIEW runtime engine to open B.vi. Please be noted that "B.vi" open perfectly in a system where LabVIEW full development system is installed. 

Any help and suggestions are appreciated. 

Thank you very much.

Regards

Hasan Baig

[Sam_Sharp]

The runtime engine is used to run executables built in LabVIEW. It will not open .vi files.

To open the .vi file, you will need to install the development system on the computer. Or turn your VI into an executable (e.g. for windows - a .exe) which you can then run on the PC that has the runtime engine installed.

[Hasan-Baig]

Hi Sam,

Thanks for your reply. 

You mean that if I simply replace .vi to .exe will run labview program using runtime engine? 

For MAC, should it be replacing .vi with .app ? I tried but it says "You can't open the application "B" because PowerPC applications are no longer supported". 

Regards

Hasan

[Sam_Sharp]

No, you can't just take a source code file and change the file extension and expect it to run! Imagine doing that with a C file? It's just text/code...not compiled/executable instructions.

You need to learn how to create an executable for your application - it's under Build Specifications -> Executable in the LabVIEW project. It should create a file which you can run on your Mac (e.g. .app? I'm not a Mac user so I don't know). There's a link here that talks you through how to create a standalone application: http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/building_a_stand_alone_app/ 

Note that you need a Professional license for LabVIEW, or the Application Builder. If you don't have a license for these, you won't be able to create an executable and you will need to install the development system on the PC you want to run the VIs on (subject to your license).

[Hasan-Baig]

Yeah my university already have a license of professional development system. 

I also know how to create LabVIEW executable files. This is what I followed to make the main application "A" executable. this executable file contains several other dependencies (.vi) files. One of the functionalities of A is to copy a file from these dependencies (lets name it file xyz) into another folder and open this file xyz.vi in run mode. This procedure of opening and running xyz.vi from executable labVIEW file "A" works fine. But when I try to open this xyz.vi separately, it doesn't work at all. 

Another question might be how may I be able to run vis (which are included in dependencies of main application)?. 

Regards

Hasan

[Sam_Sharp]

How are you opening/running the VI in your main application? Can you show us the code where you run the 'B' VI?

[natasftw]

Few things here.

1) 2015 isn't technically supported on El Capitan.  You're playing with a bit of fire using 2014.

2) You know how to build the executable.  Do that.  The runtime is meant for you to distribute your applications.  VIs are meant for editing, not distribution.  When you open iTunes, you're not getting the source code, are you?  No.  If you're sending the VI to someone, they should have the development environment.  If they're not developing, it simply doesn't make sense for them to have the source code. 

3) When you choose xyz.VI in your build spec, it compiles this VI within the executable.  It's running fine in that context because it's not the VI anymore.  Sure, you can put the VI on the system but that doesn't mean much.  It's going to use the binary compilation any time xyz is called in your code.  When you try to run the VI by itself, you don't have any application to read it.  The RTE doesn't read VIs.  It reads executables.  You can spend weeks fighting this and failing.  Why?  What you're doing doesn't make sense.  If you want to develop, send the VI to a machine with the development environment.  If you want to send applications to people without the development environment, stop sending your source code.

[Hasan-Baig · Accepted solution]

Hi Sam,

I am opening and running the VI with the simple procedure shown in the image attached. On the left, green wire represent the path of the file which I want to open. As I said that I want to generate the VI using main application and save it for later use. The problem was that I couldn't open it by double-clicking on it. 

I have implemented in a different way now. The generated B.vi can be open with the same procedure (image attached) from main application "A". 

regards

Hasan

[Hasan-Baig]

Hi nats,

Thanks for your response. 

1. I am not using LabVIEW 2015. I didn't get you saying "playing with fire using 2014"; why ?

2 & 3. I don't mean to distribute a source code. The idea is that the main application run some sort of files and based on the parameters defined in that file, it generates a VI (B.vi) for the users to perform some simulations. Each file may have different set of parameters, so users might be interested in having all VIs separately. That was my intention to figure out why I am unable to open VI externally once it is generated and saved by main application "A". 

I didn't know that .vi files can't be run using RTE. Now I know and also have implemented this functionality in a manner mentioned in my above post :-).

Thanks again for your concerns. 

Regards

Hasan

[natasftw]

I'm aware you're not using 2015.  2015 is the newest LabVIEW.  It's not yet supported for El Capitan.  If you're using something older than that, you're risking incompatibility issues due to the environment never being tested.  In other words, you're playing with fire.

What you're doing is a VERY hacky way to try to get around that limitation.  Why don't you just handle the different behavior within your application?

If your intention isn't to distribute source code, you should avoid solutions that are doing that.  If you were given an application built in VB and after you hit a button, it popped up the source code to handle the task instead of just handling it, wouldn't you shake your head at the developer in this case?  If so, why would it be any different when using LabVIEW?