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

[Hasan-Baig]

The generated Vis are saved without block diagram.so code is still not visible to users.

I noticed on some forum that if VI server methods are used, one should not put the dependencies of application inside an application.app package while building up an application using application builder. Otherwise the application won't work correctly.

So keeping the labview library outside application.app folder makes it visible to end user. Could you please suggest me an alternate solution to avoid making libraries visible while using vi server methods ?

Thanks

[rolfk]

I wouldn't call it playing with fire. Yes it's unsupported (and 2015SP1 most likely will have official support) but it's not like the Mac will burst into flames from this.

And the problem here isn't that something in the OS doesn't work nice with LabVIEW anymore but simply that the Runtime Engine doesn't register as an app for handling any specific files. And it can't since it is not an app. The Runtime Engine is a set of shared libraries that provide the necessary support for doing things like drawing windows, controls and what else on the screen, interface to various OS APIs and abstracting them to a common API on all supported LabVIEW platforms that a LabVIEW built executable can use. Your executable that the applicatoin builder creates is really just a small stub program with all the compiled VIs embedded within. This stub program does locate the Runtime Engine, loads it and links to it, then loads the compiled VI resources and starts them.

So the actual loader is in the executable you build, not in the Runtime Engine. Therefore the only way you can make a Runtime System load a VI from disk is by writiing an application that does this. This application needs to have the pass command line parameters checkbox enabled in the application builder. And it needs to be registered in the OS for handling the specific file type. This registering under Windows are several registry entries that need to be made correctly. I'm sure there exists something similar under MacOS X but I'm not familar enough with it.

IMHO it is also not a to useful option to create. The Runtime Engine can only load VIs which were saved with the exactly same version and platform as the Runtime Engine itself is. And you better don't save the VI with seperated code. Otherwise the Runtime Engine has nothing to load, as it only can load compiled code and front panels, no diagram source code.

[CoastalMaineBird]

I didn't know that .vi files can't be run using RTE.

To be clear, the RTE will not DIRECTLY load a .VI file - there is no editor to examine the panel or the diagram.

HOWEVER

It is perfectly legal to have your APP open the VI and run it.  Your App code has to find the VI file, OPEN REFERENCE to it, and RUN VI, or maybe CALL AND FORGET, or some variations.  The App can be a compiled executable without the DevSys, just the RTE.

It's possible and works just fine.....

UNTIL

The VI needs recompiling because of version issues or something.  If you try to load a 2013 VI with a 2014 App, it might need recompiling, and the executable cannot do that - there is no compiler handy.

Keep them BOTH up to date (the app and the VI) and there is no problem.

[Hasan-Baig]

Thanks for your comment Rolf

[Hasan-Baig]

Thanks for the information Coasta! 

[CoastalMaineBird]

( Brain catches up to typing hands...)

If you GENERATE the VI from the executable app, I don't think you can RUN it, even with the OPEN REFERENCE tools.

The reason is that you don't have a COMPILER.

A VI file is a CONTAINER - it contains several things:

--- The Front Panel for the VI

--- The Block Diagram for the VI (source code)

--- The Compiled Code for the VI (Object code).

--- probably other stuff (terminal listings, default values, IDK).

If you use the OPEN REFERENCE / RUN VI path, the VI in question has to have already been COMPILED.  The COMPILE process produces the compiled code part from the block diagram part.  Since an EXECUTABLE has no compiler, there is no compiled code in your VI, and it cannot be run.

[Yamaeda]

It sounds to me like it would be a better solution to create a Scripting VI. If you want this level of dynamic behaviour you can create 1 VI that interprets and runs a text-script, and/or install LabPython and generate such a script.

/Y

[Hasan-Baig]

Hi Yameda

I already had been using VI Scripting but because it is not supported in RTE, I switched to the method being discussed.

Thanks for the response. 

Regards

Hasan

[Hasan-Baig]

Hi Coastal,

Thanks for the reply.

You are right. I am doing the same i.e. opening and runing the copy of precompiled code. 

Regards

hasan

[Yamaeda]

---

@Hasan-Baig wrote:

I already had been using VI Scripting but because it is not supported in RTE, I switched to the method being discussed.

---

That was not was i meant. 🙂

I meant having a text file according to your own language, like:

"
OpenVisa(com1)
ReadVisa
CloseVisa
"

Then create a VI that interprets and runs these commands. This is a one-time development.

Since the commands are listed in a simple text file it's easy to create and run dynamically.

If you don't want to develop the script you can use LabPython for this.

/Y