Dynamically calling a VI containing vision functions from executables

[C.Mizuno]

Hello Forum,

I have a main VI which dynamically calls a sub VI which has IMAQdx functions as well as Vision Modules.

I can call the sub VI fine in LabVIEW Development System, but I get error 1003 when calling from an executable. After some debugging, I found out that the sub VI was unable to locate any of the vision function when running from an executable.

I've looked into multiple forms and KBs and still can't seem to find a proper solution.  I've put the sub VI in the "Always Include" section to no avail.  

One workaround I found was to include the sub VI in the start-up, but that defeats the purpose of trying to dynamically call a sub VI.  I am hoping to allow the end-user to customize the sub VI a bit, and save it to be called dynamically from the same executable. 

Another workaround was to include the sub VI in the same folder as the Vision module folder, but am hoping for a more clean solution.

Any input would be appreciated.

Best,

Chase

[nath05]

Hi Chase,

Do you have the licenses required for the application built?

Like Vision Runtime Engine for example.

You can check in the following link what is needed

Distributing Applications Built Using Vision Development Module - http://www.ni.com/tutorial/12530/en/

Warm Regards

[C.Mizuno]

Hello, 

Thank you for your reply.

Yes, I have Vision Runtime Engine.  For now, I am testing the exe file on the same computer as the development system. 

Also, as I've mentioned in the post, I was able to get the Sub VI running through some workarounds, but wanting a more absolute solution ( if such exists).

Best regards,

Chase

[nath05]

Hi,

I know that you have been checking a lot of KBs but did you try with this one as well?

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9fiSAC&l=en-US

[C.Mizuno]

Hi,

Yup, that's the first KB I looked up.

However, since the error happens when I try to call a sub VI dynamically, the correct KB is https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIHWSA2&l=en-US

Tried everything here with no luck, that is why my best option was to put the sub VI i the vision driver folder (the error was due to the fact that the sub VI could not find the Vision VI. It starts searching for the vision VI from the filepath of the subVI. Thus, by putting the sub VI in the vision folder, the sub VI can open up the vision VI without problem) However, I was thinking there must be a better solution than this???

[nath05]

Hi,

Are you using relative paths to do so?

[Neil.Pate]

A simple work around could be just to put the Vision VIs (or your VI that uses the VIs) somewhere on a block diagram that will definitely be included with the build.

I have a LVOOP architecture that dynamically launches Vision processing routines, and all  I need to do is make sure the objects are placed somewhere in the code. The builder does the rest including packaging them up inside the exe for me.

Having loose VIs with your build is not really a nice thing to have to live with.

[Alexander_Sobolev]

"allow the end-user to customize the sub VI a bit, and save it to be called dynamically from the same executable"

Hmm... does not it mean this vi can not be in the executable? In the lvlib(p) next to exe for example?

[C.Mizuno]

Hello,

Thank you for your reply.

Yup, that's exactly where my problem lies.  I can't statically put the sub VI (w/ vision functions) inside the main VI, because I want the end-user to customize the sub VI after I distribute the calling main executable.  However, I do not want to simply hand over the main VI due to company policies.  (The end-user will have LabVIEW development system installed so they can still edit the sub VI, just not the main executable)

What is a lvlib(p)?  Is it a file that contains the VI and its dependencies? 

[Alexander_Sobolev]

Yes lvlibp is a packed library, based on lvlib project library that contains library files and all its dependencies. Separate build specification (Packed Library). Dependencies (and library files set to private access) will be in the library file, but will be private to this library and hidden from user.

MainSub.vi file path is complicated, depending on original folder structure it can change. You can check it, if you statically use this file in main vi. 

Also you can give llb file (Source Distribution build specification, at Destination tab set LLB). All dependencies will be visible. All file paths can be targeted C:\LibFile.llb\anyfile.vi