04-25-2018 02:42 PM
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 ?
04-26-2018 06:32 PM - last edited on 06-10-2019 05:30 PM by Kristi_Martinez
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?
04-27-2018 08:00 AM
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 ?
04-27-2018 10:42 AM
I'm not sure if you've seen it already, but this help document explains the project behavior you mentioned:
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:
04-27-2018 11:10 AM
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 !!
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
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.
04-27-2018 12:05 PM
It sounds like these are two different problems:
04-27-2018 12:49 PM
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).
04-27-2018 01:09 PM
04-27-2018 01:20 PM
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 ?!
04-27-2018 01:48 PM
When you updated the step type to use a project path, did you increment the version of the type?