LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Missing subvi from ni_aalbase.lvlib

I have a data acquistion program that can record data from various equipments attached to the computer. For each equipment, there is separate code written in Labview to communicate with it and send data to the main program (using queues). I want to be able to add more equipments ("modules") after I have distributed the main program to all the users. A good way to do this, I thought, is to build source distribution of each module and put it in a certain folder (named "Modules") of the main program. The program automatically gets a list of available modules at startup.

 

I guess eventually I will build an installer for the main program, but for now I just want to copy the built executable to different computers (with Labview run-time already installed on them). As for the modules: If I want to change or add a module, I just want to copy the newest source distribution of that module into the "Modules" folder of the main program.

 

I can try building an installer for each module but then I am not sure if I'll be able to use shared queues without using VI Server. This installer probably also adds a lot of unnecessary files that should be availble on a computer with Labview run-time anyway (PS: Are Signal processing VIs included in Labview run-time?). I want to keep the module size to minimum.

 

I am getting similar problem with another module that uses VISA functions. VISA functions are also available under vi.lib.

 

 

 

Message Edited by abdel2 on 12-03-2009 06:34 PM
0 Kudos
Message 11 of 22
(2,475 Views)

Hi,

 

I think the easiest way to do this is to actually call the executable you have built from a common top level VI.  To do this, you can use the System Executable VI.  How Do I Run an Executable or External File from within LabVIEW details how to do this. 

 

Additionally, I've attached an example that I've worked up that will call an executable when you run the VI.  The CalledVI contains a VI from that Signal Processing VI that you were concerned about.  

 

You can configure the CallerVI to keep the File Dialog as it has now so the user can browse to the executable, or you can hard code it in there for various modules.  If you wanted to get fancy, you could have the VI programmatically check what is in the "Modules" folder using the List Folder Contents VI, and then give the System Exec that executable name.  

 

Cheers,

 

 

Marti C
Applications Engineer
National Instruments
NI Medical
0 Kudos
Message 12 of 22
(2,455 Views)

Thank you The Chancenator.

It looks like the executable method works great when it comes to include all the required subvis. However, it doesn't seem like I'll be able to share queues using this method because CalledVI application is not part of the caller vi application. If I just run one of the vis that is embeded in the calledVI application, then I would be able to share data between the main application and the module. The problem is that I cannot do this in Labview 8.3 or higher(http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C).

 

Right now, the easiest method seems to be one that involves calling the VI directly from the main application. This also makes it easier for me to call multiple vis of the same module. I want to run one vi so the user can change module settings, and the vi will acquire data when called.

 

 

As for the dialog box: I just included it to show all the steps properly. In reality, I'm looking for a .ini file in each module folder. This file has the exact name of the vi that is to be called for running the module.

0 Kudos
Message 13 of 22
(2,446 Views)

Hi,

 

There are a few default settings when building an executable that you should be aware of.  First, in the Additional Exclusions category there is an option "Remove unused members of project libraries" that is checked by default.  This will go through whatever libraries included and remove members that are not called--that is, any VI that you are not using in the executable from this AAL Base and AAL Pro library will be excluded.  If you would like to include all of the VI's in a library, leave this unchecked.  However, as you know, these Advanced Analysis Libraries are large and are not a part of the LabVIEW runtime engine.  

 

When you are dynamically calling a VI in an executable, its dependencies in that AAL library will still be removed since its not being called staticly (i.e., just placed on the block diagram). in that executable. If you still wanted to do this modularly, I could see it working if you knew all of the Advanced Analysis VI's that you would be using and placed them in a diagram disable structure in the top executable. 

 

I hope this clears things up. 

 

Cheers, 

Marti C
Applications Engineer
National Instruments
NI Medical
0 Kudos
Message 14 of 22
(2,438 Views)

 

I think I used the "remove unused members" option before but the source distribution size was still large. I'll try it again to make sure though.

 

Putting all the "important" vis that any module might use in the main executable is a good idea, actually. However, I have two main questions:

 

1) If I call a VI dynamically then all its dependencies will be included in the distribution as long as the VI is included in "Always Include" list, right?

 

2) Can I find out exactly which vis from vi.lib and instr.lib are included in Labview run-time, so I don't have to include them in the source distribution or the top-level executable? I can already see that Advanced Signal Analysis library is not included.

 

Thanks

0 Kudos
Message 15 of 22
(2,416 Views)

Hi,

 

As long as you include the VI's in the "Always Included" it is my understanding that their dependencies should be included.  I've searched around for a list of which VI's are included in the RunTime Engine without much luck.  I'll let you know if I am able to find any more information on this. 

 

While you are not getting this error, Error 1003 When Using VI Server in a LabVIEW Application is a helpful article for this issue. 

 

Cheers, 

Marti C
Applications Engineer
National Instruments
NI Medical
0 Kudos
Message 16 of 22
(2,402 Views)

Thanks again for all your help.

 

I have been able to run everything properly in the executable by using the following options for each module's source distribution:

 

 Remove unused polymorphic VI instances: checked

 Remove unused members of project libraries: checked

 Exclude files from vi.lib: unchecked

 Exclude files from instr.lib: unchecked

 Exclude files from user.lib: unchecked

 

 

I am also creating a llb file to put everything in one package (reduces copying time). The distribution size is not as bad as I thought it would be (< 4 MB each).

Now there is a problem in the development environment sometimes after I run the executable. The attached image pretty much explains it. I guess NI_AALBase.lvlib was already loaded from the source distribution somehow and when I opened another project that uses NI_AALBase.lvlib, it points to this loaded library rather the original one that is installed in the Labview folder. I tried mass compiling but that didn't work. Is there any way to fix this cross-linking and prevent it in the future?

 

0 Kudos
Message 17 of 22
(2,355 Views)

Hi,

 

If you click on File, is there a resolve conflicts option?  Also, will the computes that are running the executable have LabVIEW (we wouldn't want this happen to your users).  Are you running the exe while LV is open, and if so, do you see the same performance when you run the exe when LV is closed, then finish the exe, then open LV.  I'm thinking that maybe the dependencies will then reset to their defaults. 

 

Marti C
Applications Engineer
National Instruments
NI Medical
0 Kudos
Message 18 of 22
(2,342 Views)

Hi,

I have VI using the RMS.vi and the Median.vi from NI_AALBase.lvlib and NI_AALPro.lvlib. The program runs well, when I try to build an executable and run it on another computer a failure message tells me that the SubVIs are missing. Both are not called dynamicly. I tried to add them, but I did not figure out how, only the main vi is shown.

0 Kudos
Message 19 of 22
(1,756 Views)

Even when I use the option to always add the RMS.vi, the program reports the failure.

0 Kudos
Message 20 of 22
(1,750 Views)