Leaderboard

Tim, Sorry I took me a while to respond to this after I said I would in that other thread. Ok, so the other thread mentions that in general if you have an EXE that has plugins, the EXE needs to have everything it needs to run and each plugin should have everything it needs to run, in case the EXE changes or some of the plugins aren't in memory. So that should be it for the 1003 error, right? Well there is new way in LabVIEW 8.0 that you can end up with a 1003 error on your plugin VIs if they use VIs from Project Libraries and your EXE uses VIs from the same project Library. You mentioned Mean.vi which is probably one of the VIs that is broken in your plugin and it is part of a Project Library. Also you probably don't have any of your user.lib VIs in Project Libraries, so that is why you are seeing a difference. The other way to get this 1003 error is by trying to have 2 Project Libraries of the same name in memory at the same time. This doesn't happen in the development environment because there is only one copy of each Project Library. However in an EXE with plugins, where the plugins were built separately from the EXE (Method B from the other post) you can end up with a copy of the .lvlib in the exe and another copy in one or more of the plugins. This seems harmless since the first one in memory is the one that is used (just like VIs), but during the build process we remove unused members of the Project Library in the EXE. And since a VI knows which Project Library it is a member of and a Project Library knows its members. So if the Project Library is already in memory and a VI is loaded that says it is part of the Project Libary, but the Project Library doesn't think the VI is part of it, then the VI will be broken. I think this why you are seeing the 1003 but it works when you load the vi.lib VIs from vi.lib since in there is only one copy of the Project Libraries being used and no references have been removed from them. Lets take a specific example where you are using some of the Analysis VIs and the EXE only uses Histogram.vi and the plugin only uses FIR.vi (I got a CAR on this last week and wrote a long explanation that I'll copy and paste): When the exe is built it includes NI_AALBase.lvlib and Histogram.vi in the exe, since Histogram is the only item in NI_AALBase.lvlib used by the exe, App Builder by default removes all the other references that NI_AALBase.lvib has. The new copy of NI_AALBase.lvlib inside the exe is essentially a Project Library with one item referenced in it (there may be some subVIs if Histogram has any that are part of the .lvlib). When the Source Distribution is built the new copy of NI_AALBase.lvlib inside the source distribution has all its references by default because Source Distributions keep them. Even if you trimmed it down in the Build Specification it would only have a reference to FIR.vi which wouldn't be helpful either. As I said, a VI knows what .lvlib it is a member of and a .lvlib knows what VIs are part of it. So when the EXE is launched it loads the EXE's copy of NI_AALBase.lvlib into memory. Then the EXE is calling the Source Distribution as a plugin so the VI being called tries to load FIR.vi which knows it is part of NI_AALBase.lvlib, well that is already in memory, so the Run-Time Engine can't load the source dist copy of NI_AALBase.lvlib because a library of the same name is already in memory (so it doesn't matter what links that copy contains). But the copy of NI_AALBase.lvlib in memory reports it doesn't have FIR.vi as a member of it (remember the EXE copy only has a link to Histogram.vi). So FIR.vi is broken because its owning .lvlib isn't found. The removal of non-essential items is basically a size optimization, so what can be done? Well, not be optimized, by including the entire Project Library into the EXE and the source distribution. That way the 2 new copies of NI_AALBase.lvlib will have links to all the items in it, so the first one loaded will respect everything else. Either 1) move the NI_AALBase.lvlib out of dependencies into the tree with the rest of your source and include it as a Dynamic VI in the EXE build and Always Include it and its sub items in the Source Distribution. There will still be 2 copies of NI_AALBase.lvlib but they both contain links to all of the items in the Project Library, therefore which ever one loads first, it won't prevent other VIs from running. Also all the items directly referenced by NI_AALBase.lvlib and their dependencies will be included. Or 2) Uncheck "Disconnect Type Definitions and Remove unused Polymorphic VI instances", that also removes unused .lvlib components if it is checked (maybe we should make those separate options). This will cause all the contents of NI_AALBase.lvlib to be included and the contents of all the .lvlibs it links to. Since NI_AALBase.lvlib contains VIs that have references into NI_AALPro.lvlib, all of it and its dependencies will be included, even if they aren't used by the code. So this can get very big and I wouldn't recommend it (for .lvlibs without circular links, this would be okay). With method 1 you could also build the .lvlibs and the files referenced by them and their dependencies into the same location on disk. That there would only be one copy and each build would overwrite it. I have some thoughts on how to make this better for future versions of App Builder/LabVIEW, but right now it only takes what you tell it you need or it takes it all. Kennon