LabVIEW
Making a exe file which is calling a vi from library which is external to exe file project
You are likely building your path to the llb file wrong. Since you are looking for something outside of the executable, use Application Directory as the basis of building the path. When in the IDE, it points to the folder containing the project file.
Another option is that the library uses a sub VI that is not used nor available in the exe.
In development, the VI can use VIs from .vilib, but the executable doesn't look there.
Make sure all dependencies of the VI are available to the exe. For instance, make a source distribution.
Or look into packed libraries.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
Another option is that the library uses a sub VI that is not used nor available in the exe.
Along a similar line, the VI being called could have "Separate From Compiled" turned on, which means the object code is unavailable to the executable.
wiebe@CARYA wrote:
Or look into packed libraries.
In my opinion, Packed Project Libraries are the only real way to do a plug-in architecture.
@crossrulz wrote:
wiebe@CARYA wrote:
Or look into packed libraries.
In my opinion, Packed Project Libraries are the only real way to do a plug-in architecture.
Agreed.
We used to do this without packed libraries. It is possible, but it was always a pain. Haven't needed this lately, but I'll use them for sure if I need plug-ins now.
wiebe@CARYA wrote:
We used to do this without packed libraries. It is possible, but it was always a pain. Haven't needed this lately, but I'll use them for sure if I need plug-ins now.
I agree, but there is a big catch here. It gets very complicated again if you want to do a system where you use packed libraries across different target architectures. Since a packed library is compiled it has to be recompiled for each target architecture. Making sure that the right version of the packed library is found during development in different project targets is a pain in the ass. Basically you can't reference the same packed library name in a project in two different target architectures. It even goes bad if you seperate each into a different project and open both at the same time, since LabVIEW tracks references to lvlibs (and lvlibps as well as lvclasses) globally even across project contexts to be able to lock them if opened in more than one context.
While there is an unofficial way to solve that using special pseudo path resolution this breaks down once you try to build this as the pseudo path resolution is for some very strange reasons broken on the NI Linux RT platform for x64 (but not on the same platform for ARM!).
Also another snag we run into is that the Application Builder currently can't handle multi-level dependency (a lvlibp residing in a pseudo path that references another lvlibp in a pseudopath) pseudo path resolution for some reason.
Pseudo paths are paths that reference the standard LabVIEW directories such as <vilib>, <userlib>, <instrlib>. You can use them in a build application too, but this has obviously never been really exercised by NI as there are multiple long standing bugs in respect to this.
@rolfk wrote:
wiebe@CARYA wrote:
We used to do this without packed libraries. It is possible, but it was always a pain. Haven't needed this lately, but I'll use them for sure if I need plug-ins now.
I agree, but there is a big catch here. It gets very complicated again if you want to do a system where you use packed libraries across different target architectures. Since a packed library is compiled it has to be recompiled for each target architecture. Making sure that the right version of the packed library is found during development in different project targets is a pain in the ass. Basically you can't reference the same packed library name in a project in two different target architectures. It even goes bad if you seperate each into a different project and open both at the same time, since LabVIEW tracks references to lvlibs (and lvlibps as well as lvclasses) globally even across project contexts to be able to lock them if opened in more than one context.
While there is an unofficial way to solve that using special pseudo path resolution this breaks down once you try to build this as the pseudo path resolution is for some very strange reasons broken on the NI Linux RT platform for x64 (but not on the same platform for ARM!).
Also another snag we run into is that the Application Builder currently can't handle multi-level dependency (a lvlibp residing in a pseudo path that references another lvlibp in a pseudopath) pseudo path resolution for some reason.
Pseudo paths are paths that reference the standard LabVIEW directories such as <vilib>, <userlib>, <instrlib>. You can use them in a build application too, but this has obviously never been really exercised by NI as there are multiple long standing bugs in respect to this.
I never needed that complicated stuff.
Is that also a problem if you do it old school? Or is this specific for packed libraries?
wiebe@CARYA wrote:
I never needed that complicated stuff.
Is that also a problem if you do it old school? Or is this specific for packed libraries?
The pseudo path problem supposedly would exist with other files too I guess. But nobody is usually going to have a vi.lib directory inside his build application folder, and even less so on a realtime target. But after a post from Aristos Queue we figured that this would solve the problem of distributing packed libraries to multiple different realtime systems. It seems to mostly work but there are a few snags left over.
