VI Search Path not working in LV2011 for VI Server Plug-ins with exe

[Andrew Madry]

I have found what seems to be a problem with the search path when a LabVIEW 2011 built executable calls a Plug-in VI. 

When the plug-in VI has subVI’s from vi.lib on its diagram the executable has to know where to find them.  Not all VI’s in vi.lib are part of the run time engine or the dll’s that may get generated as part of the build. The things you have to do to make plug-ins work for an executable are explained in several Developer Zone articles.   The article titled “How Can I Change or Set the VI Search Path for LabVIEW Executables” describes the ini file setting  viSearchPath.  When this is set to the vi.lib directory I have not encountered problems with previous versions up to and including LabVIEW 2010.

I have come across an example in LabVIEW 2011 where it doesn’t work.  I have attached an example (I am using LV2011 SP1).  It demonstrates the basic plug-in architecture. Everything works in the development environment.  But it doesn’t work from a built exe.  I haven’t included the actual built exe in the zip file in case that causes a problem downloading it.  If you run the build spec from the src directory project file the exe should get generated in the bld directory.  The problem appears to occur when certain VIs from the analysis library are in the Plug-in.  In the example attached, the Plug-in VI is very simple but I have placed the troublesome SubVI on the diagram.  The VI in this example where there is a problem finding it is the Butterworth Filter VI.  I have placed it on the diagram in a conditional disable structure so it is easy to enable and disable.  When enabled and you run the test Plug-in VI the error 1003 is raised, meaning a subVI cannot be found in the dynamically called VI (for example see this post).  Note that a way round this may be to incorporate the Plug-in VI into the built exe but this shouldn't be necessary.  It’s not a problem with this specific filter VI, as it occurs for other VIs I try on the diagram.  However if you place an FFT VI on the diagram there is no problem.  I suspect that one is built into the Run-Time Engine.

I also note I am running Win7 64 bit and 32 bit LabVIEW (note the relevant viSearchPath in the ini file – you may need to change if you are on different version of Windows).  If the example is converted to LabVIEW 2010 everything works as expected for the built exe.  I tried that on a colleague’s computer running XP and 2010 but I am pretty sure in still also works on Win 7.

Things I am suspicious of are that the analysis VI’s are part of a LabVIEW library (lvlib)  and perhaps something has changed there?  I understand there is a problem with OOP in LabVIEW 2011.  Perhaps it is related to that as that seems to be an issue in 2011 (see this Discussion Forum post).  Perhaps it is related to OS version?

I also tried generating a Source Distribution to extract out all the vi.lib VI’s and place them directly in the Plug-in directory.  That didn’t help.

Interested in whether anyone else reproduces this behaviour.  In any case something is different in 2011.

[macncheese]

Hello Andrew.

First of all thank you for using National Instruments Forums.

You are right indicating that if you change Operative System then the file paths will change so that is something we always have to keep in mind.

Also, I found this document talking about how to call plug-ins dynamically.

[Andrew Madry]

Thanks for replying Mr O.  I was beginning to think no one would reply.

Yes we've checked the paths as you suggest eg so that on 64 bit windows the search path is .../Program Files (x86)/ ....

In fact now I think about it the exe does find the right place for vi.lib.  A dialog pops up briefly while the top level VI searchs for the plug-in.  Its hard to see because it only shows very briefly on fast machines other than the first time it calls the plug-in.  By running the program repeatedly I was able to see that it was searching in vi.lib as intended.

So I think its something to do with the analysis VI's I referred to and maybe something being made private or something like that.

I have seen the article you referred to in your post. I note there's a few mistakes in it (for example you are supposed to put a \* after the vi.lib according to other articles). The solution of building the plug-in into the executable isn't practical because we would have to build a special distribution for every user and they may be changing their plug-in frequently and don't necessarily want to provide their code.  

I tried creating a source distribution, because thats something the user could do and all the subVIs of the plug can be put in the same Plug-in directory.  You will see I already have a project file in the plug-in directory.  This has a build spec for a Source distribution.  For my example about half a dozen subVIs get created.  Even if you do that the Call by Reference returns the 1003 error.  I noted that the analysis VIs in question are part of a lvlib.  I tried to disconnect them from the lvlib in case that was a problem but I didn't seem to be able to do that.

So the more I think about it maybe its not a search path issue.  But something has definitely changed between LabVIEW 2010 and 2011.

[AndrewMadry]

Update on this post.  I contacted my local NI office with the issue and they have reproduced the behaviour and tell me it is being passed to NI R&D to look into it.

[macncheese]

Thank you Andrew,

I’ve being looking for information about this issue and couldn’t find any KB about this so probably we are talking about a Corrective Action Request here.

[Andrew Madry]

I found some more out about this issue working with my local NI rep here in Australia.  Apparently something has changed in the compiler between LabVIEW 2010 and 2011.  Using the viSearchPath token in the ini file, as described in various Developer Zone articles, now guarantees that the Plug-in will not work.  The only way to make it work appears to be to create a Source Distribution.  I noted in my original post that I had already tried this and it would not work.  It turns out that having the viSearchPath token in the ini file when using a Source Distribution causes the error 1003 to occur.  When the token is taken out of the ini file the Plug-in (containing an analysis VI) with a Source Distribution works - in the simple example I posted.

Well I then found its a bit more complicated than this.  It all worked for the simple example I posted.  Recall we found the error when there was an analysis VI in the Plug-in VI.  In our actual application (which is a large one) that calls Plug-ins - we still got the error 1003.  By trial and error I found a workaround.  There are certain Build Spec settings for the calling exe that I set and found worked.  On the Additional Exclusions page I found that I had to make sure that I left unchecked "Modify Project Library File after removing unused members".  I've always had trouble understanding the need for this setting.  In the Build Spec Help on that page it notes that the build will take longer.  In most builds you remove polymorphic VI instances, remove unused members of Project libraries and also Modify the project library file after removing the instances (this is a sub setting of the previous).  This makes the exe smaller in size and a quicker build time. Obviously modifying the project library caused a problem.  In the big application exe calling Plug-in, I probably have the same analysis VI on the diagram (I haven't actually checked and also whether it is the same polymorphic instance) and in the simple example I posted I definitely did not have VI in the calling exe example - so there may be some clue there.  I should try putting the same analysis VI on the calling exe diagram in the simple example to see what happens but I'm running out of energy on this one 😞

So none of this gives me much confidence and I wish I could get a better explanation from NI regarding this behaviour to be sure I am not going to encounter a different problem for different calling exe and Plug-ins.  I was advised that a CAR would be issued.  Perhaps this is now expected behaviour for 2011 but it would helpful if some definitive explanation could be given about what has changed from LV2010.  And an update of Developer Zone articles on the subject would be helpful.

[Dave-C]

Hello Andrew,

Ultimately what was going on with this program was that the files could not be found in LabVIEW 2011 like they had been in previous versions.  It appears to me as though that difference is caused by a change in the way vi.lib is stored starting in 2011.  The compiled code for the vi's has been removed and stored separately to help manage storage space, and is now stored in the VI Object Cache.  What I found from testing was that if the file hierarchy had to be changed above where the file being called was located to find the source distribution, I'd run into error 1003 when running the executable.  But, if the exe called a file from the path that the source distribution was in, I wouldn't see that error.  It is definitely an issue that took some time to wrap my head around, but like I say, I believe it has to do with the different reference method for vi.lib in LabVIEW 2011, and that this poses the solution for that referencing method.

Please feel free to ask if you have any other questions regarding this.

Regards,

Dave C 

[Andrew Madry]

Thanks for looking into this Dave C.  There's still one thing I don't understand.  I noted in my reply above that I had to ensure that I unchecked "Modify Project Library File after removing unused members" in the build spec of the calling exe - not in the example I posted but in a larger application exe using the plug-in method. Can you shed any light on this?  Does this "modifying the project library file" (presumably the lvib that references the VI that has now found its way to the VI Object cache) cause things to break in certain circumstances?

It seems important to understand what configuration will allow us to guarantee that the Plug-in architecture will work.