Rohde&Schwarz R&S®GTSL - Generic Test Software Library User Manual
R&S®GTSL
Generic Test Software Library
User Manual
(;[ÎÀZ)
1143645042
Version 26
This Software Description is valid for the following software versions.
●
R&S®GTSL version 3.00 and higher versions
© 2021 Rohde & Schwarz GmbH & Co. KG
Mühldorfstr. 15, 81671 München, Germany
Phone: +49 89 41 29 - 0
Email: info@rohde-schwarz.com
Internet: www.rohde-schwarz.com
Subject to change – data without tolerance limits is not binding.
R&S® is a registered trademark of Rohde & Schwarz GmbH & Co. KG.
Trade names are trademarks of the owners.
1143.6450.42 | Version 26 | R&S®GTSL
The following abbreviations are used throughout this manual: R&S®GTSL is abbreviated as R&S GTSL.
R&S®GTSL
Contents
Contents
1 General....................................................................................................5
2 Software Installation..............................................................................6
3 Functional Description........................................................................ 14
4 R&S GTSL License Management........................................................18
5 Configuration Files.............................................................................. 22
6 Editing and Running Test Sequences................................................33
7 Test Libraries........................................................................................50
8 Signal Routing....................................................................................104
9 Creation of Test Libraries..................................................................149
10 Creation of Self Test Libraries.......................................................... 200
11 Instrument Soft Panels...................................................................... 221
3User Manual 1143.6450.42 ─ 26
R&S®GTSL
Contents
4User Manual 1143.6450.42 ─ 26
R&S®GTSL
1 General
The Generic Test Software Library R&S GTSL is a collection of libraries for specific test
tasks like measurements, switching and signal generation. An ASCII file contains the
relevant configuration data which can be assigned to certain test sequences. So measurement parameters can be changed and adjusted easy and quickly with a standard
editor.
Any test management software may be used to control the test sequence. This software combines the individual test sequences to form an executable test program. It
also adds all other functions important to the production operation, such as user
administration, execution of multiple test sequences in multi-threading or parallel operation, collection and storage of relevant measurement results and report generation.
The individual test cases of the Generic Test Software Library R&S GTSL can also be
combined by a C program into an executable test program.
Requirements
●
Knowledge of Microsoft Windows operating systems is needed to operate and
work with the Generic Test Software Library R&S GTSL.
●
Knowledge of C-programming is needed to create your own test libraries.
General
5User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
Installation
2 Software Installation
2.1 General
The Generic Test Software Library R&S GTSL can be downloaded from R&S GLORIS
server. After extracting the compressed installation file, the whole contents of the
installation package can be found in the target directory.
Please read the README.TXT file before starting the installation by executing the
SETUP.EXE file.
To install the Generic Test Software Library R&S GTSL under Windows 10 or Windows
7, the user must be logged in as administrator or as a user with administrator rights.
For additional information on the de-installation of previous versions of the Generic
Test Software Library R&S GTSL or concerning installation, consult the README.TXT
file in the installation package and the chapter “Installation of R&S CompactTSVP and
R&S GTSL” of the “R&S System Manual TSVP”.
2.2 Installation
2.2.1 Runtime Setup
Before installing the Generic Test Software Library R&S GTSL the runtime environment
of the computer must be setup. The installation package contains setup routines for the
initial setup of the runtime environment.
It is not necessary to setup the runtime environment with each R&S GTSL installation
or update, but only in the case of an initial setup, or if the version number of one of the
components has changed. To get more information about whether the runtime environment has to be updated or not, please refer to the README.TXT file on the installation
package.
The directory Runtime Setup on the installation package comprises some subdirectories.
Each subdirectory contains a separate installation application. Wherever more information is helpful for the proper installation of one item, there is also a README.TXT file
located in the subdirectory. Please read this file before installing the specific runtime
setup item.
6User Manual 1143.6450.42 ─ 26
R&S®GTSL
2.2.2 R&S GTSL
Software Installation
Installation
The Generic Test Software Library R&S GTSL is installed on the computer of the TSVP
Test System Versatile Platform or on any external computer via an installation routine.
Start the installation as follows:
1. Extract the compressed installation zip-file to a directory on the hard disk drive.
2. Start the installation routine by executing the file setup.exe which is located in
the directory where the compressed installation zip-file has been extracted to.
3. The following pictures describe the installation process.
● Installation wizard welcome screen
Figure 2-1: Setup Welcome Screen
● Accept the License Agreement
7User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
Installation
Figure 2-2: Setup License Agreement
● Enter a user name and company name
Figure 2-3: Setup Customer Information
● Select the directory, where the R&S GTSL program files are to be installed.
8User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
Installation
Figure 2-4: Setup Choose Destination Location
● Select the directory, where R&S GTSL application data is to be installed.
Figure 2-5: Setup Data Directory
● Select the program features to be installed
9User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
Installation
Figure 2-6: Setup Select Program Components
● Display of the current setup settings
Figure 2-7: Setup Settings
● Display of the Setup Status
10User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
File Structure
Figure 2-8: Setup Status
● Close the installation routine
Figure 2-9: Setup Complete
2.3 File Structure
The test libraries supplied by ROHDE & SCHWARZ are stored in fixed directories at
the time of installation. The following directory structure can be found as subdirectories
below the R&S GTSL program files directory which was specified during the installation
process.
11User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
File Structure
Figure 2-10: File structure program files
Description of installed R&S GTSL program files directories:
Table 2-1: File structure
Directory Contents
GTSL
GTSL\Bin
GTSL\Develop
Libraries
●
Sample
●
Tools
●
GTSL\Documentation
GTSL\EGTSL
GTSL\Firmware Update
GTSL\Include
Generic Test Software Library. The root directory for
the R&S GTSL software can have any name.
Contains the test libraries (.DLL, .LIB) and the
help files (.HLP, .CHM) belonging to the test libraries.
The directory ..\Libraries contains generally
valid examples for the creation of a high-level test
library and a customer-specific selftest library.
The directory ..\Samples contains two sample
applications that show how to call R&S GTSL functions and driver functions.
The directory ..\Tools contains the R&S GTSL
Selftest application.
Contains the various items of documentation in PDF
file format.
Appears only if the feature was selected at installation time. For detailed information please refer to the
document 'Software Description EGTSL.pdf'.
This directory contains the firmware update application with which the firmware of all TSVP Test System Versatile Platform plug-in boards can be updated to a newer version when available.
Contains the h-files (include files) needed for the
development of new test libraries.
GTSL\Operator Interface
GTSL\Sequences
Contains the run time module for the operator interface of TestStand. A TestStand run time licence is
required.
Contains the test sequence examples created by
ROHDE & SCHWARZ.
The application data is stored in the following directory structure below the R&S GTSL
application data directory which was specified during the installation process.
12User Manual 1143.6450.42 ─ 26
R&S®GTSL
Software Installation
File Structure
Figure 2-11: File structure application data
Description of installed R&S GTSL application data files directories.
Table 2-2: Application data files directories
Directory Contents
GTSL\Configuration
GTSL\EGTSL
GTSL\IC-Check
GTSL\License
Contains samples of the two configuration files
PHYSICAL.INI and APPLICATION.INI.
Appears only if the feature was selected at installation time. Contains correction data for Enhanced
Generic Test Software Library.
For detailed information, please refer to the document Software Description EGTSL.pdf.
Contains example configuration data for the ICCheck application.
Contains one or more subdirectories with optional
license key files.
13User Manual 1143.6450.42 ─ 26
R&S®GTSL
Functional Description
3 Functional Description
Figure 3-1: R&S GTSL layer model
In terms of its structure, the Generic Test Software Library R&S GTSL developed by
ROHDE & SCHWARZ is divided into different supply components and software layers.
A distinction is made between the software components supplied by ROHDE &
SCHWARZ and the components which must be supplied or adapted by the customer.
The software components to be provided by the customer may for example include the
following elements (specific to the customer and to the unit under test).
●
device drivers
●
calibration data
●
test libraries
●
test sequences
The software used in the R&S GTSL is divided into three different layers.
●
The lowest level of the R&S GTSL accommodates the device drivers needed for
the hardware used (Device Driver Layer). These include the device drivers for the
following hardware:
– hardware developed and used by ROHDE & SCHWARZ.
– standard hardware.
●
The middle level of the R&S GTSL accommodates the different test libraries
(Library Layer). These test libraries provide the functions needed to execute test
sequences. At this level, further information concerning the two files
PHYSICAL.INI and APPLICATION.INI is transferred to the Resource Manager
Library. The different device drivers of the lowest level are called from this level.
●
The highest level accommodates the test sequences for the execution of the individual test functions (Application Layer). The test sequences call functions from the
libraries in the middle level.
14User Manual 1143.6450.42 ─ 26
R&S®GTSL
Functional Description
Figure 3-2: Software structure
The test libraries form the core of the software and of the test sequences. The test
functions stored in the test libraries (Dynamic Link Library .DLL) are combined within a
test sequencer into executable test sequences.
The individual test functions access the test system hardware via the device drivers.
The hardware initialized in the Generic Test Software Library is managed by the
Resource Manager. The Resource Manager is likewise a .DLL file.
Thanks to the hardware management of the Resource Manager, the created test
sequences are independent of the current hardware configuration, so test sequences
do not need to be modified if the hardware or hardware settings are changed. All information needed to run the test sequences is sent to the Resource Manager via two configuration files (.INI files):
PHYSICAL.INI
●
APPLICATION.INI
●
Only these files need to be modified if the hardware or hardware settings are changed.
They can be edited with any text editor.
The Resource Manager also manages the hardware during the parallel execution of
test sequences. The Resource Manager prevents conflicts in accessing different test
functions or test sequences on the same hardware.
When using the Generic Test Software Library R&S GTSL, the user only has to make
changes to certain components of the software. In all cases, the user creates the test
sequences for the test applications at the highest level (Application Layer).
The user has to adapt the configuration file APPLICATION.INI to the relevant test
application. The user only has to adapt the configuration file PHYSICAL.INI in the
event of a change to the hardware configuration.
15User Manual 1143.6450.42 ─ 26
R&S®GTSL
Functional Description
Operation of a Test Sequence
Since an APPLICATION.INI configuration file normally exists for every test application performed on the system, the file name can be matched to the test application in
question, e.g. APP_XXX.INI. The Resource Manager is told during setup which configuration file is to be used.
On the other hand, only one PHYSICAL.INI configuration file is ever available on the
system.
For ease of comprehension, the file names APPLICATION.INI and PHYSICAL.INI
are used for the configuration files in the manual.
3.1 Operation of a Test Sequence
Figure 3-3: Test sequence operation
16User Manual 1143.6450.42 ─ 26
R&S®GTSL
Functional Description
Operation of a Test Sequence
The operation of every created and executed test sequence is divided into three
stages:
SETUP
1.
First of all, the SETUP function of the Resource Manager (RESMGR) is called. During this function call, information from the two configuration files PHYSICAL.INI
and APPLICATION.INI is loaded. Then, the SETUP functions of the individual
libraries needed to perform the test steps are called (ROUTE, SIGANL, ICT etc.).
The necessary hardware and software components are requested, the relevant
device drivers are initialized and the devices are placed in a defined state.
MAIN
2.
The individual test steps are performed.
CLEANUP
3.
The CLEANUP functions of the Resource Manager and of the used libraries are
called. The system resources reserved during the setup functions and the reserved
hardware are freed again. A CLEANUP call is needed for every SETUP call.
The different CLEANUP function calls are executed even if the operation of the test
steps is interrupted. This ensures that the used system resources are always freed
again, and the used hardware is always returned to a defined basic state.
The division of the execution operation of a test sequence into these three subareas
takes place in the test sequence control system that is used.
17User Manual 1143.6450.42 ─ 26
R&S®GTSL
R&S GTSL License Management
4 R&S GTSL License Management
Starting with GTSL 3.30, no GTSL license is required.
During the installation of the Generic Test Software Library R&S GTSL, all available
test libraries are copied to the system. You need a License Key File in order to access
the functions from the test libraries. Refer to Chapter 7, "Test Libraries", on page 50
for the license key required for each test library.
Without a valid License Key File, the functions of the test library will only work in „demo
mode". Access to the hardware is only simulated.
Each license is bound to a system serial number. The enabled test libraries can only
be run on the system with this serial number. The hardware system used is identified
via the system module TS-PSYS (R&S CompactTSVP, R&S PowerTSVP).
Figure 4-1: License Check
During license checking, the serial number and the name of the called test library are
compared with the License Key from the License Key File. The test library in question
will only be enabled if these coincide. The serial number and the name of the test
library are encoded in the License Key.
18User Manual 1143.6450.42 ─ 26
R&S®GTSL
R&S GTSL License Management
Example:
License Key File
[Header]
FileVer=1.0
[Project]
Info=GTSL
[Modul]
Product=TS-LBAS
SerialNumber=850000008E4BD202
Key=C146648E1DEF9AD78663728A5D8E8D25885F457367D7F7C359F2C63BDB926 ...
The serial number is queried and a new License Key File is installed via the R&S
GTSL License Viewer. To open the R&S GTSL License Viewer, select
" Start" -> "Programs" -> "GTSL" -> "License Viewer"
Figure 4-2: R&S License Viewer
"System Identification" The serial number of the system
"Program Status" Displays the current status of theR&S GTSL License
Viewer.
"Licensed Components" Displays the test libraries for which a License Key
File has been imported.
Copies the displayed serial number to the clipboard.
19User Manual 1143.6450.42 ─ 26
R&S®GTSL
R&S GTSL License Management
Imports a new License Key File into the R&S GTSL
License Viewer. The path and the file name of the
License Key File to be imported can be selected via
a file browser dialog.
Reads the serial number into theR&S GTSL License
Viewer.
Closes the R&S GTSL License Viewer.
"File > Exit" Closes the R&S GTSL License Viewer.
"Configure > System Identification" Opens the configuration dialog (see Figure 4-3).
"Help > About License Viewer" Shows version and copyright information about the
R&S GTSL License Viewer.
Figure 4-3: Configuration Dialog
"iButton" This option is not available for Windows 7.
"PSYS" "CAN Board" and "Controller" define the board and
interface Id of the CAN interface controlling the R&S
TS-PSYS module.
Default = 0
"Frame" defines the R&S CompactTSVP or R&S
PowerTSVP frame number where the R&S TSPSYS module is located.
Default = 1
"Slot": The only valid slot number for the R&S TSPSYS module is 15.
The settings made in the Configuration Dialog are
accepted with the "OK" button.
The settings made in the Configuration Dialog are
rejected with the "Cancel" button.
For each installed PSYS, a subdirectory with the relevant serial number is created in
the ..\GTSL\License directory. The License Key Files installed via the R&S GTSL
License Viewer are stored in the relevant subdirectory.
20User Manual 1143.6450.42 ─ 26
R&S®GTSL
R&S GTSL License Management
If further test libraries are enabled, the serial number must be sent to ROHDE &
SCHWARZ. To avoid writing errors, the serial number can be copied from the R&S
GTSL License Viewer via the clipboard.
The License Key File newly created by ROHDE & SCHWARZ must be installed via the
R&S GTSL License Viewer. After that, unrestricted use of the test libraries is possible.
If, during a test sequence, test functions are used or called from a non-enabled test
library, a warning code will be displayed upon execution in TestStand. If non-enabled
functions are called during Resource Manager Setup, an error message will be displayed:
Figure 4-4: Error message from Resource Manager
If the error message is acknowledged by selecting
in "demo mode".
"Ignore", the test sequence will run
21User Manual 1143.6450.42 ─ 26
R&S®GTSL
Configuration Files
Syntax
5 Configuration Files
The required configuration files are stored by default in
the ..\GTSL\Configuration directory.
5.1 Syntax
The syntax of the Physical Layer Configuration File (PHYSICAL.INI) and of the Application Layer Configuration File (APPLICATION.INI) is identical. The only difference
between the two files is in terms of how they are used (see Chapter 5.2, "PHYSI-
CAL.INI", on page 26 and Chapter 5.3, "APPLICATION.INI", on page 30).
Both files use the standard INI file format.
Example of standard INI file format:
[section]
key = value
...
A section begins with the section name written inside closed brackets ([ ]). The following lines contain pairs of keywords and values. The keywords and the assigned values
are separated by an equals sign ("=").
In the section names and keywords, no distinction is made between upper and lower
case characters. However, the values after the equals sign are transferred exactly as
they are written in the file. Leading and trailing spaces are truncated.
5.1.1 Naming Conventions
In the Physical Layer Configuration File and in the Application Layer Configuration File,
several groups of keywords and sections are allowed. These refer to other sections
and reflect the relationships and interconnections.
The section names follow the naming conventions indicated below.
The section name begins with the section type followed by an arrow ("->", a minus sign
followed by a greater than sign). A unique name appears after the arrow. No spaces
are permitted between the name and the arrow.
In the section names, no distinction is made between upper and lower case characters.
The following characters are permitted for the logical names, the device names and the
bench names.
Table 5-1: Character set for names
"A" ... "Z" Upper case characters
"a" ... "z" Lower case characters
22User Manual 1143.6450.42 ─ 26
R&S®GTSL
Configuration Files
Syntax
"0" ... "9" Numbers
"_" Underscore
"." Decimal point
The following maximum character lengths are permitted for section names, keywords
and values:
Table 5-2: Maximum character lengths
section 80 characters
key 80 characters
value 260 characters
[LogicalNames] This section contains a list of names of devices and
benches. Any name can be used to identify a device
or bench (Application Layer Configuration File).
[Device->...] A device section contains different keywords to
identify the devices. These include the GPIB
address, the device type etc. (Physical Layer Configuration File and Application Layer Configuration
File).
[Bench->...] This section contains a group of device entries
[ResourceManager] This section contains information for the configura-
5.1.2 [LogicalNames] Section
The [LogicalNames] section is used to assign a short, meaningful name to a device or
bench. Any name can be chosen. This section contains a list of unique name allocations. The values on the right side of the expressions must be valid names of a bench
or of a device section.
The [LogicalNames] section is an optional entry and is used only in the Application
Layer Configuration File.
Example:
[LogicalNames]
ICT = bench->ict
Power = device->psu_14
which together form a bench. A High Level Library
requires the name of a bench in its setup routine
(Application Layer Configuration File).
tion of the Resource Manager.
23User Manual 1143.6450.42 ─ 26
R&S®GTSL
5.1.3 [Device] Section
Configuration Files
Syntax
The [Device] section contains a list of keywords and assigned values. These keywords
and values precisely describe the relevant device. The name of the [Device] section
begins with "Device->" followed by a unique name. Any name can be chosen.
There must be a [Device] section for each device in the Physical Layer Configuration
File.
A [Device] section with the same name can be defined in the Application Layer Configuration File. Additional device information can be given at this point by means of further
keywords and values, or device information from the Physical Layer Configuration File
can be overwritten. However, it is not possible to define a [Device] section in the Application Layer Configuration File which is not present in the Physical Layer Configuration
File.
The keywords in a [Device] section and their meaning depend on the libraries used by
the devices.
Table 5-3: Standard keywords of [Device] section
Keyword Description
Description Optional entry
Device description, remarks
Type Mandatory entry
Device type (e.g. CMU etc.)
ResourceDesc Mandatory entry
VISA device properties and device description in the
form: GPIB[card number]::
[primary address]::
[secondary address] PXI[segment number]:
:[device number]::[function]::INSTR
Examples:
GPIB0::15 or PXI0::16::0::INSTR
DriverSetup Optional entry
Special setup string for IVI driver, e.g. for simulation
of devices
The "Type" and "ResourceDesc" entries are required for the test libraries. Both entries
must be present in the Physical Layer Configuration File.
The information from the "Type" entry allows the test libraries to distinguish between
different supported devices (such as CMD55 or CMU). This information is also needed
for the system self-test.
The information from the "ResourceDesc" entry is needed to set up the device driver
and create the physical connection with the indicated device.
Example:
24User Manual 1143.6450.42 ─ 26
R&S®GTSL
5.1.4 [Bench] Section
Configuration Files
Syntax
[device->CMD55]
Description = Radio Communication Tester CMD55
Type = CMD55
ResourceDesc = GPIB0::4
The [Bench] section contains a list of keywords and assigned values which describes a
group of devices and their use. The name of the [Bench] section begins with "Bench->"
followed by a unique name. Any name can be chosen.
A [Bench] section can only be defined in the Application Layer Configuration File.
The keywords in a [Bench] section depend on the test library used by the bench. A
keyword always provides at least one reference to a device entry. Other keywords may
be necessary to describe the bench. The following keywords are predefined and
should be present in each [Bench] section.
Table 5-4: Standard keywords of [Bench] section
Keyword Description
Description Optional entry
Bench description, remarks
Simulation Optional entry
If set to 1, the complete bench is simulated by the
test library.
Trace Optional entry
If set to 1, the tracing function is enabled for the test
library
The [Bench] section can contain further useful keywords and values which are used by
a test library.
Example:
[bench->ICT]
Simulation = 0
Trace = 0
ICTDevice1 = device->psam
SwitchDevice1 = device->pmb_15
AnalogBus = device->ABUS
AppChannelTable = io_channel->ICT
5.1.5 [ResourceManager] Section
The [ResourceManager] section contains keywords and assigned values to control the
behaviour of the Resource Manager library. The following keywords are supported:
25User Manual 1143.6450.42 ─ 26
R&S®GTSL
Configuration Files
PHYSICAL.INI
Table 5-5: Keywords of [ResourceManager] section
Key name Remarks
Trace Blocks the tracing function (value = 0), enables the
tracing function (value = 1). The function impacts on
all libraries.
TraceFile Defines the path and the name of the trace file.
TraceToScreen The tracing information is displayed on the standard
screen (value = 1).
TraceTimeStamp Writes the time of day at the start of each tracing
line (value = 1).
TraceThreadID Writes the ID of the current thread at the start of
each tracing line (value = 1).
5.2 PHYSICAL.INI
In the file PHYSICAL.INI (Physical Layer Configuration File), all hardware assemblies
available in the Generic Test Software Library are described along with the corresponding definitions and settings (see example PHYSICAL.INI file). This file also contains
definitions which are applicable to all test applications to be executed on the system
(e.g. type definition). The information entered in this file is used by all test libraries and
thus by each test step.
The PHYSICAL.INI file normally exists only once in the system as it reflects the exact
physical structure. The file must only be modified in the event of a hardware change.
The Resource Manager calls and administers the information from the PHYSICAL.INI
file.
With help of the Instrument Soft Panels application you can create a physical.ini file for
the current system configuration. This is useful if new modules are added, a new system controller was assembled or if the slot assignments were changed. Refer to Chap-
ter 11.4.2, "Create Physical.ini", on page 238.
26User Manual 1143.6450.42 ─ 26
R&S®GTSL
5.2.1 Example file for PHYSICAL.INI
Configuration Files
PHYSICAL.INI
[device->PAM]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
SFTDll
SFTPrefix
[device->PSAM]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
; Note: the self test DLL and prefix keywords must be removed for the
first TS-PSAM module, because it is already tested in the basic
self test.
= "TS-PAM, Analyzer Module, Slot 5"
= PAM
= PXI1::13::0::INSTR
= rspam.dll
= rspam
= "Simulate=0,RangeCheck=1"
= sftmpam.dll
= SFTMPAM
= "TS-PSAM, Source and Measurement Module, Slot 8"
= PSAM
= PXI1::10::0::INSTR
= rspsam.dll
= rspsam
= "Simulate=0,RangeCheck=1"
Description
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
10
;SFTDll
;SFTPrefix
[device->PICT]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
SFTDll
SFTPrefix
= sftmpsam.dll
= SFTMPSAM
= "TS-PICT, In-Circuit Test Extension Module, Slot
9"
= PICT
= PXI2::15::0::INSTR
= rspict.dll
= rspict
= "Simulate=0,RangeCheck=1"
= sftmpict.dll
= SFTMPICT
10
10
1
2
3
4
5
6
7
8
9
27User Manual 1143.6450.42 ─ 26
R&S®GTSL
Configuration Files
PHYSICAL.INI
[device->PMB_15]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
SFTDll
SFTPrefix
[device->PSM1_16]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
SFTDll
SFTPrefix
= "TS-PMB, Matrix Module, Slot 15"
= PMB
= CAN0::0::1::15
= rspmb.dll
= rspmb
= "Simulate=0,RangeCheck=1"
= sftmpmb.dll
= SFTMPMB
= "TS-PSM1, Power Switch Module, Slot 16"
= PSM1
= CAN0::0::1::16
= rspsm1.dll
= rspsm1
= "Simulate=0,RangeCheck=1"
= sftmpsm1.dll
= SFTMPSM1
Description
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
[device->PSYS1]
Description
Type
ResourceDesc
DriverDll
DriverPrefix
DriverOption
SFTDll
SFTPrefix
; Analog bus pseudo-device, used by ROUTE, SWMGR and EGTSL
[device->ABUS]
Description
Type
[io_channel->system]
.DMM_HI
.DMM_LO
= "TS-PSYS1, System Module, Slot 15 (rear)"
= PSYS1
= CAN0::0::5::15
= rspsys.dll
= rspsys
= "Simulate=0,RangeCheck=1"
= sftmpsys.dll
= SFTMPSYS
= "Analog Bus"
= AB
= PSAM!DMM_HI
= PSAM!DMM_LO
1
2
3
4
5
6
7
8
9
10
1
2
3
11
12
12
28User Manual 1143.6450.42 ─ 26
R&S®GTSL
5.2.2 Description of Example File PHYSICAL.INI
Configuration Files
PHYSICAL.INI
The description is based on the example file in Chapter 5.2.1, "Example file for PHYSI-
CAL.INI", on page 27. The indicated numbers refer to the corresponding positions in
the example file. The place-holder "XY" in the following listing stands for the corresponding entries.
Table 5-6: Description of PHYSICAL.INI
1
[device->XY]
Defines the name under which the device is called in
the test libraries. A separate entry must be made for
each device. The entry in square brackets [ ] defines
a new section within which new definitions are made.
2
3
4
5
6
7
8
Description = "XY"
Type = "XY"
ResourceDesc = "XY"
DriverDll = XY
DriverPrefix = XY
Driver Option = XY
SFTDll = XY
Gives a detailed description of the defined device.
The entry is optional.
Gives the exact designation of the defined device.
This designation is needed to call the corresponding
device driver. The entry is mandatory.
Gives the necessary hardware information required
for the defined device.
The entry is mandatory.
Details provided at this point include, for example:
GPIB address: GPIB1::20::1 (example)
GPIB[card number]::[primary address]::
[secondary address]
Serial interface: COMX
PXI address: PXI1::10::0::INSTR (example)
PXI[segment number]::[device number]::
[function]::INSTR
Gives the path and the file name of the device driver.
Gives a prefix for the device driver.
Gives certain options applicable to the device driver.
Gives the path and the file name of the self test
device driver.
9
10
11
+
12
13
SFTPrefix = XY
[IO_Channel->system]
ResourceDesc_XY =
Gives a prefix for the self test device driver.
Text appearing after a semicolon (;) is interpreted as
a comment.
The following definitions of I/O channels apply to all
applications executed on the system. On the right
side are the physical channel names as defined by
the hardware and by the device driver. On the left
side are the logical channel names as used in the
test libraries.
In the case of certain devices, special subassemblies
can be addressed directly through their primary
address and secondary address. The relevant hardware information can be indicated especially for this
subassembly with the corresponding designation.
29User Manual 1143.6450.42 ─ 26
R&S®GTSL
Configuration Files
APPLICATION.INI
5.3 APPLICATION.INI
In the APPLICATION.INI file (Application Layer Configuration File) is a description of
how the individual test libraries and the test functions use the hardware components
(see example file APPLICATION.INI). Different hardware components can be combined into groups (bench). This bench can then be used within the test function. Furthermore, definitions are made in this file which apply to certain test applications to be
executed on the system (e.g. definition of designations in the case of multi-channel
operation).
The Resource Manager calls and administers the information from the
APPLICATION.INI file.
Since an Application Layer Configuration File (APPLICATION.INI) normally exists for
each test application executed on the system, the file name can be matched to the test
application in question, e.g. APP_XXX.INI. The Resource Manager is told during
setup which Application Layer Configuration File is to be used.
For ease of comprehension, the file name APPLICATION.INI is used for the Application Layer Configuration File in the manual.
5.3.1 Example File for APPLICATION.INI
[ResourceManager]
; general trace settings (normally off)
Trace
TraceFile
[LogicalNames]
ICT
[bench->ICT]
Description
Simulation
Trace
ICTDevice1
ICTDevice2
SwitchDevice1
= 0
= resmgr_trace.txt
= bench->ICT
= ICT bench
= 0
= 0
= device->psam
= device->pict
= device->pmb_15
Description
1
2
3
4
5
6
7
8
9
10
11
11
11
; used for functional test
SwitchDevice2 = device->PSM1_16
2
11
30User Manual 1143.6450.42 ─ 26
Loading...