LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI scripting functions in a built application (EXE)

Solved!
Go to solution

Hello everyone,

 

I am trying to build a LV application (.exe file) that can create VIs. However I found out the hard way that it does not work, and also came up with a similar problem on this forum (https://forums.ni.com/t5/LabVIEW-APIs-Discussions/scripting-in-EXE/td-p/3416747?profile.language=en). 


I also found this page  that mentions some VI scripting methods are not available in built applications.

 

However the post is from 2009 and it mentions a solution that does not seem valid anymore, as I could not find any recent resource about this "full feature run time engine".

I need to mention that in the end, my motivation to have a built application is more for the "cleanliness" of it and the fact that it's all locked with no possibility for the end user to mess it up. My users will have the LabVIEW Development suite anyway, so I am not in the case mentioned in the forum (use of the RTE to create VIs like one would do with LabVIEW).

 

Is there a workaround to use VI scripting in EXE? If not, is there a way to reach the same result without using the "blocked" VIs?

 

Thanks!

0 Kudos
Message 1 of 7
(3,656 Views)

I believe the full featured runtime engine is only available with the LabVIEW DSC module, and is not intended to support the use case you're describing.

 

You can remove the diagrams from your code, the easiest way to do this is to build a Source Distribution and specify that you want diagrams removed. You can also password-protect your code, but removed diagrams is the absolute most secure mechanism to keep people from viewing source code in your distribution.

Message 2 of 7
(3,635 Views)

If the development environment is present, I guess you should technically be able to open an application instance to the development system, and do the scripting in your executable on the application instance. I'm not sure to which extend this should or will work. This might be something Vision Assistant does, but I never investigated.

 

The 'normal' way is to 'script' the behavior by programming it.

 

As also suggested by AristosQueue here: It would depend quite a bit on the behavior you are trying to script. You can make formula parsers, script engines, even Python or Lua plug-ins, user events executed in sequences... The sky is the limit once you go that route, but in an executable making VIs with LabVIEW scripting is not possible.

0 Kudos
Message 3 of 7
(3,629 Views)

Do keep in mind that if you want to run VIs in your executable, you cannot separate compiled code! I'm not sure if a source distribution will force compiled code, but my guess is it won't (as it is source you're distributing).

 

The RTE cannot compile the VIs, so the VIs should contain the compiled code (in a compatible version).

 

A plug-in scheme like this will usually grow towards packed libraries.

0 Kudos
Message 4 of 7
(3,620 Views)

Thanks a lot for your answers! To complete my problem and answer some of your questions:


wiebe@CARYA wrote:

I guess you should technically be able to open an application instance to the development system


It's not really clear to me what this means and how to do it. I'm pretty new with building applications, so I have never done this.


wiebe@CARYA wrote:

The 'normal' way is to 'script' the behavior by programming it.


Again I don't really understand the difference between "scripting" and "programming" in this situation. To be more precise, what I want to do with "scripting":

-My application will be sort of a test/task sequencer. The user will be able to create a new test with a click of a button.

-A new test is composed of a class holding all relevant data, and is composed of several steps (separate VIs)

-I want to create (by scripting) the class and add some attributes to it, and create empty VIs for each step with Class IN/OUT, error IN/OUT, and most likely bundle/unbundle class or In Place Element structure.

 

Hope it makes more sense with these explanations. I will investigate the Source Distribution and packed library because I have never worked with these, so it may be an interesting alternative as you suggested.

0 Kudos
Message 5 of 7
(3,345 Views)

@seb_bd wrote:

Thanks a lot for your answers! To complete my problem and answer some of your questions:


wiebe@CARYA wrote:

I guess you should technically be able to open an application instance to the development system


It's not really clear to me what this means and how to do it. I'm pretty new with building applications, so I have never done this.



It won't be easy.

 

You can make the executable open an application reference to LabVIEW development environment. Than you can /maybe/ invoke the scripting stuff from your executable in the development environment.

 

I'm not sure if that will work. I'm sure it will be troublesome. You'd be on your own for the most part, as it's pretty exotic.

Message 6 of 7
(3,276 Views)
Solution
Accepted by topic author seb_bd

@seb_bd wrote:

wiebe@CARYA wrote:

The 'normal' way is to 'script' the behavior by programming it.


Again I don't really understand the difference between "scripting" and "programming" in this situation. To be more precise, what I want to do with "scripting":


With scripting, you'd be making a LabVIEW program that does stuff.

 

When you program this, you make your program do the stuff, based on a 'script' that the program understands.

 


@seb_bd wrote:

-My application will be sort of a test/task sequencer. The user will be able to create a new test with a click of a button.


You can program a test\task sequencer!

 

If you put the test\tasks in a sequence in a file for instance, the program can read the file and per test\step execute a VI accordingly.

 

@seb_bd wrote:

-A new test is composed of a class holding all relevant data, and is composed of several steps (separate VIs)

So in the programmed sequencer, a test is holding the relevant data, and your programmed sequencer executes the build in VIs. If you want a step\task that is not provided by your sequencer, you'll have to make it. But if you make the build-in step\tasks primitive enough, you should be able to do everything a VI can do.

 

@seb_bd wrote:

-I want to create (by scripting) the class and add some attributes to it, and create empty VIs for each step with Class IN/OUT, error IN/OUT, and most likely bundle/unbundle class or In Place Element structure.

Yes. But that is not possible within an executable.

 

If you have a script that builds a VI, you should be able to make a VI that results in the same execution result based on input conditions. So, don't make a VI based on options, but execute a VI that uses the options.

 

A VI could get complex, but with OO it will be easier. You can make a VI that executes given 'content'. The content can be a class\object. The class is a parent of a class hierarchy. The children can implement all the options you ever want to execute. Each class can have it's own merits (initialization).

 

Then you'll have a 'programmable' VI that executes whatever you want. Scripting, without LabVIEW scripting.

 

@seb_bd wrote:

Hope it makes more sense with these explanations. I will investigate the Source Distribution and packed library because I have never worked with these, so it may be an interesting alternative as you suggested.

That would completely avoid the problem...

Message 7 of 7
(3,270 Views)