NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

deployment issues

Solved!
Go to solution

Hello everyone,

I am new to Teststand and have been trying to deploy my Teststand applicatino to a target computer for the past 2 days and have a few questions regarding the process of deployment.

 

1. I developed my TestStand application on the D drive of my development computer. My target computer has only C drive. In this case, (note: TestExec.ini is also being deployed) I would  always need to:

a) change the search path configuration on the target computer after the deployment, e.g., adding/changing all the relevant paths in the search configuration to start with C drive. or

b) I can also do some tricks, by setting the search configuration to C: in the development computer just for the sake of deployment. This way, the deployment on the target computer will have the right search path (and report files output directory because I specify a fix output report directory). Then I would have to change the search configuration back to D drive for continuing the development on the deveopment computer.

 

The question is, if I choose a) as deployment strategy, in order to add/change the search configuration on the target computer, I will need a development teststand license. If I download a development teststand (as evaluation) on the target computer, after the add/change of the search configuration on the target computer, I would turn off the development Teststand and switch the license to base deployment license on the target computer, this will do it, right?

 

2. Deploying network published shared variable is not so straight forward. My target computer will communicate with a compactRIO through shared variables. The compactRIO controller is the SVE. I added a 'Labview Utility LIbrary Deploy step' in a sequence step and deploy this sequence to the target computer. I ran this sequence in order to deploy the shared variables on the target computer. However, I got an error saying that the shared variable library cannot be deployed and asking to make sure that there is only shared variables in the library. I checked and can see that there are only shared variables in the lilbrary. What could be other possible reasons? Can anyone give me hints on this problem? Is there a tool that can scan this library and tell me if there is a 'hidden' vi in this library because I cannot see anything wrong with the library even with my thick glasses.

 

I am thinking of other shared variable deployment options, for example: a) maybe I should download an evaluation LabView deveopment system on the target and copy over the Labview Project and deploy the shared variable through the labview project. or b) I can create a vi that uses the shared variable and using labview build process to deploy the vi as exe. Check the appropriate 'deploy shared variable' option in the build process, run the exe in the target computer. This way I can deploy the shared variable. After the deployment, turn off the LabView deveopment evaluation license so that there is only LVRTE on the target computer.

 

Does the above  a) and b) options make sense as shared variable deployment strategies?

 

At this point, I realize the TestStand deployment is a skill. There is no systematic deployment approach for TestStand. Do experts out there agree? I just need some inputs so that I am not on the wrong path. Thanks in advance for your feedback.

 

Yours,

hlim

0 Kudos
Message 1 of 8
(5,116 Views)

Hi,

 

welcome to the joys of teststand deployment. In my opinion the key lies in proper preparation. Make sure that you already deploy everything that you will need on your deployed test station. Planning the deployment process already from the start as something where you will need to manually configure the new test station is flawed. You might es well abandon deployment alltogether, install the LabVIEW run-time and Teststand run-time manually and copy over the files ... that would probably be quicker (and I'm sure that thought will have struck your mind). Deployment is only worth the effort if it is near fully automated. Make sure that you deploy the necessary config files into:

 

C:\ProgramData\National Instruments\TestStand <version xxxx>\Cfg

 

so that you won't have to set up search paths/station options/report options/etc manually. In your case that means: change the search paths on your machine to what they should be on a target machine and deploy that.

 

I'm doing very well in avoiding network shared variables as I don't think that they are practical or easy to use, so I won't be any help with that.

 

I'm by no means an expert but I have had my fair share of exposure to Teststand deployments. You are right that there is no obvious systematic approach to creating your deployments ... you will have to come up with your own workflow.

 

Mine is as follows:

 

- get LabVIEW code into most efficient form. I use packed project libraries, saves me from having to deploy dozens/hundreds of code step VIs. Also avoids manipulation.

- take a copy of all config files that I need to deploy (TestExec.ini: Station Options, search directories ...; StationGlobasl.ini: you need the same station globals on your deployed system; TestStandModelModelOptions.ini: Number of Test sockets etc; ResultProcessing.cfg: report customisation; ... you might need more config files).

- take a copy of all driver installers I need

- create workspace file with all the files.

- set destination for LabVIEW files somewhere in the C:\users\Public folder in the deployment wizard

- set destination for config files in the appropriate "C:\ProgramData\National Instruments\TestStand <version xxxx>\Cfg" subfolder

- set destination for driver installers to the temp directory

- select all correct run-time engines to install

- under "custom commands" on the "installer Options" add all your driver installers which execute from the temp path

 

only thing I need to configure now are things like COM ports of various devices or DAQ channels as I can't be sure how they enumerated in the system.

 

General advice from my Teststand 2 instructor was. "If you need to prepare a deployment, don't start with it on a Friday afternoon, ... start on a Monday morning!" ... it takes a while.

 

 

 

 

0 Kudos
Message 2 of 8
(5,069 Views)

Hello hlim,

 

1.

In my oppinion it is the easiest way to change the settings to C on the development PC then save the test TestExec.ini and use this ini for the deployment, because in this case the syntax is correct inside of the ini file. When the ini file is modified manually some syntax error could happend. Thenif you have one file with the correct paths it is easier to change the path later over some text manipulating code.

 

Normaly you made a deployment with the TestStand Engine inside, so you do not have to download the development system and to deactivate it after the installation.

best regards
Alexander
0 Kudos
Message 3 of 8
(5,064 Views)

Hello hlim,

 

2.

Deploying shared varibales must be only done once, so they are registered into the shared varibale engine. Then the VI and also the RIO can communicate with it. Important is to check the IP´s because they are diffenten then to the development system.

 

Developing Portable Shared Variable Applications

 

You can build a VI that deployes the chared varibales as a setup step in your sequence. You can also made a executable that was called from the installer process to deploy the variables only once during the installation process.

 

I hope this helps.

best regards
Alexander
0 Kudos
Message 4 of 8
(5,059 Views)

Thanks Mathias_B and Duffy2007  helpful hints and sharing your experience of TestStand deployment with me.

 

My problem is mainly deploying the network publish shared variable. I tried using Labview utility deploy library step, and also using a vi to deploy the shared variable but I keep getting error (error with the invoke node -2147467259). That's why I decided to install the LV development environment, run the TS Labview utility deploy library step, and then deinstall the LV development. It works this way for me unfortunately.

 

Yours,

hlim

0 Kudos
Message 5 of 8
(5,056 Views)
Solution
Accepted by topic author hlim

Hello hlim,

 

which software version do you use?

There was an known issue with bound variables in a shared library in older LabVIEW versions.

best regards
Alexander
0 Kudos
Message 6 of 8
(5,022 Views)
Solution
Accepted by topic author hlim

Hello Duffy2007,

I am using LV 2014 SP1 f1 (32-bit) and TS 2014 SP1 (32-bit). The way I overcome this shared variable deployment problem was to install the LV development (evaluation), run the TS Labview Utility Deploy Library Step to deploy the shared variables, then uninstall the LV development. It is not the right way to do it, but until I find out what the source of the problem is, I have no other choice.

 

Yours

hlim

0 Kudos
Message 7 of 8
(5,001 Views)

Hello hlim,

 

i hope this workaround was ok for you. Sorry.

best regards
Alexander
0 Kudos
Message 8 of 8
(4,995 Views)