Globals.ini location in teststand 2.0

Hi,
trying to support some old code
The code is looking for the globals.ini file, but does not tell us where it is looking
anyone know what the path to the file is?
Thanks,
Jeff

Hi,
Try c:\teststand\cfg\stationglobals.ini
Regards
Ray Farmer
Regards
Ray Farmer

Similar Messages

Need correct syntax for global.ini for FC storage connector API

for a scale out solution of 3 node HANA with master , worker and standby .
this is my global.ini. I am seeing an error when hana installer is trying to use the storage adapter to access the LUNs from specifications in global.ini.
has anyone experienced this issue? I have not mounted the filesystems when I running the installer and want the storage adapter to do the mount
the short error is : I have pasted the entire log at the bottom of this post.
             Output line 8: no storage with key (partiton, usageType) = (1, data) configured
            Output line 9: no storage with key (partiton, usageType) = (1, data) configured
[communication]
listeninterface = .global
[internal_hostname_resolution]
10.1.73.140 = vmhdb1
10.1.73.142 = vmhdb3
10.1.73.141 = vmhdb2
[persistence]
basepath_datavolumes = /hana/data/VM2
basepath_logvolumes = /hana/log/VM2
[storage]
ha_provider = hdb_ha.fcClient ç=
partition_*_*_prtype = 6
partition_*_log_mountOptions = -t xfs -o realtime, inode64,nobarrier
partition_*_data_mountOptions = -t xfs -o realtime, inode64
partition_2_data_wwid = 6001b970f24554e1f24554e118a9d796
partition_2_log_wwid = 6001b970f24554e1f24554e1cc16bc02
partition_1_data_wwid = 6001b970f24554e1f24554e11b582bda
partition_1_log_wwid = 6001b970f24554e1f24554e1cfe7404e
[system_information]
usage = test
The error is as below
Enter Installation Path [/hana/shared]:
Enter Instance Number [00]:
Options:
System usage | Description
1            | System is used in a production environment
2            | System is used for testing, not production
3            | System is used for development, not production
4            | System usage is neither production, test nor development
Enter System usage [4]: 2
Enter System Administrator (vm2adm) Password:
Confirm System Administrator (vm2adm) Password:
Enter System Administrator Home Directory [/usr/sap/VM2/home]:
Enter System Administrator User ID [1001]:
Enter System Administrator Login Shell [/bin/sh]:
Enter ID of User Group 'sapsys' [79]:
Enter Database User (SYSTEM) Password:
Confirm Database User (SYSTEM) Password:
Restart instance after machine reboot? [n]:
Installation failed
Error checking installation
    Checking system requirements failed
      Cannot mount storage devices
        Performing python script failed
          Starting external program /usr/bin/python
            Command line is: /usr/bin/python /mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdbmount.py --sid=VM2 --configFiles=/hana/shared --datapath=/hana/data/VM2/mnt00001 --logpath=/hana/log/VM2/mnt00001 --partition=1
            Output line 1: PYTHONPATH=['/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE', '/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha', '/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server', '/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server', '/usr/lib/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/Numeric', '/usr/local/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/gtk-2.0']
            Output line 2: trying: __import__('hdb_ha.fcClient')
            Output line 3: trying: getattr(<module 'hdb_ha' from '/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha/__init__.pyc'>, 'hdb_ha.fcClient')
            Output line 4: failed with: 'module' object has no attribute 'hdb_ha.fcClient'
            Output line 5: trying: getattr(getattr(<module 'hdb_ha' from '/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha/__init__.pyc'>, 'fcClient'), 'fcClient')
            Output line 6: apiVersion = 2
            Output line 7: calling Storage Connector ...
            Output line 8: no storage with key (partiton, usageType) = (1, data) configured
            Output line 9: no storage with key (partiton, usageType) = (1, data) configured
            Output line 10: Traceback (most recent call last):
            Output line 11:   File "/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdbmount.py", line 164, in <module>
            Output line 12:     main()
            Output line 13:   File "/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdbmount.py", line 155, in main
            Output line 14:     cl = clClass(method, configPath, sid, datapath, logpath, tracelvl, partition)
            Output line 15:   File "/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha/fcClient.py", line 47, in __init__
            Output line 16:     super(fcClient, self).__init__(*args, **kwargs)
            Output line 17:   File "/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha/client.py", line 413, in __init__
            Output line 18:     self.attach([{"partition" : partition, "usage_type" : "data", "path" : mnt_data}, {"partition" : partition, "usage_type" : "log", "path" : mnt_log}])
            Output line 19:   File "/mnt/DVD/SAP-Software/HANA/REV72/SAP_HANA_DATABASE/server/hdb_ha/fcClient.py", line 133, in attach
            Output line 20:     raise Exception(msg)
            Output line 21: Exception: no storage with key (partiton, usageType) = (1, data) configured
            Program terminated with exit code 1

Hi...I am getting the exact same error, while installing SAP HANA on EMC . Can you please share if you had resolved this error? Thanks in advance.
- Vijay

Read ini file in TestStand

I have a computer with TestStand, but no LabVIEW. Can I read an ini file in TestStand directly? My file have several section headings and several keys under each. Any help appreciated.
Senior Test Engineer
[email protected]

If you are comfortable calling the Win32 sdk, you could use the DLL adapter to call:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724353%28v=vs.85%29.aspx

Need Registry/.ini location info for TS version selector

I would like to know the currently active TestStand Version selected through the Version Selector. How to get this information programatically / the location where this information willl be stored (Registry/.ini file etc)?

Hey SanJay_gp,
There is a KnowledgeBase that discusses two seperate methods for determining the current version of TestStand. I have linked it here. Hope this helps!
Pat P.
Software Engineer
National Instruments

Global FlashPlayerTrust Location ist wrong in the tech Spec document

From Spec
"This directory is named FlashPlayerTrust, and is called the Global FlashPlayerTrust directory. It is located alongside the directory that contains the mms.cfg file (see “mms.cfg file location” on page 19). For example, if the mms.cfg file is in C:\Windows\System32\Macromed\Flash, the location of the Global FlashPlayerTrust directory is C:\Windows\System32\Macromed\FlashPlayerTrust. (For information on specifying content as trusted only for the current user, see “The User FlashPlayerTrust directory” on page 35.)"
This is wrong the Global FlashPlayerTrust directory is NOT located alongside. Its located UNDER the directory.
For example "C:\Windows\System32\Macromed\Flash\FlashPlayerTrust" and not like the example in the spec "C:\Windows\System32\Macromed\FlashPlayerTrust"

On Page
http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html
ducument
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/flash/articles/flash_ player_admin_guide/flash_player_11_1_admin_guide.pdf

SAP GUI 7.20 - sapmsg.ini and saproute.ini location

I have installed SAP GUI 7.20 and I moved the saplogon.ini to a folder different from C:\WINDWOS, but message server and SAProuter are still pointing to C:\WINDOWS\SAPMSG.INI and C:\WINDWOS\SAPROUTE.INI.
I don't like these files on WINDOWS, How can I move them to another location and SAP GUI still can read them?
Many Thanks in advance,
Fernando.

Hello Fernando,
please see note 38119.
Regards,
Martin

Problems in syncronyzing two threads into Test Stand using a Global Variable (TestStand 4.1.1)

I have one thread that is doing TCPIP Aquisition into a Global variable defined in Teststand. And I have another thread that it supose to read it. All are in the same sequence and execution. The problem is that the aquisition thread got a lot of bytes, while the processing thread is reading always only a few. Do you know what the problem could be?
I will attach also some pictures just to be maybe more clear...
Attachments:
Implementation_pictures.zip ‏368 KB

I wasn't looking at your Sequence, I was looking at Receive_HDL_Block.JPG. What is that VI doing (the one with number 3 on the icon and Size_in_bytes as an input) ?
Where in teststand are you doing any checking?
I don't really understand your sequence.
You have a sequence (running in a new thread) (why), following by another called Receiver Handler (also running in a new thread) then two more sequences which seem to do some with transmitting something (also running as new threads). You are only waiting on one of these threads (the Receiver Handler). There does seem to be any loops in TestStand, you dont seem to be bothered about the other threads that you have running. What happens when this test sequence finally does stop, what is stopping the Threads that you have running.
Your pictures dont really seem to fit in with your Test Sequence, such as where does Test_005.vi fit into everything
The whole thing is a bit of a nightmare.
Maybe your best bet would be to scrap the lot and start again. Only this time have a better understanding of what you what to achieve, what would be best to put into Teststand and what to put into labview. Whether you really need all those new threads running.
Sorry to be so blunt.
Regards
Ray Farmer
Regards
Ray Farmer

Teststand station global

Hi,
Can any body tell me what is the difference between TestStand Sequence file global variable / station global variables and LabView global variables.
In TestStand, I want to pass one cluster from Setup to Main, which can't be passed using Local variable.
Using LabView Global variable, I am able to pass cluster from Setup to Main.
Using TestStand Sequence file global variable / station global variables, the cluster has not been passed from Setup to Main.
Any help will be appreciated.
Thanks
Holy

Holy,
Local Variables:
Each execution has its own copies of the local variables. So you can not use them to share data between executions.
Use local variables to store data relevant to the execution of the sequence.
Sequence File Global Variables:
Any sequence in the file can access the global variables for the file. A subsequence can access the global variables in the sequence file that contains the calling sequence.
Global Variables:
Station global variables are persistent across different executions and even across different invocations of the sequence editor or operator interface. The TestStand Engine maintains the value of a station global variable in a file on the computer on which it is installed.
LabView Global Variable.
The LV global variables are used to access and pass data among several VIs.
TestStand can not access LV global variables directly.
You need to call it through a code module.
I am not sure how are u handling the cluster.
I assume that you are initializing it somehow in the setup group and after that you use it in the main group.
1. If you get the cluster from a VI in the setup group and after that you want to use it in the main group you could use a local variable.
2. If you need to share the cluster among several executions you need to use a global variable.
Could you give more details about your use case?
Hope it helps
Antonio.
Message Edited by Antonio Lie (NI) on 11-11-2005 10:16 AM

How do I deploy teststand 3.5 to a different directory?

Hi:
We are currently upgrading from a Teststand 2.0.1 infrastructure to Teststand 3.5. To reduce the amount of changes in our existing infrastructure, I'd like to remove the old Teststand 2 directory (c:\teststand) and install Teststand 3.5 to the same directory (c:\teststand rather than c:\Program Files\National Instruments\Teststand 3.5). This will save us going through and changing any sequences or DLLs that are pointing at the absolute directory path c:\teststand. I was able to do this with the regular Teststand 3.5 installer without a problem by choosing 'Custom' and then changing the Teststand directory. Everything then worked fine on the test PC after installation.
However, now I'm trying to create a run-time-engine installer using the Teststand Deployment utility, and I can not figure out how to change from the default Teststand install directory of c:\Program Files\National Instruments\Teststand 3.5. Is there a way to do this? Can this perhaps be done with a spec file, or do spec files not work with the deployment utility?
Thanks,
Dave

Hi Dave,
Sorry for the delay in response. Here's what I've found.
You can modify the setup.ini file that is created with the Deployment
Utility to give you more flexibility with your TestStand Installation.
In the setup.ini file, add
Dir1EditLabel=12
Dir2EditLabel=13
Dir1=NIDIR
Dir2=TESTSTAND350DIR
to
[SingleDirectoryDialog]
DirText1=4
DirText2=7
which results in:
[SingleDirectoryDialog]
DirText1=4
DirText2=7
Dir1EditLabel=12
Dir2EditLabel=13
Dir1=NIDIR
Dir2=TESTSTAND350DIR
This will result in the installer asking for two paths instead of
one. By default (with this change) they will not be labeled. (See
attached screenshot)
The first dialog box is the NI Default directory. Anything shared
between multiple NI products will be installed there. In the future,
when other NI products are installed, they will default to whatever was
entered in this dialog.
The second dialog box is the location that TestStand components will be
installed to. This includes the TestStand engine, components, process
models, etc.
If you wanted to add labels to these path prompts, you would need to
modify the resource strings. This can be done in Visual Studio if you
have a copy. I believe Visual Studio Express Edition is now available for free on Microsoft's website.
Hope this helps Dave, have a good one and let me know if you have any questions.
Dan Weiland
Applications Engineer
National Instruments
www.ni.com/support
Dan Weiland

Deploy teststand with labview ui

Hi,
I'm using teststand now since 9 months and now I have to distribute my application to a testing machine. I have some questions about this process. But first I discribe my application:
I have a labview ui, which has 3 main tasks:
1.) Start selected teststand sequences for automatic testing.
2.) Give operator the possibility to manually control the testing environment (purely written in labview)
3.) Run continous data aquisition, which provides data for teststand and manual testing.
Sharing data between labview and teststand is done mainly via global variables (e.g. reference to tdms file). Because of 1.) and 2.) above teststand and labview share a lot of VIs for communicating with the testing environment.
OK, now my questions:
I'm searching for the best way to deploy this application via an installer. I know, that there is a teststand deployment tool (which I havn't used, yet) and I know how to build installers with the labview project manager.
1.) What about sharing of VIs and global variables between my teststand sequences and my generated labview exe? When I place my sequences in the workspace file for the teststand deployment tool, all referenced VIs are included in teststand. But Some of these VIs are also included in my generated labview ui. Will this generate a conflict?
2.) I was thinking about to create a teststand deployment without a workspace file. The sequences and all required VIs would be placed in the generated labview ui instead. Will the teststand sequences find the VIs inside of the ui exe?
3.) What about required drivers (e.g. daq-mx)? Should I create a labview installer of my ui with the required drives and install this, then create a teststand installer (perhaps including the ui, too) and install this, too?
Thanks for any help in advance.
Marc
CLD

Hi,
I would recommend the Deployment Tool for your TestStand and OI. I would also keep your Test Sequence files seperate from your TestStand Engine amd UI deployment.
[1.) What about sharing of VIs and global variables between my teststand sequences and my generated labview exe? When I place my sequences in the workspace file for the teststand deployment tool, all referenced VIs are included in teststand. But Some of these VIs are also included in my generated labview ui. Will this generate a conflict?}
This is going to cause you a problem because LabVIEW doesn't like / will not load the same VI into memory from two different locations.
The Deployment Tool will probably object as well therefore you will not beable to create a deployment package.
The Deployment Tool will place all the VIs that are called directly from TestStand Sequence Files as seperate VI's (not in a LLB) into the target folder. It will then create a support LLB containing all the subVI's used by the directly called VI's. If you have VI's that are called directly from TestStand and are also used as subVI's you will again have problems because the same VI can be loaded from two different locations.
2.) I was thinking about to create a teststand deployment without a workspace file. The sequences and all required VIs would be placed in the generated labview ui instead. Will the teststand sequences find the VIs inside of the ui exe?
No Teststand will not beable to find your VI's in the EXE. If you need to use the same VI's in both your OI and TestStand sequence file then create a DLL.
But I would recommend you keep the OI code seperate from your Test Code.
3.) What about required drivers (e.g. daq-mx)? Should I create a labview installer of my ui with the required drives and install this, then create a teststand installer (perhaps including the ui, too) and install this, too?
Install your drivers first. The IO should be installed as part of the TestStand deployment as this will register the various components correctly.
Regards
Ray Farmer
Message Edited by Ray Farmer on 08-06-2008 01:02 PM
Regards
Ray Farmer

Why do I get -18001 Errors using Customised TestStand User Interface

Hi all
I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
If anyone
has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
Thanks
Dave

David,
I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
LabVIEW : VI is not executable.
An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
2) The same error will occur when
a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
Building The Operator Interface
The following are steps if you are using a LabVIEW operator interface.
1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
Creating a LabVIEW Run-time Server
If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
Assembling the Test VIs for Run-Time Distribution
This distribution process uses one of the shipping TS examples that calls LV VIs.
1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
3) Confirm that the sequence runs without problem.
4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
6) Set the target directory to be something distinct like C:\temp\AssblVIs.
7) If you are using TestStand 2.0 skip adding Dynamic VIs
8) Save with or without diagrams. Its your choice.
Change Search Directories
Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
1) In the sequence editor select Configure>>Search Directories.
2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
3) Close the Edit Search Directories dialog box.
4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
1) In the sequence editor select Configure>>Adpaters.
2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
Distributing Components
-To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
-To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
-You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
Hope this helps.
Regards,
Kitt
=========================================
Title:
Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
Components that need to be distributed:
TS engine
Operator interface
LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
LabVIEW run-time engine
LabVIEW test VIs
Test sequence files
Actions before distributing:
It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
Assemble the test VIs for distribution.
Update the TestStand search directories so that the sequences reference the assembled VIs.
Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
Test the distribution components on the development machine.
Enter section headings, separating each section with a line break:
TS Engine Component
Operator Interface Component
LabVIEW ActiveX Server
Configuring the LabVIEW Standard Prototype Adapter
LabVIEW Run-time Engine Component
Assembling your Test VIs for Distribution
Note
TS Engine Component
With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
Operator Interface Component
You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
LabVIEW ActiveX Server
You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
Configuring the LabVIEW Standard Prototype Adapter
When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
LabVIEW Run-time Engine Component
If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
Assembling your Test VIs for Distribution
After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
Links: See Distributing LabVIEW Test VIs below
Note
Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
==============================================

File path of a currently executing teststand test step

How do i extract the file path for the currently executing LabVIEW test step within my operator interface.
Many Thanks,
Dave.

Hi,
I assume you need the SequenceFile Path where the LabView test step is located in TestStand.
To reach to the currently executing step SequenceFile path you have to:
1. get the SequenceContext for the execution
2. get the currently executing step from the SequenceContext (SequenceContext.Step)
3. get the sequence in which the step resides from the Step (Step.Sequence)
4. get the containing sequence file for the Sequence (Sequence.SequenceFile)
5. get the Path from the SequenceFile (SequenceFile.Path property)
In case you want to determine the VI file path for the LabView test step Module one approach is:
1. get the SequenceContext for the execution
2. get the currently executing step from the SequenceContext (SequenceContext.Step)
3. get the PropertyObject for the step (Step.AsPropertyObject)
4. get the VI relative path from the step subproperty using "TS.SData.ViCall.VIPath" lookup string (PropObject.GetValString)
5. now use the Engine.FindFile on the retrieved path at the step 4. above, to get the path to the executing VI
Hope this helps,
Silvius
Silvius Iancu

How to store a relative path in a global variable

Hi,
I'm using Teststand 2013 and Labview 2013
Is it possible to define a relative path for a global variable in the Teststand? Ex. "..\vector1.hws"
Or I should use the Labview functions to solve this issue?
Thanks,
Solved!
Go to Solution.

Paths are so much easier to manipulate in LabVIEW. So you could store the relative path as a string and then use LabVIEW to make the absolute path.
I typically store a folder in a global variable and then I can just concatinate the strings to build the absolute path. For example:
FileGlobals.Folder = "C:\\foo\\bar\\",
Locals.Path = FileGlobals.Folder + "blah.txt"
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Adding a timestamp to a save file location

Hi,
How can I add a timestamp to a save file location in testStand?
My Teststand Sequence calls a VI to grab an image, I tell the VI where to save the image and also name it, I now wish to add a time stamp
to the image, so when I record multiple images the previous one is not overwritten.
Any ideas.
Thanks

Hi,
How can I add a timestamp to a save file location in testStand?
My Teststand Sequence calls a VI to grab an image, I tell the VI where to save the image and also name it, I now wish to add a time stamp
to the image, so when I record multiple images the previous one is not overwritten.
Any ideas.
Thanks

How to create an array Station Globals programmatically in CVI?

Hello all,
I want to create an array Station Globals programmatically in CVI. Where can I find some examples?
Thanks,
Zhonghui Ning

Zhonghui,
There is a KnowledgeBase on our website that describes the methods needed to do this. You can find the KnowledgeBase at http://digital.ni.com/public.nsf/websearch/C7C81F4AE5A46BB686256CDA005FA4C6?OpenDocument.
I found this by searching for "teststand create variable". You can find TestStand examples on our Developer Library by going to http://www.ni.com/devzone and clicking on the link for Developer Library. This page has example code as well as tutorials and application notes on many aspects of TestStand. There are quite a few examples there that already address this type of question: Creating Sequence File Global Variables Using the TestStand API with LabWindows/CVI
and Creating and Inserting a New Data Type into a Sequence File using LabWindows/CVI
We continually add examples to these web pages, so it is always a good place to look for examples. While they may not have the exact answer to your questions, the examples usually cover a topic that is close enough for you to be able to apply the example to your question.
Hope that helps.
Regards,
Shannon R.
Applications Engineer
National Instruments

Globals.ini location in teststand 2.0

Similar Messages

Maybe you are looking for