LTT GUI Manual

• System Overview
• Folder Structure
• Setup Guide
• MesSy Version Setup

A life time tester (LTT) is an electric control cabinet, whose purpose is to perform long term electrical tests on various electrical devices (so called devices under test, or short DUT) under certain environmental conditions (temperature, humidity, etc.). One can say, it simulates the aging process or lifetime of an electrical device.

The IRS LTT software, which comes with every IRS life time tester is composed of several parts.

This is the documentation of the IRS LTT software, including the graphical user interface (GUI), the TestStand sub system and all other related components.

After installation you will find a certain folder structure below your root installation folder.

The 50_LTT_SW folder content is like below:

If you start a brand new LTT GUI installation for the first time you need to perform certain setup tasks before you can load and run a LTT TestStand sequence file.

Although the GUI assists you with this task by displaying various messages, an overview of the minimum steps needed to run a LTT TestStand sequence file is given right here.

Each of the below steps links to the corresponding chapter in which the required action will be explained in detail. In each of those chapters a back link to this setup guide is provided, so you can easily jump between the setup guide and the individual topics.

For the first 3 steps the LTT GUI may not be open. Please close the GUI if you have it currently open.

Click to open the main configuration file ltt_main_config.xml.

The main configuration file contains:

• some flags to determine certain behaviours
• some LTT settings like project name and cabinet number
• some GUI settings for display purposes
• some paths
• database configuration
• backup settings (read more)

Please note, not all parameters are explained. Only those you are meant to change. Undocumented parameters are for internal purposes only.

1.1.2.1.1Flags

1.1.2.1.2LttSettings

1.1.2.1.3Paths

Do not change any of the paths.

1.1.2.1.4GuiSettings

1.1.2.1.5BackupSettings

Read more.

Click to open the module configuration file ltt_module_config.xml.

For training or demonstration purposes you can take the default module configuration and go on with your setup.

The module configuration's main purpose is to configure the drivers for LTT standard hardware, which is:

• power supplies (for the DUT's)
• temperature sensors (for climatic chambers)
• temperature chamber contact (TCC) (digital I/O)
• uninterruptible power supply (UPS)

Each LTT hardware is configured by a <Module name="xxx"></Module> block. The name attribute determines the type of hardware and the concrete instance of it.

A LTT can have multiple instances of a power supply and/or temperature sensor, but only one TCC and UPS.

The name attribute value is composed of a predefined prefix and an optional index number starting with 1. The index number is mandatory for those hardware modules, which are able to have more than one instance, even if only one instance is used.

After installation there is a default module configuration, containing 2 simulated power supplies and 1 simulated temperature sensor.

Each module has at least a path parameter, which is mandatory and pointing to the driver file for this module. A module driver is a file with the extension .lvlibp. All so far existing module drivers are located at

50_LTT_SW\LTT TS\lib\IRS.Mod

The path to the module driver should be provided relative to the 50_LTT_SW\LTT TS folder.

Each module type comes with a default simulation driver. That way you can run the LTT SW without having any actual hardware.

Any other parameter a module may need is provided in form of a <Parameter name="xxx" value="yyy"/> block. The parameters of each possible module type are explained in the following sub chapters.

All power supply (PS) modules have the following mandatory standard parameters:

Depending on the specific PS module, there might be additional parameters, which are described here.

Per default a power supply configured here is controlled by the underlying LTT software layer. This means the PS is automatically initialized and configured to the provided parameters. Nevertheless, in your testplan you can still change voltage and/or current during runtime, as well as access the latest values read from that PS (see here). But you have no control over when the PS is initialized/closed and when the output is turned on/off.

1.1.2.2.1.1TestStand-only control

There are situations in which you might need more control over your power supply from within TestStand. For such situations you can provide the tsonly="true" attribute to the Module node.

<Module name="PS1" tsonly="true">
...
</Module>

If you do so, you are in charge of initializing, setting and closing the power supply properly. Read here to learn how to do.

You can access the PS control panel through GUI and also via TestStand. However, the control panel is not available for self-controlled (tsonly="true") power supplies.

Some power supply drivers have additional parameters besides the standard ones described in here.

1.1.2.2.1.2.1Delta.PSC232

1.1.2.2.1.2.2EA.PSI800R

1.1.2.2.1.2.3Model

1.1.2.2.1.2.4Keysight.E363X

1.1.2.2.1.2.5Kniel

1.1.2.2.1.2.6Kniel.New

1.1.2.2.1.2.7Sim

1.1.2.2.1.2.8TDK.Gensys

1.1.2.2.1.2.9TDK.GensysPlus

1.1.2.2.1.2.10TDK.LambdaZ

The standard TCC module is a NI PCI-6503 24 channel digital in/out card. The 24 channels are grouped by 3 ports á 8 lines. This card is also used for the UPS. For the TCC port 0 / lines 0 - 7 is used. For the UPS port 1 / line 0 is used.

A temperature chamber contact module has the following mandatory standard parameters:

You can access a TCC control panel through GUI and also via TestStand.

A temperature sensor (TS) module has the following mandatory standard parameters:

Depending on the specific TS module, there might be additional parameters, which are described here.

You can access the TS control panel through GUI and also via TestStand..

Some temperature sensor drivers have additional parameters besides the standard ones described in here.

1.1.2.2.3.1.1PMA280

The "uninteruptable power supply" (UPS) module is responsible for reacting to power failure by shuting down the LTT software while the UPS provides battery voltage. The UPS module is actually no driver for a UPS but a driver for a digital input card, which will be set when the overall LTT power supply fails.

The standard UPS module is a NI PCI-6503 24 channel digital in/out card. The 24 channels are grouped by 3 ports á 8 lines. This card is also used for the TCC. For the UPS port 1 / line 0 is used. For the TCC port 0 / line 0 - 7 is used.

An uninterruptible power supply has the following mandatory parameters:

Click to open the MesSy configuration file ltt_messy_config.xml.

The MesSy signal configuration is where your DUT outputs and inputs are mapped to the corresponding MesSy inputs and outputs. You need to adjust this configuration depending on how your DUT's are connected to the LTT.

For training or demonstration purposes you can take the default MesSy configuration and go on with your setup.

The definition of the MesSy analog inputs are important for the signal definitions in LTT GUI's project wizard.

The file format for the MesSy signal configuration is different in MesSy V2 compared to MesSy V1. Depending on what you have selected during installation, the configuration file is for that MesSy version. If you want to switch to other MeSy versions read about changing the MesSy version.

You can find an example MesSy signal configuration file with all possible features and explanatory comments here:

• 50_LTT_SW\LTT TS\lib\IRS.MesSy\SignalConfig.Example.xml
• 50_LTT_SW\LTT TS\lib\IRS.MesSy\V1\SignalConfig.Example.xml

The new LTT software can be used with both MesSy V2 and MesSy V1. During installation you have to choose for one option but you can switch to the other MesSy version at any time afterwards.

Before you setup the MesSy version in LTT software make sure that LTT GUI is closed.

To switch from one MesSy version to the other you need to perform some configuration changes in different places. The following table describes those changes.

- 1 for MesSy V1
- 2 for MesSy V2 |

| ltt_messy_config.xml | The MesSy signal mapping file has a different format for MesSy V2 compared to MesSy V1.

You will find an example signal configuration for MesSy V1 here: 50_LTT_SW\LTT TS\examples\ltt_messy_config_V1.xml

You will find an example signal configuration for MesSy V2 here: 50_LTT_SW\LTT TS\examples\ltt_messy_config_V2.xml

Depending on what you have chosen during installation, one of those signal configuration files is copied to 50_LTT_SW\LTT Config\ltt_messy_config.xml for use in a LTT testplan.

If you want to create a testplan for the other version of MesSy, simply copy the corresponding MesSy signal configuration file from 50_LTT_SW\LTT TS\examples\ to 50_LTT_SW\LTT Config\ltt_messy_config.xml. | | LTT Template.seq | With the LTT installer there comes a LTT template sequence file - one for each MesSy version.

You will find the LTT template sequence file for MesSy V1 here: 50_LTT_SW\LTT TS\lib\IRS.MesSy\V1\LTT Template.seq

You will find the LTT template sequence file for MesSy V2 here: 50_LTT_SW\LTT TS\lib\IRS.MesSy\LTT Template.seq

Depending on what you have chosen during installation, one of those template sequence files is copied to 50_LTT_SW\LTT TS\LTT Template.seq.

If you want to create a testplan for the other version of MesSy, simply copy the corresponding template sequence file to 50_LTT_SW\LTT TS\LTT Template.seq. | | LTT GUI - Project Wizard (F3) | Open the project wizard in LTT GUI and go to Test Station Configuration. Read the corresponding chapter for more informations. |

For TestStand integration read chapter MesSy Integration.

Click to open the history configuration file ltt_history_config.xml. Be aware that after a fresh installation, this file is not present and will be created after you start the LTT GUI for the first time.

For training or demonstration purposes you can take the default history configuration and go on with your setup.

The history configuration defines what columns and in which order they should be written to the history files.

The LTT GUI creates a so called history log file for every station (DUT) and test order. The main purpose of the history files is to log failed limit tests during test execution. But also other generic status information will be logged to the history files. You can create custom history log entries by yourself from any TestStand sequence.

• How to create a history log entry?
• More information about history data

Each history log entry is put into a separate line in the history file and is accompanied by a number of auxiliary information, such as date, time, climatic chamber temperature and so on.

You can choose what additional information are logged with each log entry and in which order they should appear in the file.

1.1.2.4.1Available Column IDs

There is a predefined set of available data, which you can pick by using a certain identifier. The following table gives a list of all possible data you can pick.

For each history column you write a line

<HistoryColumn ID=[SOME_ID] name="MyColumnHeader" />

where you set the ID to one of those in the table above and provide a name for the column header. The default history configuration already contains all available columns in a certain order. You can change the order and/or maybe remove some unwanted columns or add additional custom columns.

1.1.2.4.2Format Specifier

You can also add an optional format attribute to each HistoryColumn entry.

<HistoryColumn ID=[SOME_ID] name="MyColumnHeader" format="F2" />

The following format specifier are available:

If no format is specified, string is assumed.

1.1.2.4.3History File Split Size

Usually history files will be split into several chunks if the file size exceeds a certain limit. The default file split size is 1 MB (1048576 bytes). You can change this value by adding a size_limit attribute to the top level <LttHistoryColumnConfig> element.

<LttHistoryColumnConfig size_limit=10485760>

The above will set the file split size to 10 MB.

1.1.2.4.4History File Column Separator

By default the history columns are separated by a semicolon ;. You can change the column separator with the following attribute:

<LttHistoryColumnConfig separator="|">

The above will set | as a column separator.

1.1.2.4.5Custom Columns

You can define any number of custom columns for the history files. To do so add HistoryColumn entries with the ID CUSTOM. The provided name will be the column header.

<HistoryColumn ID="CUSTOM" name="HV Voltage" />
<HistoryColumn ID="CUSTOM" name="HV Current" />
<HistoryColumn ID="CUSTOM" name="U_Kl30_Sense" format="F2" ShowInStationPanel="false" />

Custom columns get their values from TestStand. Those so called runtime values are displayed in GUI for each station display as well as inserted into the history file's custom column with the matching name.

If you do not want to have such a runtime value to be displayed in GUI but only be shown in history file you can add a ShowInStationPanel="false" attribute to that HistoryColumn element.

The following configuration files are generated through the GUI and not meant to be edited manually. Any manual changes to those files will be overwritten by the next GUI start or stop.

The purpose of the generated configuration files is mainly documentation, and in case of limit files, exchange. The files are also used by any LTT TestStand sequence file, rather than accessing the information from the configuration database.

You will find the limit configuration files at [Install Location]\50_LTT_SW\LTT Limit Files.

<LttLimitConfig DutType="Type1">
  <Signal name="U_24V">
    <Limit name="default" id="1000" val1="-1" val2="1" />
    <Limit name="active" id="1001" val1="12" val2="12.5" />
    <Limit name="over" id="1002" val1="15.8" val2="16.5" />
    <Limit name="under" id="1003" val1="8.7" val2="9.2" />
  </Signal>
  <Signal name="U_Kl30">
    <Limit name="default" id="1010" val1="0" val2="90" />
  </Signal>
  <Signal name="U_Ubatt">
    <Limit name="default" id="1020" val1="0" val2="90" />
  </Signal>
</LttLimitConfig>

In the F5 - limit configuration dialog you can configure limits for every signal defined in the signals definition dialog. Limits are defined per DUT type, so you can have different limits for the same signal in different DUT types. For that reason you will find in the above folder different limits configuration files, one for each DUT type. The files will have a file name with the following pattern: limits_for_[DUT type name].xml.

Limit configuration files are only present if you have actually configured some limits for a DUT type. After a fresh installation the LTT Limit Files folder is empty.

All limits are stored in configuration database, but are also exported to XML. The Action Logs mechanism use those files as a form of documentation of the parameter changes over time. The exported limit configuration files are also used to transfer limits from one LTT to another (more info).

Do not make any changes in this files as they will be overwritten by the GUI.

Click to open the recording configuration file ltt_recording_config.xml.

The recording configuration file is an automatically generated file and contains all settings made in the Data Recording dialog.

Do not make any changes in this file as they will be overwritten by the GUI.

Click to open the test configuration file ltt_test_config.xml.

The test configuration file is an automatically generated file and contains all settings made in the F10 - test parameter configuration and F11 - test configuration dialogs. It also contains some settings from the F3 - project wizard.

All test configuration settings are stored in configuration database, but are also exported to XML. The Action Logs mechanism use this file as a form of documentation of the parameter changes over time.

The LTT TestStand process model also uses some of those informations for its own purpose.

As a summary, you will find in the test configuration file the following informations:

• what DUT types are available?
• what test groups are available?
• how many test stations are present and what test orders / DUT's are configured for them?
• what operation modes are available and what parameters do they have (per test group)?
• what operation mode <> TCC mappings are configured?
• what power supplies / temperature sensors are assigned to what test group?

Do not make any changes in this file as they will be overwritten by the GUI.

The configuration manager is your central point to save and restore LTT GUI configurations.

There are 3 common use cases:

1. backup an existing LTT configuration for a project
2. export a LTT configuration to transfer it from one LTT to another
3. switch between different projects

1.1.2.6.1Backup

By making a backup you create a snapshot of your current LTT configuration. You can later revert to that backup configuration anytime. The backup will include the following data:

• station configuration (number of stations, DUT types, groups, signals)
• limit configuration
• operation modes + parameters
• main configuration (ltt_main_configuration.xml)
• MesSy configuration (ltt_messy_config.xml)
• hardware configuration (ltt_module_config.xml)
• recording configuration (ltt_recording_config.xml)
• history configuration (ltt_history_config.xml)
• all test related data
  • DUT's
  • test orders
  • error counters

1.1.2.6.2Export

The Export button will save the same configuration as Backup but without test related data. This is useful if you want to transfer the configuration from LTT to another of the same kind.

1.1.2.6.3Import

To import a configuration just select a previously exported configuration zip file.

Your current configuration will be irreversibly overridden! The GUI will be automatically restarted.

1.1.2.6.4Switch projects

With the help of the configuration manager you can even switch between 2 or more completely different projects (with different DUT types, DUT's, signals, limits, etc.).

The LTT GUI is the main graphical user interface used to control the LTT and to display all related information. LTT GUI serves as a front end to the underlying test execution system - National Instruments TestStand.

LTT GUI

The LTT GUI is the main graphical user interface used to control the LTT and to display all related information. LTT GUI serves as a front end to the underlying test execution system - National Instruments TestStand.

The main window contains: - assigned DUT name and type - current test step - current status - current runtime - current step runtime - temperature chamber contact status - power supply voltages - chamber temperatures - current operation mode

The window title shows some basic informations about the software.

• Left: IRS LTT GUI + [Project name] + [LTT number] (as defined in ltt_main_config.xml)
• Middle: current date and time
• Right: Program version

Please note that all configurations are stored under the given project name. If you change the project name you basically start a new configuration. Read chapter Configuration more details.

From the menu you can access all functions of the LTT software. The most important ones are also accessible from the Toolbar below.

The toolbar offers the most important program functions as buttons with keyboard shortcuts. All those functions are also accessible through the Menu.

Icon	Function
	Start / Stop single test station
	Start all test stations
	Dialog: reset errors
	Stop all test stations
	Dialog: project wizard
	Abort station
	Dialog: action log
	Dialog: test parameter configuration
	Dialog: station overview
	Dialog: history data
	Dialog: limit configuration
	Dialog: test configuration
	Dialog: error configuration
	Dialog: data transfer
	Dialog: error live display
	Dialog: measurement live display
	Dialog: reset cycles / time
	Dialog: reset history data

The test station display is the central part of the main window and shows the configured test stations as a rectangle, which contains various information about the individual test stations.

A test station represents the physical location where a device under test (DUT) can be connected to the LTT. The LTT may have more than one test station.

1. test station number (more info)
2. DUT type and name (more info)
3. runtime values (more info)
4. requested state (e.g. start requested, stop requested)
5. custom status message or error text (more info)
6. current runtime | cycle counter | error counter(s) (more info)

A test station display can have the following appearances:

Stopped test station Status text is "OFF". Runtime values are not displayed.

Running test station Status text und runtime values are updated from TestStand. Runtime gets updated periodically.

Error limit reached Status text is "error limit reached [nnnn]", where [nnnn] is the error number (more info) of the corresponding limit test, whose error limit is reached. A test station stops if a limit test has reached its error limit. Details can be found in history log.

Limit not found Status text is "limit not found". The test station stops if a limit test step cannot find its limit. Details can be found in history log. See troubleshooting for further explanations.

Testplan error Status text is "testplan error". The test station stops if there is an error during TestStand execution (e.g. syntax error). The exact error reason is shown as a tooltip if the mouse pointer is moved over the status text. Further details can be found in history log. See troubleshooting for further explanations.

GUI error The test station stops if there is an error in GUI software. This can be due to a software bug but also due to invalid data sent from TestStand to GUI. The exact error reason is shown as a tooltip if the mouse pointer is moved over the status text. Further details can be found in history log. See troubleshooting for further explanations.

The test groups display is located at the bottom part of the main window.

A test group is a logical container which groups one or more DUT's together with one or more power supplies and temperature sensors.

• How to configure test groups?
• How to assign DUT's (test stations) to a test group?

You need to create at least one test group. More than one test group are usually only needed when you want to run different sets of DUT's with different supply voltages in parallel.

The test group display shows various test group related information:

1. group name
2. assigned test stations
3. current TCC value (more info)
4. current temperature (more info)
5. current supply voltage (more info)
6. currently mapped operation mode (more info)

The displayed TCC input indicators for each group are determined by the TCC mask which is defined in the project wizard. If you move your mouse cursor over such an indicator, a tooltip appears, showing the TCC indicator index. The index goes from 1 to 8 (left to right).

Group display

The test groups display is located at the bottom part of the main window.

A test group is a logical container which groups one or more DUT's together with one or more power supplies and temperature sensors.

• How to configure test groups?
• How to assign DUT's (test stations) to a test group?

You need to create at least one test group. More than one test group are usually only needed when you want to run different sets of DUT's with different supply voltages in parallel.

The test group display shows various test group related information:

1. group name
2. assigned test stations
3. current TCC value (more info)
4. current temperature (more info)
5. current supply voltage (more info)
6. currently mapped operation mode (more info)

The displayed TCC input indicators for each group are determined by the TCC mask which is defined in the project wizard. If you move your mouse cursor over such an indicator, a tooltip appears, showing the TCC indicator index. The index goes from 1 to 8 (left to right).

The status bar at the bottom of the main window contains a button for loading a TestStand sequence file on the left. Once a TestStand sequence file is loaded it also displays the name of that sequence file.

If you have an invalid or incomplete configuration the load button is disabled.

On the right, you will see an indicator whether measurement recording is active or not. By clicking on that indicator the Data Recording dialog opens.

Each dialog can be canceled by pressing ESC. All changes made in a dialog only take effect, when the dialog is closed through the Apply button.

In this dialog you can reset certain things related to individual test stations. You can select what to reset and which stations to reset. The dialog can be opened through different buttons / key combinations. Each type of invocation results in different reset options to be preset. Despite of the preset options you are free to change them after the dialog has opened.

Use F2 to reset the temporary error counters. Use Alt+F6 to clear all station data (incl. history data). Use Alt+F12 to only clear the history data.

The "Archive history files" function is only selectable if the dialog is opened through the corresponding button inside the Alt-F10 dialog.

The project wizard guides you through the most basic settings of your individual LTT project and is usually performed only one time during the initial setup of your LTT.

You need a password to enter the project wizard. Ask IRS for the password.

The project wizard is composed of 4 steps:

• Definition of test stations
• Definition of DUT types
• Definition of test groups (and the assignment of power supplies / temperature sensors to that groups)
• Definition of signals (and the assignment of those signals to individual DUT types)

A test station represents the physical location where a device under test (DUT) can be connected to the LTT. The LTT may have more than one test station. You need to define at least one test station.

To add test stations, simply click on the ➕ button. To remove them click on the ➖ button. You can however only add/remove stations at the end of the list, not in between. The stations are numbered automatically, starting from 1. You are free to change the number to something else at any time.

The number of stations determine how many parallel executions of the later loaded TestStand sequence file will be started. Each TestStand execution serves one DUT. The test station index is used to distinct between those executions in any form of display and file output. In TestStand you can access the current station index through a TestStand variable.

1.1.3.2.2.1.1MesSy V2

If you use a MesSy V2 within your LTT, which is the standard case, the test station index defined in GUI relates to the station index defined in the MesSy configuration file.

As you can see in the picture above, each station index maps to a single MesSy with a given IP address. However there are more advanced station configurations possible, which are not part of this documentation. Refer to the comment section inside of the example MesSy configuration file for more informations.

If you create more stations than you have defined in your MesSy configuration, the GUI will show you a warning.

1.1.3.2.2.1.2MesSy V1

If you want to use MesSy V1 you first have to change several other parameters as well. After restarting the GUI the test station configuration dialog will look like this.

Bus represents the last digit of the IP address of the MesSy to which this station is connected. The preceding part of the IP address is defined in MesSy configuration file (for example 192.168.222). A bus number of 3, for example, means, that this station is connected to the MesSy with the IP address 192.168.222.3.

Slot is a number to distinguish between multiple DUTs connected to one MesSy. It defaults to 1 and only needs to be changed if there are more DUTs connected to one MesSy. In fact, the combination of bus/slot must always be unique.

Read more about the usage of station ID or bus/slot in chapter MesSy Integration.

go to initial setup guide

A DUT type represents a specific variant of your devices under test. You need to define at least one DUT type.

To add a DUT type simply click on an empty row in the grid and type a name. Description is optional.

To delete a DUT type select a row and press the DEL key on your keyboard.

Later, when you configure your test, you assign each DUT a DUT type. The DUT type also determines which set of limits to use for that DUT, since each DUT type has its own set of limits.

go to initial setup guide

A test group is a logical container which groups one or more DUT's together with one or more power supplies and temperature sensors. You need to define at least one test group.

To add a test group simply click on an empty row in the grid and type a name. To delete a test group select a row and press the DEL key on your keyboard.

The Max. Runtime parameter is the desired runtime in hours of the tests running under this group. You can later change this parameter in the F10 - test parameter configuration dialog.

The TCC mask determines, which of the total of 8 TCC inputs you want to use for this group. You can use all 8 inputs or just a subset of them. You can also use the same inputs in multiple groups. The TCC mask determines, which TCC indicators are displayed for each group in main window's group display or in the F10 - test parameter configuration dialog.

If you move your mouse cursor over such an TCC input indicator, a tooltip appears, showing the TCC indicator index. The index goes from 1 to 8 (left to right).

Finally you assign one or more of the available power supplies (PS) and temperature sensors (TS) to each group. Those are defined in the module configuration file, which you need setup before running the project wizard. Multiple power supplies and temperature sensors are differentiated by a 1-based index following its fixed prefix (PS or TS). In TestStand you can refer to those power supplies and temperature sensors by using that index.

go to initial setup guide

A signal is an analog output of your device under test or any other DUT related data you want to evaluate through a limit test (for example a CAN message).

To add a signal simply click on an empty row in the grid and type a name. Description is optional.

To delete a signal select a row and press the DEL key on your keyboard.

You assign a signal to one more DUT types (which you have defined previously). By default, each created signal is assigned to all available DUT Types. In most cases this common but it may happen, that one variant of your DUT has less/different analog outputs than another one.

Usually you want to evaluate all analog DUT outputs which are defined in the MesSy configuration file. Therefore you can import the signals defined there.

go to initial setup guide

In this dialog you can define limits for the signals you have defined in project wizard.

You have to go through the project wizard first, before you can configure limits.

Here are some quick facts:

• There are separate limit definitions for each DUT type.
• A signal can have multiple limits.
• Each limit has an unique numeric identifier (the error number) and a name.
• The error number must be unique within the same DUT type.
• The limit name must be unique within the same signal.
• It is possible to define numeric and string limits.

When you open the F5 dialog, you see near the top of the dialog a tab for each DUT type you have defined in project wizard. In each tab, the signals you have defined in project wizard are listed. If you expand those signals (small down arrow), you will see the limits defined for each signal. In case you have a newly setup LTT there are no limits yet.

To define a limit, simply click in an empty row below an expanded signal. You have to provide a unique error number and a unique limit name. You have to check by yourself which error number is unused, but the dialog will not allow you to apply any changes if there are duplicate error numbers or limit names.

A limit error number must be unique within the same DUT type. A limit name must be unique within the same signal. You are responsible!

The preset limit name is default, but you can change it to whatever you want. The idea is, to provide multiple limits for the same signal, because the signal can be tested under different circumstances / in different contexts. For example, you have a default limit for a signal when it is not stimulated / active. That limit might be around 0 V, depending on your signal type. Then you have a limit for the case, when the signal is stimulated / active. A possible limit value could be around 12 V and the limit could be named active. Additionally you may want to test the signal under different stimulation levels, for example under voltage. You could create another limit name under_voltage with a different limit range.

There can be multiple limits per signal, depending on in how many different scenarios you want to test the signal. Read about Limit Tests to learn how to select and perform a specific limit test.

It is a good practice to keep numeric gaps between the error numbers for each signal. That way, you can later add additional limits to a signal while having a continuous numeration within that signal. A numeric gap of 10 should be sufficient for most cases.

go to initial setup guide

Instead of typing each limit manually, which can be a tedious work if you have many signals, you can use the limit generator, which you launch with the button at the right top corner.

With the limit generator you create a limit with the provided name, min and max value for every signal and every DUT type. As for the error numbers, you choose a starting number and an increment (remember the numeric gap). If you apply the generator like in the picture above to an empty limit configuration, you will get the following result.

Afterwards, you can adjust the limit values if needed, which is altogether a faster way of creating limits than doing it one by one.

Assume you have the following limit configuration:

Open the limit generator and enable the Renumerate limits option.

That way you can enter a different error starting number and increment together with a limit name. The min and max values are ignored in that case. If you apply, all limits with the provided name will be renumerated, starting from the provided value with the provided increment.

Be careful to avoid collisions with existing error numbers. The generator will tell you if this is the case and the numbers will not be applied.

Assume you have the following limit configuration:

Open the limit generator and enable the Overwrite option.

That way you can enter different min and max values together with a limit name. The error number and increment values are ignored in that case. If you apply, all limits with the provided name will be set to the new min and max values.

You can use the renumerate and overwrite option in combination.

If you setup your limit configuration for one DUT type and want to copy it to the other DUT types you can do so by expanding the Additional functions at the bottom of the dialog.

There you choose the source DUT type from the left combo box and one or more destination DUT types from the list to the right. If you click on the Copy limits button all limits, including their min and max values are copied to the selected DUT types.

The copy limits function adds limits from a source DUT type, which do not exist in the destination DUT type. If the overwrite limits option is active, then existing limits in destination DUT type will be overwritten with the ones from source DUT type.

When you have more than one LTT and want to copy the limits from one LTT to another one, then use the Import limits function.

First, you have to copy the 50_LTT_SW\LTT Limit Files folder, containing the limits you want to import on another LTT, to the other LTT, but not at the same location!

Overwriting the limit configuration XML files of one LTT with those from another will not transfer the limits!

Assume you currently have the following limit configuration:

And you want to import those limits from the other LTT:

The best praxis is to copy the limit configuration folder from one LTT to the Desktop of the other LTT. Once you have the limits folder copied to the target LTT, you can press the Import limits button in the top right corner of the dialog. A folder selection dialog will prompt you the select the limit files folder to import.

All limit files (DUT types) from the import folder will be imported as long as there is a matching DUT type on the target LTT. If you want to import a specific DUT type only, then delete all other limit configuration files from the import folder.

After you have selected the import folder the limit import is performed. Once it is finished it will display a summary:

Be aware that importing limits will remove existing limits if they are not present in the imported limits.

After the import the limit configuration looks like this:

In this dialog you can do several things:

• set the maximum runtime your your test run
• set the minimum and maximum temperature of your temperature sensor(s)
• set the minimum, maximum and nominal voltage of your power supply/ies
• defined TCC <> operation mode mappings
• set operation mode parameters

All those settings are provided per test group.

You first need to define one or more test groups in project wizard before you can use this dialog.

Runtime

When a test station reaches the runtime you entered here it will automatically stop.

Temperature and voltage limits

A test station will stop with a system error if one of those limits are violated.

• Read more about operation mode mappings
• Read more about operation mode parameters

go to initial setup guide

You can add an operation mode mapping by pressing the button in the operation mode mapping section of the F10 dialog.

You need a password to add or remove operation mode mappings. Ask IRS for the password.

You need to load your testplan before you can map to operation modes of that testplan.

Each operation mode mapping consists of 1 to 8 round TCC input indicators and a drop down box. The TCC input indicators represent the value of the TCC hardware (or the simulated one).

The displayed TCC input indicators for each group are determined by the TCC mask, which is defined in the project wizard. If you move your mouse cursor over such an indicator, a tooltip appears, showing the TCC indicator index. The index goes from 1 to 8 (left to right).

In the drop down box you can select an operation mode sequence from the currently loaded testplan. You can add as many operation mode sequences as you want and select a corresponding TCC input pattern (like binary). You even can have multiple TCC patterns map to the same OM sequence. You should avoid, however, using the same TCC pattern for more than one OM.

With an operation mode mapping, you map a certain TCC input pattern to a single operation mode sequence of your testplan.

Once you have configured your TCC operation mode mappings you can run your testplan and it will execute that operation mode sequence, which is configured for the current TCC value.

You can see the currently mapped operation mode in the main window's group display. If this display is empty, no valid mapping exists for the current TCC value and the testplan will execute a fallback sequence.

The main window will display a warning message if there is no valid operation mode mapping at all and you are not allowed to start the loaded testplan.

This can happen if you

• have not configured any mapping yet
• changed the name of the operation mode sequence or deleted the sequence

go to initial setup guide

You can change operation mode parameter values in the operation mode parameters section of the F10 dialog. There is a tab for each operation mode defined in your testplan.

You need to load your testplan before you can see and change operation mode parameters.

The operation mode parameters are defined in your testplan, so you cannot add or remove parameters here. In this dialog you only change the current values of those operation mode parameters.

You can update operation mode parameters even if if testplan is already running.

go to initial setup guide

In this dialog you assign your devices under test to the individual test stations.

You first need to define one or more test stations in project wizard before you can use this dialog.

You first need to define one or more DUT's in DUT management dialog before you can assign them to test stations.

The best practice procedure to configure your test stations is as follows:

1. Make sure you have created the DUT's you want to assign
   • If not, create them in DUT management dialog.
2. Multi-select all stations you want to configure
   • Select first station
   • Press and hold shift key
   • Select last station
   • To select non-consecutive stations hold down ctrl key while selecting each station.
3. Choose / enter the common for all settings
   • Those typically are test order ID, qualification ID, DUT type, Group and chamber ID
   • Qualification ID is optional
   • Chamber ID is optional
   • Vibration axis is optional
4. Select each individual station and choose / enter the individual settings
   • Those typically are DUT name and cable ID.
   • Selection will jump to next row if you enter DUT name and current row is complete.
   • Cable ID is optional and should be entered first, otherwise the selection might jump to next row.
5. Press Apply

go to initial setup guide

Before you can assign DUT's to test stations you need to define DUT's by their serial numbers / names.

Open the DUT management dialog by pressing the small button next the the DUT name drop down field in F11 dialog.

Just enter a name prefix and a numeric suffix and press the button.

You can delete individual DUT's by selecting them and pressing the del key.

back to F11 dialog

TODO

Through the hardware menu of the main window you can access panels to show / control every LTT standard hardware.

A LTT usually comes with the following standard hardware:

• power supplies (for the DUT's)
• temperature sensors (for climatic chambers)
• temperature chamber contact (digital I/O)

You have to configure the LTT standard hardware in module configuration file.

You can access the power supply control panels through the main window menu Hardware > PS.

A panel will open for every PS configured in module configuration. Power supplies configured as tsonly will not show up.

You can access the temperature sensor control panels through the main window menu Hardware > TS.

A panel will open for every TS configured in module configuration. With simulated TS driver you can set a temperature, otherwise the panel is read only.

You can access the temperature chamber contact control panel through the main window menu Hardware > TCC.

With simulated TCC driver you can set a TCC value, otherwise the panel is read only.

The temperature chamber contact is a digital input for the LTT.

The input is usually set from the climatic chamber, which usually accompanies each LTT.

The TCC consists of 8 input channels (bits).

You need the TCC input for determining which operation mode of your testplan should execute.

The standard TCC module is a NI PCI-6503 24 channel digital in/out card. The 24 channels are grouped by 3 ports á 8 lines.

A valid test station can be

• started
• stopped
• terminated
• aborted

A test station is valid if it has a completely configured test order.

You can choose to start the currently selected test station (F1) or all valid test stations at once (F7).

You can issue a stop request for the currently selected test station (F1) or all running test stations at once (F8).

By issuing a stop request, it depends on the TestStand sequence file if, when and how the test actually stops. This is determined by the use of the Check For Stop step inside of your TestStand sequence file. See stop conditions for more informations.

It may happen, that a test station refuses to stop. This can have several reasons:

• no proper usage of the Check For Stop step (infinite loop)
• a blocking call to an external code module (LabView, .NET)
• long time to reach the next Check For Stop step

In such cases you can terminate a test station (Shift+F9). A termination request will end the execution of the selected test station, no matter where the execution currently is and whether a Check For Stop step is used or not!

Terminating test stations still perform all cleanup steps defined in the TestStand sequence file.

The termination will not work however if the test station execution has a (infinite?) blocking call to an external code module. If that is the case you can press Shift+F9 again. This will change the termination request to an abort request.

Aborting test stations do not perform any cleanup steps defined in the TestStand sequence file. This may lead to leaving the system in a dangerous state, possibly causing harm to the device under test!

1.1.3.5.1The test station display bottom line explained

The bottom line of a test station box displays 4 different information:

• current test time
• current test cycle
• number of total errors (1)
• number of temporary errors (2)

(1) This is the number of error entries (lines) you will see in F4 dialog "total error counters"

(2) This is the number of error entries (lines) you will see in F4 dialog "temporary error counters"

1.1.3.5.2Test station display status colors

The station boxes in main window can be configured to be more colorful in order to display the current status of a station. You can enable this feature in menu Configuration > Test panel configuration.

Once you have this feature enabled, the station display bottom line has the following colors during a test run:

There are a couple of station errors which can happen during the execution of a test. The so called system errors are treated like limit errors and have error numbers < 50.

Do not provide error numbers < 50 for your limit tests.

Like with limit errors, you can set the error tolerance in F6 dialog.

National Instrument TestStand is the underlying test execution system used by the LTT GUI.

This chapter is by no means an introduction or documentation of National Instruments TestStand itself. At this point you should already have basic knowledge about basic TestStand concepts such as sequence files, sequences, steps and variables. If not, maybe you want to read the TestStand help document.

Within the LTT folder structure all TestStand related files are located below [Install Location]\50_LTT_SW\LTT TS\. The TestStand sequence file which represents your LTT testplan must be located there. There is a LTT sequence file template (\50_LTT_SW\LTT TS\LTT Template.seq) if you want or need to begin from scratch. This sequence file template contains all necessary structures needed for a LTT testplan.

The LTT template sequence file is different for MesSy II or MesSy II FD. Depending on what you have selected during installation, the template file is for that MesSy version. If you want to switch to the other MeSy version read chapter MesSy Version Setup.

A TestStand sequence file must meet certain criteria in order to be used for LTT. We call TestStand sequence file a LTT testplan, when it fulfills all required criteria.

The required criteria for a TestStand sequence file to be a LTT testplan are as follows:

• it need to have a specific process model
• it need to contain some predefined sequences
• it need to contain some predefined variables

During this chapter the terms execution, socket, DUT and (test)station may be used. They are interchangeable in most cases. Execution or socket are NI TestStand jargon. An execution / socket means a single DUT / test station.

When you run the LTT installer, you usually do not need to take care of setting up TestStand for the needs of the LTT software. This chapter only provides some background knowledge in case anything goes wrong or you want to do a manual setup, for whatever reason. You can skip this chapter if you are not interested yet.

There is a tool located at [Install Location]\50_LTT_SW\LTT GUI\IRS.TS.Tools.exe which helps you to configure TestStand. Please close TestStand and LTT GUI before you use this tool!

For the LTT software to work properly the following things need to be setup correctly:

TestStand configuration directory

The default TestStand configuration directory is at C:\ProgramData\National Instruments\TestStand\. Within this directory there are files storing all vital TestStand settings like search paths, StationGlobals, model plugins, report configuration and so on. To not interfere with an existing TestStand configuration the LTT software sets the TestStand configuration directory to [Install Location]\50_LTT_SW\LTT TS\config. It is important to set the configuration directory first, before applying any other changes, as otherwise those changes would affect your previous TestStand configuration.

TestStand search paths

There are 2 necessary paths, which need to be added to the TestStand search paths.

• [Install Location]\50_LTT_SW\LTT TS\lib\
• [Install Location]\50_LTT_SW\LTT GUI\

TestStand type palette paths

There are 3 INI files, which need to be added to the TestStand type palette paths.

• [Install Location]\50_LTT_SW\LTT TS\config\IRS.LTT.Types.ini
• [Install Location]\50_LTT_SW\LTT TS\lib\IRS.MesSy\V1\IRS.MesSyI.Types.ini
• [Install Location]\50_LTT_SW\LTT TS\lib\IRS.MesSy\IRS.MesSyII.Types.ini

Those files will add custom step types to your TestStand insertion palette.

1.1.4.1.1IRS.TS.Tool.exe

Luckily this tool will help you with the setup task. It is normally run during installation, but in case anything went wrong just start it manually after installation.

Simply click on "Apply LTT config" to setup everything.

The LTT TS directory is the root of the LTT test execution system. At top level it contains the actual TestStand sequence file implementing your specific LTT testplan (and/or the template sequence file). It also contains the following sub folders:

1.1.4.2.1The lib folder

The lib folder contains some standard sub folder and files, which will be explained here. But it is also the place to put in your project specific assets, like additional DLL's or LabView VI's. Feel free to add more sub folders / LLB's / DLL's or VI's. But do not place your specific assets into one of the existing standard sub folders, since they get replaced by each LTT software update!

There are certain variable structures in FileGlobals and StationGlobals, which need to be present for a LTT testplan to work properly. A LTT testplan need to have an item named LTT and of type LTT_Client_Data placed in its FileGlobals.

The FileGlobals.LTT.CFG container contains variables representing the current test configuration. Those variables are automatically filled at start.

TestStation, DutName, DutType, Group, OrderName, QualName

Those variables are filled with the data entered in F11 dialog of LTT GUI.

BasePath

Path to the directory where your LTT sequence file is located.

PS_Index, PS_Indizes, TS_Index, TS_Indizes

A DUT belongs to a test group and a test group can have one or more power supplies and temperature sensors assigned. The X_Index variable holds the zero based (!) index of the assigned power supply/temperature sensor, whereas the X_Indizes array holds all assigned indexes. You rarely need to use those since the assigned PS and TS are automatically controlled and usually do not need your further assistance.

The FileGlobals.LTT.RV container contains variables representing various runtime values which get updated frequently during testplan execution.

Runtime, Cycles

The current runtime of this test in seconds. The current cycles of this test.

OpModeSeq, OpMode

The currently executing operation mode. Note that the variable OpModeSeq holds the exact sequence name, whereas the variable OpMode holds the name of the operation mode (without the sequence prefix).

HW

FileGlobals.LTT.RV.HW contains voltages and currents of all configured power supplies as well as the temperatures of all configured temperature sensors. Use the FileGlobals.LTT.CFG.XX_Index variables to determine which PS/TS is relevant for that particular DUT.

HW.TCC

The current TCC value. Please note that this value is not masked. It represents the value of all 8 bits of the TCC input.

A LTT testplan need to have an item named LTT and of type LTT_Global_Settings placed in its StationGlobals.

The StationGlobals.LTT container is mainly used for internal parameters which you do not need to know or modify, nor should you. An exception is the StationGlobals.LTT.MESSY container. In that you will find some variables of relevance.

A LTT testplan need to have certain predefined sequences.

See chapters order of execution, operation modes and process model for a better understanding.

The green and purple sequences at the top are predefined mandatory TestStand sequence callbacks triggered by the process model. They will be triggered in the following order.

1. SequenceFileLoad: called at sequence file load. Initializes limits.
2. ProcessSetup: called one time after start for all stations. Use this to perform initializations per LTT and not per DUT.
3. PreUUTLoop: called one time after start for each DUT.
4. MainSequence: main sequence entry point. Do not make any changes here. It serves as a dispatcher to the various operation mode sequences.
5. PostUUTLoop: called one time during stop for each DUT.
6. ProcessCleanup: called one time during stop for all stations. Use this to perform cleanup per LTT and not per DUT.

Additionally to the standard TestStand sequence callbacks there are a couple of other, optional sequences.

Besides those standard and optional sequences above, there are so called operation mode sequences, which are important for the LTT.

A LTT testplan need to contain at least one operation mode sequence.

See chapters predefined sequences, order of execution and process model for a better understanding.

In LTT terminology an operation mode is a sequence of operations, which is executed under certain conditions. Those conditions can be different voltage levels, temperatures or DUT states (sleep, normal).

A LTT sequence file contains some predefined sequences, together with various other arbitrary sequences and so called operation mode sequences. An operation mode sequence's name need to start with the prefix OPMODE or OM.

You can think of an operation mode sequence as the main entry point for that operation mode. From there on it calls other sequences to do whatever the operation mode should do.

There is, however, a main entry point for the whole LTT sequence file. This entry point is called MainSequence and is responsible for switching to one of the defined operation mode sequences, depending on the current temperature chamber contact state (TCC) and the configuration you made in GUI's F10 dialog.

Do not make any changes to the MainSequence.

The MainSequence will call an operation mode in a continuous cycle, which only exits as a result of a stop condition.

If there is no operation mode defined for the current TCC value, the testplan will execute a fallback sequence which does nothing but displaying a status in GUI, that there is no valid operation mode mapping.

Although not mandatory it is common for an operation mode to have parameters.

Operation mode parameters are defined as FileGlobal variables in TestStand.

The FileGlobals.LTT.OM structure is an array of containers. Each container represents the parameters for a single operation mode sequence. The container must be named exactly like the operation mode sequence itself. Within each operation mode parameter container you can add as many variables as needed. Only variables of type string, bool and numeric are supported.

For each operation mode parameter variable you set a name, a default value and a description (as variable comment). When the testplan is loaded in GUI you can see a list of all operation modes with their parameters in F10 dialog. There you can modify individual parameters, even during the testplan is running. The default parameter values entered in TestStand remain untouched. If you run without GUI you work with the default parameters. You need to change the values in TestStand if they do not fit your current need.

TestStand stores its sequences in so called sequence files. A sequence file usually has a so called process model attached. TestStand ships with 3 standard process models: sequential model (default), parallel model and batch model. In TestStand the normal sequence file is also called client sequence file, whereas the process model is called process model sequence file. For the LTT we call the client sequence file testplan. The testplan represents the project specific collection of sequences.

Each LTT testplan needs to have the LTT process model assigned. It is located at \50_LTT_SW\LTT TS\model\LTT Model.seq. Do not modify the LTT process model as it gets overwritten by the next update.

The LTT process model specifies the frame sequence for each LTT testplan. It determines the order, in which each of those standard sequences are called and also provides some execution logic, initialization, error handling and so on. The LTT process model is the same for every LTT testplan, hence it is not project specific.

The LTT model is derived from the standard TestStand parallel model. It is therefore able to handle multiple DUT's in parallel. The LTT model also contains features of the standard TestStand batch model.

When running multiple DUT's in parallel, you need to be aware that parallel execution has some limitations / drawbacks.

• You cannot access hardware simultaneously, which exists only once for all DUT's. Therefore you need some kind of locking to make sure that the hardware is accessed serially.
• Since parallel DUT's run independently, some are faster than others. At some point in your testplan you might need to wait for all DUT's before you continue. You will need this kind of synchronization especially if you want to change the voltage level of your power supply, if it supplies more than one DUT.

Use the SYNC sequence to change your DUT's voltage level and/or wait for the other DUT's to continue.

See chapters predefined sequences, operation modes and process model for a better understanding.

When starting a LTT testplan it follows the following basic order of sequence calls.

A LTT testplan can be started by GUI (F1/F7) or by TestStand itself (without GUI).

• ProcessSetup is executed. This sequence may be used to initialize shared components, which exist only once and not per DUT.
• Teststand starts a parallel execution for every station. PreUUTLoop typically performs a per DUT setup for each test station / execution.
• MainSequence is called after PreUUTLoop. All stations are synchronized at this point, guaranteeing that all stations start the operation mode at the same time. This also makes sure that all stations run an equal number of cycles.
• MainSequence calls an operation mode sequence, depending on current TCC value and configuration (F10). The OpMode is executed in parallel for each station.
• When running with GUI, the testplan will endlessly call the current operation mode sequence until a stop condition is met. When running in TestStand the behavior is slightly different.
• When a stop condition is met, the process model will execute the PostUUTLoop sequence per DUT and the ProcessCleanup sequence once.

1.1.4.6.1.1Stop conditions

• Active stop: the testplan issues a stop request by itself (how to).
• TestStand error: If a TestStand step returns an error (for example if a VI call returns an error in the "Error Out" cluster) the execution will terminate.
• TCC input change: The testplan need to actively check for this stop condition (how to). By default a TCC change check is performed only at the beginning of an operation mode sequence. It is up to the user to perform additional TCC change checks during the execution of the operation mode.
• User request (GUI ONLY): by pressing F1 or F7 in GUI. The testplan need to actively check for this stop condition (how to). By default a stop request check is performed only at the beginning of an operation mode sequence. It is up to the user to perform additional stop request checks during the execution of the operation mode.
  Note: if there are no more intermediate stop checks, it may take a long time between the stop request and the actual stop!
• Limit error max reached (GUI ONLY): when a limit test for a specific limit has failed the number of times configured in F6, the GUI will stop the test.
• Max. runtime reached (GUI ONLY): when the test ran for the time configured in F10 the GUI will stop the test.

You can run your testplan without GUI.

Just press the green arrow button in TestStand after you have loaded your testplan.

First the ProcessSetup and PreUUTLoop sequences will execute. The latter one will connect to your MesSy (only if MesSy is enabled in StationGlobals). After a while the default TestStand UUT Information dialog will appear. You are limited to one DUT. You can ignore the UUT Serial Number input and just press OK to go on with your testplan.

Now the MainSequence will run. It will call one of your existing operation mode sequences depending on the current TCC value and how you have mapped it (read chapter Order of execution for more details). After a fresh installation there is a default mapping to the one and only operation mode [insert name] when the (simulated) TCC returns 0.

To make your testplan execute a certain operation mode when running standalone in TestStand you need to configure a mapping in LTT GUI F10 dialog and make sure that your TCC (simulated or real) returns the correct value.

For a correct operation some variables also need to be set, which will normally be done by LTT GUI. You need to set the MesSy V2 StationID or MesSy V1 Bus/Slot variables manually (read chapter MesSy integration).

The best place for setting variables manually is in PreUUTLoop. There is already a Statement step placed, with some commented out code. Just uncomment it and set the variables according your needs.

When the operation mode sequence has finished, the execution will pause and you need to manually resume it again in the UUT Information dialog or terminate the execution.

When you press Next UUT and then OK, the operation mode will start again. You can change the TCC value in between to switch to another operation mode as long as you have mapped it in LTT GUI.

When you press Exit the PostUUTLoop and ProcessCleanup sequences are called and the execution stops.

If you want to stop the execution during an operation mode you can press Terminate in the UUT Information dialog.

The purpose of a LTT testplan is to test DUT outputs (signals) against certain limits. Hence, the limit test is the most important TestStand concept for LTT.

TestStand offers 3 standard limit test types:

• numeric limit test
• string limit test
• pass/fail test

The LTT software adds a fourth type of limit test - the LTT limit test. The LTT limit test is a combination of the numeric and string limit tests and allows limits to be configured by XML file. That way it is easily possible to change limits without changing the the testplan itself. Additionally the LTT limit test step provides a limit selection panel in TestStand, where you can easily select the signal and limit you want to test.

You first need to configure signals and limits in GUI before you can use the TestStand limit selection panel.

For this chapter we assume the following configuration:

In TestStand you can place a LTT Limit Test step. A dialog will appear.

A dialog will appear where you:

1. Select a signal from the drop down box
2. Select a limit from the drop down box
3. See a preview of the selected limit for the selected signal for each DUT type
4. Provide a data source, typically a TestStand variable holding the value to be tested
5. Optionally provide unit, precision and comparator, just like in the standard TestStand numeric limit test
6. Check the "Rename Step?" (recommended) and click OK

The inserted step will be renamed to the selected signal/limit. It will also contain the unique error number which you configured for that signal/limit.

A limit test step name in a LTT testplan—no matter if standard numeric limit test or LTT limit test—should always contain an error number in [square brackets] at the beginning of the step name. Optionally the step name could further follow the format {signal name} @ {limit name}.

If you select a LTT limit step and click on the edit button or press Ctrl + E, the limit selection dialog will appear again. You can choose another signal and/or limit and the step will adapt to your settings.

1.1.4.8.1.1Dynamic Limits

By pressing the "tool button" to the right of the signal or limit drop down boxes, a TestStand expression editor window will open.

There you can select a TestStand variable from Locals, Parameters, FileGlobals, etc. and/or specify a more complex expression which determines the signal and/or limit name dynamically. As a result, the limit preview will not show all possible limits, since now the step does not specify one exact limit.

LTT limit steps containing expressions for signal and/or limit name are called dynamic limits. The step name will not contain an error number but a [???] instead, since many are possible. The step name will also contain <variable> for that part which is an expression. However, when you run the testplan the step will update to the correct limit, name and error number, depending on the value of the provided expression.

If the expression for a dynamic limit does not evaluate to an existing signal/limit name you will get a limit not found error and the station will stop.

Besides the LTT limit test you can—of course—still use all other TestStand standard limit tests.

Besides the LTT limit test you can - of course - still use all other TestStand standard limit tests.

When using standard limit tests you can not easily access GUI configured limits (XML). Read here about how to do it.

In the picture above you see some examples of TestStand standard limit tests. Besides of the step name starting with an error number in square brackets, you are free to name your limit test step what you like. Yet, you are encouraged to name the step according to the pattern {signal name} @ {limit name} if applicable.

When using standard limit tests you still should supply at least an error number in [square brackets] at the beginning of the step name. Like with the error number you configure in GUI's F5 dialog, you need to make sure not to use duplicate error numbers.

Standard limit tests with error numbers will be shown in GUI's F6 dialog, where you can provide an error limit for them. Please be aware, that those TestStand only error numbers get added to the GUI but not removed if you remove them in TestStand. However, you can manually remove them in F6 dialog.

The limit test step with the yellow exclamation mark (!) in the picture above is still valid, however you will not be able to configure an error limit in GUI's F6 dialog, since it has no error number.

The limit test step with the red exclamation mark (!) in the picture above is invalid and will result in an error, which will stop the station. The reason is that this limit test step is using an error number [1001] which is already in use by a different limit test step.

If you run your LTT testplan in TestStand you will notice some "process result" steps inserted after each TestStand standard limit test. Those are automatically inserted by the LTT process model and are needed for the result processing. If they bother you, you can remove them via TestStand menu Configure > Remove Result Processing Steps.

In some situations you might need to query a GUI configured limit (XML) without using the LTT limit test step.

Normally you do NOT need to do this.

TODO

TestStand comes along with a set of default step types, like action, if-statement, numeric limit test and so on. It also provides the possibility to create custom step types.

(The file is empty)

Send Status

With the LTT Send Status step type you are able to send an arbitrary string to the station display.

With the LTT Send Log step type you are able to send an arbitrary string to the history file.

With the LTT Send Value step type you are able to send one or more named values to the station display. We also call those LTT runtime values.

For send value to work correctly it is important to name the values consistently throughout the whole testplan.

Optionally, you can configure one or more of those values as additional history columns.

To do so, you need to edit the history configuration file and add a custom column for each runtime value you want to have as a history column.

It is important that the custom column name is exactly the same as the value name used in this step type.

In combination with history column configuration there are 3 different usage scenarios for LTT runtime values possible:

The LTT Cycle Start and LTT Cycle End step types should be placed at the setup / cleanup of each operation mode sequence. That way the cycle counter will increment by one each time the operation mode sequence has passed through.

Of course, when the cycle counter should increment depends on your concrete testplan. For example, if your operation mode sequence never leaves (not recommended) the cycle end call should be placed inside the loop of your operation mode.

The cycle counter is available as a TestStand variable: FileGlobals.LTT.RV.Cycles.

The cycle counter is also added as a separate history column per default.

Only cycle end is needed to increment the cycle counter. You only need to place a cycle start step at the beginning of your cycle if you configure data recording to record every x minutes. Read more about data recording.

In your testplan you can place a LTT Check Stop check wherever you want. It checks if there is a stop request from the user interface, initiated by the user pressing F1 or F8. If this is the case, the step will jump to the cleanup section of the currently executing TestStand sequence.

A check for stop is necessary to react to user stop requests and TCC value changes. By default, the only check for stop is done in MainSequence. This means:

• The test execution will only stop after an operation mode sequence returns, which can take a long time or not happen at all.
• The testplan can only react to a TCC value change when the current operation mode is finished.

Both may or may not be desired behavior.

Be aware that LTT Check Stop only jumps to cleanup of the current sequence. If you are in some nested sequence you will need to place a LTT Check Stop in each sequence all way up to your operation mode sequence entry point.

• Read more about other stop criteria
• Read more about station control

In your testplan you can place a LTT Station Stop whenever you want to actively stop the test execution of this station. Of all stop criteria, this is the only active one, where you, the testplan developer, decide when to stop. That's also the reason why a station stop is usually accompanied with a step precondition.

Normally, there is rarely a need to actively stop a test from within the testplan. However, if you do so, be aware that the station stop does the same as if a user would have pressed F1 or F8. You still need a check for stop step hierarchy to actually stop the execution.

Do not make any changes to databases, tables or server settings unless you know what you do or are being told to do so by IRS support.

The Measurement Database System is a software bundle consisting of:

• Apache web server
• MySql database server
• PhpMyAdmin (database administration tool)

In the context of a LTT it is used for two different purposes:

1. for storing the LTT configuration in a database
2. for storing measurement values in a database

The URL for the database administration is: http://localhost/phpmyadmin.

There is a GUI for visualizing measurement values from the measurement database. See chapter LTT MesVis GUI. You need to configure data recording before measurement values are stored in database.

The MDBS installs automatically with the LTT installer and you need it to run the LTT GUI. The MDBS installs two Windows services in your system—the web server and the database server. Those services will automatically start with Windows.

You can start the MDBS control panel, which is located at [Install Location]\55_LTT_MDBS\MDBS.exe.

You have four buttons, each aligned together with an indicator, with which you can install/uninstall/start/stop the Apache or the MySql service. A green indicator shows that the service is installed/running, a gray indicator shows that the service is not installed/running.

The other buttons for MySql have the following meaning:

In this chapter you will find additional topics, which do not fit elsewhere.

This chapter contains a collection of common problems, their explanation and possible solution.