R&S QuickStep Test Executive Software (1528.9010.02)
●
Development option for R&S QuickStep Test Executive Software
(1528.9026.02)
●
R&S QuickStep license dongle and key card (1528.9003.02)
The firmware of the instrument uses several valuable open source software packages. For information,
see the "Open Source Acknowledgment" document, which is available for download from the customer
web section on GLORIS, the global Rohde & Schwarz information system: https://extranet.rohde-
schwarz.com.
Rohde & Schwarz would like to thank the open source community for their valuable contribution to embedded computing.
Welcome to the R&S QuickStep Test Executive software! QuickStep provides a
high-speed test sequencer in combination with a powerful graphical user interface
for the parameterization and control of test execution. Test procedures are
designed in a graphical editor as flow charts based on the provided or additionally
developed test functions.
QuickStep lets you set up and run test plans – sequences of individual tests
together with scheduling and execution information –, to build test procedures and
to evaluate the test results. During test execution, QuickStep controls the test
equipment.
QuickStep includes example test projects for typical test conditions and hardware
setups. It offers facilities to adapt given test plans and their execution schedules
and to develop new ones. Customer extensions can easily be integrated, e.g. for
exploiting or developing special test algorithms.
If you only use the QuickStep OTA basic application (installed with QuickStep,
QS-ATSCAL license required), most test executive features are hidden at the GUI
but used in the background. For details, see the QuickStep ATSCAL OTA Testing
user manual.
1.1Key Features
General features:
●
High performance:
QuickStep causes a minimum processing overhead. The test execution speed
is comparable to native C++/C# code. Parallel execution of code is supported.
●
User-friendly handling:
Configurations are done via graphical user interface (GUI) and intuitive handling (for example drag & drop). Standard tests need only a minimum configuration effort.
●
High flexibility and wide application range:
–Examples and reference test cases are available and ready to run.
The test packages are optimized regarding time consumption.
9User Manual 1177.6223.02 ─ 11
R&S®QuickStep
–QuickStep is not confined to a certain set of test instruments since stan-
dard communication interfaces are used for controlling the test equipment.
3rd-party instruments are easily integrated.
–Customer-defined test setups and test conditions are supported.
–QuickStep is appropriate for production tests (particularly due to high per-
formance) as well as for test development purposes.
●
Support for developing test functionality and easy integration of customer
code
Test plan / test procedure configuration:
●
Static and dynamic parameter references
●
Convenient set and sweep functions
●
Limit handling
●
Configuration of preparatory and finishing test phases (for example for instrument initialization) around sequences of test steps
Welcome
Key Features
●
Dynamic control statements (loops, if conditions, jumps)
Test results and execution protocol:
●
Diagram for result plots
●
Histogram view for statistical analysis
●
Configurable result charts and live view results
●
Configurable reports
●
Test execution protocol viewer
System configuration management:
●
Graphical representation of the test setup
●
Intuitive building of system configurations with elements from a library
●
Parameter and path mapping for multiple test setups
Development of new tests:
●
Intuitive building of test procedures via flow charts of blocks from a library
●
Control structures (conditions, "If", "Or") and dependencies
●
GUI supported generation of source code templates for new test functions
●
Powerful API to support standard functionality
●
Microsoft Visual Studio® based test function development with C++ or C#
10User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Software Components, Product Licensing
●
Debugging support: Breakpoints allow to pause a test run on well-defined
steps and block functions; single step execution mode is provided
●
Usage and extension of R&S Forum, MATLAB and Python scripts
●
Support of user-defined dialogs implemented with Windows Forms or WPF
●
Standalone usage of block DLLs
Welcome
1.2Software Components, Product Licensing
The software has the following components:
●
Test Executive Software
Includes the complete functionality to define tests based on the provided block
functions, to run tests and analyze the results.
Type: R&S QS-APP, included option keys: R&S QS-EXE, R&S QS-EDI
●
Development Option
Enables the creation of new block functions. The Block Development Tool provides the complete interface to integrate user code into QuickStep via MS Visual Studio projects.
Type: R&S QS-DEV, option key: R&S QS-DEV, included option key: R&S QSDBG
Additionally required type: R&S QS-APP
●
OTA Basic Application
Provides the OTA ATSCAL view for easy and integrated control of OTA (over
the air) RF radiation testing, particularly for calibration and antenna measurements in combination with an ATS1000. No configuration of a testplan or test
procedure is needed. Test results (total radiated power, gain, radiation pattern)
are also displayed in the view including polar and 3D chart.
Type: R&S QS-ATSCAL, option key: R&S QS-ATSCAL
Additionally required type: R&S QS-APP
●
ATSDRV Positioner Driver Package
Provides the functionality to control an ATS-CCP1 antenna positioner with
turntable and one antenna boom.
Type: R&S QS-ATSDRV, free of charge
The licensing is realized with a License Dongle (R&S QS-DGL) and controlled
with the R&S license server. The license dongle consists of a smart card and a
USB smart card reader. If the license dongle is connected with a USB port at the
PC where QuickStep runs, the local R&S license server (contained in the Quick-
11User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Documentation
Step installation package) manages the licensing. If connected to a server in the
network (particularly for using floating licenses), an R&S license server at that
server is needed for managing the licenses.
Welcome
1.3Documentation
PDF documentation
The pdf documents are included on the product's USB stick. Most documents are
also accessible after QuickStep installation via the Windows "Start" button and
the folder "R&S QuickStep > Documentation" or via the QuickStep Help menu.
Additionally, the Getting Started is provided as printed document.
The pdf documentation consists of the following documents:
●
Getting Started
Provides basic information about the product and how to install it.
●
User Manual
Provides detailed information about the features of the application and how to
install, configure and use the application. The manual includes descriptions of
the applied mechanisms, step-by-step procedures showing how to carry out
typical tasks, a reference chapter where the GUI elements and their usage are
described, and application examples.
●
OTA Testing User Manual
User manual that is specialized for the OTA ATSCAL component of QuickStep.
●
Release Notes
Contains the most current information on the application, for example latest
changes, news, restrictions.
●
Training Manuals
Provide detailed descriptions how to use QuickStep based on instructive
examples. The descriptions include step-by-step procedures and many hints
on practical usage.
–User Training: Covers all topics related to the usage of QuickStep – except
for the development of new blocks.
–Developer Training: Covers the tasks for developing functional blocks.
Code examples illustrating how user-defined block functions are devel-
oped. The example code can be copied and inserted in programming files
12User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Welcome
Typographic Conventions
in MS Visual Studio; therefore two versions of the training manual exist:
one for programming in C++, one for programming in C#.
●
Quick Reference
Lists the typically required API functions on a poster.
●
ActiveReports User Guide
Describes how to use the ReportDesigner which is accessible via the Test
Procedure Editor's toolbar. The ReportDesigner allows to create and edit
report definitions and styles for the QuickStep reporting functionality.
Help, CHM documentation
●
The context-sensitive help system is embedded in QuickStep. Press the
"Help" button or the F1 key to access the help from the graphical user interface.
●
The QuickStep API description is a help system describing the classes and
files for block development. It is accessible via the Windows "Start" button and
the folder "R&S QuickStep > Help and Manuals" or via the QuickStep Help
menu.
●
Developer documentation (CHM files) of the provided R&S base blocks for reuse of the block functions for the development of 3rd party blocks.
1.4Typographic Conventions
This document uses the following typographic conventions to make information
easier to access and understand.
|Vertical bar indicates alternate selections - the bar means "or".
...Ellipsis indicates nonessential information omitted from the example.
1.5Using the Help
The help system is integrated into the software. The help system is an integral
part of the product's framework and thus provides information about all application parts that are officially released, independendly of whether the applications
are installed or licensed, or not.
1.5.1Accessing the Help
Use one of the following options to access the help. Depending on the specific
help calls, several help windows may open in parallel.
●
F1 key
Opens the help. If the selected GUI element provides context-sensitive help,
opens the related help topic.
For example, if a tab is selected, F1 will open a reference description for the
tab.
●
Menu bar
The "Help > R&S QuickStep Help" item opens the Online help ("Help" provides links to other documents, too).
Using ToolTips
Move the pointer over an element to display a short description of it.
14User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Welcome
Using the Help
1.5.2Navigating in the Help
As in most help systems, you can use common tabs to find the information of
interest. You find the tabs in the left pane: "Contents", "Index" and "Search". The
icons in the toolbar provide further navigation support, see the following table.
Table 1-2: Help menu
CommandDescription
"Hide"/"Show"Hides or shows the left pane.
"Previous"Opens the previous page of the help directory.
"Next"Opens the next page of the help directory.
"Back"Opens the topics you visited before.
"Home"Shows the start page of the help (legal notice).
"Print"Lets you print the current topic or the selected heading and all
subtopics.
15User Manual 1177.6223.02 ─ 11
R&S®QuickStep
What's New
2What's New
This document is related to version 5.0 of QuickStep and later.
The following sections list the main changes in the document since version 4.65.
For more details, see the Release Notes.
Test Procedure Editor
●
Block colors:
–Blocks newly created in the "Blocks & Connectivity" section get a default
color which you can change in the "Properties" pane. The same block
color is displayed for all test execution phases.
–Disabled blocks (see below) are displayed in grey color.
–Block functions that carry an execution condition are displayed with blue
frame.
●
Block context menu: Has been extended, for example with alignment and
resizing options.
●
Disabling a block (main area):
16User Manual 1177.6223.02 ─ 11
R&S®QuickStep
What's New
You can enable/disable all functions of a block via context menu. If disabling
was applied, the block turns grey. Afterwords you can use the "Enabled"
checkbox in the "Properties" pane to enable just the selected block function;
consequently the block gets its color again.
To enable/disable several blocks in one step, select them and use the context
menu.
●
Connecting a block automatically:
If you drag a block from the "Block Library" into the main area over an existing
block that has no outgoing connection yet, the new block can automatically be
connected to the existing block by dropping the block. The connection is directed from the existing block to the new block.
●
Alignment features (main area):
–Grid and snapping to grid
–Snapping to item
Figure 2-1: Snap to item
–Alignment of blocks and other items
17User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Licensing
What's New
Floating licenses can be used to unlock QuickStep functionalities. Occupation of
a floating license is controlled from the "Settings" menu with the new items
"Enable/Disable License Occupation" and "Set License Occupation Time".
The licensing is handled with the R&S license server web application (contained
in the QuickStep installation package). See Licensing Tasks for details.
Command line operation
New options are provided for using QuickStep without GUI in a command line
interface (CLI, via Command Prompt window). See Command Line Interface
(CLI) for a description of the command options.
18User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Block development
Pythons scripts can be used as functions of a script block.
What's New
19User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Typical Test Setup
3Introduction to QuickStep
This chapter provides a brief overview over QuickStep for a first orientation. The
given information is not comprehensive and not represented with full complexity.
3.1Typical Test Setup
Figure 3-1: Schematic test setup (DUT: Device under Test)
Characteristics:
●
QuickStep runs on a PC and controls the test instruments.
●
QuickStep basically commands a sequence of test steps where the values of
one or several test parameters are varied. The results for each test step are
collected and presented within QuickStep.
●
Typically, SCPI commands sent over LAN (or GPIB) control the test instruments. Any other remote control interface might be adapted.
●
The test instruments can be of any type. Examples are generators, analyzers,
power supplies, power sensors, switching devices. The number of used test
instruments is not limited.
●
One or more test instruments provide test signals as input for the DUT. Vice
versa, one or several test instruments gather signals or data from the DUT.
Examples:
–A generator instrument provides an RF signal to the DUT. QuickStep
defines the properties of the RF signal to be transmitted.
–An analyzer instrument receives RF signals from the DUT and measures
their properties. QuickStep gets the results from the analyzer.
–A power supply with variable voltage powers the DUT.
20User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Graphical User Interface
3.2Graphical User Interface
All operational tasks for configuring and executing tests are carried out on the PC.
When starting QuickStep, the "QuickStep" window – the graphical user interface
(GUI) – opens.
Figure 3-2: GUI overview
1 = Menu bar
2 = Tabs
3 = Toolbar
4 = Navigation / browser / library
5 = Main pane
6 = Secondary pane
The GUI is structured with a menu bar, tabs, a toolbar and several panes. The
content to be displayed is distributed in several tabs. The selected tab defines
which type of information is displayed in the different panes. See the descriptions
below for information on the content for single tabs. The entries in the toolbar also
depend on the selected tab.
21User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Graphical User Interface
3.2.1Test Execution
This view becomes relevant when the current test is executed. You can start the
test run and control the test execution.
Figure 3-3: Test Execution
1 = Start the test execution
2 = See and control the execution progress
3 = View the logged messages
4 = Select the block function flow chart of interest
5 = Inspect the current block function
Progress bar
The progress bar shows how far the test has been executed. You can control test
execution, for example resume test execution after a halt due to a breakpoint in
the test plan.
Log Viewer
The Log Viewer protocols the events occurred during operation of QuickStep,
particularly after starting the test execution. The messages are color-coded.
22User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Graphical User Interface
Test Procedure Debugger
The "Test Procedure Debugger" allows to check the values of parameters during
test run. It includes the Test Procedure Browser from the Test Procedure Editor
for selecting the block function diagram that contains the block function of interest.
The debugger works together with the progress bar during test run. You can proceed in the test execution step by step with the "Step" button. If you have defined
breakpoints for test steps (to be done in the Testplan Editor) and have clicked the
"Continue" button, the test execution is halted at each breakpoint until you click
"Continue" again.
3.2.2Test Plan Editor
The "Test Plan Editor" is the initial view of QuickStep. The user prepares a list of
test steps and starts the test execution from the toolbar.
Figure 3-4: Testplan Editor
1 = Select a sequence of test steps (or define groups and sequences)
2 = Inspect and edit the sequence of test steps
3 = Edit parameter values
4 = Start the test plan
23User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Central test step table
In the table, each test step is represented in one row, the columns display the
related parameters. Parameter values can directly be edited in the table after a
double-click.
Each test step is connected to a test procedure by the entry in the "Test Procedure" column. The parameter set of each test step is dynamically adapted
according to the selected test procedure. If test procedure parameters are modified in the test procedure editor, the modifications get effective in the test plan editor after clicking "Update Test Project" or when the test is started.
Powerful sweep and set functions allow quick generation of parameter sweeps for
efficient parameter setting of multiple test steps. Multi-parameter sweeps might
be defined within one single test step. Prioritization might be used to keep control
on the order of the parameter sweeps within nested loops.
Introduction to QuickStep
Graphical User Interface
Panes on the right-hand side
In the "Test Step Parameters" tab, the parameters of a test step are displayed in
vertical order for a better overview and providing a more convenient way to edit
parameters without scrolling. The "TPR Options" tab contains parameters for the
whole test, for example repetitions. The "Test Step Limits" tab shows the configured limits for measurement results.
Regarding test development, various settings for logging and debugging are
offered. Breakpoints for debugging and single-step execution can be enabled for
specific test steps.
Test Project Browser on the left-hand side
Multiple test step parameter tables are organized in a tree structure for keeping
an overview of large tests. Control structures can be applied to sequences of test
steps, their parameters are configured in the right pane. "Test Project Parameters" contains static and dynamic global parameters to be configured in the middle pane.
3.2.3Results Viewer
The results of a test run are displayed in the "Results Viewer".
24User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 3-5: Results Viewer
Introduction to QuickStep
Graphical User Interface
1 = Select a result file
2 = Inspect the result table and select one or more result columns
3 = Inspect the diagram representation of the results for the selected column(s)
4 = Inspect the distribution of result values and check the statistical evaluation
Results File Browser on the left-hand side
The "Result File Browser" helps to keep an overview of large sets of result data.
Each test run generates a new time-stamped folder with a complete set of result
files with tab-separated measurement and timing results. When testing several
DUTs in "Continuous Run" mode, a separate subfolder is created for each DUT. If
results of the type trace are generated, these are also collected in a DUT-specific
subfolder. Additionally, a copy of the test plan and the execution log is stored as a
reference.
When selecting a result file in the Result File Browser, its content is shown as
table in the central area. TestStepsResults.log is the main result file con-
taining the results for each test step. ExecutionProtocol ... .txt contains
all logged messages with timestamp and origin.
Central Results Table
The central "Results Table" shows the results in a table. In case
TestStepsResults.log has been selected, each test step is presented in one
row and each result parameter in one column. If one or several result parameters
25User Manual 1177.6223.02 ─ 11
R&S®QuickStep
in the results table are selected, the results over the test steps (or other configurable running variables) are represented in the diagram on the right-hand side.
Each column of the table offers powerful sort and filter functions. An export filter
makes it possible to export a subset of the table as CSV or XLS file. In case the
table shows the content of the execution protocol, it is possible to export and
reuse SCPI sequences within other test environments. References to specific
results can be created via right-click. These can then be used in the "Test Procedure Editor".
Analysis panes on the right-hand side
The "Diagram" pane plots the data of a single or multiple columns that are
selected within the result table. Scatter plots are possible, since any result parameter can be selected for the x-axis of the plot. Results can be assigned to colorcoded groups by selecting an additional grouping parameter. Delta markers are
available for measurements.
Introduction to QuickStep
Graphical User Interface
If results of the trace type are selected, an adopted diagram pane is available.
Traces files can also be loaded directly into the central results table and displayed
with the standard results viewer. Zoom in and out is supported by mouse click,
mouse wheel and diagram bars. A right-click menu offers access to additional
settings.
The "Histogram & Statistics" pane provides a histogram pane and statistical
analysis of the result data that is selected within the result table.
3.2.4Test Procedure Editor
A test procedure basically defines what functionality is executed when the test
steps connected to the test procedure are carried out. The blocks which can be
used for a test are managed in the "Blocks & Connectivity" part. The test flow for
each procedure is then set up as flowchart with a graphical editor, based on a
library of provided functions or user-developed functions.
26User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Graphical User Interface
Figure 3-6: Test Procedure Editor
1 = Select an execution phase
2 = Drag a new block function into the main pane
3 = Select block functions, add block function dependencies, select a block function
4 = Edit the parameters of the selected block function
Control elements such as "If", "Or", “Fork” and “Join” are available to handle execution branches and loops. Conditions achieve a conditional execution of test
functions. All test function parameters can be made available for test parameterization within the test plan editor. Existing test procedures can be modified or
extended without source code development. The right-click menu provides
accesss to additional features like automatic alignment or changing the block
instance. If a new block function is dropped directly on an existing block function
without a successor, the new block function is automatically connected.
The toolbar provides access to tools for developing blocks, handling SCPI commands for connected test instruments, designing reports and integrating scripts.
3.2.5System Configurator
The "System Configurator" reflects the test setup and can be used for setting the
device- and connection-specific parameters as occurring with the test setup.
27User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 3-7: System Configurator
1 = Drag a symbol into the main area
2 = Connect the symbols
3 = Select an element
4 = Edit the properties (parameters) of the selected element
Introduction to QuickStep
Graphical User Interface
The main pane displays the used devices (test instruments, components, even
attenuators) and connections. You drag devices from the "Device Library" on the
left pane into the main pane. Then you draw connections between the devices.
On the right side in the "Properties" pane, you can see and edit the properties of
the currently activated device.
The system configurator facilitates the handling of several use cases:
●
Assistance for building up a VISA connection to a test instrument.
●
Automatic calculation of the RF path loss during test execution. Attenuations/
losses for individual components of the system are defined, then one or more
connections and system components are assigned to an RF path.
●
Easy switching between several test benches. Therefore, the system configuration contains the configuration for each of them.
●
Management of system-dependent parameters like connection IDs.
Using these features in a test plan is optional, the "System Configurator" can also
be left empty.
28User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Introduction to QuickStep
Block Function Development
3.3Block Function Development
The Block Development Tool is provided for defining new test blocks, test functions and the associated function parameters. Based on these definitions, Microsoft Visual Studio C++ or C# projects with source code templates are automatically generated. The templates just have to be extended with user code in order
to create user-specific test functions. The newly developed test functions are
available in the test procedure editor after compilation.
Figure 3-8: Main section of the Block Development Tool
The QuickStep API (application programming interface) offers a comprehensive
set of functions for data exchange with other functions, logging of results and
other frequently required tasks. Even users with limited software development
experience can implement new test functions with just a few lines of code. Development experts can exploit all capabilities of Visual Studio for development of
complex test functions.
29User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Test Structures and Their Relations
Concepts
4Concepts
4.1Test Structures and Their Relations
Test plans, test procedures and blocks
QuickStep organizes a test configuration with the following main structures:
●
Test plan: Contains a sequence of test steps, each one using a set of parameter values, and scheduling information. Each test step is connected with a
test procedure. Multiple test procedures for different test purposes may be
used in one test plan.
●
Test procedure: Defines the test functionality to be applied within a test step.
A test procedure is structured by a flowchart of block functions (see below)
which execute application software. The block functions can be arranged with
certain control structures.
●
Block: Contains a set of functions and one function is selected. A function fulfills a certain task and provides the parameters for user input. Often, a block
reflects the functionality of a test instrument. But it can also represent instrument-independent functions ("software block") or only parts of an instrument's
functionality. User-specific block functions can be developed with C++ or C#
or with scripts (Python, Matlab, Forum).
This structure keeps the test steps free from the real test equipment functionality.
The concept of blocks carrying functions allows you to provide, adapt and
develop test algorithms optimized for special test equipment and test conditions.
The blocks in a test procedure can be arranged in parallel or in sequence or in
combination with decision functions.
Figure 4-1: Logical representation of a test (principle)
30User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Structures and Their Relations
A test step is connected with a test procedure by its Test Procedure value in the
testplan table. See the figure where test steps 1 and 2 are connected to Test Procedure A.
Figure 4-2: Connecting a test step with a test procedure
Parameters
Parameters provide the concrete, quantitative settings used for the test execution,
for example frequency and power values.
The same parameters are related to block functions, test procedures and test
plans as well: The parameters required for specific functionality (for example for
controlling a generator instrument) are defined by block functions. So, they
appear in a test procedure when the related block function is added in the procedure. Afterwards, they get available for the test steps of a test plan table when the
test steps are connected to the test procedure.
In the test plan table, the parameters are displayed as columns, grouped by the
originating functions. Usually, the parameter values are set in the test steps of the
test plan with certain variations over the test steps. When the test is executed, the
functions of the connected test procedure take over these values e.g. for their
communication with the test instruments and calculations. This interplay between
test steps and test procedure is fundamental; a test step without connected test
procedure is undefined.
Figure 4-3: Definition and display of parameters (principle)
31User Manual 1177.6223.02 ─ 11
R&S®QuickStep
The default values of the parameters in the test plan refer to the parameter values
set in the "Properties" section in the "Test Procedure Editor". Parameter values
can also be set by references, see chapter Setting Parameter Values by Referen-
ces.
Additionally, common parameters for a test procedure or even the test project can
be defined.
Test run mechanism
When starting the test execution, the test steps of the test plan are processed
according to the order and the repetitions defined in the test plan. For each test
step reached during the test run, the connected test procedure is called. The test
procedure takes over parameter values from the test step and executes the functions as defined in its blocks and regarding their arrangement.
The sequence of test procedure executions for the test steps is enframed with
some procedure-like control structures (for example "Testrun Before"). Usually,
the term "Test Procedure" is reserved for the procedures related to test steps
only, but if convenient, the additional procedure structures can also be included.
The parameter sets of the control structures also appear around a test step table
and are included in the term "Test Plan" if convenient.
Concepts
Test Project
4.2Test Project
A test project is the master structure for the components of a QuickStep test. For
each test, it contains the test plan and test procedures as well as result and log
files, various configuration files and other components. The following figure gives
a symbolic overview over the main components, their main substructures and
relations. The blue colored fields correspond with the main GUI partitions (Test
Plan Editor, Results Viewer, Test Procedure Editor and System Configurator). The
system configuration is optional.
32User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Execution Phases
Figure 4-4: Test project structures and relations (simplified)
See Chapter A, "File Extensions and File Locations", on page 308 for information
about actual file locations.
4.3Test Execution Phases
An overall test run consists of several phases. Phases which contain block functions are displayed in the "Test Project Browser" within the "Testplan Editor". The
parameters for the currently active phase are displayed in the table area of the
"Testplan Editor". The functionality to be executed for such an item is configured
by block functions in the "Test Procedure Editor".
33User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Execution Phases
Figure 4-5: Test execution phases and their representation in Testplan Editor and Test
Procedure Editor
The "Test Steps" phase is the main one where the actual testing takes place.
Other phases control settings before the "Test Step" phase is started or after it
has ended.
Test execution phases:
●
"Testrun Before" and "Testrun After" (mandatory phases): are executed once
at the beginning and end of a test run. They are used for initializing the test
instruments and for closing their activities and the connections to them in the
end.
●
"DUT Loop Before" and "DUT Loop After" (optional, not displayed here if no
function is connected) become relevant if several DUTs are tested in a row
(DUT: Device under Test). They are executed at the begin and end of the test
of each DUT. For details, see Chapter 4.10, "DUT Handling", on page 66.
The DUT loop mechanism can be used for the control of a handler in a production environment.
●
"Test Procedure Before" and "Test Procedure After" (optional) become relevant if test steps of the test plan are assigned to different test procedures. The
functions within these phases are executed whenever the test procedure
changes during test run. Use these phases for setting and assuring defined
system states when changing the test procedure.
●
"Test Procedure" (mandatory) executes the sequence of test steps as defined
in the table of test steps.
34User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Repetitions of the test procedure execution phases can be used to validate the
stability of measurement results and to improve the reliability of results. Result
data is generated in a loop for statistical analysis.
Concepts
Test Plans
4.4Test Plans
A test plan consists of one or more test sequences, each with individual test steps
to be executed consecutively. Several sequences can be collected in a group and
the test plan can comprise several groups. Control statements can be used to
additionally structure a test plan. The test plan also contains scheduling information such as the number of repetitions and conditions for the execution of a group
or sequence of test steps. Each test step is represented by a row in the test plan
table. The test steps have groups of parameters, see the following figure showing
an example. Each group to the right of the Test Step Settings and Test Procedure
Parameters represents the parameters of one block function.
Figure 4-6: Groups of test plan parameters (example)
●
The Test Step Settings (light grey) comprise some control parameters. The
Test Procedure column offers a drop-down menu for selecting the test procedure used for this test step (if more than one test procedure has been defined
within the Test Procedure Editor).
●
The Test Procedure Parameters comprise the parameters with common settings for several block functions. The block functions take over the parameter
values by reference. This mechanism avoids that common parameters have
to be set at the generator and the analyzer separately).
●
The parameters of the generator function (selected in a generator-related
block) define the characteristics of the signals which the generator transmits
to the DUT, for example frequency and power. The shape and details of the
signals are determined by waveform files.
35User Manual 1177.6223.02 ─ 11
R&S®QuickStep
●
The parameters of the analyzer function (selected in an analyzer-related
block) define which measurements are executed, for example the Adjacent
Channel Leakage Ratio (ACLR) or the Error Vector Magnitude (EVM).
It depends on the selected test procedure and its underlying functionality which
parameter columns are displayed (dynamic column sets).
Concepts
Test Plans
4.4.1Test Sequence with Several Test Procedures
The following figure shows the execution order of the phases for a test run where
two test procedures are involved.
Figure 4-7: Test with two test procedures
4.4.2Single-Line Sweep
A parameter in the test plan table can be varied by a loop within one test step.
This mechanism is called single-line sweep. It realizes a sequence of value iterations for a parameter in a compact way while the other parameters keep their values. The single-line sweep belongs to one table cell (determining both the parameter and the test step) and is defined by usual loop parameters: Start value, step
size and count (or stop value instead of step size). Such a sweep can conveniently be set up with the help of the "Edit Test Step" dialog from the context menu.
36User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Plans
Figure 4-8: Definition of a single-line sweep
For each loop iteration, the complete test step actions are carried out and an own
result is logged. The results are distinguished by their loop ID in the "Loop ID"
column of the results table.
If several single-line sweeps are applied in the same test step, the loops are nested. A priority parameter determines the order of the loops: Assumed that there
are two single-line sweeps (for example with priority values 1 and 2), the sweep
with the higher priority number (2) is carried out in the inner loop. In case of several single-line sweeps with same priority, all parameters are altered in each test
step.
37User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Figure 4-9: Execution and result of a single-line sweep
4.5Test Procedures
Test procedures control the flow of actions and executed functions during test run,
typically the operation of the test instruments, and are structured by blocks and
selected functions – short: block functions. Dependencies between block functions and conditions for their execution can be defined. The following figure
shows a part of an example test procedure. The test procedure is related to the
"Test Procedure" item of the "Test Procedure Browser". "Test Procedure" contains
the functionality to be executed for each test step which is connected to that procedure.
38User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Figure 4-10: Test procedure (example)
Regarding a complete test run, a test procedure is embedded in some procedurelike control structures. The overall functionality for a test run is distributed in a
"Blocks & Connectivity" section and several test execution phases (for example
"Testrun Before"; "Test Procedure" is one of them). The phases are selectable via
the "Test Procedure Browser" on the right side of the Test Procedure Editor.
4.5.1Blocks & Connectivity
All blocks which are used within the test procedures of a test project have to be
added to "Blocks & Connectivity". If a block is not contained in "Blocks & Connectivity", it is not available for any test execution phase. Several instances of a block
can be used.
Figure 4-11: Blocks & Connectivity (example)
Block Connections
Connections between blocks define the paths for inter-block communication (data
transmission between blocks). Such block connections are created and displayed
in the "Blocks & Connectivity" tab. Block connections are required if a block
39User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Test Procedures
needs information from another block, for example state or control information or
any kind of data, to work properly. Or a block could require another block to execute a specific function.
Each block connection is represented by an arrow line from an out port to an in
port. The connection has its origin at an appropriate out port of the block requesting some data or activity. It terminates at an appropriate in port of the block
receiving the request. The answer to a request is sent back over the same connection.
The blocks provided within QuickStep already indicate by their ports if they can
have a connection for passing or getting information. A port name often tells
which type of block is needed for the other end of the connection. For example,
the GeneratorOut port of the requesting SensorPAMeas block is connected with
an in port of the receiving RSGenerator block (see the figure) which is the RSGeneratorContr port.
Concepts
When developing a new block, its block ports have to be defined via the Block
Development Tool, see for example Chapter 9.3.2, "Block Definition File Editor",
on page 276.
In "Blocks & Connectivity" also some parameters can be set for each block
instance ("Enabled", "Emulation Mode", "Block Instance Color"). A right-click
menu additionally offers to change the block instance for all related block functions.
4.5.2More about Test Execution Phases
The test execution phases are selected in the "Test Procedure Browser". The
functionality of the different test execution phases is defined by flow charts of
block functions in the main (middle area) of the Test Procedure Editor. Each
phase has its own block functions.
40User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Figure 4-12: Test execution phases in the Test Procedure Browser
The "Main Procedure ..." nodes within the "Test Procedure Browser" collect the
phases which serve as frame for the test run. The node following "Main Procedure Before" contains the actual test procedure. Each "Test Procedure" has two
enframing phases "Test Procedure Before" and "Test Procedure After".
Several test procedures used in one test plan
Several test procedures (with accompanying "Test Procedure Before" and "Test
Procedure After" phases) can be defined in the "Test Procedure Browser". A test
plan may use more than one of them. The "Main Procedure ..." actions are
applied for all test procedures.
41User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Figure 4-13: Several test procedures used in one test plan
4.5.3Block Functions
A block is displayed with its name given in the headline and a selected function
below the block name. The function defines what is done when the block comes
into action. Generally, the functions operate based on associated parameters
which are displayed in the "Properties" area on the right side of the Test Procedure Editor. The parameter values are often set in the current test step of the connected test plan. A parameter appears in the test plan table and is set there if its
check box in the "Properties" area is not ticked.
42User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-14: Parameters associated with a block function
Concepts
Test Procedures
Rohde & Schwarz provides blocks for several R&S test instruments. You can also
create your own blocks and integrate any functional code, see Chapter 7, "Block
Development", on page 129. In all cases, the block structures are the same.
4.5.3.1Execution Conditions
Each block function in a test procedure contains the "Condition" property which
controls if the block function is executed or not depending on the values of
parameters during test run. The condition is a functional and logical expression
with parameter values, mathematical functions and operators and logical operators. It is evaluated when the block is reached during test run. If the condition is
satisfied (true), the block function is executed. Else (false), the block function is
skipped. Blocks are framed in blue color in the Test Procedure Editor if they contain a dependency.
Conditions can contain references to parameter values from other data structures
(test plan, test procedure, test result), see Chapter 4.7, "Setting Parameter Values
by References", on page 52 and Chapter 6.4, "Setting Values by Reference",
on page 104.
43User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Test Procedures
Figure 4-15: Execution condition for a block function
Syntax rules:
●
The condition has to be expressed in accordance with the Mathematical
Expression Toolkit Library (ExprTk) which QuickStep uses for evaluation.
Condition: ($P.Frequency) <= 1900
The block function is executed if the value of the test procedure ($P) parameter "Frequency" is equal to or exceeds 1900.
●
Condition: ($T.ServoMode) == true
The block function is executed if the value of the test project ($T) parameter
"ServoMode" is true.
This kind of condition is useful for controlling a fork block connection, e.g. for
two fork ends: The block function at the left fork end gets the condition
($T.ServoMode) == true, the block function at the right fork end gets the condition ($T.ServoMode) == false.
●
Condition: ($R.<RS_Mathematics><Calculation><Result><this><this><this>)
<= 16
The block function is executed if the current value of the Result parameter is
equal to or less than 16.
44User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Test Procedures
Note that a condition containing a result reference is resolved at runtime during
test execution. The affected block function is not activated until the result is available. Depending on the value of the expression in the condition, the block function is then either executed or skipped.
For more details and examples using references and expressions in conditions,
see the QuickStep User Training manual.
Concepts
4.5.4Connections between Block Functions, Control Structures
Arrow connections in a flow chart of blocks define the execution order within a
test procedure phase. They are drawn via mouse. First, the block function at the
arrow base is processed, then the system proceeds to the block function at the
arrow head. All root block functions without incoming arrow are initially started in
parallel when the test procedure is executed. Block functions belonging to different blocks are executed in individual Windows threads.
Fork and join dependencies
Blocks without dependencies are executed in parallel. Explicit parallel execution
of functions is supported with fork and join dependencies between several blocks.
These dependencies can be drawn in the "Test Procedure Editor" arrow line by
arrow line in the same way as simple dependencies (via mouse). The additional
Fork/Join element provides a simultaneous forking and joining point for any number of incoming and outgoing dependencies. Even a combined join and fork structure can be realized (e.g. three incoming block dependencies and two outgoing
dependencies). The Fork/Join element improves the readability of test procedures
in case of forks and joins but has no other function (forks and joins can also be
realized without this element). It is transparent for the test execution, and the execution timing is already determined by the block dependencies.
45User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-16: Fork/Join element in a test procedure
Concepts
Test Procedures
Figure 4-17: Alternative join dependency
●
Fork dependency: After the block function at the fork base has been executed,
the block functions at the fork ends are executed in parallel.
●
Join dependency: The block function at the joining end comes into action after
the selected functions of all blocks at the originating ends have been executed. This corresponds with a logical AND on the input of the block function.
The execution of the block at the join end is inhibited if the execution of only
one originating block does not come to an end. This behavior can cause an
unwanted stop of the test run and can be avoided with an appropriate condition for the block, see Chapter 4.5.3.1, "Execution Conditions", on page 43.
●
Combined join and fork dependency with Fork/Join element: This structure
has the same behavior as if the arrow lines have been drawn directly from the
originating blocks to the terminating blocks. In case of three incoming block
dependencies (from blocks 1, 2, 3) and two outgoing dependencies (to blocks
A and B): Block A comes into action after blocks 1, 2, 3 have been processed.
Block B behaves in the same way. Consequently, block A and block B are
executed in parallel.
46User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Control statements: If, Or, End
The course of block functions executed during test execution can be controlled
with "If" and "Or" statements. In this way, block functions can be repeatedly executed in one test step, for example in combination with loops. The end of an
assembly of block functions can be stated by the "End" element. The following
figure shows by example how these elements are used.
Figure 4-18: Control statements in a test procedure
The "End" statement is only required if "If" or "Or" statements are used in the
block flow chart (to avoid that the test execution phase ends when one branch
execution is completed).
The "End" statement can be used in two ways:
●
Several branches end in one single "End" statement: The execution phase
ends as soon as the block functions on all input connections to the "End"
statement are completed.
●
The test procedure branches terminate in several different "End" statements:
The execution phase ends when the first "End" statement is reached. Already
started block function are completed, but no new block functions are started in
that execution phase. The following execution phases are started as usual.
For more information, see the QuickStep Training Manual.
47User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Test Procedures
Concepts
4.5.5Parallel and Synchronized Test Execution
4.5.5.1Parallel Execution of Block Functions
A parallel execution of block functions is often useful to shorten the overall test
time. Therefore, the block functions are arranged in parallel in the "Test Procedure".
If functions of the same block shall be executed in parallel, a second condition is
required for real parallel execution: The block functions must belong to own block
instances. The mechanism is illustrated by example with two block functions.
Case A: Only quasi-parallel execution
Figure 4-19: Quasi-parallel block execution
The block for the used block functions is added once in the "Blocks & Connectivity" section resulting in just one block instance. One block instance defines one
thread and both block functions are executed in this thread. The block functions
send communication messages in parallel according to their arrangement in the
test procedure. Since there is only one block instance, the messages get into the
incoming queue of the block instance and are processed sequentially.
48User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Test Procedures
Case B: Parallel execution
Figure 4-20: Parallel block execution
The block is added twice in the "Blocks & Connectivity" section resulting in two
instances of the block and two threads for block function execution. The block
functions are executed in separate threads, so they are executed in parallel.
4.5.5.2Synchronization during Test Execution
The figure shows the synchronization points during execution of a test including
the test phases.
49User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
System Configuration
Figure 4-21: Synchronization
Synchronization takes place at the Join elements (black bars). “Synchronize nonLog messages” waits for all block functions to be completed. For example, a
block function calls another block function asynchronously with the called block
function not contained in the block function flow chart of the test procedure
(implicit call). If the block functions were not synchronized, block functions of different test steps would run in parallel, and this behavior is not intended.
Log messages do not influence the functionality. Therefore, they can be
synchronized after all repetitions are done. The log messages are synchronized
with “Synchronize System”. The logging information is separated from the test
procedure execution to guarantee high performance. This leads to a performance
optimized processing of the log messages which uses idle time during test execution.
4.6System Configuration
The System Configurator can be used to model the physical test setup in terms of
devices, RF connections and paths (groups of contiguous RF connections and
attenuator components). Frequency-dependent attenuations can be defined. Dif-
50User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
System Configuration
ferent test benches for a test project are modeled with different system configurations.
Figure 4-22: System Configurator
1 = Drag a symbol into the main area
2 = Connect the symbols
3 = Select a symbol or connection
4 = Edit the properties (parameters) of the selected device/connection
Initially, the System Configurator is just a graphical representation without direct
link to the test execution. When building a new system configuration, the displayed system and its elements (test instruments and any object that is represented as symbol) have no associated parameters at first; the "Properties" view for
these elements is empty. The system configuration parameters are created with
the "Mapping Table Editor" accessed via the "Testplan Editor" and mapped to elements of the system configuration, see "Referencing to system configuration
parameters"on page 55 (note that there is no need to limit the usage of sym-
bols in the system configuration to blocks used in the Test Procedure Editor's
"Blocks & Connectivity" section). Afterwards, the test plan or test procedure can
set values of parameters by reference to system configuration parameters, see
again Referencing to system configuration parameters.
Using the System Configurator is mandatory if path attenuations are used. For
more details, see Chapter 4.8.2, "Compensation of RF Attenuations via System
Configuration Paths", on page 59. Otherwise the usage is optional.
Using system configurations and referencing to system configuration parameters
keep test procedures free from the test setup details and allows to switch easily
between different test benches.
51User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Setting Parameter Values by References
Use cases
●
VISA resources of the test instruments (closely related to the test setup) are
set in the System Configurator and used in the test procedure after appropriate mapping.
●
Attenuations for RF connections, additional RF components (for example splitters) and RF paths are set in the system configuration and used in the test
procedure after appropriate mapping. It is often more convenient to handle
path attenuations than the attenuations of all the single path components.
●
Several test benches are available, for example the test setup is realized with
different types of test instruments. All system-specific settings (attenuations,
VISA recourses, …) are centrally managed within the system configurator.
Handling:
–The different test benches are described by different system configura-
tions.
Concepts
–The test procedure contains general block functions suitable for different
devices.
–Parameters of the general block functions are mapped to the desired sys-
tem configuration and its elements. Selecting one of the system configurations automatically selects all system-specific settings.
●
The test setup contains more than one instrument of one type (for example
two R&S NGMOs): Set instrument parameters according to the instrument's
position in the test setup, i.e. in the system configuration.
System definition file
A system configuration defined by the "System Configurator" is embedded in the
*.tpl test plan, but it can separately be exported and imported as *.sdf system definition file. In this way, sharing of system configurations is supported.
4.7Setting Parameter Values by References
QuickStep provides referencing functionality: Parameter A can get the value of
parameter B by reference; therefore the value entry of parameter A is a reference
to parameter B.
Use cases:
52User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Setting Parameter Values by References
●
Several block functions require the same parameter (for example “Frequency”
at generator and analyzer block functions): It would be inconvenient to set the
parameter values at each block function. Instead, a common parameter (for
example a test procedure parameter) is defined and the analog parameters of
the block functions get their values by referencing to this common parameter.
●
During test run, a result of a test step or block function is used as input for a
following test step or block function, for example:
–The input parameter for the current test step gets its value by reference to
the result variable of another, previous test step.
–An out parameter value of an executed block function determines if a fol-
lowing block function is carried out or skipped (dynamic execution condition).
●
Parameters which are closely related to the test setup and are used in the test
plan: The values of such parameters are best set in a system configuration.
The test plan parameters get their values by referencing to system configuration parameters. Note that system configuration parameters have to be created via "Mapping Table" within the "Testplan Editor" before they are available
for referencing, see "Referencing to system configuration parameters"
on page 55.
Concepts
●
VISA resource strings are required for several test instruments: The VISA
resource strings are collected in one table. The resource string parameter of
an instrument block function gets the required string by reference to the table.
The reference to a parameter is realized as reference string set in the input field
of the referencing parameter. The reference string is composed of a starting $
followed by the area indicator (describing where the referenced parameter is located) and the referenced parameter's Id. See the table below for details and additional options.
Referencing via the "Set Reference" dialog is more convenient. This dialog is
available in various contexts, for example for parameters in the "Test Step Parameters" tab within the "Testplan Editor". The "Set Reference" dialog is opened
when a parameter input field is right-clicked and "Set Reference" is selected. See
"Set Reference dialog"on page 222 for details.
53User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-23: Set Reference dialog
Table 4-1: Reference strings
Concepts
Setting Parameter Values by References
Reference area
("reference to")
Test project$T.$T.BandReference to the test project parameter
Test procedure$P.$P.FrequencyReference to the test procedure param-
Reference to the global variable with Id
"TestStepMeasValue"
Value can change during test run
eter with Id "Frequency"
Reference to the EVM result in current
repetition and loop, last test step. The
EVM result belongs to the RSAnalyzer
block and the Measure EVM block function
Reference to the In Power result in repetition 3 and test step 7
System configuration
Short version:
$R.<Pin>
$M.$M.SMW_ChannelReference to the system configuration
$V.$V.VisaAliasReference to a VISA resource string
Reference to the current In Power result
parameter of the selected system with
Id "SMW_Channel"
configured in the “VISA Instruments”
section in the System Configurator
54User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Setting Parameter Values by References
Note the difference between test project parameter ($T) and test project variable
($G): The value of a ($T) test project parameter is fixed during a test run while the
($G) test project variable's value can change.
Special care hast o be taken when using global variables to avoid race conditions. For example, the procedure dependencies have to ensure that a measurement is written into a $G variable before it is used in another block function as
input value.
How to: See Chapter 6.4, "Setting Values by Reference", on page 104
How to: See Chapter 6.5, "Using a Block Function Result as Input for Another
Block Function", on page 108
Note that in the testplan table all values which were determined by resolving a
reference are displayed in blue font.
For more details (for example concatenating references) and examples, see the
QuickStep User Training manual.
Concepts
Referencing to system configuration parameters
Use case: A test plan shall be executed with several test setups. The test setups
consist of the same functional components (analyzer, generator, ...) but are realized with different devices (for example same type but different LAN addresses)
or different device types (analyzer type A, analyzer type B, ...). The devices acting
as the same functional component shall be controlled by the same parameters
but with different values. So, the same test plan and test procedure can be used.
55User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Setting Parameter Values by References
Figure 4-24: Referencing for several test setups
Solution: The test setups are represented by system configurations. If the value
of a parameter used in the test plan or test procedure depends on the used
device / test setup, a kind of global parameter, a system configuration parameter,
is created which is mapped to the related device of each system configuration.
Then, the value of the parameter in the test plan or test procedure can be set as
reference to the system configuration parameter. For changing the test setup, you
just have to change the active system configuration in the "Testplan Editor". Consequently, the system configuration parameter and subsequently the referencing
parameter in the test plan or test procedure gets its value from the selected system configuration. No test step or test procedure parameters have to be adjusted
when changing from one test setup to the other one.
Creation of system configuration parameters and mapping to systems and their
elements (like devices) is done with the "Parameter Mapping Table" in the "Testplan Editor", not in the "System Configurator".
56User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Handling of RF Attenuations
Figure 4-25: Creation and mapping of system configuration parameters
For information about using system configuration paths, see Chapter 4.8.2,
"Compensation of RF Attenuations via System Configuration Paths",
on page 59.
4.8Handling of RF Attenuations
Connections (cables, connectors) between DUT and test instruments as well as
other devices (e.g. splitters, attenuators) in the RF signal paths produce signal
attenuations. These attenuations are compensated in order to avoid inaccurate
results. The compensation makes sure that, for example, the test instruments
57User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Handling of RF Attenuations
indicate exactly that power values which are present at the DUT's ports. In a typical application, the attenuations for an output path (signal from the DUT) and an
input path (signal to the DUT) are compensated separately.
Figure 4-26: Compensating in and out attenuations
Concepts
4.8.1General Methods
Frequency-independent compensation: The most simple way of compensation
uses just one fixed in attenuation value and one fixed out attenuation value for all
attenuation contributions in an RF path. Some test procedures provide RF Level
Offset parameters which can be used for compensating the attenuations. For a
better transparency, it is recommended to use path compensation as described
below.
Frequency-dependent compensation: This method requires attenuation tables,
each row containing the attenuation values for one frequency. The standard files
for this purpose have the *.s2p, *.s3p or *.s4p format (SnP files, Touchstone
format) and are typically generated using network analyzers. Alternatively, *.csv
files can be used which allow to store frequency-dependent information in a simpler way.
All loss files to be used by a specific QuickStep project have to be placed in the
project sub folder:
C:\...\ProjectName\ConfigurationFiles\LossFiles
58User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Handling of RF Attenuations
Concepts
4.8.2Compensation of RF Attenuations via System Configuration Paths
QuickStep handles attenuations with the following items:
●
Paths in the System Configurator defining attenuations (see figure in Paths in
the System Configurator and 1 in the figure below)
●
Mapping parameters (2 in the figure below) which are mapped (linked) to System Configurator paths; this is done in the "Mapping Table Editor" within the
Testplan Editor; the mapping parameters are also created in the "Mapping
Table Editor"
●
Test procedure or block function parameters of type RF_Path (3 in the figure
below) that get a mapping parameter as value
Figure 4-27: Using a system configuration path via mapping parameter
The test procedure or block function parameters get the attenuations defined in
the System Configurator via the intermediate mapping parameters.
This approach keeps attenuations of the test setup in the system configuration
and decouples the test procedure from test setup details. It is also possible to use
the same mapping parameters for different system configurations, so the same
test plan and test procedure can be used without parameter change if the system / test setup is changed to a corresponding system / test setup.
Note that block functions can have parameters of type RF_Path (defined in the
Block Development Tool). Parameters of this type can directly be filled with a
number of type double (negative value for a loss (attenuation), positive value for a
gain) or with the name of an RF path mapping parameter.
59User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Paths in the System Configurator
Concepts
Handling of RF Attenuations
Figure 4-28: Paths in the System Configurator
Multiple input and output paths can be defined in the System Configurator. Each
path collects RF elements (whose individual attenuations are separately assigned
in the "Devices" and "Connections" nodes in the System Browser). The "Use"
parameter of the path "Properties" defines how the attenuation of the path is calculated. "Use" has the following values:
●
"Subelements": The path attenuation is calculated as sum of the attenuations
of the individual path elements.
●
"Path Loss": The attenuation is a fixed, frequency-independent value as
defined in the "Path Loss" parameter. Note that path losses have to be
entered as negative numbers while positive numbers correspond to gains.
●
"SnP File": The path attenuation is taken from the *.snp file as defined in the
"SnP File" parameter (frequency-dependent compensation).
●
"CSV File": The path attenuation is taken from the *.csv file as defined in the
"CSV File" parameter (frequency-dependent compensation).
60User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Limit Handling
4.9Limit Handling
Limits are used for checking if results are within desired value ranges and for triggering predefined actions if this is not the case. They basically define maximum
or minimum values for a measurement result variable. The limits can be set specifically for each test step or for higher test plan entities like a complete test
sequence. If a measurement result is outside its limits, a failure is reported.
Limit setting is realized in two stages: First, limits are defined as arrays which
carry maximum and minimum values (and optionally additional information). Second, a result variable is connected with such a limit, thereby getting the limit's values. The limits are defined in an Excel sheet which is imported in QuickStep.
Limit table, setting result limits
Limits for a test are defined in an Excel limit table. The Excel file contains two
sheets. In the “Limits” sheet, each table row begins with the name of a limit and is
followed by one or more minimum, maximum and binning values. In the “Binning"
sheet, softbins and hardbins are defined. Each softbin is linked to a specific
action and a specific hardbin.
Figure 4-29: Import of a limit table
To apply limits for a result variable, first the Excel limit table has to be stored
under the directory
C:\...\ProjectName\ConfigurationFiles\LimitFiles\ and then to be
61User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Limit Handling
imported from there into QuickStep. The import is requested via the "Limits Test"
button in the toolbar of the "Test Plan Editor" and then the "Import Limits" button
in the "Limit Table" dialog. The dialog additionally shows the current limit table
according to the imported Excel table.
The result variables of QuickStep are manually connected with imported specific
limits in the table of the "Set Result Limits" dialog. So, QuickStep does not show
the limit values for a result variable but the connected limit name.
Result variables and connected limits – if available – are also shown in the "Test
Step Limits" tab on the right side of the "Testplan Editor".
Figure 4-30: Setting result limits
Which result variables are available and displayed in the "Set Result Limits" table
is determined by the used block functions in the test procedure. QuickStep finds
the result variables mainly by searching for Send…LogResult…(…) commands
in the code. The names of the result variables must be unique and each name
must consist of one contiguous string to avoid any conflicts. Additionally, a result
row can be added and filled manually; this is useful if for example a result name is
dynamically constructed during test execution and thus cannot be found in the
code.
The "Set Result Limits" table is empty if no test step or sequence (or higher test
plan entity) has been selected or if no Excel limit table has been imported.
62User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Limit Handling
Validity area for limits
Limits set via "Set Limits" from the toolbar are applied to one or several test steps
which have been activated before by clicking one or more test step rows. For
applying limits to a complete sequence, group or the test plan itself, a "Set Limits"
context menu is available for sequences, groups and test plan in the "Test
Browser".
Figure 4-31: Setting limits for a complete sequence via Test Browser
The limit checks and the behavior in case of failures can be defined in the TPR
options.
Binning
QuickStep supports binning which is an extended mode of limit handling: Several
limit sets (min and max) can be defined for a result parameter determining the
severity of a failure. The test results are grouped in several containers ("bins")
according to the failure severity.
Figure 4-32: Principle of binning
Characteristics (according to the figure):
●
Each result value for a result variable is submitted to a sequence of limit
checks. A limit check is passed if the result value is within the associated limit
set (usually defined by a maximum and minimum value). If not, the result
63User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Limit Handling
value fails that limit check. The limit gates (XY_Limits in the figure) are specific for the result variable (XY).
●
The first limit gate has to be tighter than the second limit gate which has to be
tighter than the third limit gate. So, if a measurement value passes one gate, it
also passes the following gate.
●
Softbins: Each limit set of the result variable contains one or several softbins.
The softbin which a measurement value is assigned to is determined by the
last limit check failure if there is any.
–A result value which passes the tightest limit gate is assigned to the first
softbin which is named "PASS".
–If a result value fails only on the tightest limit gate, it is assigned to the sec-
ond softbin "XY_Limit_break" for that result variable.
–If a result value fails on the first and second limit gate but passes the third
one (if available), it is assigned to the third softbin for that result.
–If a result fails on all limit gates, it is assigned to the last softbin for that
result, here "XY_Limit_fail".
●
Each softbin is related to an action:
–Pass: The test execution is continued.
–Break: The active test step is finalized, then the test execution halts with a
pop-up window. Options are provided to select how to continue.
–Fail: The active test step is finalized, then the test execution is stopped.
●
Hardbins: Hardbins allow a second level of grouping of several softbins into
one hardbin. In a production environment, a handler can be used to sort the
DUTs after testing in several physical trays. The handler could be controlled
using the hardbin number. In the example, hardbin "1" collects the result values without failure, hardbin "2" collects the failures with associated "break"
action, hardbin "3" collects the failures leading to the "failed" action.
The softbins are defined in the first sheet of the Excel limit table to be imported
into QuickStep, the softbin actions and the hardbins are defined in the second
sheet.
Figure 4-33: Definition of softbins and limits
64User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Limit Handling
Figure 4-34: Binning table
QuickStep executes the actions break and fail listed in the Action column in the
Excel Binning tab if "Continue on Fail" is deactivated in the "TPR Options" of the
test plan.
After import of the limit table, the softbins and hardbins are shown together with
the limits.
Figure 4-35: Imported limits with SoftBins and HardBins
65User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Failure report
The failures due to limit violations are reported in the execution log and in the
execution protocol available via the "Results" tab. A failure report includes the
name of the assigned softbin.
At the end of the execution protocol, a failure report of that test step is repeated
where the first limit violation occurred. It includes the softbin assigned to the first
result variable which caused a limit failure in that test step.
Figure 4-36: Failure report
Concepts
DUT Handling
4.10DUT Handling
Typically, it is more efficient to test several DUTs in a row within one test than with
separate tests: The initial test execution phase ("Testrun Before" typically including initializations of the test instruments) has to be executed only once. For handling several DUTs within one test, a DUT loop mechanism is available which
relies on the execution phases "DUT Loop Before" and "DUT Loop After", see the
following figure.
66User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
DUT Handling
Figure 4-37: Test execution phases for a DUT loop
The "DUT Loop Before" phase is used for specifying the DUT. The "DUT Loop
After" phase can carry any desired block functions. Looping back from the "DUT
Loop After" phase to the "DUT Loop Before" phase is done automatically based
on user input during test run. So, the number of loops is dynamic. A special block,
"DUT_Handling", is provided for entering DUT information, configuring information elements to be logged and ending the DUT loop. The functionality is contained in the block functions "AskForDutInfo" and "LogDutInfo".
For testing several DUTs in a row via the DUT loop mechanism, the test execution has to be started by clicking “Continuous Run” from the "Testplan Editor" toolbar. “Single Run” ends the test execution after the first DUT test is completed.
67User Manual 1177.6223.02 ─ 11
R&S®QuickStep
AskForDutInfo block function
Concepts
DUT Handling
Figure 4-38: AskForDutInfo in DUT Loop Before
The "AskForDutInfo" block function is placed in the "DUT Loop Before" phase.
When it is called (that is at begin of each DUT loop repetition), the "DUT Information" dialog is displayed for entering information about the DUT and the test situation. In this way, test results can be related to the used DUTs.
When clicking the "Stop Testing" button in the "DUT Information" dialog during
test run, the test execution is stopped immediately (the current DUT cycle is not
executed anymore).
68User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
DUT Handling
Figure 4-39: DUT information dialog
LogDutInfo function
The "LogDutInformation" block function is placed in the "Test Procedure" phase in
the "Test Procedure Editor". It allows to select which items are stored in the
TestStepsResults.log file.
Characteristics:
●
The parameters of the function reflect the DUT information elements listed in
the "DUT Information" dialog (see the "AskForDutInfo" block function). If a
parameter is activated via checkbox in the Testplan Editor, the information element appears as column header in the results table of the
TestStepsResults.log file. The values of the selected DUT information
elements are given for each test step.
●
For each DUT, a separate results folder is provided. The folder name begins
with the DUT loop count and includes the DUT ID and DUT No (DUT Number)
(which are parameters of the function).
69User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
DUT Handling
●
"LogDutInfo" can be placed in each test procedure phase of all test procedures in order to log the DUT loop information in each result file. Alternatively,
it can be placed in the "DUT Loop After" phase which centrally stores the DUT
loop information in the DUTLoopResults.log file.
Figure 4-40: Usage of LogDutInfo
Figure 4-41: LogDutInfo results
70User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
4.11Result Handling
4.11.1Charts
QuickStep provides means to visualize test results in a chart within an extra window.
Figure 4-42: Chart window with curve at halt of test run
a = Current Test Step ID and Repetition
b = Result value for the current Test Step ID and Repetition
c = Movable marker showing the data point values
The charts are defined and configured by functions of the "RS_Visualization"
block. This is done in the Test Procedure Editor. The visualization block offers different chart types such as cartesian or polar charts, 3D charts or histograms.
For all visualizations, several functional steps are required realized by block functions as shown below.
71User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-43: Block functions used for creating a chart in an extra window
The additional "Windowshot" block function is optional and provides a bitmap file
of the chart window content before the window is closed.
See Chapter 6.10, "Displaying a Result Curve in a Chart", on page 116 for
details and a step-by-step description.
4.11.2Live View Results
The "RS_Visualization" block provides functions for showing current (live) results
during test run in an extra window.
Figure 4-44: Live result visualization window
Creation and configuration of the live view is done with specific block functions
which are analogous to those for charts.
72User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Result Handling
Figure 4-45: Block functions for live result visualization (two results)
See Chapter 6.11, "Showing Live View Results", on page 119 for details and a
step-by-step description.
Concepts
4.11.3Reports
Reports store test results in doc (Word), pdf or HTML format. The resulting files
can be inspected in the Results Viewer but also independently from QuickStep.
The report functionality is realized by the "RS_Report" block. A sequence of block
functions has to be set up and configured in the Test Procedure Editor over several test execution phases. The content of the report (result values, traces,
screenshots, text) can be defined in detail using the provided block functions. The
following figures show an example report for a test where several DUTs are tested in a row, the related test procedure and block configurations. The numbers
indicate corresponding elements in the figures.
73User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-46: pdf report (example)
Concepts
Result Handling
1 = Header information from the "CreateReport" block function
2 = Result from the "AddResult" block function
3 = Result from the "AddResultMinMax" block function, includes limit handling
4 = DUT number according to DUT loop, automatically inserted
Figure 4-47: Block functions for creating a report (example)
Note that the report is created in the "DUT Loop Before" execution phase and
saved in the "DUT Loop After" execution phase. So, a separate report is generated for each DUT (additionally, the "DUT_Handling > AskForDutInfo" block function in the "DUT Loop Before" execution phase is required, test execution with
"Continuous Run"). The DUT number as shown on top of the "DUT Information"
dialog box during test run is automatically inserted in the current test report.
74User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
The "Close" block function is necessary to terminate the block successfully and to
ensure that the report generation queue is emptied before the test execution is
finalized.
Figure 4-48: Report configuration (example)
The QuickStep reporting functionality is based on ActiveReports® from GrapeCity. The ActiveReports documentation is included in the QuickStep documentation
folder accessible via the Windows "Start" menu.
Report with table
The following figure shows by example the block functions and their configurations to include a table in a report and the resulting table.
75User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-49: Table in a report
Report with chart from trace file
Data from a trace file can be displayed in a chart within a report. Therefore, the
"TraceToChart" block function is provided. The trace file (storing data in character
separated columns) is usually created during test run by a test instrument and
stored with an appropriate block function (for example "RS_RfSignalAnalyzerBase > SaveTrace").
Figure 4-50: Configuration for displaying trace data as chart in a report
76User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-51: Cartesian chart in a report
4.11.3.1Customizing Reports
QuickStep uses report definitions in RDL format to set up the structure and
appearance of its reports. RDL, Report Definition Language, is an XML application for describing reports. RDL report definitions for QuickStep are stored
in .rdlx and .rdly-styles files.
Report customization is done by editing RDL report definitions and connecting
QuickStep report block functions to them. For editing report definitions, QuickStep
provides the ReportDesigner tool accessible via the Test Procedure Editor's toolbar. The following figure shows an example scheme of the relations. Advanced
users can use an XML editor for modifying existing RDL files.
77User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-52: Relations between .rdlx file, ReportDesigner and block functions (example)
The report definitions used by QuickStep are distributed in three components
each of them with their own RDL files:
●
Subreport (.rdlx files)
●
Header (.rdlx files)
●
Style (.rdly-styles files)
See the following sections for details.
It is recommended to collect commonly used .rdlx files under
C:\Users\Public\Documents\Rohde-Schwarz\QuickStep\Common\
ActiveReports\ and the Subreport or Header subfolder.
User defined .rdly-styles files have always to be stored under
C:\Users\Public\Documents\Rohde-Schwarz\QuickStep\Common\
ActiveReports\Styles.
Conventions for paths
Some block functions need the path and filename for the RDL file to be used.
Absolute and relative paths can be entered.
Absolute paths are entered according to the Windows standard notation, for
example C:/folder/file.rdlx.
Relative paths must start with either "./" or "../". "./" indicates that the file is
in the same directory as the current DUT result folder. "../" indicates that the file
is located in the parent directory.
78User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Subreports
A report can contain different configurable report parts in its content area which
are called subreports.
Figure 4-53: Example subreports within a report
First, the structures of the subreports have to be defined in .rdlx files. Afterwards, these files are used by QuickStep block functions. The following figures
show how the RDL structures of the example subreports are displayed in the
ReportDesigner. The subreport definitions have fields serving as containers for
data from QuickStep. The fields are assigned to text boxes which define positions, sizes and typography. Additional elements such as text or tables can be
included.
79User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-54: Subreport 1 definition in the ReportDesigner
Concepts
Result Handling
Figure 4-55: Subreport 2 definition in the ReportDesigner
In QuickStep, the "RS_Report" block provides the required subreport functions,
see the example test procedure in the following figures. The numbers in the figures indicate corresponding parts.
80User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-56: Test procedure for two subreports
Figure 4-57: Block function properties for subreport 1
The "AddSubreport" block function adds a subreport and connects to the .rdlx
subreport definition given in the "SubreportPath" variable. Each "AddResultToSubreport" block function fills a field of the subreport definition with data by assigning a "Value" to a "FieldValue" (field name of the subreport definition). The
"AddResultToSubreport" block functions are connected to the "AddSubreport"
block function by the "SubreportId". To avoid that subreport values are overwritten
in subsequent test steps, QuickStep internally uses the combination of Subreport
Id, Repetition Number, Test Step Number and Loop Id to create unique Subreport
Ids in each test step.
81User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Configuration of the Report Header
The report header can be customized with an .rdlx header definition. See the
following figures for an example.
Figure 4-58: Customized header in pdf report
Figure 4-59: Customized report header definition
In the RDL header definition, the fields which can be filled by QuickStep must
have the following names:
●
Title
●
Subtitle
●
DeviceUnderTest
The "CreateReport" function of the "RS_Report" block connects to the RDL
header definition. If the fields in the RDL header definition have the names listed
above, they are filled with the values of the corresponding parameter values in
the "CreateReport" block function.
82User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Concepts
Result Handling
Figure 4-60: Connecting to an RDL header
Report Styles
Some report block functions which refer to certain report elements assign a style
to the report elements. For example, the "AddResult" block function has a "Style"
variable whose value determines the font and other properties of the added
result. QuickStep provides several styles which can be selected at the block function's "Style" variable. A user-defined style can also be assigned by entering its
name directly. The user-defined styles have to be defined in .rdly-styles files
and are stored under the following path:
QuickStep automatically scans the .rdly-styles files under this path for userdefined styles if necessary.
83User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 4-61: Editing and assigning user-defined styles
Concepts
Result Handling
Figure 4-62: Report result with user-defined style
User-defined styles in an .rdly-styles file are edited with the Stylesheet Editor within the ReportDesigner. This editor is accessible from the ReportDesigner's
"Report > Stylesheet Editor" menu.
84User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Required Hardware, Software and Firmware
Preparing for Use
5Preparing for Use
5.1Required Hardware, Software and Firmware
Required hardware and operating system
●
Standard PC
●
Windows 10 or Windows 7 as 64 bit version, including service pack 1 and universal C runtime update (KB2999226)
Required software
The required software comprises the QuickStep software itself and environment
software such as Microsoft C++ Redistributable packages, .NET framework
including Developer Pack and the R&S License Server.
Delivered software
The required software is delivered via USB stick. It contains:
●
The QuickStep installer which includes all required software
●
A floating license server installer package for licensing QuickStep via a floating license server.
●
PDF user documentation such as Getting Started, Release Notes, Open
Source Acknowledgment
●
If ordered, the ATSDRV positioner driver package
Alternatively, the software can be downloaded from GLORIS, the Global Rohde &
Schwarz Information System (registration required).
Additional and Optional software
If you want to use VISA instruments for your tests or even develop your own
QuickStep blocks, then install the related additional software.
85User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Required Hardware, Software and Firmware
Table 5-1: Additional and optional software
SoftwareUsage
R&S VISA 5.5.5 or higherVISA communication with test instruments (except for GPIB)
VISA for GPIB instruments provided by the
manufacturer
NI Driver for GPIB-USBHS adapter
R&S NRP ToolkitNRP power meter measurements; includes NRPZ VXI plug&play
SignalCraft Scout DriverSignalCraft Scout USB to serial / GPIO adapter
Microsoft Visual Studio
(Community) for C++/C#
(supported versions:
2015, 2017)
R&S Forum 3.3.6Editor and runtime environment to create and execute Python
Python 2.7 or higherNative Python installation to edit or create Python scripts
Python extension for Visual Studio Code
Alternative VISA communication with test instruments for GPIB
connections
NI USB-GPIB adapter
drivers
Integrated development environment for block development
scripts, for example for remote control of instruments
Editor and runtime environment to create and execute MATLAB
scripts
Debugger for Python scripts
R&S-VISA and NI-VISA can be installed in parallel. The VISA variant can
be selected per connection type (GPIB, Socket, HiSLIP, USB), for example
in the RsVisaConfigure tool. R&S VISA does not support GPIB connections.
The optional software is not provided with QuickStep but can be downloaded from
the manufacturer’s website or is provided together with the test instruments.
For obtaining Visual Studio Community, search for "Visual Studio Community" on
https://www.microsoft.com/en-us/download and follow the first link.
Special test instruments may require additional software on the host PC, for
example device drivers.
Required firmware on the test instruments
The provided example test applications require certain firmware versions and
options of the involved measurement equipment. So, verify that the firmware ver-
86User Manual 1177.6223.02 ─ 11
R&S®QuickStep
sions and options on the measurement equipment comply with the requirements
given in the release notes.
Refer to the manuals of the measurement equipment on how to check and
respectively update the firmware if necessary.
Preparing for Use
Installation
5.2Installation
5.2.1Licensing Tasks
The QuickStep functionality is licensed with a smart card provided to the licensing
PC via USB smart card reader and USB connection. At the PC, the R&S License
Server manages the license issues. You can choose between the following
options and related installations:
●
Licensing on the PC where QuickStep will run: The QuickStep installation
includes the installation of the R&S License Server. No separate license-related installations and configurations are required.
Proceed as described in Putting the Smart Card into Operation, then connect
the USB smart card reader containing the QuickStep smart card with the
QuickStep PC.
●
Licensing over another (remote) PC that is LAN-connected to the (local)
QuickStep PC: This method allows to use licenses on different LAN-connected PCs, one PC for one license at a time (floating license concept). At the
licensing PC (used as floating license server), the R&S License Server is
required and additionally a QuickStep configuration file.
87User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 5-1: Using a floating license server
Preparing for Use
Installation
Proceed as follows:
–Install and configure as described in Prepairing the Usage of a Floating
License Server.
–Proceed as described in Putting the Smart Card into Operation.
–Connect the USB smart card reader containing the QuickStep smart card
to the PC used as floating license server.
Details about using the RS License Server are described in the associated Help
accessible via the Windows Start menu and via Help button in the title bar of the
R&S License Server Manager (which is the GUI representation of the R&S
License Server).
5.2.1.1Prepairing the Usage of a Floating License Server
Not required if licensing is done on the PC where QuickStep will run.
1. At the PC used as floating license server, install the
RSQuickStepFloatingLicenseServer_<version number> package.
This package is part of the QuickStep software delivery provided with the product's USB stick. It contains the R&S License Server (which would update an
already installed license server) and required QuickStep configurations.
2. Connect the R&S License Server at the PC where QuickStep will run with the
floating license server:
88User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Installation
Figure 5-2: Connecting to the floating license server
a) At the PC where QuickStep will run, open the list of programs from the
Windows Start button, open the "R&S License Server" folder and select
"Edit Configuration".
The R&S License Server Manager starts up with selected "Configuration"
tab.
b) In the "Configuration" area on the left side, select "Floating license serv-
ers".
c) Select "Add" from the toolbar of the main area.
d) Enter the "Hostname" of the floating license server, keep the "Main port"
value and click the "Add" button to accomplish the configuration.
The RS QuickStep floating license server package is versioned according
to the QuickStep software. So, if you install a new version of QuickStep on
the QuickStep PC , you also have to install the corresponding RS QuickStep floating license server package on the licensing PC.
5.2.1.2Putting the Smart Card into Operation
A smart card and a USB smart card reader (USB stick) is provided with the
QuickStep delivery.
Proceed as follows to use the smart card in SIM format together with the USB
card reader (alternatively, the full format smart card can be inserted into a reader
connected to or built into a PC):
1. Break out your smart card.
89User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Installation
Figure 5-3: Smart card and USB smart card reader
2. Insert the smart card with the chip facing upwards and the angled corner facing to the USB stick into the USB stick. The USB stick's LED or "Rohde &
Schwarz" label is also facing upwards.
Figure 5-4: Inserting the smart card
3. Push the smart card completely inside the USB smart card reader.
The USB smart card reader is now ready to be connected with the PC used for
QuickStep licensing.
5.2.2Installing QuickStep
The QuickStep software is provided as RSQuickStep_[BuildNo].exe file on
the product's USB stick.
Proceed as follows to install QuickStep on the PC:
1. Copy the RSQuickStep_[BuildNo].exe file into a local directory on your
PC.
90User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Installation
2. Double-click RSQuickStep_[BuildNo].exe.
The installation wizard opens. The dialog includes the license terms and conditions.
Figure 5-5: Installation wizard
3. Read the license terms and conditions carefully and tick the checkbox at "I
agree to the license terms and conditions" if you agree. Then click "Install" to
start the installation.
The installation progress is displayed. The installation comprises QuickStep
itself, environmental software and QuickStep applications.
The "Installation Successfully Completed" report indicates the end of a successfull installation process. Additionally, optional software packages not
installed yet are listed (to be installed later if required for your intended usage
of QuickStep).
The installation of the environmental software might require a restart. Click
"Restart" in this case to finish the installation.
4. Click "Launch" or "Close".
QuickStep is stored under
C:\Program Files\Rohde-Schwarz\QuickStep\. The example and user
files can be found under
C:\Users\Public\Documents\Rohde-Schwarz\QuickStep. Depending on
the Windows installation this path might vary. Use the links in the "R&S QuickStep" folder in the Windows start menu to determine the exact location.
91User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 5-6: QuickStep in the Windows start menu
Separate icons are created on the desktop to directly start QuickStep, the QuickStep Block Development Tool and the QuickStep OTA application.
QuickStep is ready to be started at the PC.
Preparing for Use
Installation
Installation via command line with log file creation
In case of an error during usual installation (for example due to a version conflict
with a VS Redistributable), try the installation via command line with log file creation:
1. Open a command shell.
2. Navigate to the directory containing the QuickStep *.exe installation file.
3. Enter RSQuickStep_<Version>.exe -log quickstep_installation.log.
4. If the installation still ends with an error, send the created
quickstep_installation.log via e-mail to R&S Customer Support to
get further help. Use the contact information listed at http://www.customersup-
port.rohde-schwarz.com.
A typical error cause could be a version conflict with respect to VS Redistributable
software. The log file indicates if and which package, installed by the QuickStep
bundle installer, causes problems.
5.2.3Installing Optional Software and Firmware
●
Get the optional software packages as needed for your purposes, for example
VISA.
●
Install the optional software packages.
92User Manual 1177.6223.02 ─ 11
R&S®QuickStep
–For remote control of VISA instruments, a VISA library is required as pre-
requisite.
–If you use the SignalCraft Scout USB to serial / GPIO adapter, see Instal-
ling the SignalCraft Scout Driver.
●
For block development with C++ or C#, install Microsoft Visual Studio – at
least Visual Studio Community. For obtaining Visual Studio Community 2017,
search for "Visual Studio Community 2017" on https://www.microsoft.com/en-
us/download and follow the first link.
●
Install required firmware on your test instruments if needed. For requirements
and instructions see the user manuals for the test instruments.
Preparing for Use
Installation
5.2.4Updating License Keys
The QuickStep software options are enabled by license keys (also called option
keys). In case of an update of an existing license dongle, the license keys are
provided as key codes. The license keys are assigned to the unique serial number of the QuickStep smart card. An update of license keys is done with the R&S
License Server Manager. The R&S License Server Manager shows currently
available licenses and allows to administer the licenses on the smart card. The
R&S License Server Manager is part of the QuickStep delivery.
Figure 5-7: R&S License Server Manager
The R&S License Server Manager provides an integrated help. See this
help for detailed information.
93User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Installation
To add a license key
Preparations:
●
Make sure that QuickStep is installed on the same PC which is used for the
license key update. Otherwise the R&S License Server Manager does not display the “Designations” of the license keys.
●
Make sure that the USB reader with the QuickStep smart card (carrying the
serial number) is connected to the PC.
1. Start the R&S License Server Manager via Windows "Start" menu.
The R&S License Server Manager detects the smart card and lists all active
license keys.
2. Under "Licenses", select the license provider, see (a) in the figure.
3. Click "Activate" in the menu of the main area ((b) in the figure).
The "Activate License" dialog is opened.
Figure 5-8: License activation
4. Enter the provided license key code ((b) in the figure), or search for an .xml
or .rsi license file and select it.
5. Click "Next" and then "Close".
94User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Network Configuration
5.3Network Configuration
The PC hosting QuickStep and the test instruments usually operate within a
closed network. Therefore, an IP configuration is required on the host PC and the
test instruments. The PC's and the test instrument's addresses must be unique
and must belong to the same IP subnetwork.
IP configuration on the host PC if a DHCP service is not available
Proceed as follows on the host PC:
1. Start from the Windows "Start" button, select the "Control Panel", then "Network and Internet" and "Network and Sharing Center".
2. Click the desired connection in the "View your active networks" section.
Figure 5-9: Network selection
3. Click at "Internet Protocol Version 4 (TCP/IPv4)" to highlight it and then click
the "Properties" button.
95User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Network Configuration
Figure 5-10: IPv4 properties
4. Enter an unused IP address within the subnet of the network used for testing
and use an appropriate subnet mask.
96User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Determining Input and Output Attenuations
Figure 5-11: IP address and subnet mask
5. Click "OK".
IP configuration on the test instruments
Please refer to the manuals of the measurement equipment on how to change the
IP addresses. Take care that each test instrument and the host PC are assigned
to different IP addresses within the same IP subnet.
5.4Determining Input and Output Attenuations
A very basic way to determine the attenuations of a connection or a RF device is
to apply a continuous wave signal with fixed RF frequency and RF level on the
relevant connections and measuring the power level at the end of the connections. One measurement is needed for the in attenuation, a second one for the
out attenuation (no measurements with a frequency sweep). The RF signals are
97User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Preparing for Use
Determining Input and Output Attenuations
generated with a manually configured signal generator. The RF power level measurements are done with a signal analyzer (or with a power meter).
Figure 5-12: Determining the in attenuation
To determine the attenuation for a connection:
1. Connect the generator to the analyzer using just the cable connection you
want to evaluate – including the attenuators if part of the connection.
2. At the generator, set the RF Level to 0 dBm.
3. At the generator, set the target RF frequency.
4. At the analyzer, set the mid frequency to the target RF frequency.
5. Run “Peak Search” at the analyzer and read the measurement value.
6. Calculate the attenuation value:
Attenuation in dB = RF Level (Generator) in dBm – Peak Search Level (Analyzer) in dBm
A better accuracy is achieved if only relative measurements are executed with the
analyzer. Alternatively a power meter or a network analyzer can be used.
98User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Starting QuickStep
Operation
6Operation
This chapter provides procedures for configuring, running and evaluating tests.
The descriptions begin with simple tasks and step forward to increasing complexity. You can combine procedures or parts of procedures to cover all operational
tasks.
You can also refer to the QuickStep Training manuals for step-by-step descriptions of many operational tasks. The manuals are accessible via the Windows
"Start" button and the folder "R&S QuickStep > Help and Manuals", or via the
QuickStep Help menu.
6.1Starting QuickStep
Prerequisites:
●
QuickStep has been installed on the PC.
●
A smart card reader with inserted smart card for QuickStep (providing the
required licenses) has been connected with the licensing PC. Connecting the
smart card can also be done after start of QuickStep.
●
The test instruments and the PC have been connected according to the
desired test setup.
Proceed as follows:
1. Start all involved test instruments and devices.
2. Ensure that all test instruments are reachable from the PC.
3. At the PC, start QuickStep with a double-click from the Windows start menu or
from the desktop icon.
99User Manual 1177.6223.02 ─ 11
R&S®QuickStep
Figure 6-1: QuickStep in the Windows start menu
QuickStep starts up and provides a start dialog.
Operation
Starting QuickStep
Figure 6-2: Start dialog
If you start the QuickStep OTA ATSCAL application, this start dialog is not
shown. Login as user Operator. No password is required and the following
steps are not relevant.
4. If you do not want QuickStep to occupy an existing floating QS-DEV license in
a network (which shall be used on another PC), select "Settings > Disable
Development Option" from the menu. Then, the Test Procedure Editor and the
Test Procedure Debugger will not be available.
You can also occupy the QS-DEV license for several days and offline operation via "Settings > Enable License Occupation" from the menu. Select the
desired license duration via "Settings > Set License Occupation Time".
5. Select one of the project options (for example, "Open Project") or double-click
a project from the list of "Recent Projects".
100User Manual 1177.6223.02 ─ 11
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.