calling compiled subroutines (solved?)

[Robert.Bedford]

I would like to programmatically call (load and unload) subroutines from a VI.  There must be a way to do it, but I haven't quite figured it out.

First the scenario:
ABSTRACT SCENARIO: I have a LabView VI that will end up being compiled into an EXE.  In this VI, I have a file list (Array) of which I will pick one file each pointing to a VI.  I plan on using a Menu Ring that selects one of the options from the file list and then runs the corresponding VI.  I would like to be able to add or remove VIs from the list.  Furthermore, I would like to be able to change this so each file in the list points to a compiled function (maybe a dll?). 
SPECIFIC SCENARIO: I have a measurement program that controls (adjusts settings/returns readings) external equipment.  I would like to be able to change the piece of equipment and simply change a measurement subroutine so that I can "drop in" different modules for each power meter, using the same main program.  I would like to programmatically load and unload these depending on usage.  After compilation of the main program, I would like to be able to add/change/remove subroutines to accommodate different equipment.


When I compile the main program, if I compile the supporting VIs, I am no longer calling VIs.  If I don't compile the supporting VIs,  then I am running uncompiled code from compiled code (not very efficient).  I believe the way to do this is to actively load and unload dlls but I can't seem to do this programmatically (i.e. define what dll to call based on a file string).  The only dll calls seem to be "Call Library Function Node" and "Code Interface Node" each which must be linked to a dll a priori.

I thank anyone sincerely for their feedback.

[TiTou]

Hello Bob,

They are 3 points, I think, you may concider :

1. Compiling your VI won't improve the performances a lot. I would say a few percent, depeding on your application of course. But you souldn't count on this.

2. When you compile your code, all your sub VIs are put in the same "container", so you hard-coded the paths to the VIs you want to load dinamically then they won't work anymore when the code is compiled (i.g. if you use "current VI path" + "strip path" functions you'll  need one more strip path to make the compiled programe to work).

3. It is of course possible (and not really hard) to laod a VI dynamicaly from its path. Again to di this 2 possibilities :
  3.1 You need to pass inputs to this vi :
       use the "open VI reference", linking the correct vi path, then use a "call by reference node" both available in the "Application control" tool palette
  3.2 This vi doesn't need input, it is autonom :
       use the "open VI reference", linking the correct vi path, then use a invoke node.

Hope this answer your questions, if you need further help I might be able to find some VIs in LabVIEW 6.1 or 7.1 to give you a way through these 3 points.

[Robert.Bedford]

Hello TiTou,

I appreciate your quick attention.  I have a few more specifics (plus an attachment to boot).

I simply assumed compiling the VI would make significant improvements.  However the computer I am running it on does not have LV.  I just assumed the "open VI reference" would not work on a computer that does not have LV on it.  I just checked it, and it does indeed work.  I have attached a small example (both compiled and uncompiled). The compiled version is using 7.1 engine.

So, TiTou, I think this will be the tack I take.  While my main file will be compiled, the subroutines will remain uncompiled VIs.  I think this should work fairly well, even if the computer I run it on does not have LabView.  If you (or anyone else) have any further comments on other methods to accomplish this task, I would be curious to hear them.

Message Edited by Robert.Bedford on 09-09-2005 03:49 PM

[LV_Pro]

A few points of my own. If, when you say compile, you mean build an ".exe" that is really "building an application", which takes the vi's in your program, essentially builds them into a ".llb" type file, removing diagrams and front panels from all but those that display user interfaces at runtime. When you run the resulting .exe file it is loaded by LabVIEW, the runtime engine version if the development system isn't installed, and I believe compiled at that time. When you run a VI during development, the time delay before running the first time is LabVIEW compiling the code. If you stop the VI and rerun it you will see that it starts running much more quickly the next time.

You can build a structure that dynamically loads called vi's. Depending on the complexity of the called "plugin" there may be a delay before it executes, but it should be pretty brief, partly time to read it from disk, partly to compile the vi's code. I'm pretty sure that subsequent calls to that vi will be essentially instantaneous. Attached is a snip from some of my code that preloads the names and filepathes of vi's that may be run into two arrays and then when a specific vi name is called indexes the filepath based on the name. The VI plugins have to meet the criteria of having identical connector panes in this application, so you would need to develope an architecture that allows that.

P.M.

Message Edited by LV_Pro on 09-09-2005 04:58 PM

[johnsold]

Robert,

One point. All LabVIEW VIs are compiled (at least since the very earliest versions). If a VI has a broken Run Arrow, then it cannot be compiled and will not execute. When you execute a VI from within the LV development environment you are executing compiled code. When you create an executable, the LabVIEW Run-Time Engine as well as the VIs are put into a library. The Run-Time Engine executes the VI code. It can be confusing, and I am not sure I have explained it completely accurately.

Lynn

[Robert.Bedford]

Well it is quite obvious that my definitions were off.  When I say "compile', I was indeed referring to building an application (i.e. an executable .EXE).

But hmm... I am a bit curious what you mean when you (LV_Pro) say "building an application" is essentially building a ".llb" type file.  I had always treated llb files somewhat like zip (or more appropriately tar) files in as much as it is a file containing multiple VIs.  If I have two, unrelated VIs in an llb, I am unclear as to whether they are all loaded into memory when I open one of them.  Can you elaborate more on this?

Thanks for your help (Titou, Johnsold, and LVPro)

cheers.