LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem executing dynamically loaded plug-in .vi's from .exe in run-time environment.

I have a LV 8.0.1 application that's built into an EXE targeted for a LV Run-time environment. The app uses a dynamic plug-in architecture where at startup it sniffs a folder for .vi files and opens and runs them. This design is needed because I want to be able to add .vi plug-ins at a later date without recompiling/redistributing the main application.

The application works fine unbuilt and also works fine built into an EXE and running on the development machine. However, it breaks when I deploy to my test machine which only has the LV Run-Time engine loaded. In the Run-Time environment, the main .exe works fine but the plug-ins will not start. I've investigated this quite a bit and the vi's appear to refuse to start because they cannot resolve the location of any of the LabVIEW library vi's referenced from the plug-in vi's. For example, if I create a simple plug-in vi that make's a reference to LabVIEW's mathematical "Mean.vi", this will not run. If I remove Mean.vi it will work fine.

I've setup "my_app_name.ini" with:
[LVRT]
DLLPath=C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\8.0

This seems to be required to get the main EXE to execute, but doesn't seem to have any affect on the dynamically loaded vi's.

Does anyone have any ideas on how I can tell the plug-ins where to find the LV Run-Time library?

Thanks in advance,

Mike Teixeira
Unaxis USA, Inc.
0 Kudos
Message 1 of 16
(5,935 Views)
The run-time engine does not contain everything you could possibly need to run a program. For example, it does not include hardware drivers such as NI-DAQ or NI-GPIB. It also doesn't include some DLLs that you need for this application - namely lvanyls.dll. When you call the Mean VI normally in an application, the installer will include this dll in the Data folder. You can add the DLL as a support file when you do the build for the main application.
0 Kudos
Message 2 of 16
(5,934 Views)
I had already tried copying the lvanyls.dll (amongst others) to both the plug-in folder and the main app's folder, but this didn't work.

I will try what you suggest and add the lvanyls.dll as a support file in the build. I hope this works!

Thanks for the suggestion.

Mike
0 Kudos
Message 3 of 16
(5,923 Views)
Well, I've tried every variation I could think of and still can't get this working. I've included lvanlys.dll as a Support File in the build spec, I've copied the DLL manually to every folder of interest on the target computer and still no luck. The plug-in VI's simply refuse to run.

Has anyone actually succeeded getting this type of architecture to work with LV8?
0 Kudos
Message 4 of 16
(5,900 Views)
Hi Mike,

I've been working on a method that I hope should work for this application. I haven't been able to test it on a computer that doesn't have the LabVIEW development system installed, but I have come across the same type of missing VIs errors that you experienced in some of my earlier tries, so I hope this will resolve them.

What I would suggest to you is to build your dataplugin VIs into executable packages, even if you don't intend to ever double click and launch those executables. The idea is that by building them into that type of package, LabVIEW will package them with all the DLLs and subVIs they require to run. Then you can launch the VIs by opening references to them at directories like myapp.exe\myVI.vi or whatever. You can also use the List Directory advanced file function to search for VIs in the myapp.exe directory.

The only problem here is that you'll not only find the dataplugin VIs you want with that method, but also all their subVIs. It might be difficult to separate the few VIs you do want from the dozens of subVIs you don't want to open references to and launch. So I have a solution for that too.

My first idea was to build the executable, but include the dataplugin VIs of interest in the destination directory instead of the exe package itself. This sort of works. Although this makes it easy to find the VIs of interest, when you open up a reference to the VIs and open their front panels, the run-time engine will have to search for the subVIs which are contained in the exe. Since they're all in the same folder, they will be found, but you'll see that searching dialog which pretty much strikes this as a possibility.

Instead, the better option is to include all your dataplugin VIs in one or more Project Libraries. Then include the whole Project Library under Startup Vis in your build spec. When you build the package, LabVIEW will include all the necessary subVIs and DLLs, as well as the .lvlib file itself that contains the names and paths of the relevant dataplugin subVIs. Your app that calls the dataplugins could then search the exe file for *lvlib files (or better yet, give them some sort of identifiable name to distinguish them, like DataPlugin*.lvlib), open references to the Project Libraries, and then derive the VI references from there.

I know this might be a lot to take in, but the end result is a rather robust solution to the problem, where all the linking requirements are taken care of. It also provides a rather easy way to package your dataplugins. Just throw them all in a Project Library called DataPlugin*.lvlib or whatever, then build the whole thing with the library set as the Startup VI.

I'll attach an example below. Again, I haven't tested this on a non-LV machine, but I can only imagine it would work, since at that point the exe file with the dataplugins should be completely self-sufficient. Let me know how this works out, or if you have any advice to improve on this!

Just unzip the dataplugins zip file. That contains the project with the library with the plugins and the correct build spec. Build that exe, then take a look at Caller.vi, which searches through the exe for Data*.lvlib files and opens references to all its VIs. Hope this helps!

Jarrod S.
National Instruments
Download All
0 Kudos
Message 5 of 16
(5,888 Views)
Hi Jarrod,

I worked with your idea to build an .EXE out of the plug-in today. I decided to name the EXE the same as the main VI to simplify finding the VI within it.

I created a simple test plug-in named "Mean Test.exe" with the main VI inside named "Mean Test.vi". This VI just had two LV library calls within it. One to "Mean.vi" and the other to "Mean PtByPt.vi". I added the call to the PtByPt version in there to see how it would work with a VI that wasn't implemented via an external DLL (eg. lvanlys.dll).

Sure enough, it worked fine on my development system but the VI broke again on the Run-Time target machine. The error was indicated as:

"Missing subVI NI_AALBase.lvlib:Mean.vi in VI Mean Test.vi"

I iterated through all of the VIs embedded within the EXE to verify that Mean.vi was in there. It is, so this message is a little misleading. Perhaps LV prints this if the VI is having trouble locating its associated DLL?

Here are the contents of "Mean Test.exe" using the "List Folder" function:

Mean PtByPt.vi
Mean Test.vi
Mean.vi
NI_AALBase.lvlib
NI_PtbyPt.lvlib

Note that the "Mean PtByPt.vi" had no problems but "Mean.vi" did. Apparently the external DLL tripped it up again. When I built "Mean Test.exe", it detected that lvanlys.dll would be needed and put it in the "data" folder. I copied the "data" folder to both places on the target machine where I thought it might look for the dll. These were the folder that "Mean Test.exe" lives in and the folder that the main application (that loads the plug-ins) lives in.

None of this works. I thought that maybe the absolute path to the DLL on the development machine might be being stored in the EXE. To test this I put the DLL on the target machine at that location with no luck. I also put the DLL in the windows and windows\system32 folders as a last resort.

Do you see anything that I'm doing wrong?

Mike
0 Kudos
Message 6 of 16
(5,872 Views)

Hi Mike,

I had some DLL path troubles in distributed/plug-in environment - you might try this:

Close/Open LabVIEW so it will "forget" any DLLs it was using.  Hide the Mean DLL on the development station so that you're prompted to find it when Mean is loaded (if you're not prompted, you haven't hidden the DLL it's using).  Relocate the DLL (on the development station) to the same path/location where the DLL will be on the Target station and point Mean to the new location.  Then, compile and distribut the app!

May the force be with you (that is, good luck!).  Smiley Happy

Message Edited by Dynamik on 05-12-2006 03:28 PM

Message Edited by Dynamik on 05-12-2006 03:30 PM

When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 7 of 16
(5,870 Views)
Hi Dynamik,

Thanks for the suggestion. Here's what I tried:

I hid the LabVIEW DLL and put a copy of it in a folder on my dev machine called C:\Program Files\My Application. I then opened my plug-in VI and when it asked for the location I told it the new one. I then compiled my plug-in VI into an EXE as described in my prev post.

On the target machine I put the DLL in the C:\Program Files\My Application folder. I also copied the new version of my plug-in EXE over.

This had exactly the same result as before. No luck. It complains with exactly the same error.

Have you had success with this method in LV8 or was it with a previous version?

Thanks!

Mike
0 Kudos
Message 8 of 16
(5,847 Views)
Hi Mike,

This issue seems to go a little deeper than I first presumed. It turns out this is a known issue that has been reported to R&D for further investigation. The problem seems to be that when you build your source distribution, you are packaging the necessary subVIs from vi.lib with the distribution. Many of these VIs are contained in project libraries. When LabVIEW builds the source distribution, it includes the project library file with the distribution, but only an abridged copy of it. In other words, it edits the project library to only include the vi.lib subVIs that you are including in the build.

The conflict comes about when one of these abridged project libraries is first loaded into memory, and then another VI that is normally in that project library, but is not in this particular abridged copy tries to get loaded. Project libraries have two-way binding, meaning the library knows what VIs it owns and the VI knows which library it belongs to (if any). If you have two abridged copies of the project library and one is already loaded into memory, then LabVIEW won't try to load the second copy. This causes a problem when a VI claims to belong to a certain library that doesn't claim it in return.

There is a way to work around this issue, but it will involve including the entire library in your source distribution build, even if you only plan to use some of the VIs. Try these steps to work around this issue:

1. Refresh your dependencies before starting your build.
2. Locate the NI_AALBase.lvlib file under Dependencies and drag it from your dependencies to your Project.
3. Include the library in your source distribution. Make sure the setting for the included items is "Always Include".

Then when you build your source distribution, you will always be using complete copies of your project libraries. Let me know if this works. This should let you use a plugin architecture without using the exe idea I suggested earlier. I hope this helps!

Jarrod S.
National Instruments
0 Kudos
Message 9 of 16
(5,844 Views)
Hi Jarrod,

Unfortunately, I'm still floundering. I've tried to implement your workaround and haven't succeeded.

My main application does not make any calls into the NI_AALBase.lvlib so it was not included as a dependency. To make trying your scenario easier, I dropped a Mean.vi onto my block diagram to force the dependency. I then moved the NI_AALBase.lvlib from the Dependencies section to the main section of the project (see enclosed Project.bmp).

I rebuilt the EXE. Then I adjusted my Source Distribution to force NI_AALBase.lvlib to be included (see Source Dist.bmp).

I only saw one reference in the collection of distribution files to NI_AALBase and it was a file called NI_AALBAse.lvlib which was only 1k in size (see Files.bmp). The standard file in vi.lib is 26k. My EXE file didn't grow so I don't think the VI's from the library are being embedded within it.

Attempting to run this distribution on the target machine produces three error dialog boxes:

"LabVIEW: Generic error.
The file 'lvanlys.dll' is not a valid LabVIEW file."

then:

"LabVIEW: Resource not found.
An error occurred loading VI 'NI_AALBase.lvlib:Mean.vi'
LabVIEW load error code 3: Could not load front panel."

then:

"Missing subVI NI_AALBase.lvlib:Mean.vi in VI EPW.vi."

After this, my main VI will not even run and shows the broken "list errors" arrow.

Is there anything obvious to you that I did wrong with your workaround?

Mike
Download All
0 Kudos
Message 10 of 16
(5,821 Views)