NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Error -19506 when build Deployment on workspace containg a VI calling a shared variable

Hi,

 

I'm trying to build a TS deployment (TS 2014) based on a Workspace.

In that WS, one of my sequences calls a step type 'Get Temperature'. That step type calls a module relying on the LabVIEW adapter, and which calls a VI containing a shared variable.

 

My step type is then called many times in my sequences.

 

When building the deployment (image only for now), I'm facing the error -19056 pointing on the first step asking for the temperature (so calling my step type).

I've tried everything described here : http://zone.ni.com/reference/en-XX/help/370052W-01/tsdeploysystem/infotopics/preparingcomponents/

LVLIB is included in my WS, I even included the LV project containing that LVLIB. I tried to mass compile the VI. I tried to add a 'deplor' step within my test sequence (even if I don't need it because it is my GUI which will deploy it before launching any sequence).

 

But nothing works.

 

Any idea ?

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 1 of 12
(2,392 Views)

Hi CyGa,

 

Could you share what the error code says?

 

In addition, I just want to check did you create the shared variable in the Shared Variable Engine and configure the LabVIEW Adapter to automatically deploy the shared variable?

CiCi Z.

Applications Engineer

0 Kudos
Message 2 of 12
(2,352 Views)

Hi,

It just says the module is incorrectly defined.

When you open the test sequence there is no problem.

 

Why creating the variable in the Shared Variable Engine ? I'm talking about deployment here, not running the code on my own PC. My actual conf should not impact the depolyment configuration. Moreover, as said in my first post, the shared variable is deployed at first by a custom operator interface made in Labview, so it will be present in the SVE on the destination computer when TestStand will run the sequence. It is not TS role to actually deploy this variable.

I even added a 'deploy' step pointing the library (just tp try it even if not necessary), but it didn't fix anything.

 

I actually fixed the problem by referencing the project in the step module... Even if the project, library and VI where already in the WS, I had to explicetly add the project reference in the module of this step.

By the way, referencing the project inside the code module of my step type doesn't propoagate the setting into the sequences calling these step type even if the files are open at modification application time.

 

Also, I had to do the exact same workaround (adding project reference) for VI which are not step types, but already referenced in my workspace... Weird, no ?

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 3 of 12
(2,342 Views)

I'm not sure if you've seen it already, but this help document explains the project behavior you mentioned:

https://zone.ni.com/reference/en-XX/help/370052R-01/tslabview/infotopics/variable/

 

Referencing the VI from within the project on the step actually has more impact than may be obvious. It changes the application instance that the VI will run in. NSV's can communicate across app instances, but other options (like an FGV) are scoped to a specific instance. There may be times when it makes sense to not use a path, like if you want a code module to share an app instance with the operator interface, but in general it's best to specify the project path so you're certain what instance it will run in.

 

This white paper does a good job of covering the details:

http://www.ni.com/product-documentation/14335/en/

 

-Trent

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 4 of 12
(2,333 Views)

Hi Trent,

 

My GUI is an EXE, it has its own application instance. This EXE deploys a Network Shared Variable. This SV will be accessible to every application needing it.

This same EXE instantiate the TestStand process, therefore every code module called by my sequences (and run by the engine engine related to the App Manager instanciated in my EXE) will run with the same app instance. And sees the SV (tested, works well).

 

So why does the deployment is requiring the project to be specified ?

 

My guess was 'to link the correct variable to the code module'... So I decided to make a test and remove the project link of my code module.

I saved all, and relaunched the image creation. This time it worked !! Smiley MadSmiley Frustrated

 

But another problem suddenly appeared : one of my VIs is relying on IVI module calling a specific dll (driver of AGN5747A).

The DLL is relinked into my WS to be sure it is not missing on the target computer, and placed in the same directory as the VI calling it (so it will find the dll right away).

Here is the problem I now have :

 

The following VIs or project libraries have duplicate names.
You must change the duplicate VI names or add the VIs to project libraries. (Message Code: -19035)
C:\Users\xxxx\Documents\xxxx\xxxx\xxxx\Code\700 - HW\N5747A\Driver\agn5700_32.dll
agn5700_32.dll

 

It is not my first deployment (using TS for 10 years now), but it is the first time I come to this so inconsistent behavior.

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 5 of 12
(2,328 Views)

It sounds like these are two different problems:

  1. The shared variable one: unless you have the "auto deploy shared variables" option checked, the project path shouldn't be required. If you can tell me how to produce that behavior, I'll file a CAR.
  2. The path one: It looks like the analysis is finding and including the absolute path to the DLL, as well as the copy that's next to your VI. Did you manually add that path to the workspace? This shouldn't be necessary if LabVIEW can already find the dll.

-Trent

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 6 of 12
(2,326 Views)

Indeed, seems to be 2 different problems.

For now, the first has not poped-up again, but it refuses to build du pt 2.

For pt 2, I removed the dll from the workspace but still the same problem. I even removed the driver llb from the deployement (distributed files tab), and it still fail. I had the same problem yesterday, and it just magically disappeared... to re-appear today (I was able to build images and installers yesterday evening).

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 7 of 12
(2,324 Views)

OK, so pt 2 is now fixed (a single VI in the was still referencing another dll...).

Back to pt 1!

 

The adapter is set not to un/deploy the SV.

The step is not referencing a project for now (I removed that setting).

You can see in the atteched file how simple is the VI.

CLA, CTA

View Cyril Gambini's profile on LinkedIn
Download All
0 Kudos
Message 8 of 12
(2,320 Views)

I finally get back to adding the link to the LV project to my steps.

This 'Get Temperature' step is a step type, in which the LV code module is specified using the project path.

This setting has been made after the steps were inserted in the sequences. It didn't propagate, even if the sequences were all open.

 

I set just one of the step calls to point on the project file. This step is now not a problem anymore for the deployment ; but all other steps of the same type are now being referenced by the deplyment tool as problematic.

So I've got to change the settings for ALL steps INDIVIDUALLY.

 

Is there something I'm missing somewhere ?! Smiley SadSmiley Frustrated

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 9 of 12
(2,318 Views)

When you updated the step type to use a project path, did you increment the version of the type?

https://www.linkedin.com/in/trentweaver
0 Kudos
Message 10 of 12
(2,305 Views)