TestStand 4.0 Types

We have a large TestStand project with multiple development PCs and developers. We are using Perforce to source control and share our work. We have created some custom type files which are in the Teststand\Components\User\TypePalettes directory which we have put under source control. This has worked well in the past.
We recently upgraded to TestStand 4.0. Subsequently, we decided to customize the order of the Step Types in the insertion palette. After customizing the Step Type Menu, all of the type files under NI's directory and the User directory in the Type Palette are starred indicating that they all have changes to be saved.
If we save all the type files on that PC and then check in our custom type files under \User, we would like to be able to go to our other development PCs and get the latest revision of the type palettes in the \User directory and have those other PCs show the new step type menu structure. That does not happen unless we also copy the \NI\TypePalettes\NI_Types.ini file to the other PCs.
We have three workarounds, all of which have negative consequences:
1) Leave NI_Types.ini out of source control and manually copy it to the \NI directory of each development PC every time we change the Step Type Menu.
The bad: prone to error if a copy is not done on one station or if the wrong version of NI_Types is copied.
2) Copy NI_Types.ini from the \NI to the \User add add it to source control. This allows us to automatically update our Step Type Menus across all the dev PCs just by getting the latest revision of \User from Perforce.
The bad: TestStand now shows two versions of NI_Types in the Type Palette, one from \NI and one from \User. We had hoped that once TestStand found NI_types.ini in \User, it would no longer use the one in \NI, as happens with other files that are copied from \NI to \User such as the sequential model.
3) Do 2) and additionally manually delete NI_types.ini from \NI on each dev PC.
The bad: It's a manual operation that will have to be remembered for each existing dev PC and any new ones we buy. Then when we upgrade to a future TestStand version, we're guessing that NI_Types.ini will again show up in \NI so we'll have to manually delete it on each PC again.
Questions
1) Is it a bug that a TestStand modification such as editing the Step Type Menu makes changes to files outside of \User? It does create problems for us. We thought the whole point of \User was to avoid these types of issues.
2) Is there a better workaround than what we have come up with?
Thanks,
Hans

For anyone that is looking for the answer to this post, it can be found here.
Pat P.
Software Engineer
National Instruments

Similar Messages

The type library information for 'TestStand IVI Step Types' was not found (Error code: -18351)

Hi,
I get the error in the message subject when I add an IVI-C step (no matter IVI Power Supply, IVI Dmm or others) and try to edit the step by pressing Ctrl+E (or double-click the step and click "Edit IVI Power Supply" for instance).
I have installed 2 IVI-C libraries that I downloaded from 'NI idnet' both with IVI technology (namely agn330xa_MS.msi and agn6700_MS.msi). They can both be seen in Add/Remove programs under "NI IVI Specific Drivers" group.
The error message says "Make sure the server is registered".
Does anybody know what server is it complaining about and how can the registration be done?
Regards,
S. Eren BALCI
www.aselsan.com.tr
Attachments:
error 18351.jpg ‏66 KB

Hi ebalci,
I believe this error is occurring because the ActiveX components that are used by the IVI step types are either not properly installed or not properly registered. I would recommend first making sure that the IVI compliance package and NI-VISA are installed on the system. If both of these are already installed, I would recommend running the TestStand Version Selector because this should re-register the ActiveX components used by the IVI step type. The TestStand Version Selector can be found by going to the Start Menu>>Programs>>National Instruments>>TestStand 3.5. You will need to select the version of TestStand you want to use and click the "Make Active" button. I have also pasted links below to VISA and the IVI compliance package. Hope this helps!
NI-VISA
IVI Compliance Package
Pat P.
Software Engineer
National Instruments

Why Teststand modifies the types folder though i haven't done any modification?

I have a custom step type which uses a custom data type. When i open the sequence, Teststand immediately modifies the step type and says (modified) next to the version in the types view. Also it puts a star mark next to my sequence file name. Now i save my file and close it. When i open the file again, Teststand modifies the step type again and puts a star mark mext to my sequence file name. From other posts, i have found that it has something to do with my custom data type version.
Any more light on this issue would be much appreciated.
Attachments:
VerifyCANMessage.seq ‏6 KB

Hi Sarasvisu
It seems you have a type confict.
You could use SequenceFileDiffer.exe to solve it.
or maybe you could slove it with TS editor itself
just goto
1.) Configure->StationOptions->Preferences->"Before Saving Modified Types:" Set to "Prompt to Increment Types"
2.) If using TS4.2 Configure->StationOptions->File->"Allow Automatic..." Set to "Never"
Hope this helps
Juergen
=s=i=g=n=a=t=u=r=e= Click on the Star and see what happens :-) =s=i=g=n=a=t=u=r=e=
Attachments:
Message.jpg ‏131 KB

TestStand's container type from LabVIEW

Hi,
With a LabVIEW's VI, I'd would like to set a TestStand cointainer as a TDMS file properties.
So i tried to get all the elements of my container using PropertyObject Class (ThisContext.AsPropertyObject)
with this method :PropertyObject.GetValVariant
( lookupString, options)
But i get an error because of Set TDMSproperty method doesn't accept the variant type i got.
So I'd like to get the type (string, number....) of each elements of this container to setting them as TDMS properties one by one through a for loop.
How can i do that?
Alex

I have a TestStand sequence. In this sequence i have defined a container (filesGlobals) who contains some results of the current Sequence execution. At the end of the sequence execution (in the cleanup) i want to get all the container's values to set them in a TDMS file.
So i have made a VI who gets all these datas using ActiveX properties. This VI will be called as a TS step.
But i don't know what are the types (string, number, boolean, array of...) of the varaibles of my container, so i use a method to get Variant. When i want to set my TDMS with this variant an error appears because the variant type is not allowed for TDMS files. So i need to make a VI who could get the type of each variable of my container to convert it in this type and so send it in my TDMS.
TestStand FileGlobals                                         LabVIEW
MyContainer{}                                                       TabName                  TabValue                        TabType
    Name (string)                                                        (0) Name                  (0) AlexString                  String
    Reference (Number)                     ==>>                  (1) Reference            (1) 1003214                     Number
    ResultOfTest (Boolean)                                        (2) ResultOfTest        (2) True                           Boolean
    Errors (Arrays of string)                                          (3) Errors                  (3)                                  String
    ....                                                                             [0]                            ErrorA
                                                                                     [1]                            ErrorB
With this 3 tabs i could send each varaibles of my TS container elements by elements usisng a for loop as define here:
for (i=0, i++, i<sizeof(TabName))
     if (Tabtype(i) == String)
          {TabValue(i) = getStringVal}
     if (Tabtype(i) == Number)
          {TabValue(i) = getStringVal}
     if (Tabtype(i) == Boolean)
          {TabValue(i) = getStringVal}
     Set TDMSNameProperty
     Set TDMSValue
So i need to get the type of all my container's varaibles.
Like that i will not obliged to get only Variant and could get the correct type to send to the TMDS...
Alex

TestStand custom data types

I created a container in custom data types and pass it into a VI as an input variable. The problem is whenever I step into my VI, the values passed in from the container changed to another set of value, also the value is not random, I could consistently get back the same value. Is there any setting that I need to apply when using the container?

There is no special setting required. Look at the simple example in the attach. I have created a custom data type "cluster" containing string, numeric and boolean variables. If you will execute the VI then you will se how appropriate values pass to the VI.
Hope this will help,
Max
Attachments:
screen.JPG ‏140 KB
stub.vi ‏6 KB
test.seq ‏5 KB

TestStand Action Step Type

Hello, all--
I have a TS question on the Action step type, no adapter. In code I am maintaining, I see this step type used to output information to a custom report. The data/comment to output is put into StationGlobals.Measurement.String and StationGlobals.Measurement.ActionType is set to 1 or 2. The TS documentation tells me the action step is an NI step type, and it doesn't appear that this has been customized in any way. I cannot find any documentation either in built-in help or online explaining how to use the action step in this manner or what values are valid for .ActionType and what they signify.
Am I wrong? Is this a customized step type, or is this use just undocumented? If someone has knowledge about using action step like this, please reply. Thanks very much.

Hey ctakac,
Look in your StationGlobals. Ctrl-G or View->StationGlobals. In there you should have a container (I'm assuming) called Measurements. If you expand that you should see String and ActionType. It should tell you the type in the Type column. It is probably Number since it's set to 1 or 2. Whoever set up your StationGlobals inserted this as I've never seen it before.
The Action Step Type is native to TS and they are probably using those StationGlobals to either get set or set a step property. Go to the step that is doing this and look at the properties. Look in the Expressions and see if they are using them there. They could also be used in the Precondition or PostAction.
Let me know what you find,
Regards,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Latest IVI Class Step Types in TestStand

IVI instrument classes have recently been defined for RF Signal Generator, Spectrum Analyzer and Power Meter. There are IVI drivers for these classes available for download from the Instrument Driver network. However, TestStand3 does no contain step types for accessing these drivers. Does anyone know when NI plans to add support for these to TestStand? Has anyone created step types for these classes, or have an example of how to do this?

David -
There is no documentation on the low-level workings of the TestStand IVI step types. As with many of the step types that have source code, it is available as examples of developing a step type in various languages.
The additional work to add the a new class to the TestStand IVI step types is not small, that is why to date we have not done it. The amount of work could be divided into the following areas:
* Update the TsIviStepTypes to add the new class to the enumeration.
* Create the new step type definition (subproperty structure) based on the IVI spec.
* Upcate the TSIviStep and TSIviSFP code to allow you to edit and perform the work to process the expressions and initiate the various IVI class operations.
* Add low level
IVI class layer logic to talk to the IVI class driver. This piece was previously done in a VB ActiveX control written by the Measurement Studio group in NI.
The last two items are the biggest and they would take some time. That is why I was suggesting creating specific Action steps that call into custom code modules to talk to IVI directly, that is, no edit dialog box, no SFP, etc.
Scott Richardson (NI)
Scott Richardson
National Instruments

I Date TestSTand data type

TestSTAND date data type
I use TestSTAND pop up message to request user to input date in the input string
for example: 10/8/2008 in TestSTAND input string in popup message.
I assume this is a string
how do I compare this date to today date or any other date.?
Does TestSTAND have a TestSTAND Date data type?

Hi,
No TestStand doesn't have a Date type.
The Date() function returns a string i.e "20/10/2008". Therefore, providing you entered in the same format you could do a StrComp(Locals.DateEntered, Locals.CurrentDate) which if the same would return 0.
But you could get Date() to return the individual Year, Month, Day values then you could do a check on these values. Check out the syntax in the Function Browser.
Hope this helps
Regards
Ray Farmer
Regards
Ray Farmer

How to make teststand understand I64 data type

I am calling one Labview VI in teststand where the input is numeric (representaion I-64).
Under the Module Section the Parameter Name, Type, In/Out, Default information is grayed out for the input.
Teststand understand the input if I change the same control to I32 type.
How can I make teststand understand I64 type of input?
Thanks,
Vidula

As a workaround, if you could convert it to a double in LV, you could still do math and comparisons with it as a single value in TestStand. To do this, you would have to be sure your value won't ever exceed the maximum integer range a double can losslessly represent, which I think is around 2^52.
For example, I think this would be an option if your value represented a file size in bytes for a file that you know is guaranted to always be smaller than a petabyte.

Step Type Problems with TestStand 3.5

I have a TestStand system where I have created some custom step types (Created originally in TestStand 2.0). I've
used these step types successfully in TestStand 3.1 projects with no problems.
With TestStand 3.5 I have a recurring problem that I cannot clear.
Once the custom steps have been added to the system, I re-load my Process model sequence files and resolve type
conflicts by selecting currently loaded types. (Since my process model utilises these steps and was developed under
3.1)
I save the Process Model and then load in my test programs, again resolving type conflicts by selecting currently
loaded types.
So far so good.
However, when I exit the sequence editor I'm ALWAYS being prompted that the NI_FlowControl.ini typepalette file has
been changed.
This happens even when I set the system to have NO Process Model selected and don't load a program! i.e. I open the
sequence editor and shut it down immediately.
1. Why isn't the Sequence editor prompting me that it's about to change the typepalette file?
2. Why is it changing the type? (And at what point is it happening?)
3. I have no indication as to what has changed within the type and where the conflict is coming from.
4. Why is saving the type having no effect whatsoever?
At one point with a configuration it kept telling me that the NI_DatabaseTypes.ini file had changed (and that it was
the only one to change) I experimented by removing that type palette entry (since I didn't use the database steps
with my process model) and it then started complaining about one of the other NI types as being changed! (Is this a
TestStand bug?) or is there a decent explanation?
I've even tried redefining the typepalette files of my step types to create a clean system, but it all falls apart
whenever I try and load an existing test program. No matter how careful I am, TestStand insists on changing loaded
types without telling me or giving me the option to choose what I want to do!! (Note - re-writing the test programs
is NOT an option!)
Any ideas would be welcomed....

Brian,
Have you modified the CommonResults data type? What is the version that you have loaded? I have seen this problem when you have a newer version of a data type than the engine loads on startup. You can fix this problem by either reverting back to an older version of that type (the same as the engine version), or using the following workaround:
In TestStand, open your type palette window. In the Palette pull down ring select "Customize". Create a new type palette and make sure it is the top-most palette in the list. Name it whatever you like. Click "Ok". Now select your NI_DatabaseTypes.ini from the pull down. Go to the "Standard Data Types" tab, select the "CommonResults" type and copy it.
Select your newly created type palette from the pull down, and paste the "CommonResults" type into this palette. Save all of your palettes.
You should no longer be prompted to save your type palettes unless an actual change has been made.

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

How can I convert a Database Handle from TestStand to LabVIEW?

I want to use a Database Handle (already created in TestStand by an Open Database step) in a LabVIEW-VI (called from TestStand) to connect it with the "Connection Reference" input of the "Easy SQL.vi"? If I use a directly connection via the "TestStand - Get Property Value (Number).vi" I get back the error message 4101 in LabVIEW. How can I convert the Database Handle?
Test Engineering
digades GmbH
www.digades.com

The TestStand database step types use the CVI SQL Toolkit to talk to databases. The handle that you are referencing is an internal memory location and not a actual handle that you can directly use. Currently as implemented the handle that is stored in a numeric TestStand property for the connection and the SQL statement are the handle values returned from the CVI SQL Toolkit. So for the connection handle, you could call the CVI SQL Toolkit function
DBGetConnectionAttribute (
int Connection_Handle,
tDBConnectionAttr Attribute,
void *Value);
and get the CVI CAObjHandle reference. With this you could then call the CVI ActiveX function
CA_GetInterfaceFromObjHandle(
CAObjHandle Object_Handle,
const IID *Interface_Id,
int Force_AddRef,
void *Inte
rface_Ptr,
int *Did_AddRef);
to get the actual ActiveX interface reference. This would have to be converted into a LabVIEW reference.
You may want to consider just using LabVIEW to open a new parallel reference only using the toolkit.
Scott Richardson
National Instruments

5112 in Teststand using IVI step

I am trying to configure with options and set the 5112 to average but get an error. I also can not validate any of my niscope settings. The step seems to work when I execute it, and I only find out what is not supported when it fails.
Error executing substep 'Post'.
An exception occurred calling 'RunStep' in 'ISubstep' of 'TestStand Ivi Step Types 1.0 Type Library'
An error occurred while executing the step.
Component Works IVI Control Error: The IVI Configure operation failed for logical name 'niScope'.
Details: Extension capability not supported by instrument driver. (AverageAcquisition)
Source: TSIviStepTypes
Please help.

If you are running TestStand 2.0, you will need to upgrade to 2.0.1. You can get information about this at www.ni.com/upgrade. If you are currently using 2.0.1 then I need to know what version of NI-Scope and what version of the IVI engine.
Michael

How to access the attributes in an object using TestStand.?

hi,
I have a class named Status in C# that has 2 data members. There is another Class named Parameter and it has functions that return objects of type Status.
I made the DLL of the class Parameter. Then i added that class to NI TestStand and called a fucntion and that function is returning an object of type Status.
Is there any way by which i can access the Data Members of the returned Object in TestStand ??
Thanx in advance
Solved!
Go to Solution.

Yes, there is another alternative. If you make Status a value type (i.e. a struct in C#) then you can tell teststand to store it in a corresponding TestStand data structure rather than an object reference variable. This works even for private fields in your struct. To do this:
1) First make Status a value type and make whatever other changes are necessary in your code to account for this (value types are copied when passed by value to another method, if this is not what you want you will need to pass them by reference - i.e. ref keyword in C#).
2) Recompile your assembly.
3) In the TestStand .NET module specification panel you should now see a new button next to the expression for the return value of type Status that looks like the TestStand data type icon. Push that button and it will prompt you to create a TestStand custom data type that corresponds to the .NET type. Select to save the type in MyTypes.ini type palette file. You only need to do this once. Once the type is in your MyTypes.ini type palette file it will be available from then on and you only need to update it if you change the .NET type.
4) Create a local variable of the TestStand Custom data type instead of Object Reference. Note that you can expand it and see the properties underneath.
5) Use this new local variable to store the Status return value. TestStand will copy/update the properties of the variable to correspond to those of the .NET struct that the method returns.
NOTE: You can also just store the individual fields of a struct in separate variables by expanding the return value of type Status once it's a struct and specifying a separate variable for each field rather than creating a TestStand custom data type.
Keep in mind that TestStand is making a copy when you store a struct this way so changes to the struct after this will not be reflected in the copy.
Hope this helps,
-Doug

Ho to run LV-DLL in TestStand with bool-parameters?

Hello,
i´m using LabView 8.21 and Teststand 3.5. Currentlly i´m playing with the project-Explorer where i´m creating DLLs.
The first and easiest step was to create a new VI with string-in and string-out.
Then i added this vi to my project and created a DLL from it.
This DLL is called in TestStand where the parameters are automatically detected and everything works perfect.
But when i add an boolean-input and boolean-output und do exactly the same then Teststand says:
"This function either does not have parameter-information in the DLL or uses types not recognised by teststand."
The type of the boolean is "LVBOOLEAN" in the created header-file.
What
am i doing wrong? Why is this simple bool-value not working? If bool
works not then i can never use the Labview-error-out-cluster inside a
DLL?
Or is there an easy trick to solve this?
Thanks for your help

Hi OnlyOne,
I just verified your issue and figured out that a boolean value cannot be transfered to a LV dll, because the datatype representation of a boolean is different in LabVIEW than in C.
The flexible Prototype adapter from TesStand can identify the functions of your LabVIEW dll when you use basic datatypes like scalars, pointer to scalars or C strings. That's the reason why it works in your "String dll".
When one uses LabVIEW specific datatypes there will no typelibrary provided and it's essential to define the prototype manual in TestStand. I found a link that provides some more information to that:
http://digital.ni.com/public.nsf/websearch/DBCE27265FFB554986256C9400026FE8?OpenDocument
One possibillity to transfer boolean values simply to a LV dll would be to use a numeric value, for example an integer and use a comparison like "!0" in the LV dll to determine if the status means "true" or "false".
Hope that helps to come along with your application,
regards,
Nikolai

TestStand 4.0 Types

Similar Messages

Maybe you are looking for