Problem in Teststand Operator Interface

I am facing problems when i try to run my sequence file from TestStand Operator Interface for LabVIEW. It gives either all tests as failed or skipped but the same sequence file when i execute from TestStand Sequence Editor it gives me correct results. I am not able to figure out what is the problem?? Somebody worked with teststand operator interface please help me to solve the problem.
Regards
Subramania Bharathi.

Hi,
Which version of TestStand and LabVIEW are you using.
Are you using a Customised LabVIEW Operator Interface or are you using the default version?
If you can provide a example of your Test Sequence File to help identify your problem.
Regards
Ray Farmer
Regards
Ray Farmer

Similar Messages

How to disable the run-time popup menu in the sequence display on TestStand Operator Interface, that allow the use to skip the test?

How to disable the run-time popup menu in the sequence display on TestStand Operator Interface, that allow the use to skip the test?

Hello,
Regarding the skip/force pass/force fail options, when I set the ControlExecFlow to True in Teststand 3.1 and 3.5, in the Sequence Editor the menu options for skip/force pass/force fail are not active for Technician but, when I launch the Operator Interface logged with Technician the options are active. The problem is that if the technician sets one step to one of these options, and change the user to Operator, the test step remains skip/force pass.
Is there any possibility without modifying the Operator Interface (at programming level), to reload default values of the steps when changing the user to Operator?
Thank you,
Best regards,
paio

How can I view TestStands Operator Interface front panel, from a VI, while a test is taking place.

I need to view the sequences and steps that are displayed during a test session while running TestStand. Except I would like to view this in a LabVIEW front panel

JD,
I'm not sure if you're asking to be able to view the actual code module's front panel (ie. VI front panel) while it's executing, or if you just want to see the steps and overall sequence in a VI front panel. If the latter is true then you can use the simple LabVIEW operator interface that ships with TestStand, as Dennis mentioned in his answer. This would indeed be a great place to start if you want to add any further functionality to the operator interface. If the former is true and you want to see the actual VI front panels of the steps as they execute, you can check that box "Show VI Front Panel" from the "Specify Module" window in TestStand.

I'm developing a test system that reqiures that I run a TCP/IP session in the background while running TestStand. How could I incorporate this TCPIP vi into the TestStand Operator Interface ?

Test Engineering
Empower RF Systems Inc.

Mal,
If you have the LabVIEW Operator Interace, you can place your TCP/IP Vi anywhere you want. Either at the beginning of the execution, when a particular sequence is running, when a user logs in, etc. Since you have the LV code, you can just add your TCP/IP as a subVI in the right place. You could also place a button in the front panel that will allow you to CONNECT/DISCONNECT by calling your VIs.
Does this help?
Azucena

Unable to include Operator Interface in TestStand deployment

Hello. I have created a test system using TestStand 3.5.
There is only one sequence file, and this sequence calls several VIs
that I have created in LabVIEW 8.0. I would like to distribute
this test system to a target computer, which will then run the default
Operator Interface. No bells and whistles, just plain and
simple. However, I'm running into problems.
First, I created a Workspace file in TestStand. I then added a
Project to it. In the Project, I added all necessary files for my
project (the sequence file as well as all of the custom VIs).
Then I proceeded to follow the TestStand reference manual in order to
deploy my system.
For reference, text in italics is the reference guide and text in bold is my comments.
Deploying the TestStand Engine
1. Launch the TestStand Deployment Utility by selecting Tools»Deploy
TestStand System from within the sequence editor.
I did this, and set up my build how I wanted it.
2. On the System Source tab, enable the Deploy Files in TestStand User
Directories option.
This option collects files from the <TestStand>\...\User
directories, so that any customizations that you have made to process
models, step types, language strings, and so on, will be distributed to
the target computer.
I did this, and copied my Operator Interfaces\NI folder to Operator
Interfaces\User. This would assure (I hope) that I would have the
default operator interfaces included in my project.
3. On the Installer Options tab, enable the Install TestStand Engine
option.
Done.
4. On the Installer Options tab, click Engine Options to launch the
TestStand Engine Options dialog box, which you use to select the
TestStand components that should be present in the installer.
Done. Everything is checked.
In the TestStand Engine Options dialog box, expand Operator
Interfaces»Full-Featured in the tree view.
a. Click the X next to LabWindows/CVI to include the
Full-Featured LabWindows/CVI Operator Interface in the engine
installation. The X should become a green checkmark.
b. Click OK to accept the new settings and close the dialog box.
This is where things go wrong. There is NO Operator Interfaces box in my tree view. It simply doesn't exist.
I've tried several different builds using different strategies.
I've done builds with the CVI operator interface in the User directory,
and I've also tried copying over the files manually. On the
target computer, I've always gotten either an error message (Could not
open the TestStand Engine), or else TestStand opens in evaluation
mode. In both cases, my custom VIs and sequence files are nowhere
to be seen. Can anyone shed some light on this? It's
driving me a bit crazy!
Thanks very much,
Brett Gildersleeve

Hi Brett,
Whenever you deploy your TestStand application to target machines, you will always needs a license. The licenses for distributing TestStand are different than for distributing LabVIEW and LabWindows/CVI code modules.
LabVIEW does not require you to purchase any run-time licenses for a deployment system. You can even run LabVIEW VIs in VI format (not executables) from TestStand without using the development environment and without an additional license.
In order to run LabWindows/CVI code modules, you will need the LabWindows/CVI Run-Time engine which is also available free of charge.
Regarding TestStand, you will need a license for each machine that runs a TestStand sequence. TestStand has three types of licenses which are the TestStand Development System License, the TestStand Debug Deployment Environment License, and the TestStand Base Deployment Engine License.
TestStand Development System License
The TestStand Development System License is required for any test sequence development and/or editing of existing TestStand sequence files that you perform within the TestStand Sequence Editor or programmatically using the TestStand API.
TestStand Debug Deployment Environment License
The TestStand Debug Deployment Environment License gives you maximum flexibility for deploying TestStand and LabVIEW, LabWindows/CVI, and Measurement Studio-based systems. This license allows you to install the development versions of TestStand, LabVIEW, LabWindows/CVI, and Measurement Studio, along with any corresponding add-on toolkits, so that you can debug your test application on your deployed test station. This license does not include the ability to perform any development tasks within the TestStand Sequence Editor or programmatically using the TestStand API.
The TestStand Debug Deployment Environment License has debugging capabilities including settings breakpoints, monitoring variable values, and stepping into test code directly from the TestStand sequence.
(Note: This license does not provide the software but rather gives you the right to install a previously purchased piece of software on the target machine.)
TestStand Base Deployment Engine License
The TestStand Base Deployment Engine License is the minimum license required for all deployed TestStand-based applications. This license allows you to deploy the TestStand Engine, a TestStand Operator Interface, and TestStand sequence files to the single test station for which the license is applicable.
The TestStand Base Deployment Engine License provides simple sequence debugging capabilities, including setting breakpoints and single stepping through test sequences in your Operator Interface. You cannot save sequences and open the sequence editor.
I hope this clears things up.
Best Regards,
Jonathan N.
National Instruments

Is it possible to shutdown TestStand LabWindows/CVI operator interface programmatically?

Hi,
Like the title says, I'm trying to find a way to shutdown TestStand operator interface automatically after sequence execution is completed.
Any suggestion is appreciated, thanks in advance.

Thank you for your reply.
I did a loop but it wouldn't work :s
I managed to create an ActiveX button to exit test stand.
I found an example within the TestStand Course I and II.
static void ExitApplication(void)
VBOOL canExitNow;
TSUI_ApplicationMgrShutdown (AppManagerHandle, &errorInfo,&canExitNow);
if (canExitNow)
  QuitUserInterface(0);
// the ApplicationMgr control sends this event when it is ok to exit the application.
HRESULT CVICALLBACK ApplicationMgr_OnExitApplication(CAObjHandle caServerObjHandle, void *caCallbackData)
ExitApplication();
return S_OK;
void CreateTSEngineHandle ()
GetObjHandleFromActiveXCtrl (panelHandle, PANEL_APPLICATIONMGR,&AppManagerHandle);
GetObjHandleFromActiveXCtrl (panelHandle, PANEL_EXIT,    &AppExit   );
TSUI__ApplicationMgrEventsRegOnExitApplication (AppManagerHandle, ApplicationMgr_OnExitApplication, NULL, 1, NULL);
TSUI_ApplicationMgrConnectCommand (AppManagerHandle, &errorInfo, AppExit, TSUIConst_CommandKind_Exit, 0,
            TSUIConst_CommandConnection_NoOptions, NULL);
TSUI_ApplicationMgrGetEngine (AppManagerHandle, &errorInfo,&EngineHandle);
TSUI_ApplicationMgrStart     (AppManagerHandle, &errorInfo);
TS_EngineGetGlobals(EngineHandle,NULL,&Globals);
This way I click my QuitButton and it calls the the ActiveXExitButton witch calls the ExitApplication function.
The ApplicationMgr control sends ApplicationMgr_OnExitApplication event when it is ok to exit the application.
Hope this was clear enough and I hope this may be helpfull for someone else.
I apreaciate all the help.
Regards,
Daniel Coelho
Daniel Coelho
VISToolkit - http://www.vistoolkit.com - Your Real Virtual Instrument Solution
Controlar - Electronica Industrial e Sistemas, Lda

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.
==============================================

Error Generated by DIO Port Read when using a compilied Operator Interface

When using a compilied version of an TestStand Operator interface, a Vi that reads the status of a port on a PCI-6602 board stops working. Within this VI a sub VI called Read DIO Port brings back an error -10007. But when I use the un compilied version of the operator interface there is no problem with the VI.
Why is this so?
Attachments:
Get_SIU_Switch_States.vi ‏58 KB

I have tried to simulate this issue and I have not been able to replicate your issue.
I know the -10007 occurs when you try and create/use a resource index that is not possible i.e if your referencing channel 9 and the device only has 8 channels.
Have you managed to overcome this issue yet?

User manager in operator interface

How can I add/edit list of users in TestStand Operator Interface?

Hi hss,
In your teststand examples is a useful example called CreateDeleteUsers.seq
It demonstration creating and deleting of user by running a sequence and using the TS API calls.
To simply add the capababilty you require to your OI, all you need to do is add it to the tools menu.
See attached bmp showing CreateDeleteUsers.seq linked in the Tools Menu. Also note that its only available in the Operate Interface.
Beware, this example is only a demonstration and requires additional error checking such as checking for duplicate entries.
Hope this help
Ray Farmer
Regards
Ray Farmer
Attachments:
Customize_Tool_Menu256.bmp ‏321 KB

Remove step icons from CVI Operator Interface to improve execution performance

The CVI Operator Interface updates the icons for each step (lower right) when tracing is enabled. Can these be stopped but the steps still visable and would this improve execution performance.

Hi Dave,
I take it you are using the old style Teststand Operator Interface.
The only way would be to modify the code in the exedisp.c, in UpdateOnStepChange() function. Just comment out the SetCtrlBitmap() function there are two calls in this function.
As to whether it is going to make a noticable different in performance, well that depends on the spec of the controller (PC), graphics card etc. you are using. But you probably wouldn't notice any diference.
Before you make any changes, copy the sub-folders from the NI folder to the User folder and work from the User folder.
Regards
Ray FarmerMessage Edited by Ray Farmer on 05-07-2005 06:29 PM
Regards
Ray Farmer

Problems in Operator Interface for LabVIEW

Hi Ray,
I am using LabVIEW 7.0 and TestStand 2.0 version. I am using the default operator interface for labVIEW provided in the TestStand and i am using custom step types in my sequence file.
This sequence calls a VI, which transmits strings that i specify from the serial port to the NI-7831 RIO Fpga Card for differnt baud rates. The same sequence is working fine when called from Sequence Editor but it is not working when it is called from Operator Interface for LAbVIEW. It justs either fails the test or skips them. Please tell me if there is any solution for it. I have attached the sequence file and the vi that i am calling from my sequence file.

Hi,
You forgot to attach your sequencefile and VI, but never mind.
I think the problem maybe that because you are using the default Operator Interface.
If it still the one in the NI folder, then you will have to re build the testexec.exe application using your LabVIEW 7.0 Application Builder. The default exe file has been built using LabVIEW 5.1.1
Before you start, copy the LV folder from OperatorInterfaces\NI\ to OperatorInterfaces\User.
Load the testexec.bld file in your Application Builder and rebuild testexec.exe.
Launch your new testexec.exe from the User\lV folder and retry your test sequencefile.
Hopefully that should cure your problem.
Regards
Ray Farmer
Regards
Ray Farmer

Send UI meassages from teststand sequence to Simple CVI Operator Interface with Asynchronous Timer

Hello,
Is it possible and how is it possible to send UI meassages from a teststand sequence to the Simple CVI Operator Interface with Asynchronous Timer which could be downloaded from NI Hompage. I use this problems because it is more stable than the standard OIs
regards samuel

This post could help:
http://forums.ni.com/ni/board/message?board.id=330&message.id=7567
Regards.

Problems to show IVI driver, properts loader when using operator interface

I am using the Operator Interface (programmed in CVI, with asynchronous timer) in folder OP1 in attached zip file. This operator interface puts not the error message of IVI driver, properts loader etc... on the screen (messages like in attached picture error.jpg in attached zip file). Because of stability problems I am using this operator interface but I need these error message.
A Other Operator interface is OP2 in attached zip file. This operator interface puts the error message of IVI driver, properts loader ... on the screen (messages like in attached picture error.jpg in attached zip file).
Now I want to have this functionality with OP1 becaus of stability reasons I have to use OP1.
How can I implement this in OP1? I tried and searched a lot of time but I have not found a method to implement this.
can anyone help me?
thank you
regards Samuel
Attachments:
OP.zip ‏3405 KB

Hi Sam,
if you open the userinterface which comes with Teststand - the simple one - you should be able to find the difference. You can find it here:
C:\Programme\National Instruments\TestStand 4.1\UserInterfaces\Simple\CVI
I hope this helps.
Greetings, RMathews

Hide disabled executions in Teststand 4 Operator interface?

Hi:
I'm customizing the Teststand 4 Full Featured CVI Operator interface.
When running in the Batch model, we often run on less then the full number of test sockets indicated in our model options.
In this case, the unused test sockets show up as disabled executions in the operator interface.
Is it possible to hide the disabled executions?
Thanks,
Dave

Hi:
I was working on the batch model TileWindows changes in parallel and had noticed the tracing problem as well. The TileWindows subsequence from your BatchModel fixes this problem - thanks.
However, I'm able to reproduce a run time error through a sequence of (perhaps unlikely) events:
* start a test sequence with 4 test sockets using the batch model
* run the first socket, terminate in PreUUT, don't restart the first socket
(only the initial TestUUTs execution plus socket 0 will be visible in the operator interface, as expected)
* run the second socket, terminate in PreUUT, don't restart the second socket
(only the initial TestUUTs execution is visible in the operator interface)
* run the third socket, terminate in PreUUT: run time error popup:
Execution is already closed. Not found in list of executions
Operation Failed. [Error Code: -17500]
I'm assuming this has to do with the PreUUT call being before the TileWindows call. Suggestions on how to get around this error? Do I need to force all socket windows back open before the TileWindows call to catch this condition?
Thanks,
Dave

TestStand 4.0 Operator Interface Changes Not Seen

Hi guys,
Ive worked with TestStand before, but now im trying to modify the operator interface (located C:\Program Files\National Instruments\TestStand 4.0\UserInterfaces\NI\Simple\LabVIEW). Well, i try to modify the VI in the project, but i cant see my changes when i run the VI. Ive tried building the executable and see that hte executable does get rebuilt, but none of my changes show up.
Also, how does the "entrypoint 1" button get renamed to something else when the VI actually runs?
thanks
jeff

Looking at the help, it appears that the TestStand button only uses the system color unless it is in toolbar mode. If you want to use a LabVIEW button instead, you can implement the button action by calling <SequenceFileViewMgr>.GetCommand(...).Execute().
This thread might help you determine when to dim or enable the button: http://forums.ni.com/ni/board/message?board.id=330&message.id=15720
Here is the button help:
BackColor Property
Syntax
Button.BackColor
Data Type
Color
Purpose
Specifies the background color for the Button control.
Remarks
When you set Style to ButtonStyle_ToolBar, this setting applies to the face and border of the button. When you set Style to ButtonStyle_Standard, the button face adheres to the system settings, and this setting affects only the border of the button.
See Also
ButtonStyles
ForeColor
Style

Problem in Teststand Operator Interface

Similar Messages

Maybe you are looking for