External library not being packaged when saving with options

[Randall_T]

Hi I am getting the following error when I save my application with options to a single location including all vi.llb's, external code, and runtime menus.  Actually I first get the file dialog which ask for this dll. I browse to the location and load it.

Earlier I was saving this application using the same procedure and it worked fine. I expected the dll to be included in the llb file. The expected path is very simular to the actual path.

Mean.vi
  Virtual Instrument
    - The external library expected to be at "Program Files:\National Instruments\LabVIEW 7.1\resource\lvanlys.dll" was loaded from "C:\Program Files\National Instruments\LabVIEW 7.1\resource\lvanlys.dll".

Any suggestions?

[Travis_M.]

Hello Randall,

Is this dialogue causing an error or is it announcing that it is loading a primitive function from a new location?  If you continue with running your VI after the prompt, are you still able to run the VI as usual?  The VI which is causing the problem is a primitive -- these functions are not saved in with the application distribution.  If you execute the VI on a different computer the functions must be reloaded and you can get this dialogue.

I hope this helps!  Please let me know if this problem is interfering with the execution of your program or if you have additional questions.

[Randall_T]

Thanks for your reply. My posting left out some important information such as this is LabVIEW 7.1 running on Windows 2000 and XP. In desperation in order to get this going before the holiday I wrote around the mean function. I would like to resolve the issue though.

If the wiring diagrams are removed the application will not run on the new machines. With the diagrams and if the other machine has the development version you can point to the dll and the program will run it. My target machines only have a LabVIEW runtime installed so the application is broken.

During early stages of development this was working correctly. I saved the application with options, included the external calls, menus, and vi library. sent it to a separate location with a single prompt. This would go into a vi library file.  When placed on a target machine with the run time installed it functioned correctly. (The mean.vi was in use and functioned correctly.)  After a few modifications to the program this quit working. The modifications did not have anything to do with the portion of code that calls the mean.vi.  I suspect I could place the dll in question into the resource folder to correct the problem but this started out working correctly and I thought it was included when the mean.vi was saved into the library.

If I understand your reply, the dll should be part of the runtime installation and loads when the application calls for it. If that is true the dll might not be the same build as on my development machine or perhaps the mean.vi is calling a different dll than it originally was. The only way I can see this happening is if I managed to have a vi opened that was calling the same dll from a different location and accidentallysaved some of my vi library linking to the wrong location. (Could this happen?)

[Travis_M.]

Hello Randall,

First, to give a little bit of background here for you or other readers of this thread I’ll explain a little about the inner workings of LabVIEW.  First, there are several different components of each LabVIEW VI -- 3 of which concern us – the front panel, block diagram, and the code.  The code is generated by the LabVIEW compiler from the block diagram, but the block diagram is not needed to execute the VI once the code has been generated.  Without the block diagram the code cannot be altered, but the code can be executed on any system with the Runtime engine or the LabVIEW development system (which incidentally includes the runtime engine).  It is also the case that if something has changed on your system (say a sub VI is missing, or a call library node can no longer find a DLL) LabVIEW attempts to search for a missing VI and replace the old instance with an instance of the moved VI or DLL.  For these reasons, if you have a VI with the block diagram removed, and LabVIEW needs to modify the code, it will be unable to do so.

Additionally, there are several different levels of VIs that LabVIEW provides the user.  One is the primitive “function” VIs such as the add, divide, etc…  The other extreme is the fully developed VIs that come with LabVIEW (such as the express VIs, the toolkit VIs, etc…).  These VIs all have block diagrams attached that you can open, view, and modify (redistributing these is of course copyright infringement).  The other type is a basic VI (which generally come from vi.lib) such as the Mean VI which has a block diagram that does nothing more than make a call to a DLL included somewhere in the LabVIEW directory structure.  When you make a development distribution you can choose whether or not to include these since they can be loaded from a machine with the runtime engine.  A development distribution creates a .lib of your VIs – Vis and only VIs are included in this (i.e. no DLL ever is put in a lib file).

To address this specific problem, it is possible that the location of the lvanlysis dll has been modified on your development machine leading to the problems on your client machines.  From your first post, you are getting a dialogue which suggesting that the DLL was originally located at "Program Files:\National Instruments\LabVIEW 7.1\resource\lvanlys.dll".  I have not seen any sort of directory of the format “Program Files:\” so I suspect that this might be the case (the normal directory is the one it loads from in the second part C:\Program Files\National Instruments\LabVIEW 7.1\resource\lvanlys.dll".

I would suggest that you open the Mean VI and open its block diagram.  Double-click the Call Library Function node and make sure that it has the proper directory (see the attached screen-shot).

Hopefully this will fix the problem or shed some more light on it.  Please keep me posted on how things go!

Message Edited by Travis M. on 11-30-2005 12:53 PM

[Randall_T]

Thanks for your excellent reply. The dll location is the same on my machine as your screenshot. The originall dialog showing "Program Files:\...." bothered me at the time I did not notice the ":"  I just thought the C:\ was left off in the dialog. It looks like this might be the issue.  I will try this again when time permits and let you know.

Thanks again for the information.

Randall