Can't deploy shared variables programmatically, LV8.2.1

[Jeff_Long]

Hi,

I'm testing some code that will be used to deploy shared variables from a LabVIEW executable, version 8.2.1.

When I execute the invoke node for Application->Library.Deploy Library, using a valid file path for my lvlib file containing my shared variable definitions, I get an error as follows:

Error 1 occurred at Invoke Node in APP  GlobalInit.vi

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

Method Name: Library:Deploy Library

The "path" parameter passed into the invoke node is "C:\300TRT\data\Belt.lvlib", which is absolutely a valid path.  In fact it is generated programmatically by feeding the directory path "C:\300TRT\data" into the "List Folder" VI with pattern input "*.lvlib", and using the "Build Path" VI to concatenate the names so that all of my libraries in the directory get deployed.  Additionally, I can execute a "File/Directory Info" VI on the exact same path and get valid file size, date, etc. info returned.

I have tried using and not using the IP address of my local machine in the "Target IP Address" parameter with no change in result.

Please help.

Jeff.

[RavensFan]

Check out this link.

It is related to finding a VI within the .exe, but perhaps the .lvlib gets stored within the .exe as well.  So instead of C:\300TRT\data\Belt.lvlib try C:\300TRT\application.exe\data\Belt.lvlib or C:\300TRT\application.exe\Belt.lvlib where application.exe is the name of your .exe file.  I won't guarantee the results, but it's worth a try.

[Jeff_Long]

Thanks.

But generating the correct file path is not my problem.  My problem is that the invoke node returns an invalid file path error for a path that is proven to be valid.

Additionally, while you are probably correct about the method for specifying the path of a VI located in an exe, please see the following note pertaining specifically to shared variable distributions:

Shared Variables and Stand-Alone Applications or Shared Libraries

If you plan to distribute a stand-alone application that uses shared variables, do not include the .lvlib file in an LLB or in the executable. Use the Source Files Setting page of the Application Properties dialog box to change the Destination of the .lvlib file to a destination outside the executable or LLB. You can deploy the shared variables in two ways:

• Write the application so that it programmatically deploys shared variables at start time. Call the Deploy Library Method in the top-level VI of the application. In the Library Path input of the method, use the relative path to the .lvlib file that contains the shared variable.
• Manually deploy the shared variables to the computer or target Shared Variable Engine before running the built application.

from http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/project_variables/

Jeff.

[Adao]

Hi there Jeff,


I had the same problem.

I fixed it simply by using a constant file path (think you have already done this) and getting the Ip address of the PC programmatically, using the String to IP block.

I have attached an example below.

This is the first thing that my program executes and if it returns error it exits the program.

Hope it helps...

Adam

[Jeff_Long]

Hi,

Thanks for the help.

Upon working with this further, I've noticed that this error only occurs when attempting to deploy 2 (out of 😎 libraries.  The other 6 deploy successfully.  I suspect that the two libraries that give me trouble do so because I'm testing the deployment capability on a PC that is not configured with all of the hardware, VIs, XControls, etc. to which the shared variables and libraries refer.

I was unluck enough to choose one of the problematic libraries as my test case.

In summary, the method for deploying shared variables as described in the LV documentation and illustrated by Adam works correctly.  But if there is a problem deploying the library, LabVIEW generates a misleading error message that would make the user think that the library file path is incorrect, when it isn't.  Perhaps NI could fix this in a future release?

Thanks again for the help.

Jeff.

[M.Shair]

Hi Mr. Jeff

actually now I'm facing the same problem,

so I'm wondering if there's a solution for this problem The NI came up with or not yet

I'll be so thankfull for cooperation

[LaurenLL]

Hi Mahmoud,

It looks like this is a duplicate post on using Shared Variables in an Executable.

Regards,

Lauren 

[Christian vP]

I had the same problem in LV 8.5 when trying to deploy a library that would contain shared variables and custom controls. When I removed the custom controls from the library, the deploy run without any problem.

[LaurenLL]

Hi Christian,

You should be able to deploy a library that contains custom controls.  One thing to keep in mind, though, is that custom shared variables do not support RT FIFO.

Take a look at the following KnowledgeBase article on creating a shared variable for a cluster.

Regards,

Lauren