MT43315 S 141 v5 Advrobotics

Process Simulate on TC Advanced Robotics
Student Guide
October 2018
MT43315 – Version 14.1
Restricted © Siemens AG 2018
Page 1 Siemens PLM Software

Advanced robotics (OLP) course
overview

Advanced robotics (OLP) course overview

Advanced robotics (OLP) course overview
Course description
The Process Simulate on Teamcenter Advanced Robotics course provides
step-by-step instruction on how to use Process Simulate to configure, simulate,
and upload/download (OLP) using MOP, realistic robot simulation (RRS), RCS
(Robot Controller Software), and ESRC (Emulated Robot Specific Controllers).
Course objectives
Learn about:
• Introduction to Robotic Off-Line Programming (OLP)
• Introduction to MOP, RCS, RRS, and the Process Simulate robot controllers
• Setting up the RCS, RRS, and the Process Simulate robot controllers
• Creating Robot Programs
• Inverse Kinematics Solution Selections (Robot Configurations)


• Robot Controller Selection and Setup
• Testing the Teach Pendant and Fixing Setup Problems
• RCS Management
• Robot Controller Specific Signals, Commands, Frames, Setup, and Motion

Attributes
• Templates, Uploading, and Downloading
• ESRC OLP Commands
• OLP Command XML Customization
• Motion XML Customization
• Robotic Path Template XML Customization
• Other XML Customization Topics
• Other Related OLP Topics


Learning tracks
Learning tracks for the Tecnomatix application are

found on the Siemens PLM Software training website:
training.industrysoftware.automation.siemens.com/index.cfm
Related Courses
• TR43101 – Process Simulate on Teamcenter Part Flow Simulation
• TR43106 – Process Simulate on Teamcenter Human Simulation
• TR43115 – Process Simulate on Teamcenter Basic Robotic Simulation
• TR43215 – Process Simulate on Teamcenter Intermediate Robotics
• TR43315 – Process Simulate on Teamcenter Advanced Robotics

Lesson 1
Introduction

Introduction

Introduction
Purpose
To discuss the basics of Off-Line Programming with Process Simulate.
Objectives
After you complete this chapter, you should be familiar with:
• An overview of OLP.
• An overview of the Process Simulate data model.
• The basics of robot models.
• The basics of RRS, RCS, and the ESRC (Emulated Robot Specific
Controllers).
• How to setup the RCS, RRS, and robot controller.
• The steps for process generation and process to program.


• The problems that can occur if OLP is not considered.
• How to prepare the scene for OLP.
• Some sources of error in OLP.

Introduction to OLP
Purpose
In this topic, you are introduced to OLP.
Objectives
After you complete this topic, you should be able to:
• Get some basic background in OLP.

OLP Basics
This course focuses on portion of Process Simulate known as Process Simulate

Robotics. Process Simulate Robotics contains a set of tools for performing OLP.
• OLP (also known as Off-line programming) — the process of designing,
modifying, and testing a robot program in an external system without the need
of the actual robot. Once the program is created it can be downloaded from
the external system and uploaded into the actual robot controller.
• Downloading — the process of exporting a text file of the program from

a system or robot controller.
o For example: Downloading from a real robot exports a file from the real
robot controller.
o For example: Downloading from Process Simulate exports a file from

the system.
• Uploading — the process of importing a text file of the program into a system
or robot controller.

o For example: Uploading to a real robot imports a file into the real robot
controller.
o For example: Uploading to Process Simulate imports a file into the

system.
Here is the basic process. A program can be originated in Process Simulate or

directly on the real robot (controller). After that, it can be cycled through this
continuous loop:

• Path — A path (also known as a robotic operation) is a representation of
the robot work plan in the Process Simulate world. It consists of locations,
sequence of locations, and location attributes.
• Program — A collection of paths (and or locations) used for downloading.
• Program File — A task is a textual format of the robot work plan which
includes motion commands and parameters.

Business process
This is an overview of the steps to off-line program robots and of the topics in the
first half of this training. The last part of this training describes how to customize
and make your use of the robot controller more efficient.

Allocating a Worker
Purpose
In this topic, you add a worker to the station.
Objectives
• Add a worker to the stations.

Data model basics
The center of the Process Simulate universe is the operation tree of the loaded
scene.
Studies can contain four types of data. The actual content depends on the
shortcuts that have been added to the scene and the relationships of the data to
objects in the operation tree:
• Product
• Operation
• Resources
• Manufacturing Features
• “Engineering Data”
In general, the data can be initially found in these viewers:

• Product, Resources, and Engineering Data can be found in the Object
Tree viewer.

• Operations are found in the Operation Tree viewer.
• Manufacturing Features can be found in the Mfg Viewer.

Operation Tree
The operation tree contains a structure that typically starts with a station. This
station contains several compound operations sequenced together. This initial
structure could have been setup in Teamcenter and is farther detailed and
validated in Process Simulate. This is done by adding simulative operations to the
desired compound operations. There are several types of simulative operations:
• Object flow operation - a simulative operation consisting of the movement of
a part along its assembly path. It is represented using the icon. (Covered in
the TR43101, TR43106, TR43115, and TR43215 courses).
• Device operation - a simulative operation consisting of any mechanical

device (for example a robot, human, clamps, cart, etc.) moving from one
pose to another. It is represented using the icon. (Covered in the TR43115
and TR43215 courses).
• Robotic operation - a simulative operation consisting of a sequence of

locations (positions) for the Robot TCPF. This type can be used for material
handling or welding. It is represented using these , , icons. (Covered in
the TR43115 and TR43215 courses)

• Human operation - a simulative operation consisting of a single human
motion or a series of motions. It is represented using these , , , ,
icons. (Covered in the TR43106 course).
• Non-sim operation - a simulative operation detailing an activity requiring

time (but is not simulated) that you want to include. It is represented using
the icon.

Robotic simulative operations
A robotic operation can be made up of:

• Weld locations — each is linked to a weld point (manufacturing feature). The
weld gun is actuated at each weld location.
• Pick and Place Locations
• Seam Locations — locations that move the robot along the contour of the part
• Via Locations — general movement or clearance moves
Robotic operations can be visualized as a path (also known as a sequence of

locations) in the Graphic Viewer.
Robotic properties of locations and robotic operation:
There are several types of properties that can be stored on a location or robotic
operation.
• Motion Type (interpolation)
• Speed

• Zone
• Tool
• Process parameters
• OLP commands
• Configuration and turns
Some of this information can be mapped from a generic (default) controller (for
example for something simple like motion type). Much of the information that is
robot manufacturer (or sometimes robot) specific is done differently (for example
how configurations are represented).
Instead it is typically better to work directly in the language of the robot, within
Process Simulate, rather than to work in a generic language and then translate
it later. However, you could work with the default controller if needed (no RRS),
and get about 80% motion accuracy.
The motion planning, how the joint motions of the robot are synchronized,
cannot have the accuracy of the real robot because of the real robot’s smoothing

algorithms may be different than the default controller’s (for example motion from
down to up may use a different motion than from up to down).

OLP software packages
An OLP software package contains the following:

• A user interface to set parameters
• RRS Simulation access to the RCS

you discuss this topics in detail starting in lesson 4, however these are
two core technologies of robotic offline programming:
o RRS — Realistic Robot Simulation
o RCS — Robot Controller Software
• Downloads — create a program file to run on the real robot
• Uploads — the most complex since some things needed to run a simulation
are only defined (exist) in Process Simulate and cannot be extracted from
the program file.

Standard OLP software packages are released with the Process Simulate
software. Currently there are packages for robot manufacturers.
Each controller has its own OLP package executable. Files are installed
under the C:\Program Files\Tecnomatix\eMPower and C:\Program
Files\Tecnomatix\eMPower\Robotics\OLP folders.

A specific license is required from Siemens PLM Software and the robot
vendor to activate each controller (and underlying robot specific abilities).

Robot models
Purpose
In this topic, you learn about robot models used in this system, including the
MotionParameters.e file.
Objectives
• Know where to find the robot models you need.
• Make them ready to use for OLP.
• Know a little about the MotionParameters.e file

Business process

Robot model basics
One of the first factors that must be considered when doing OLP is the robot
model. There are several questions that can be asked. For example:
Does a robot model for my real robot already exist in Process Simulate? Answer:
There are several places to go to find robot models:
• Method 1: In Robcad data you may have from old projects. The advantage
here is that you may already have the proper robot models and related
configuration files already gathered in one place.
The Robcad .CO formatted robots found here need to be converted to

.JT format before it can be used in this system.
Similarly, the RCS install used by Robcad can be reused with Process
Simulate by adding the related TUNE bridge file. This is discussed in
more detail later in this course.
• Method 2: Software install DVD (Robcad and RobotExpert only).

• Method 3: GTAC (Many robot models are available for download from
the Siemens PLM Software Global Technical Access Center at
support.industrysoftware.automation.siemens.com or 1–800-955-0000.
You learn more about downloading files from GTAC later in this course.
The Robcad .CO formatted robots found here need to be converted to

.COJT format before it can be used in this system.
• Method 4: Given to you by an OEM.
• Method 5: Most robot models must be gotten directly from the robot
manufacturer, for intellectual property reasons. Typically robot manufacturers,
such as Duerr, Fanuc, or Yaskawa/Motoman, provide a robot model to a
customer that purchases the real robot. Here the are robot manufacturer
websites:
o ABB Robotics: http://new.abb.com/products/robotics
o Cloos Robotic Welding: http://cloosrobot.com/


oComau Robotics: http://www.robotics.comau.com/ o
Denso Robots: http://densorobotics.com/
oDuerr Paint Systems: http://www.durr-paint.com/ o
Epson Robots: http://robots.epson.com/
o Fanuc Global Network: http://www.fanuc.com/

oIGM Robotersysteme: http://www.igm-group.com/en o
Kawasaki Robotics:
https://robotics.kawasaki.com/en/index.html?language_id=1
oKuka Robotics: http://www.kuka-robotics.com/en/ o
Panasonic Robotics:
https://eu.industrial.panasonic.com/products/robot-welding-system-solutions
o Staubli Robotics: http://www.staubli.com/en/robotics/


o (ABB) Trallfa (robot
history):http://www.abb.com/product/ap/seitp327/583a073bb0bb1922c12570
o Universal Robots: http://www.universal-robots.com/
o Yaskawa/Motoman Robotics: http://www.motoman.com/

More on robot models
Here are some additional questions:

Does the robot model have a MotionParameters.e file?
• This file has many uses, which include helping set the proper speed,
acceleration, and selecting robot configurations; especially when
disconnected from the RCS.
Does the robot model include other robot controller files in the robot model that
are needed to establish a proper RCS connection?
• Typically, there is a file or group of files from the robot manufacturer, that
describe how a specific robot is to move. They can be provided as part of the
RCS install or as part of the robot model. You learn later in this course, on a
case-by-case basis, which files are needed to make the robot work with the
RCS since it is different for every robot manufacturer.

The robot model selected should have geometry and kinematics which
closely represents the robot you use in the plant. This allows you to have
the same reach envelope in this system as in reality and get a accurate
robot configurations from the RCS.

Getting robot models from GTAC
Here is an example of the steps required to bring a new robot into the system:
1. Browse to https://download.industrysoftware.automation.siemens.com.
2. Select Tecnomatix Products.
3. Browse to Product updates/Robot_Models.
4. Browse into a folder such as the ABB or KUKA folder.
5. Right click the desired robot and save a copy to your computer.
For the sake of your discussion, assume that you have locally saved
(downloaded) a robot model named abb_irb2400_10.co.tar.gz into a
temporary folder named C:\temp and that this folder is empty.

A Robcad formatted .CO robot model is downloaded. It is compressed
(zipped) using .tar and .gz formats. In most situations you need to
convert to a .COJT format. This can be done by running tools like
Upgrade to Version or Import CAD Files.
6. Uncompress (unzip) the contents of the abb_irb2400_10.co.tar.gz file to the

C:\temp folder.
If the downloaded file is in the .zip format, simply uncompres (unzip) it
and go to the next page.
A folder named C:\temp\ROBOTS_ABB is created and contains the

abb_irb2400_10.co.tar file.
7. Uncompress (unzip) the contents of the abb_irb2400_10.co.tar file and

move the resulting abb_irb2400_10.co folder directly to the C:\temp folder.
8. Continue to the next page to see how to use the robot model in the system.

Create the robot’s Item
1. In Teamcenter, click Home from the navigation pane.
2. Either deselect everything or select the Newstuff folder.
3. From My Teamcenter, choose File→New→Item .
4. In the New Item dialog box, select Robot.
You could select either Item, MEEquipment, Robot, or Resource.

However, at your site you may select something different else. For
example you may have a custom Item type that you should select.
5. Click Next.
6. Click Assign.
7. For ID, click Assign.
8. In the Name box, enter abb_irb2400_10_user1.


9. Click Finish.

Create the robot’s datasets
For the sake of your discussion, assume that you have a robot model
named abb_irb2400_10.co.
Instructor: These files are from the training data's

D:\users\student\student_files folder (from the training data’s
student HOME folder files folder). Outside of this course, students would
need to gather the robot model and place it into a folder such as C:\temp.
More details on this are provided in the TR43315 Process Simulate on
Teamcenter Advanced Robotics (OLP) course.
1. From My Teamcenter, expand the abb_irb2400_10_user1 robot.
2. Locate the abb_irb2400_10_user1 robot revision.
3. Using Windows Explorer, browse into your D:\users\student\student_files

home folder (where the training data is located).

4. Browse into the D:\users\student\student_files\
Robots\arcwelding_robots\abb_irb2400_10.cojt folder or the
C:\temp\abb_irb2400_10.cojt
5. Drag the abb_irb2400_10.jt file from the Windows Explorer and drop it on
the abb_irb2400_10_user_id robot revision within Teamcenter.
6. For Dataset Type, select DirectModel.
7. Click OK.
8. Set the Relation Type to Rendering in the Details view.
9. Drag the motionparameters.e file (or .e file) from the Windows Explorer and
drop it on the abb_irb2400_10_user_id robot revision within Teamcenter.
10. For Dataset Type, select ProcessSimulateMotionParams.
11. Click OK.

Advanced kinematic definitions (MotionParameters.e file)
Functionality
• In Process Simulate the motionparameters.e file is used during simulation.
It must beplaced in a ProcessSimulateMotionParams dataset associated
to the robot’s ItemRevision
In Robcad, the motionparameters.e file was known as the .e file.
The motionparameters.e file, pronounced “motion parameters dot

e” file, is an ASCII text file stored under the robot model’s .COJT
folder containing measured robot motion parameters such as speed,
accel/decel, zones, configurations, and delay/settle times.
Simulation packages contain only limited knowledge about the
robot’s technical capabilities such as reach, speed, limits etc. Other
information such as payloads, momentum, acceleration, and similar
parameters where limited. The .e file was the initial solution for this
problem (for example it was the pre-RRS technique). Tecnomatix
engineers performed measurements on the robots themselves in

order to determine specific parameters (for example a very long
process requiring intimate knowledge of the robot).
The syntax for this file can be found in the Motion Planning Definition
File Reference Guide included on the Process Simulate DVD.
• Allows the use and editing of former Robcad .e files when placed in
a ProcessSimulateMotionParams dataset associated to the robot’s
ItemRevision
Why is this important to you?

• More accurate behavior of devices
• Reuse legacy Robcad data
Getting into the details within a motionparameters.e file is a very

advanced topic and is behind the scope of this course. However, some
additional information can be found by reviewing the online help for the
motionparameters.e file found on the install DVD.

Introduction to the MotionParameters.e file
Motionparameters.e (dot-e) files are produced from data obtained by performing

measurements on actual robots. The files model the behavior of robots that are
simulated with Process Simulate motion-planning capabilities. As in Robcad, the
.e file is mainly required in MOP-based and default controllers but the config/turn
part is also required in RCS-based controllers for storing the configuration at
the location.
A motionparameters.e file can be written for a robot either with or without

an inverse solution, and also for a device. However, many statements,
particularly those pertaining to Cartesian motion, apply only to robots
having an inverse solution.

MotionParameters.e units
For both joint and Cartesian motion, velocity, acceleration, deceleration and jerk
values are assigned to each joint in the units shown in the table below. “Jerk” is
the rate of change of the acceleration the derivative of the acceleration.
Rotational Motion Linear Motion
Velocity radians per second millimeters per second
Acceleration radians per second millimeters per second
squared squared
Deceleration radians per second millimeters per second
squared squared
Jerk radians per second cubed millimeters per second
cubed
A common error is to supply rotational values in degrees, resulting in very
high speeds producing extremely short cycle times.

MotionParameters.e motion types
All robot motion is planned mathematically. Two basic plans, or types, of motion
exist for both actual and simulated robots: joint motion and Cartesian motion.
Joint motion
For joint motion, the mechanism moves according to motion parameters specified
individually for each joint. It applies to all mechanisms: devices and robots both
with and without an inverse solution. The manner in which the specified values
apply to the joints during actual motion depends on whether the type of the motion
is synchronous or slew.
• Synchronous motion — In synchronous motion, the more common type,
all of the joints begin together and also complete their motion together. The
joint which requires the most time to complete its motion (usually because
it moves the farthest) moves at its specified velocity. The other joints move
at speeds correspondingly slower than their specified speeds, in order to
complete their motion together with the fastest-moving joint.
• Slew motion — In slew motion, all of the joints begin together but complete
their motion separately. Each joint moves at its specified velocity. The joint

which requires the least time (usually because it moves the smallest distance)
completes its motion first, with the other joints following behind. The joint
requiring the longest time to complete its motion (usually because it moves
the farthest) completes its motion last.
Cartesian motion
Cartesian motion is effected by commands directed to the TCP of a robot. The
system then uses inverse algorithms for the robot to calculate the required motion
of each joint from the TCP data contained both in the various kinematic and
motion-planning files in the motion command itself. It thus applies only to robots
having an inverse solution.
Cartesian motion occurs by means of interpolations between the start and finish
locations of the frame at the robot TCP (the TCPF). Both the position and the
orientation are interpolated. Various types of Cartesian motion are possible:
• Linear-type Cartesian motion causes the robot to move its TCP in a
straight-line trajectory to a target location.
• Circular-type Cartesian motion causes the robot to move its TCP in a circular
arc through an intermediate location to the target location.

MotionParameters.e configurations and turns
The inverse algorithm used to effect Cartesian motion usually produces two
or more solutions, combinations of joint values which enable the robot to
superimpose its TCPF on the target location. Each such combination of joint
values, or configuration, can be stored with a location in order to require the robot
to reach the location with the desired configuration. This consideration pertains
only to Cartesian motion.
In addition, a rotational joint capable of multiple turns may produce for the same
location many inverse solutions which are actually the same, but with the values
of the joint differing by multiples of 360 degrees. In order to distinguish between
these solutions, the range of such a joint is divided into subranges of 360 degrees
(a full turn) which themselves are identified by names. The desired turn for a joint
when the robot arrives at a location can be stored with the location. Moving to
these locations by joint motion only puts the joints in the position corresponding
to the turns recorded with the location. The recorded turns are ignored during
Cartesian motion; the motion itself determines the actual turns.

MotionParameters.e zones
Most robot controllers accommodate the definition of zones around target

positions.
When a robot arrives at its specified zone from the target position, it sends a zone
reached signal which can inform the controller immediately to plan the next motion.
The robot thus does not reach precisely the target position and does not need to
come to a full stop, reducing cycle time where precise arrivals are not necessary.
It can also facilitate synchronizing other tasks by informing them of impending
arrival at the target.
The zone type can be defined as an absolute or relative distance either constituting
a sphere around a working point or measured from a target joint position, or as a
condition on the speed of the robot as it approaches the destination. For example,
the zone can be defined to begin when all of the joints have decelerated to half of
their steady-state speed during the motion. When during motion a robot arrives at
its specified zone from the target position, it sends a zone signal to its controller.
Zones apply both to joint motion and to Cartesian motion.

Defining zones in the MotionParameters.e file
The zone_define parameter specifies controller-dependent zone information.

Its full syntax is:
zone_define name type space parameters;
Name is usually one of fine, medium, coarse or nodecel, or one of sp_zone#
where # is an integer from 1 to 6; however, it may be any user-specified character
string that does not contain spaces. A motion command in the robot program
specifies the desired zone by referring to its name. The names are arbitrary and
serve only to allow the robot program to reference the desired zone. It is thus
desirable but not necessary to use fine as the name for the most precise zone.
The nodecel name can likewise be used for a zone that causes the robot to
move to a point but continue to the subsequent point without decelerating. The
sp_zone# values can be used when more than four zone types are needed.
Type is one of:
• dist
• rel_dist
• speed

• time
• min
• max
• no_decel
• no_smooth
• no_settle_time
A dist zone type defines a distance constituting for Cartesian motion the radius of
a sphere around a target location, or for joint motion the linear or angular deviation
from a target joint position. A rel_dist type permits defining zones as a percentage
of the total distance for each motion. A speed zone type begins the zone at
a specified percentage of the speed of the robot as it decelerates toward the
destination. A time zone type similarly begins the zone at a specified time before
the robot reaches its destination. A min or max zone type permits defining a zone
as either the smaller or larger of two previously defined zones, respectively. A
no_decel zone type begins the zone when the motion profile begins to decelerate.

And no_smooth can be specified to require the robot to reach its destination
precisely. The no_settle_time value is used by only a few robots.
Space is either joints or Cartesian. It specifies the space in which the zone is
defined by means of the corresponding parameters; they are specified in the
unit of measure corresponding to the zone type. For joints space, parameters is
a list of values separated by spaces; one value is specified for each joint in the
mechanism.
For Cartesian space, parameter is a single value. If a zone is defined in Cartesian
space, Cartesian-motion commands using that zone use the zone parameters
as defined by zone_define. For joint motion using that zone, motion planning
generates values in joint space approximately equivalent to the value defined in
Cartesian space. Likewise, when a zone is defined in joints space, joint-motion
commands using that zone use the zone parameters as defined by zone_define.
For Cartesian motion using that zone, motion planning generates a value in
Cartesian space approximately equivalent to those defined in joint space.

Cloos specific MotionParameters.e for zones
All zones that can be used on the locations should be defined in the
MotionParameters.e file of the Cloos robot component with a special
naming:
• Joint Zones: stv<SmoothTransitionValue> For example:
o zone_define stv1 rel_dist cartesian 25;
• Cartesian Zones: setdd<Dist1>_<Dist2> For example:

o zone_define setdd10_20 rel_dist cartesian 65;
o zone_define setdd50_50 rel_dist cartesian 65;

Although the exact MotionParameters.e zone name are internally stored
on the location, in the Teach Pendant and Path Editor, zone information
appears in Carola terms, for example:
•Zone stv10 maps to STV(10) on the controller.
•Zone setdd10_20 maps to SETDD(10,20) on the controller. The
available zones are filtered using the location motion type:

• For GP, only stv zones are available.
• For GC and ARC. only setdd zones are available.
STV(0) and SETDD(0,0) are mapped to the fine zone.

Epson specific MotionParameters.e for zones
For robot configurations, you should enter these motionparameters.e config and
turns entries to properly record the configurations on the locations:
• config_family cf_over_head_pos;
• joint_config_family j3 joint_cf_elbow_up;
• joint_config_family j5 joint_cf_pos;
• default_turns j1 0 -90.0, j2 0 -180, j4 0 -180.0, j6 0 -180.0;

Kawasaki specific MotionParameters.e for speed and accuracy
• Speed:
o Speed value in % is converted to mm/s (via cart_max_lin_speed entry
in MotionParameters.e) for linear motions.
• Accuracy: If ACCU<i> zone is defined in the MotionParameters.e file, this

actual zone is used. Otherwise conversion from accuracy value (in mm) to
default zones is as follows:
o0 < val < 5: fine
o5 < val < 30: medium o
30 < val < 75: coarse o
75 < val: nodecel

NC specific MotionParameters.e for zones
Zone (must be defined in the robot’s MotionParameters.e file)

Zone name is selected from the list of allowed zones by reading the
MotionParameters.e file under the robot component directory. For example:
zone_define G93 no_smooth;
zone_define G92 no_decel;
The zone is shown in the teach pendant as:

G92
G93
G194
Zone fine is downloaded as first no_smooth zone in the list of available zones
Otherwise zone fine is downloaded as G09

Panasonic specific MotionParameters.e for zones
For other motion types besides no decel, it uses the closest distance Cartesian
zone defined in the MotionParameters.e file.
zone_define fine no_smooth;
zone_define z1 dist speed cartesian 10.0;

fine
z1

z2
z3
z4
z5
z6
z7
z8
z9
The default smoothing is z4.

Reis specific MotionParameters.e for zones
zone_define medium speed cartesian 5.0;
zone_define sp_zone1 speed cartesian 10.0;
40.0;
zone_define sp_zone4 speed cartesian
50.0;
60.0;
zone_define coarse speed cartesian 75.0;
zone_define nodecel speed cartesian 99.5;
zone_define nodecel speed joints 99.0 99.0 99.0 99.0 99.0 99.0;
fine

medium
sp_zone1
sp_zone2
sp_zone3
sp_zone4
sp_zone5
sp_zone6
course
nodecel

Staubli specific MotionParameters.e for zones
All zones that can be used in the trajectories should be defined in the
MotionParameters.e file of the Staubli robot component with a special naming
convention: fine or z<Blend>l<Leave>r<reach>
For example:
• fine: zone fine (Blend off)
• zcl10r15: zone with Cartesian blend (flyby type), leave value of 10mm and
reach value of 15mm
• zjl15r10: zone with Joint blend (flyby type), leave value of 15mm and reach
value of 10mm
Although the exact MotionParameters.e zone name is internally stored on the

location, in the Teach Pendant and Path Editor, zone information should appear
in Staubli terms, for example:
zone_define zcl10r15 dist cartesian 12;

zone_define zjl15r20 dist cartesian 17;
The zones are shown in the teach pendant as:

fine
zcl10r15
zjl15r20
zcl20r30
Zone fine is shown as first no_smooth zone in the list of available zones

Universal specific MotionParameters.e for zones
zone_define z1 dist cartesian 1;
zone_define z2 dist speed cartesian 2;
fine
z1

z2
z10
z20
z50
z100
z200
z500
z1000
Universal joint speed and acceleration are defined in deg/s and deg/s2.The
simulation converts those values into joint speed values into percent max speed
(the only unit supported by MOP).
The following motionparameters.e entries are used:
• cart_max_rot_speed <speedInRadS2>
• cart_max_rot_acc <accInRadS2>
Example of motionparameters.e file speed entries:

cart_max_lin_speed 2000;

cart_max_lin_acc 2000;
* 100 deg/s
cart_max_rot_speed 1.74533;
* 2500 deg/s2
cart_max_rot_acc 43.6332313;

Motion planning (Introduction to MOP, RCS, and RRS)
Purpose
In this topic, you get introduced to the concepts of MOP, RCS, and RRS.
Objectives
• Better understand MOP, RCS, and RRS.

Motion planning basics
Process Simulate’s motion planner controls the trajectory and cycle-time of all
motions. It also determines if a motion is possible, and also can give error
messages if a motion request exceeds the capability of the modeled mechanism.
There are several different types of robot controllers available:
• DCM (also known as MOP) – the default robot controller. No RCS license
is required.
DCM – Dynamic Controller Model
• DCM with RRS – the most accurate robot

motion RRS – Realistic Robot Simulation

What is MOP?
MOP stands for MOtion Planner. Process Simulate uses it to process motion
requests from the user, and passes the results back to the Graphic Viewer. It is the
motion planner of the Process Simulate default robot controller. It can be used by
all robots. It uses a robot’s MotionParameters.e file to create robot specific motion.

Process Simulate motion planning flowchart
Description:
• Siemens PLM Software’s patented path-based simulation based on a
selected Process Simulate robot controller
Advantages:

• User designs, simulates, and optimizes a path using the related Process
Simulate teach pendant.
• Automatic creation of a robot program file from Process Simulate path
• The created program is an accurate translation of the designed path
• Only a few modifications may be required

What is RRS?
RRS – In a combined effort, initiated by the European Car Manufacturers

Association, robot manufacturers, and software simulation vendors worked
together to form an accurate representation of robot algorithms for each robot in
production engineering simulation packages (for example Process Simulate).
Basically RRS is the interface used by Process Simulate to access a virtual robot
controller (RCS).
• Realistic Robot Simulation (RRS) - An international standard developed

by robot manufacturers and robotic CAD/CAM companies. The standard
specifies communication algorithms and protocols, used by Process Simulate,

or any other system, to communicate with a software model of a robot
controller. The standard defines a software model of a robot controller as a
"Black Box" with a specific input and output scheme. Siemens PLM Software
develops an RRS interfaces for Process Simulate to access the RCS.
• RCS Module - A software model of a robot controller (for example virtual

robot controller), which knows how to deal with RRS inputs and outputs. It
is developed by the robot manufacturer to behave just like the real robot
controller.

MOP, RRS, and ESRC
Purpose
In this topic, you see the connection from MOP and RRS to ESRC.
Objectives
• Know the history of RRS and ESRC.
• Know the contents of ESRC.
• Recall the information exchange between a PLC and a robot.

ESRC history and content
RRS1:
• Developed a long time ago (around 1990).
• Motion planning of robot to communicate to simulation software
o Interpolation
oTransformation
oKinematics modeling o
Machine data
o External axes
oConveyor synchronization o
Internal event generation
o Error messages

o RCS Validated (accurate) robot path
o RCS Verified (accurate) motion time
• About 97% motion accuracy including (payload) dynamics
• All process parameters are included / can be downloaded
• Need a configuration file
• Good for standard, non-complex, configurations (for example no servo gun,

non-rail robot, etc.)
• But cannot provide accurate cell cycle time because of the following reasons:
o Waiting for devices
o Robot interlocks
o Path optimization cannot take into account any synchronization of

devices
RRS2:

• Good for local changes after robot commissioning
• Too complex
• Gives full controller
• Motion and logic
• Need real controller available
• Need to know all sorts of information to set it up that is not known when
the paths are developed in Process Simulate or it won’t run (for example
temperatures, sensor signal registers, how many I/O boards, how may servo
motors, etc.)
• Not the best for project lifecycle (for example want to do robot simulations two
years before commissioning)
• Performance problems (controller needs to “boot” and start everything)
ESRC:
• Emulated Specific Robot Controller

• Easier to use and configure than RRS2
• ESRC = (RRS1 or MOP) + desired logic + robot specific commands
• It is used in the Process Simulate Cyclic Event Evaluator environment (CEE

is covered in the TR43215 Process Simulate on Teamcenter Intermediate
Robotics (CEE) course)
• Subset of robot language used to get accurate cycle time
• Can create XML customization files (OLP commands and motion commands).

Contents of ESRC
• Command recognition (send/wait signals, etc.)
• Edit robotic commands
• Non-boolean signals
• Comment robotic command
• Free text command


• Boolean/analog evaluation
• Under program/call path (conditional).
• Macro
• Simulates robot commands without the need of RRS2.
• Enhances the usage of RRS1 or MOP with internal robot logic.
• Enables a better design.
• Enables checking alternatives at an early stage.

Robots as integrated production resources
All RRS papers identify clearly two very important points:

• Robots never are standalones in a production station – they need all the
relevant production and control devices (conveyors, tools, sensors etc.).

• An external Controller (PLC or similar) is a must in order to make the VRC
(virtual robot controller) work.

Robotics: Information exchange between PLC and robot
There are three categories of information to be exchanged:

• Synchronization signals (Wait, Continue) on locations
• Program (path) number and GO/End
• Status Information even on “in between location” positions (for example on

each simulation cycle)
Setting up the Process Simulate OPC connection to a PLC was

described in the course.

Setting up the RCS (part 1)
Purpose
In this topic, you learn how to setup the RCS.
Objectives
• Configure Process Simulate to access the RCS/RRS

Business process

Process Simulate access to RCS/RRS
Process Simulate interfaces with robot manufacturer supplied RCS modules.

Each robot interface is customized to use the functionality of the RCS module
as defined by the robot manufacturer.
In order to use RRS to perform a simulation in Process Simulate:
• You must have the RCS module from the robot manufacturer installed
and licensed in the computer. This is referenced, before starting Process
Simulate, in the rrs.xml file.
The specifics of each RCS module covered in the activities. In general
you should get the proper version of the RCS directly from the robot
manufacturer. However, a few versions of some RCS modules are
available on the Siemens PLM Software GTAC website.
• You must use a RCS robot and compatible RRS controller (its motion can be
controlled in Process Simulate using an installed RCS module). This is setup
in a specific scene in the Robot Properties dialog box.
For example:

Robot Manufacturer Language Controller RCS or MOP
ABB Rapid S4, S4C, S4C+, RCS
IRC5, RW6
ABB Volvo (Volvo only) Rapid S4, S4C, S4C+, RCS
IRC5, RW6
Cloos Carola Qirox MOP
Comau PDL C3G+, C4G, C5G RCS
Comau Volvo (Volvo PDL C3G+, C4G, C5G RCS
only)
Denso PacScript RC8 MOP
Duerr EcoTalk EcoRC2, EcoRPC RCS
Epson Spel RC+ 7.0 MOP
Fanuc F100iA F100iA F100iA also known RCS
as CFLEX
Fanuc RJ3, RJ3iB, TPE (teach RCS
R30iA, R30iB pendant editor)
(RJ13ic)
Fanuc Japan (Japan RJ3, RJ3iB, TPE (teach RCS
customers only) R30iA, R30iB pendant editor)
(RJ13ic)

Fanuc VW (VW only) RJ3, RJ3iB, TPE (teach RCS
R30iA, R30iB pendant editor)
(RJ13ic)
IGM INS K4 MOP
Kawasaki AS C, D, E (block step RCS
motion format)
Kuka KRC KRC1, KRC2, RCS
KRC3, KRC4
Kuka BMW (BMW KRC KRC1, KRC2, RCS
only) KRC3, KRC4
Kuka Volvo (Volvo KRC KRC1, KRC2, RCS
only) KRC3, KRC4
Kuka VKRC (VW only) VKRC VKRC1, VKRC2, RCS
VKRC3, VKRC4
Nachi SLIM FD, AW RCS
NC Machining G Code G Code MOP
NC Machining BMW G Code G Code MOP
(BMW only)
NC Machining Danobat G Code G Code MOP
(Danobat only)
NC Riveting G Code G Code MOP

NC Riveting Embraer G Code G Code MOP
(Embraer only)
Panasonic CSR G3 MOP
Reis Robstar Robstar5 MOP
Staubli Val Val3 MOP
(ABB) Trallfa Robtalk Robtalk3 RCS
Universal (planned URScript v3.1 MOP
release Q4 2015)
Yaskawa/ Motoman INFORM XRC, NX, DX100, RCS
DX200

Setting up MOP versus RCS robot controllers
Since this lesson deals specifically with setting up the RCS, nothing needs to be
done for MOP-based robot controllers. By definition, only RCS-based controllers
have an RCS.
For RCS-based controllers, each robot manufacturer has implemented their RCS
differently. Each has some software in a folder under the rrs_bin folder. In some
cases, the entire RCS is found here. In other cases, this folder many contain the
RCS client with the RCS server and license server in different folder or on other
computers (such as a centralized server).
From the perspective of Process Simulate, the RCS is considered 3rd party
software. this means that it is developed and supported directly by the robot
manufacturer.

Activities
In the Setting up the RCS and RRS (Part 1) section, do the following activities:
• ABB — Setting up the RCS (Discussion Only)
• Cloos — Setting up the RCS (Discussion Only)
• Comau — Setting up the RCS (Discussion Only)
• Duerr — Setting up the RCS (Discussion Only)
• Epson — Setting up the RCS (Discussion Only)
• Fanuc — Setting up the RCS (Discussion Only)
• IGM — Setting up the RCS (Discussion Only)
• Kawasaki — Setting up the RCS (Discussion Only)
• Kuka — Setting up the RCS (Discussion Only)


• Nachi — Setting up the RCS (Discussion Only)
• Trallfa — Setting up the RCS (Discussion Only)
• Yaskawa — Setting up the RCS (Discussion Only)

Setting up the robot controller (part 2)
Purpose
In this topic, you learn how to setup the ESRC robot controllers.
Objectives
• Setup the robot controller.

Business process

Robot controller setup basics
In this lesson, you discuss downloading and installing the latest Process Simulate
robot controller from the GTAC site.
For example:
Robot Manufacturer Language
ABB Rapid
ABB Volvo (Volvo only) Rapid
Cloos Carola
Comau PDL
Comau Volvo (Volvo only) PDL
Denso PacScript
Duerr EcoTalk
Epson Spel
Fanuc F100iA F100iA
Fanuc RJ3, RJ3iB, R30iA (RJ13ic)
Fanuc Japan (Japan customers only) RJ3, RJ3iB, R30iA (RJ13ic)
Fanuc VW (VW only) RJ3, RJ3iB, R30iA (RJ13ic)
IGM K4
Kawasaki AS

Kuka KRC
Kuka BMW (BMW only) KRC
Kuka Volvo (Volvo only) KRC
Kuka VKRC (VW only) VKRC
Nachi Slim
NC Code machining G Code
NC Code machining BMW (BMW only) G Code
NC Code machining Danobat (Danobat G Code
only)
NC Code riveting G Code
NC Code riveting Embraer (Embraer G Code
only)
Panasonic CSR
Reis Robstar
Staubli Val
(ABB) Trallfa Robtalk
Universal UR Script
Yaskawa/ Motoman INFORM

** In Process Simulate the Cloos, Denso, Epson, Fanuc F100iA, IGM, NC Code
machining, NC Code riveting, Panasonic, Reis, Staubli, Trallfa, and Universal
robot controllers are currently license free.
Terminology note:
You can install various Process Simulate robot controllers, which include a
teach pendant and an interface to the related RCS. The RCS is the virtual robot
controller (software and license) from the robot manufacturer. A Process Simulate
robot controller and teach pendant together are your interface to various features
of the real robot controller. It is not required to have a real robot controller or
teach pendant from the robot manufacturer to use the Process Simulate robot
controller and teach pendant.

Pictured: A real robot controller and teach pendant from Kawasaki Robotics, Inc.

Whether the Process Simulate robot controller is MOP-based or RCS-based, you

must download and install it separately from Process Simulate.
This robot controller is developed and supported by Siemens PLM Software and
can be referred to as the ESRC.

Activities
In the Setting up the robot controller (part 2) section, do the following activities:
• ABB — Setting up the Latest Process Simulate robot controller (discussion
only)
• Cloos — Setting up the Latest Process Simulate robot controller (discussion

only)
• Comau — Setting up the Latest Process Simulate robot controller (discussion

only)
• Default — Setting up the Latest Process Simulate robot controller (discussion

only)
• Denso — Setting up the Latest Process Simulate robot controller (discussion

only)
• Duerr — Setting up the Latest Process Simulate robot controller (discussion

only)

• Epson — Setting up the Latest Process Simulate robot controller (discussion
only)
• Fanuc — Setting up the Latest Process Simulate robot controller (discussion

only)
• IGM — Setting up the Latest Process Simulate robot controller (discussion

only)
• Kawasaki — Setting up the Latest Process Simulate robot controller

(discussion only)
• Kuka — Setting up the Latest Process Simulate robot controller (discussion

only)
• Nachi — Setting up the Latest Process Simulate robot controller (discussion

only)
• NC — Setting up the Latest Process Simulate robot controller (discussion

only)

• Panasonic — Setting up the Latest Process Simulate robot controller
(discussion only)
• Reis — Setting up the Latest Process Simulate robot controller (discussion

only)
• Staubli — Setting up the Latest Process Simulate robot controller (discussion

only)
• Trallfa — Setting up the Latest Process Simulate robot controller (discussion

only)
• Universal — Setting up the Latest Process Simulate robot controller

(discussion only)
• Yaskawa — Setting up the Latest Process Simulate robot controller

(discussion only)

Setting up the RRS.XML file and more (part 3)
Purpose
In this topic, you learn how to setup the RRS.
Objectives
• Set the basic RRS.

Business process

RRS setup basics
• Setup the RCS before setting up this file, if working with RCS-based
controllers.
• The Process Simulate robot controller must be setup in the rrs.xml file.
This includes where the RCS is located, where the custom XML is located,
and whether it should try to connect to the RCS. This file is located in the
C:\Program Files\Tecnomatix\eMPower\Robotics\OLP folder.
Basic syntax for the RRS.xml file:

The rrs.xml file can have several lines. Typical parameters are:
• ControllerName — the RRS name used to reference the RCS from within
Process Simulate.

The default value for decoupling can also be setup in the
rrs.xml file on the controller line (in class located in the
D:\users\student\student_files\OLP_config_files\ folder).
For example to be disconnected by default: <Controller
Name="Fanuc-Rj" RCSDecoupleSimulationAction="True"
RCSDecoupleNonSimulationAction="True">
• VersionName — the version of the RCS module.

You can place all the customer specific controller files under a shared
folder in single location, allowing all users to just point to this folder
by adding the CustomizedPath attribute to the Version element in
the rrs.xml file. Typically this folder would be a shared drive such as
or \\ilhzsomebody\Kuka-Krc. You learn more about this at the end of
this course.
• ModuleName — the absolute path and name of the executable that is the
RCS.
• ModulePathName — the absolute path where the RCS module is located.


For example:
Example RCS Example Version Required
Controller Name Module Name Names Decoupling
C:\Tecnomatix
\rrs_bin\rcs_abb\ 5.0 IRC5
ABB-Rapid
rcsabb_rw5.61.01.irc(5rw
\ 5.61.01)
rcsabb_tune.exe
C:\Tecnomatix
\rrs_bin\rcs_abb\ 5.0 IRC5
ABB-Rapid-Volvo
rcsabb_rw5.61.01.irc(5rw
\ 5.61.01)
rcsabb_tune.exe
Cloos-Carola N/A v1
C:\Tecnomatix
\rrs_bin\rcs_comau\ C4G (3.12)
Comau-Pdl rcs_cm_c4g_3.12\
cm_3.12.01_tune.exe
C:\Tecnomatix
\rrs_bin\rcs_comau\ C4G (3.12)
Comau-Pdl-Volvo rcs_cm_c4g_3.12\
cm_3.12.01_tune.exe
default N/A v1 Not supported

Denso N/A v1
Duerr-Ecotalk C:\Tecnomatix 5R\PC (v5.1.7)
\rrs_bin\rcs_ecopc\v
rcsdb01_tune.exe
Epson-Spel N/A v1
Fanuc-F100iA V8.2d (fr13.v5.0),
debug
Fanuc-RJ C:\Tecnomatix V8.2d (fr13.v5.0),
\rrs_bin\rcsfr13\ debug
robcad.bin\
rj3_rcs_tune.exe
Fanuc-Rj-Japan C:\Tecnomatix V8.2d (fr13.v5.0),
robcad.bin\
rj3_rcs_tune.exe
Fanuc-Rj-Vw C:\Tecnomatix V8.2d (fr13.v5.0),
robcad.bin\
rj3_rcs_tune.exe
Igm-Ins N/A v1 Must be set to True.

Kawasaki_As C:\Tecnomatix C (KW07), D
\rrs_bin\rcskw\ (KW08),
rcsKW09_tune.exe E (KW09)
Kuka-Krc C:\Tecnomatix V52 (r02)
\rrs_bin\rcs_krc1\
krc5.2_r02\bin\
rcskrc1_tune.exe
Kuka-Krc-Volvo C:\Tecnomatix V52 (r02)
\rrs_bin\rcs_krc1\
krc5.2_r02\bin\
rcskrc1_tune.exe
Kuka-vKrc C:\Tecnomatix V52 (r02)
\rrs_bin\rcs_krc1\
krc5.2_r02\bin\
rcskrc1_tune.exe
Nachi-Slim C:\Tecnomatix FD
\rrs_bin\rcsnf_ax\ xe
rcs_main_ax_tune.
e
NC-Code N/A v1 Must be set to True.
NC-Code-BMW N/A v1 Must be set to True.
NC-Code-Danobat
Restricted © Siemens AG 2018 N/A v1 Must be set to True.
NC-Code-Riveting N/A v1 Must be set to True.
Panasonic N/A v1
Reis-Robstar N/A v1 Not supported
Trallfa-Robtalk C:\Tecnomatix v2.1.2
\rrs_bin\rcstr\
rcstr01_tune.exe
Universal-URScript N / A v1 (TBD)
Yaskawa-Inform C:\Tecnomatix DX
\rrs_bin\rcsyma\ e
rcsmainDX_tune.ex
The rrs.xml file is a mapping file. It must be edited to reflect your environment
(for example the version of the RCS used, the folder it is installed in, decoupling
mode, custom XML folder, etc.).
A section must exist in this file for every RCS and RCS module version that is
used, but not for every RCS supported by Process Simulate.
An example of the rrs.xml which matches the exercises in this course is

included with the training data. Some modifications may need to be done
to the file in order to use it in your training environment.

The major step covered in these activities is the configuration of the RRS.xml file.
The configuration of this file is required for RCS-based robot controllers, but is
optional for MOP-based robot controllers.
For RCS-based controllers, it is used to reference the RCS under the rrs_bin
folder. For most RCS-based robot controllers you need to add a section to this file
for each robot controller and for each version of the controller (accept for Fanuc).
One reason to setup a section in this file for MOP-based controllers is if you would
like to place your customer specific configuration files for a robot controller in a
different folder other than the default. In this case a Version section is added to
the file and can be named anything. This is what you have done in these activities
by naming it v1.

Activities
In the Setting up the RRS.XML file and more (Part 3) section, do the following
activities:
• ABB — Preparing to setup the RRS (discussion only)
• Cloos — Preparing to setup the RRS.xml (discussion only)
• Comau — Preparing to setup the RRS (discussion only)
• Default — Preparing to setup the RRS.xml (discussion only)
• Denso — Preparing to setup the RRS.xml (discussion only)
• Duerr — Preparing to Setup the RRS (discussion only)
• Epson — Preparing to setup the RRS.xml (discussion only)
• Fanuc — Preparing to Setup the RRS (discussion only)
• IGM — Preparing to setup the RRS.xml (discussion only)


• Kawasaki — Preparing to Setup the RRS (discussion only)
• Kuka — Preparing to Setup the RRS (discussion only)
• Nachi — Preparing to setup the RRS (discussion only)
• NC — Preparing to setup the RRS.xml (discussion only)
• Panasonic — Preparing to setup the RRS.xml (discussion only)
• Reis — Preparing to Setup the RRS.xml (discussion only)
• Staubli — Preparing to setup the RRS.xml (discussion only)
• Trallfa — Preparing to setup the RRS (discussion only)
• Universal — Preparing to setup the RRS.xml (discussion only)
• Yaskawa — Preparing to Setup the RRS (discussion only)

Process overview
Purpose
In this topic, you get an overview of the process.
Objectives
• Get a basic overview of the steps to create a process and then output it as a
program for the real robot.

Process generation
1. Basic Process Roughed Out.

• Setup of basic structure of data
2. Detailed process motion completed and verified. (Topic covered in TR43115

Process Simulate on Teamcenter Basic Robotic Simulation)
• Create Process Locations
• Select Robot Tool
• Place Robot
• Create Via Locations
• Optimize the Process
• Simulate the Process
3. Logic added and verified (Topic covered in TR43215 Process Simulate on

Teamcenter Intermediate Robotics)

• Setup sensors
• Flexible tooling for variants logic
• Verify robotic zone signaling
• Conveyor setup
• Simulate the process logic
4. Fully verified robot programs are completed and ready for downloading. (Topic
covered in TR43315 Process Simulate on Teamcenter Advanced Robotics)
• Sending a process to a robot using OLP
• Etc.

Process to program
1. Verify collision free simulation.
2. Add process logic attributes.
3. Teach local locations for process using correct motion type at each location.
4. Download the program.

OLP in process design
Purpose
In this topic, you learn about using OLP to design a process.
Objectives
• Know problems that can occur without considering OLP issues
• Take OLP into consideration.
• Do the up-front work required.
• Include relevant information at each step of the process.
• Supply information needed in later steps of the process.
• Know what should be considered for OLP.


Problems that can occur without considering OLP issues
If no Off-Line Programming considerations are made by the process

designer, it is assured that the shop floor engineer has major problems
with the Process Simulate generated programs. In many cases these
problems may justify discarding the OLP deliverables.
Some of the types of problems are:

1. Robot pose configurations (impossible, senseless, etc.).
• Example: The robot moves from a FLIP to NO-FLIP.
2. Dangerous (to man and machine) singularity problems.

• Example: Joint 4 & 6 move in an unpredictable, high-speed rotation.
3. Elements of the program are missing.

• Example: The robot controller doesn’t have good editing capabilities.
4. The shop floor engineer does not understand the total control scheme.

5. Need to calibrate? Need to maintain?
6. No flexibility in the design to compensate for mechanical and build

inaccuracies.
• Example: A change is required, but the robot is already working on
a joint limit!
7. No obvious way to "dress" the robot with this program.

How to take OLP into consideration
At each processing stage, a good designer can make many of the OLP
shopfloor decisions without venturing out of their office. Also, a good
designer is responsible for ensuring successful OLP by making their
design intent clear

Do the up-front work required
Example:
• Using the required robot controller, test a sample of the programs you
generate. Identify a program certification process/authority. What is the
required program structure?

Include relevant information at each step of the process
Example:
• What robot is used?
• What is the maximum cycle time allowed?
• How many robots does the cell include?
• What about zones clearance?
• What about joint limits?

Supply information needed in later steps of the process
Example:
• Setup kinematic devices and robot tools.
• Enter signals information.
• Create the sequencing.
• Add notes for shop floor engineers.
Always be alert, and check the design against common robotic constraints.

What should be considered for OLP?
At the concept design stage:

1. Robotic welding? Human operations? Fixed automation?
2. Do not position robots close to each other.
3. Make the part accessible - Shop floor personnel need to work there safely.
4. Is the robot required to pick and place as well as weld? Remember: The
tooling on this robot makes it harder to manipulate and less flexible.
5. What robot is designated for use? Can it do the job (weight, speed, etc.)?
6. Go and see the actual robot you are working with. Request a presentation of
the unique capabilities of this robot.
7. Where is calibration performed? Maintenance?
At the initial (rough) processing stage:


1. Assign a robot only those locations it can actually reach. Check extreme
cases with the ACTUAL robot.
2. Make sure the location orientation makes sense.
3. Color-code the location assignment. This makes it easier to see what is

happening.
4. Use naming conventions from the very beginning (weld locations, via points,
pounce, home, maintenance, safe, tip dress, etc.).
5. Sequence the locations assigned to a robot in a consistent fashion, according

to plant specifications as well as the concept sequence (for example a robot
that is assigned a pick & place and weld combination).
6. When sequencing welds, consider orientation changes as well as geometric

properties. It may be easier and faster for a robot to work on a further out
(geometrically) weld than to twist it’s configuration.
7. Make realistic gun size assumptions.


8. Process for a smooth gun motion. This, in turn, leads to a smooth robot
motion and an easy program.
9. Immediately (by default) assign a linear motion type to all segments where
the gun tip is close to the part.
10. Immediately (by default) assign zone type fine to all segments where the
gun tip is close to the part.
At the layout and integration stage:

1. Position the robot such that not only can it reach all the locations, but also
comply with the shop floor soft limit set up.
2. Position the robot such that not only can it reach all locations, but also have
a +/- 10 degrees of freedom for future changes.
3. Position the robot such that not only 1 and 2 are covered, but also all
segments of motion in between welds are considered for 1 and 2, and all
possible configurations.
4. Optimize for bottlenecks.


5. Optimize for cycle time, but indicate possible changes.
6. Include all robot specific commands you find relevant to maintain the design
intent, such as : speed instructions, signal and control instructions, etc.
7. Duplicate locations if it makes program structure easier for the shop floor
engineers to manipulate.
8. Approve and certify the program/database (by a shop floor representative).
At the detail process design stage:

1. Keep the gun motion smooth. Do not force big gun orientation changes.
2. Avoid using large envelope stretches. This causes difficulty in positioning

the robot.
3. Avoid complicated control schemes if possible (for example opening and

closing clamps to make welds). Request a change as early as possible for
such conditions. If you don not, the shop floor engineers need to do it later.

4. Mirror situations, where the left robot and right robot are performing a mirror
image of the same path, are preferable.
5. Mark optional calibration data (use naming and color conventions).
6. Add via locations the way the robot would naturally move - not how you think
it should.
7. Immediately, (by default) assign jointed motion type to all segments where
the gun is moving between via locations.
8. Immediately, (by default) assign zone type coarse to all segments where the
gun is moving between via locations.
9. Add your comments of design intent for the shop floor engineer.
At the documentation stage:

1. Create OLP outputs. Set up as follows:
• Create a Snapshot, displaying only relevant data. Blank data used for
presentation needs. Blank all irrelevant details. Include Notes and

Labels in the image to document the location names or other relevant
information.
• Include screen shots of problematic areas.
• Create AVI of the simulation, so shop floor can understand the complete
design.
• Create robot program files (OLP downloads).
2. Prepare the media for the program (diskette, files, etc.).
3. Test problematic programs locally before they are shipped to the plant.

Scene preparation
Purpose
In this topic, you get an overview of how to prepare the environment.
Objectives
• Get an idea of now to prepare the environment.
Overview
1. CAD geometry is latest revision of workpiece.
2. Scene components are modeled to a sufficient level of detail to verify collision

avoidance.
3. Robot model chosen according to job requirements.
4. Robot is positioned to reach all target locations.
5. Scene layout of components is matched to real-world conditions.


Activity: Verify and adjust your scene as required per previous instruction.

Error sources
Purpose
In this topic, you learn several major sources of error in OLP.
Objectives
• Know about five major sources of errors in the process.

Five major sources
Robot inaccuracies:
• Geometric model (link lengths, joint limits, joint direction)
• Elasticity (gravity effects)
• Zero positions
• Conversion coefficients
• Motor and gear performance
• Every robot on the factory floor is slightly different from each other and from
the Process Simulate "ideal" model.
Tool inaccuracies:
• Manufacturing tolerances
• Geometric model

• Mounting frame
Workpiece:
• CAD model variances
• Manufacturing tolerances
• Deformations during the process
Layout:
• Installation errors
• Tolerances
External devices:
(positioner, gantry, rotary tables, 7th axis, etc.)

Summary
Subjects learned in this topic:

• An overview of OLP.
• An overview of the Process Simulate data model.
• The basics of robot models.
• The basics of RRS, RCS, and ESRC.
• How to setup the RCS and RRS.
• The steps for process generation and process to program.
• The problems that can occur if OLP is not considered.
• How to prepare the scene for OLP.

• Some sources of error in OLP.

Lesson 2
Robot programming background


Purpose
To provide information on the default controller, ESRC’s (Emulated Specific Robot
Controller) and robot programs.
Objectives
• The basic motion attributes.
• Robot configuration, 7th axis, and the Robot Viewer.
• Where and how to store signals and conditional statements.
• Robot program basics and robot signals.
• Robot program creation and usage.

Basic motion attributes (default controller)
Purpose
In this topic, you learn how modify basic motion attributes using the default
controller.
Objectives
• Motion attributes basics.
• Robot controller.
• Know about basic motion types.
• Know about basic motion termination (accuracy/zones).
• Know about basic default controller examples.
• View and edit location attributes.


Do I do this

Motion attributes basics (default controller)
You start by using the default controller to talk about the basic theory of motion
attributes. Later in this course, you revisit this topic using robot specific motion
attributes. Much of the information in this lesson is a review from previous
Process Simulate training.

Robot controller
The robot controller can be set or viewed from the Controller tab of the Robot
Properties dialog box (Robotics→Robot Properties ) in Process Simulate. It
is used to assign a Process Simulate controller and machine data to a robot;
which sets the teach pendant (containing robot specific motion parameters) and
motion planner for a robot.
For this portion of the course, you use the default controller. Later, you
switch to an ESRC one.

Motion types (default controller)
On the Default controller, motion type refers to joint motion, linear motion, or
circular motion. Proper selection of motion type is very important in the design of
the process.
• Motion Type — Describes how a robot moves to this location. For example
here are two most common motion types found in the default controller:
o Joint (PTP) — Typically causes the robot to move the quickest between
locations (usually resulting in a curved path).
o Linear (LIN) — Causes the robot to move straight to this location.
When to use a motion type:

• Joint (PTP) motion should be used where high speed and low accuracy of
the TCP trajectory is allowed.
• Linear (LIN) motion should be used where high accuracy of the TCP track is
required; robot speed may be somewhat curtailed.

• Circular (CIRC) motion is used when the robot TCP is required to move
along a circular arc; most often in an arc-welding or sealing process.
Motion type constraints:

The process designer must take this into account during layout of a robot path, or
the robot may want to "unwind" the wrist in a critical portion of the process.
• Linear (LIN) and Circular (CIRC) motion place constraints on how the robot
is allowed to reach the target locations.

• Configuration refers to the specific wrist pose the robot is required to attain
in reaching a location.
Configuration only applies to locations that have been taught.

Motion termination for the default controller
A "zone" (also known as termination zone or accuracy) in Process Simulate

determines how closely the TCPF approaches the target location. Zone types
include "fine" (accurate positioning), by distance (window), by relative distance,
by speed, or by time. Zones have different effects on TCP trajectory based on
the motion type.
An absolute or relative distance constituting the radius of a sphere around

the working point, or a condition on speed or deceleration as it approaches
the destination point. When the robot reaches the zone around a location,
it immediately begins execution of the next instruction of the program.
• Zone (Called Accuracy or Term Type on various ESRC controllers) —

Describes how the robot approach/arrive at a location. For example here are
four zones found in the default controller. Each can be mapped to a range
of values on the ESRC controllers (you discuss this later). The two most
common are Fine and No Decel:
o Fine — causes the robot to slow and “arrive” at the location.

o Course and Medium in between Fine and No Decel.
o No Decel — cause the robot to not slow and “approach” the location
(However, arrival is not a requirement).


Curvature effect on a linear path because of a "nodecel" zone
Zone determines the precision by which the robot’s TCPF reaches
intermediate locations as it performs motion commands. Intermediate
locations (via locations) are those through which the robot passes without
stopping. These are all of the locations except the last location in a path,
as well as all the locations where, when reached by the robot, a delay or
wait command is specified. The numeric values of the different zones
are defined in the robot motionparameters.e file under the robot .cojt
component directory.
Using UpgradeToVersion to convert an old .co component to a .cojt

component, automatically convert the .e file within the component to a
motionparameters.e file.

Location reference frames
Scenarios for location reference frames

• Method 1: Defined when the gun is mounted to the robot (for gun on robot)
or when External TCP is checked on the Operation Properties (for remote
TCP). All locations in the path use this same default TCPF position.
• Method 2: A different TCPF position can be set for each location in the
path using the Tool Frame, Remote TCP Frame, or Work Frame location
attributes. In this case there is no default TCPF position. There is only the
current TCPF position. A path can even contain a combination of locations
with different location attributes (for example one path with gun on robot
locations and remote TCP locations). However, it is recommended that each
location have a specific TCPF position defined. This is much closer to how
the real robot operates.
When a gun is mounted to a robot, the default TCPF position is also set.
Alternately if this is not desired, a different TCPF position can be set on each
location. Tool Frame and Remote TCP Frame locations.
Location Attributes for Frame References:

• Tool Frame (for gun on robot) — this is the typical place for defining the
TCPF position on a location. Pick any frame in the Object Tree or Graphic
Viewer. Make sure the frame name is unique in the scene.
• Remote TCP Frame (for an external TCP) — this box is used when the
TCPF should be on an object which is not mounted to the robot. Pick any
frame in the Object Tree or Graphic Viewer. Make sure the frame name is
unique in the scene.

Other default controller examples
• Speed
o Speed for Joint (PTP) motion is measured as a percent of the maximum
speed.
o Speed for Linear (LIN) or Circular (CIRC) motion is measured in

mm/sec.
• Wait Time is measured in seconds.

Viewing and editing location attributes
These attributes can be viewed and edited in several ways in Process Simulate:
• Teach Pendant dialog box
• Path Editor dialog box
Both of these techniques were covered in the TR43115 Process Simulate

on Teamcenter Basic Robotic Simulation course. You use these
techniques throughout this course.

Activities
In the Basic motion attributes (default controller) section, do the following activities:
• Set up the macro folder
• Set up some basic robotic operations
• View simulation differences

Robotic configuration selection
Purpose
In this topic, you learn how to view and select robotic configurations.
Objectives
• Select a solution (robot configuration).
• Identify solution and turns for a location.
• Use the Robot Viewer.
• Understand how an external axis effects solution selection.

Business process

Robot configuration selection basics
In several cases, a robot has more than one choice for inverse kinematics (robotic
joint angle selection to reach a specific location with its TCPF). This lesson
investigates some of the factors affecting inverse kinematics solution selection. In
robotics, the inverse kinematic solution is also known as a robot configuration.

Solution and turns
Configuration — A specific combination of joint values obtained as a

solution of inverse kinematics.
Turns — A condition related to joints with greater than 360 degrees of
travel.
Solutions (also known as the Robot Configuration) and turns can be accessed in
several places in Process Simulate. In cases where multiple inverse kinematics
solutions are available to reach a location, it allows the viewing and selection of
specific solutions. Configuration information is read from the controller, stored on a
local location (our solution), and downloaded (controller specific solution) to
the program file.
In most common robots there are 23 = 8 possible solutions for each

location. However, some are ruled by limitations of the robot:
• J1 — Overhead or not overhead
• J2, J3 elbow up or elbow down


• J4, J5 flipped or not flipped
The solution also affects cable rap (entanglement).
Controller selection of solutions:

For each robot there are criteria to sort out which solution to select (specific
configuration bits). For example, flip or no flip, overhead or not overhead, and in
general where the robot is within a 360 degree area divided into four sections,
etc. The controller translates this information into a string, depending on robot
type, which is placed in the downloaded program file. Each robot family has
different key words. Process Simulate needs to have access to the RCS for the
selected robot. Otherwise, it won’t be able to get the robot configuration string for
the real robot (critical).
Communication between Process Simulate and the RCS:
• Process Simulate gives the location information to the RCS
• The RCS gives back configuration results
• RCS can have a tolerance for configuration selection


• In some cases (for example Fanuc rj2ic) the RCS may have special syntax
flags to say which one to use
• You auto teach and store your configuration on a location which may be
diffident than the RCS.
The Robot tab→Reach group→Jump to location command uses
simple kinematics (not RCS) to calculate the configuration.
• If not connected to the RCS then it writes the solution from the default
controller. Not having a connection also causes it to not understand that the
controller specific OLP commands during download.
The guy on the floor doesn’t see different solutions because he

teaches the configuration solution. You are trying to solve it each time.
Solution information can be viewed or edited using:


• Robot Configuration dialog box
• Teach Pendant dialog box
• Path Editor
Teaching a solution for a location (also known as creating a local location

in Robcad):
1. Select a location.
2. From the ribbon, choose Robot tab→Setup group→Robot Configuration .
The current location configuration is bold. A MotionParameters.e file

must exist in the robot .COJT for this command and the simulation
engine to function properly. There is an entire guide dedicated to this
file. However, it contains various definitions for how the robot moves
and is required by default controller (MOP) and RRS simulation.

3. Select a configuration from the list
4. Click Teach.
5. OR you can select a turn by clicking
Turn (+/-) OH = overhead

In the Robot Configuration dialog box, in the Joint Turns area, if the joint
name is different than the joint index, the joint name is added in parentheses.
If you download with an RCS connection, Process Simulate writes the translated
stored version of the configuration. It should be the same as what is stored on the

local location except if there was a problem with the mapping (The connection
allows the validation of what you put in the mapping). If there is a problem,
it would show in the log file.
Joint value defined locations don’t have a configuration

Using the Robot Viewer
This tool was discussed in the TR43115 Process Simulate on Teamcenter

Basic Robotic Simulation and TR43215 Process Simulate on Teamcenter
Intermediate Robotics (CEE) course.
The Robot Viewer can be found by picking a robot and choosing Robot tab→Play
group→Robot Viewer .
• Can be used to view joints moving along the path
• Can be used to look for steep or radical joint value changes (winding)
• Can export to excel or various picture formats
• Can gather statistics on min/max (values or %) including the applied software

limits

A key OLP issue is the engineering judgment of the robot behavior over time and
not only at a specific point. The Robot Integrated Development Environment
(RIDE), available for multiple robots, contains several tools essential to robot
programming and debugging:
• Trend-like graphical presentation of robot joint values
• “Historical view” — the values of the information are visible over time
The Robot Viewer contains the following panels:

• Joint Monitor — It generates and displays a graphical representation of their
values at all points of time in the simulation. The trace for each joint of the
selected robot is displayed in a different color. Each trace is comprised of
finite points in time where measurements are taken. The higher the sampling
rate, the more accurate is the trace.

You can display the lower and upper limits for each joint as a dashed line,
providing a visual impression of the state of the joint (but does not generate
alarms).
The Joint Monitor panel also displays statistics concerning joint values during
simulation. The Statistics section shows the minimum and maximum values
for each joint of the selected robot during the current simulation. When the
joint value enters one of the working limits, its value is displayed in orange
and when it reaches its minimum or maximum value, it is displayed in red.
• Joint Status — shows the current value for each joint of the selected robot
(including external joints). Alternatively, you can display the current joint value
as a percentage of the joint range.
• Digital Signals — See TR43215 Process Simulate on Teamcenter

Intermediate Robotics for more information.
• Analog Signals — See TR43215 Process Simulate on Teamcenter

Intermediate Robotics for more information.

• TCPF Speed Monitor — Displays a graph of the speed of the robot TCPF. In
the Legend section, you can set the color of the trace. The Statistics section
displays the minimum and maximum speeds of the robot TCPF.
• Joint Speed & Acceleration — Displays graphs of joint speed and

acceleration.
• Power Consumption — The graph above shows the current Power

Consumption of a robot during simulation in units of kW (kilowatts). The
Statistics section on the right of the graph displays the following: Overall
energy — The total energy consumption (in Joules) of the robot during
simulation. This is the sum of all the RCS updates until the simulation ends
(or pauses). Peak power — The peak power consumption (in kilowatts) as
sampled during the simulation. The system also notes the time at which the
peak energy consumption occurred. Currently, this feature is only supported
by robots connected to the KUKA KRC8.3 RCS (or higher version).

External axis
For more information on external axis usage and kinematic definition, see
the TR42115 Process Simulate on Teamcenter Basic Robotics Simulation
course.
External axis — (for example 7th axis). A typical example is a robot on a rail,
where the rail is the external axis. This allows multiple solutions to a location,
based on the position of the robot on the external axis. This information is stored
on the compound location.
External Axis process overview:
• The external device (for example rail) is created as a separate component
with (at least) one joint.
• The robot base must be attached to the carriage (for example slider) entity
of the external device.
• The robot is made the active mechanism by selecting it.
• Add the joints from the external device to the robot’s joint list.

• Mark compound locations (for example to store the position of the robot on
the external device’s joints onto the location that is being reached)

Activities
In the Robotic configuration selection section, do the following activities:

• Viewing and setting robot configurations
• Robot Viewer

Review of robot programs and robot signals
This topic reviews some of the robot programs and robot signal topics from the
course.

It contains the following subtopics:
• Robot Programs
• Robot Signals
• Status Signals

• Robot Path Reference Operation
• Robot Program

Business process

Robot programs
RCS/RSS simulation does require the definition of a Process Simulate

program. It can be used with just one simple robotic operation (for
example one path). A Process Simulate program is used when switching,
during simulation, between several robotic operations using logic, or when
downloading.
A robot has as task to be executed. Normally it is made up of motion tasks and

logic instructions organized in a robot program. Almost all robot programs have
the same basic skeleton:

To guarantee correct behavior all robot vendors enforce a predefined sequence of
signal exchange:
• To prevent the robot from starting to move in an uncontrolled way.

• To continue its motion until the end of its task.
The Siemens PLM Software default behavior doesn’t simulate all of the signals
used by a real robot. Those significant signals for the correct process behavior
are included in the default behavior. Specific behavior may be implemented in the
relevant ESRC (Emulated Specific Robot Controller), which has to be purchased
separately and has its own documentation.
In the TR42215 Process Simulate on eMS Intermediate Robotics (CEE)

course, you discussed how to create a simulation where logic is used to
switch between the different robot paths (for example trigger them) that
are part of a robot program (for example when to run path 1, path 2, etc.).

Robot signals
In the TR42215 Process Simulate on eMS Intermediate Robotics (CEE)

course, you discussed how create and use robot signals and associate
them to signals on a PLC in order to control the simulation (for example
trigger the execution of various events).
A robot program is a series of instructions to the robot. For example:
It’s easy to see that some of the signal values are only checked when a specific
location is reached. Such signals are called robot signals (might be of type Input,
Output, or Memory).
In the example it can be seen that the value of $OUT [17] is set only on the on
“POINT2” location (for example it is a robot signal).

Status signals
Status signals play a different role. They are continuously evaluated by the robot
controller (either input signals, for example emergency stop, or output signals,
for example pose signal). They are a way of simulating behavior that can be
downloaded. Using status signals, paths can be simulated like robot programs
using path numbers inside the program.
Default (PLC) output signals:
• startProgram (signal function = Starting Program)
• programNumber (signal function = Program Number)
• emergencyStop (signal function = Program Emergency Stop)
• programPause (signal function = Program Pause)
Default (PLC) input signals:

• programEnded (signal function = Ending Program)
• mirrorProgramNumber (signal function = Mirror Program Number)


• errorProgramNumber (signal function = Error Program Number)
• robotReady (signal function = Robot Ready)
• HOME (signal function = Pose Signal)

Robot path reference operation
The New Operation →New Robot Path Reference Operation command

enables you to run robotic operations of a robotic program in a line simulation.
• A robot path reference operation activates one or more specific operations

within a robotic program via the path number.
• You can run it in a line simulation.
• Because the robot path reference operation refers to the robotic operation
only by its path number, you can change the target of it by re-assigning a path
number to a different robotic operation.
Creating robot path reference operation:

• Keeps the part associated to a material flow alive

• Allows full flexibility in changing paths without changing anything in the Gantt
chart
• Are only be executed using robot program parameters (robot status signals)

Robot program
The following schematic diagram shows the general robot behavior based on
a path view:


Creating robot programs (default controller)
Purpose
In this topic, you learn how to create robot programs using the default controller.
Objectives
• Use a couple methods to create and edit a program.
• Create a robotic program from a compound operation.

Business process

Robot program basics
In order to download paths you need to make a program. The robot program is
used to organize the robot operations in a specific order and enumerate them.
• A program is an object
• It can be downloaded and simulated
• It can contain several paths and can be edited
Program features in the Path Editor:

• The Path Editor supports opening robot programs and robotic paths
• Used to set up robot programs as an executable program – like on a real robot
• Used to add robot paths to a program by drag and drop to the program
• A program can be renamed by selecting it in the Path Editor, pressing F2,

and entering a new name.

Methods to create and edit a program
Methods to create a robotic program:

• Manually create it using a combination of the Program Inventory dialog box
and the Path Editor. This technique is described in this lesson.
• Select a compound operation containing the desired robotic operations

and choose Robot tab→Program group→Create Robotic Program for
Compound Operation .
Alternately, you can right-click a compound operation in the Operation

Tree and choose Create Robotic Program for Compound
Operation .
• Use the Segmentizer (a separately installed command that is discussed

in the appendix)

View or edit the contents of a robotic program:
In the Program Inventory dialog box, select the program and click Open in
Program Editor to edit or show a program’s contents in the Path Editor.
A robot program is stored as part of the scene details and is specific to

one robot occurrence.

Creating a robotic program from a compound operation
The Create Robotic Program for Compound Operation command searches

for robotic paths in the selected compound operation. If all the paths it locates
are assigned to the same robot, the system creates a new robotic program for
the robot and names it after the name of the selected compound operation with
an _program suffix. The system then inserts all the paths from the compound
operation under the new robotic program. The order of paths in the new robotic
program is the order in which the paths run in the compound operation. The
command is enabled when you select one or more compound operations (or
PrStationProcess objects).
• If you select multiple compound operations, the system repeats the process
for each one and creates a new robotic program for each one.
• The compound operation remains unchanged.
• Paths inserted in the new robotic program are retained by the robotic
programs to which they have previously been assigned.

• If there is no robotic path under the selected compound(s), the system does
not create a program. No error message is issued.
• The system ignores operations that are not robotic paths. No error message
is issued.
• If you select paths assigned to different robots, the system does not
create a program and issues the following message: "The system
was unable to create a Robotic Program for one or more Compound
Operations, which contain operations performed by different robots: < list of
compound_operation_names>".

Activities
In the Creating robot programs (default controller) section, do the following

activities:
• Creating a robot program and using default signals (review)
• Creating an Excel spreadsheet of a path (review)

Summary

• The basic motion attributes.
• Robot configuration, 7th axis, and the Robot Viewer.
• Where and how to store signals and conditional statements.
• Robot program basics and robot signals.
• Robot program creation and usage.

Lesson 3
ESRC setup and motion parameters


Purpose
To describe how to setup and setup and add motion parameters to paths using
emulated robot specific controllers (ESRC).
Objectives
• Got an overview of OLP features.
• How to setup a basic robotic scene that you can use to learn about ESRC.
• How to select a controller and view the teach pendant.
• How to do some basic setup of a robot and robot controller.
• How to test a teach pendant and fix some setup problem.
• How to reset the RCS and decouple it.


• How to setup specific controller frames using the Teach Pendant and other
specific setup.
• How to set specific controllers motion attributes using the teach pendant.
• How to create a program.
• How to simulate a process and create configurations.

Process Simulate OLP introduction
Purpose
In this topic, you learn how using a specific controller differs from using the default
controller.
Objectives
• Overview the basic steps to setup a robot controller

MOP-based and RCS-based controller set up
There are several steps required to setup up MOP-based and RCS-based robot
controllers.
Overview of setting up a MOP-based simulation
1. Select a supported robot configuration (for example a robot with a gripper
mounted) as described later in this lesson.
2. Setup and configure all guns that can be mounted on the robot. Tell which is
gun1 and gun2 and if is it a pneumatic or servo gun.
3. Verify the setup of the rrs.xml file for all robots by vendor. This file
contains configuration information for all robot vendor RCS modules.
It contains information such as where the RCS installed and which
version is installed. (for example for ABB the Module Path would
be: C:\Tecnomatix\rrs_bin\rcs_abb\rcsabb\rcsabb_tune.exe). This
information needs to be maintained manually (for example as new versions of
the RCS are installed, this file needs to be updated accordingly).

4. Configure the robot controller for a specific robot instance: Right-click the
robot and choose Robot Properties. Select the Controller tab. Select the
Controller, RCS Version (optional), and Controller version. This is stored
in the scene data.
5. If the robot is using specific machine data (ex : robot with external axes): In
Setup dialog box, choose Robot Settings, choose Load Machine data, and
import the desired file from the robot.
6. Choose Robot Settings then choose Create/Update System frames to

create all required frames (for example world, tool, wobj, etc.)
7. Setup the tool frame and base frame definitions. They are stored at the
scene level.
8. Setup the desired attributes on the teach pendant and run the simulation.
Overview of setting up a RCS-based simulation

1. Select a supported robot configuration (for example a robot with a gripper
mounted) as described later in this lesson.

2. Setup and configure all guns that can be mounted on the robot. Tell which is
gun1 and gun2 (can have two for Fanuc) and if is it a pneumatic or servo gun.
3. Verify the setup of the rrs.xml file for all robots by vendor. This file
contains configuration information for all robot vendor RCS modules.
It contains information such as where the RCS installed and which
version is installed. (for example for ABB the Module Path would
be: C:\Tecnomatix\rrs_bin\rcs_abb\rcsabb\rcsabb_tune.exe). This
information needs to be maintained manually (for example as new versions of
the RCS are installed, this file needs to be updated accordingly).
4. Configure the robot controller for a specific robot instance: Right-click the
robot and choose Robot Properties. Select the Controller tab. Select the
Controller, RCS Version, and Controller version. Enter the Manipulator
Type (the machine data entered must be precise). Usually in the syntax of
RCS software version and robot description (robot model, arm configuration,
7th axis, servo, etc.). This is stored in the scene data.
5. If the robot is using specific machine data (ex : robot with external axes): In
Setup dialog box, choose Robot Settings, choose Load Machine data, and
import the desired file from the robot.

6. Choose Robot Settings then choose Create/Update System frames to
create all required frames (for example world, tool, wobj, etc.)
7. Setup the tool frame and base frame definitions. They are stored at the
scene level.
8. Start the RCS (if required) and connect to it
9. Setup the desired attributes on the teach pendant and run the simulation.

ABB supported configurations
Process Simulate supports these ABB configurations:

• Robot with one or two mounted pneumatic guns
• Robot with gripper and one or two pedestal pneumatic guns
• Robot on rail with one or two mounted pneumatic guns
• Robot with gripper on rail with one or two pedestal pneumatic guns
• Robot with one or two mounted servo guns
• Robot with gripper and one or two pedestal servo guns
• Robot on rail with one or two mounted servo guns
• Robot with gripper on rail with one or two pedestal servo guns
• Robot with moving object frame (object attached to an external mechanical

unit, like a turn table)

• Paint process is not supported
• Configurations with conveyors are not supported

Cloos supported configurations
Process Simulate supports these Cloos configurations:

• Robot with mounted gun
• Robot with mounted workpiece
• Robot on rail

Comau supported configurations
Process Simulate supports these Comau configurations:

• Robot with a mounted gun
• Robot with a mounted workpiece
• Robot on a rail
• Robot with one servo gun
• Robot on rail with one servo gun

Denso supported configurations
Process Simulate supports these Denso configurations:

• Fixed robot with fixed part
External axes are not supported for the Denso controller.

Duerr supported configurations
Process Simulate supports these Duerr configurations:

• Multiples robots on rail with a conveyor

Epson supported configurations
Process Simulate supports these Epson configurations:

External axes are not supported for the Epson controller.

Fanuc supported configurations
Process Simulate supports these Fanuc configurations:

• Robot with one or two mounted pneumatic guns
• Robot with gripper and one or two pedestal pneumatic guns
• Robot on rail with one or two mounted pneumatic guns
• Robot with gripper on rail with one or two pedestal pneumatic guns
• Robot with one or two mounted servo guns
• Robot with gripper and one or two pedestal servo guns
• Robot on rail with one or two mounted servo guns
• Robot with gripper on rail with one or two pedestal servo guns

IGM supported configurations
Process Simulate supports these IGM configurations:

• Fixed robot with part mounted on an external manipulator
• Robot on gantry with fixed part

Kawasaki supported configurations
Process Simulate supports these Kawasaki configurations:

• Robot on a rail

Kuka supported configurations
Process Simulate supports these Kuka configurations:

• Robot on a rail
• Moving bases (bases attached to an external manipulator)

Nachi supported configurations
Process Simulate supports these Nachi configurations:

• Robot on a rail

NC supported configurations
Process Simulate supports these NC configurations for machining:

• “Robot” or NC machine with an external axis
Process Simulate supports these NC configurations for drilling and riveting:

• GemCor machines G86 and G2000
• Brotje machine

Panasonic supported configurations
Process Simulate supports these Panasonic configurations:

• Fixed robot with positioner
• Robot on rail or gantry with fixed part
• Robot on rail or gantry with positioner

Reis supported configurations
Process Simulate supports these Reis configurations:

• Robot on a gantry
• Robot with a positioner (dynamic user frames)

Staubli supported configurations
Process Simulate supports these Staubli configurations:

• Fixed robot with a fixed part

Trallfa supported configurations
Process Simulate supports these Trallfa configurations:

• Robot on a rail
• Robot with one conveyor

Universal supported configurations
Process Simulate supports these Universal configurations:

External axes are not supported for the Universal controller.

Yaskawa supported configurations
Process Simulate supports these Yaskawa configurations:

• Robot with a pneumatic mounted gun
• Robot with a mounted workpiece with pneumatic remote gun
• Robot on a rail
• Robot with one external positioner (1 or 2-axes positioner)
• Multiples robots with conveyor

Basic scene setup
Purpose
In this topic, you learn how to a basic scene.
Objectives
• Setup a Scene to access a controller.

Business process

Process Simulate robot controller application support
(Robot) Arc Material Spot Continuous

Controller Support Handling Support App.
Support Support
Abb-Rapid Yes Yes Yes Paint,
Dispensing
Abb-Rapid- Yes Yes Yes Paint,
Dispensing,
Volvo Laser Weld,
Laser Braze,
Nut Run, Seal,
Stud
Cloos-Carola Yes —- —- —-
Comau-Pdl —- Yes Yes —-
Comau-Pdl- —- Yes Yes Stud, Nut, Glue,
Laser Weld
Volvo
Duerr-Ecotalk —- —- —- Paint
Epson-Spel —- Yes —- —-
Fanuc-F100iA —- Yes —- —-

Fanuc-RJ Yes Yes Yes Sealing
Fanuc-Japan Yes Yes Yes Sealing
Fanuc-Vw Yes Yes Yes Sealing
IGM-Ins Yes —- —- —-
Kawaski-As Yes —- Yes —-
Kuka-Krc —- Yes Yes —-
Kuka-Krc- —- Yes Yes Nut, Glue
Volvo
Kuka-Vkrc —- Yes Yes —-
Nachi-Slim —- —- Yes —-
NC-Code —- —- —- Machining
NC-Riveting —- —- —- Riveting
Reis-Robstar Yes Yes —- —-
Staubli-Val —- Yes —- —-
Trallfa- —- —- —- Paint
Robtalk
Universal- i—
pt- Yes —- —-
URSc
Yaskawa- Yes —- Yes Paint
Inform

Scene basics
In this lesson, you load a scene, mount the gun, and create a small path that you
later download. All the steps covered in this lesson should be a review of what
was learned in the TR43115 Process Simulate on Teamcenter Basic Robotics
Simulation course.

Activities
In the Basic Process Simulate Setup section, do the following activities:

• Basic Scene Setup

Robot controller selection
Purpose
In this topic, you learn how to select the robot controller for a specific robot.
Objectives
• Select a robot controller.
• Figure out the manipulator type for a robot.

Business process

Robot controller selection basics
Selecting the Controller affects this information for the selected robot instance:
• The motion planner used during simulation (for example RCS-based or
MOP-based)
• Teach Pendant
• Robot Setup
• Download to Robot
• Upload Programs
• Simulation
• Path Editor dialog box
On the Controller tab of the Robot Properties dialog box, there are four
parameters that are typically related to Selecting a controller for a specific robot
instance:

• Controller
o This list is populated based on which Process Simulate controllers (teach
pendants) have been installed (development specified). (Each is a
separate install, as you have seen in earlier in this course)
o As you have seen earlier in this course: For RCS-based controllers, an

entry for each controller in this list should be in the rrs.xml file (user
specified)
• RCS version
o Comes from the rrs.xml file (user specified)
o Set on the Robot Properties dialog box
o Only used to select which RCS to use during simulation
• Manipulator type
o For RCS-based controllers, it is user specified and must match a valid
value on the RCS
• Controller version

o Hard-coded in the controller (development specified)
o Set either on the Robot Properties dialog box or the Robot Setup
→Controller version dialog box.
o Handles any slight difference in the software such as features available

in the teach pendant, download syntax, simulation, etc.
Other Controller Topics:

• Connect / Disconnect — used to decide whether to connect to the specified
RCS.
• Validate RCS — located on the Controller tab of the Robot Properties

dialog box, it becomes available when connected to the RCS. It checks the
compatibility between the selected RCS Version and selected Controller
Version.
As of v10.0, this feature is not currently supported for all controllers.
However, it does work for the Fanuc controller.
• Robot Setup — This is described in the coming lessons.


Opening the Controller tab of the Robot Properties dialog box:
• Choose a robot and choose Robot tab→Setup group→Robot Properties
or right-click the robot and choose Robot Properties .

How to figure out the manipulator type for an RRS controller?
The Manipulator Type is only needed by RRS-based controllers. If you

are using a MOP controller, this is not needed.
Check the .rrs file located under the

D:\users\student\student_files\robots\robot-prototype.co\rrs folder.
The file is used by Robcad and may not available if the .CO was converted
to .COJT
Abb:
• For a Robcad cell connected to Process Simulate, just look at the .rrs file
either under the <cell>/<robot>_rrs folder or robot prototype folder and use
same value as defined for ManipulatorType
• For a new scene: See the s4c.cfg, s4cplus.cfg, or irc5.cfg files under the
ABB RCS install folder.
Comau:

Leave the manipulator type box blank. It figured out a different way.
• Typically it is the name of the .rcs file located in the
D:\users\student\student_files\robots\robot-prototype.co\rrs
folder.
Fanuc:
• For a temp robot: see the
C:\Tecnomatix\rrs_bin\rcsfr13\robcad.bin\VERSION\<RCS
Version>/standard.cfg file inside RCS module folder (client)
o In the standard.cfg file enter: <Temp Robot>. For example:
R2000IF-165KG (as specified in the Fanuc robot setup wizard).
o In the Manipulator Type box in Process Simulate, select:

<RCS Version>,<Temp Robot> from the list. For example:
V7.40,R2000IF-165KG
• For a named robot, use following manipulator type format :

o In the specific.cfg file enter: <Named Robot>. For example:
R2000IF-165KG (as specified in the Fanuc robot setup wizard).

o In the Manipulator Type box in Process Simulate, select:
<RCS Version>@<Named Robot> from the list. For example:
V7.40@R2000IF-165KG.
Kuka:
• Later you browse and select several files from the MADA folder under the
Kuka RCS install.
Nachi:
• Check the manipulators.cfg file in the FD folder for the right name under
the Nachi RCS client install folder.
Tralfa:
Yaskawa:
• Check your Yaskawa RCS license file for the right name.

Activities
In the Robot controller selection section, do the following activities:

• Robot controller selection

Robot controller setup
Purpose
In this topic, you learn how to set up various robot controllers.
Objectives
• Setup a robot controller for a robot.
• Access Robot setup using method 1.

Business process

Robot controller setup basics
In this lesson you discuss basic controller setup using the Robot Setup dialog box.
This button can be found in two places:
• Method 1: Click Robot Setup on the Robot Properties dialog box opened
for a specific robot.
• Method 2: Click Robot Setup on the relevant robot controller specific

Teach Pendant dialog box opened for a specific robotic operation.
• Method 3: From the ribbon, choose Robot tab→Setup group→Robot Setup

to access it directly instead of inside other dialog boxes.
Setup must be done to define / upload:

• Machine data (for example must always be done for Kuka and Comau)

• System data (Tool, Base, Load, …)
• Creation / Update of system frames
• Simulation & Download settings
• Program template definition

Accessing Robot Setup using method 1
Robot Setup is located on the Robot Properties dialog box. To open this dialog
box:
1. Right-click a robot in the Graphic Viewer and Selecting Robot
Properties .
2. In the Robot Properties dialog box, click the
Controller tab The controller information must be
3. Click the Robot

filled in. Setup button.

Accessing Robot Setup using method 2
Robot Setup is located in every Teach Pendant dialog box. To open this dialog box:
• Right-click a robotic path in the Operation Tree (the robot must be assigned to
operation) and choose Teach Pendant .
A robot must be assigned to the operation and a robot controller,

besides the Default, assigned to the assigned robot.
• From the Teach Pendant dialog box, click Robot Setup .

ABB Robot Setup dialog box – first buttons

• Load Machine Data – If the robot is using specific machine data (ex : robot
with external axes): In Setup dialog box, choose Load Machine data. In
Load Machine Data dialog box, select the desired moc.CFG file. (There are
some samples on GTAC for a 7th axis). Close the dialog box by clicking OK.
• Create / Update System Frames – Creates all ABB system frames (if not
already existing) and places them in the scene with respect to the machine
data:
o <robot>.w - robot controller world frame created in the Frames folder
of the Object Tree.
o <robot>_<mechUnit>_base and <robot>_<mechUnit> - system

frames for external manipulators. Only available for robot with external
manipulators (turn table,...) configurations.
o In case of a conflict in the robot orientation on the rail, the user is

prompted whether he would like the application to align the robot position
in the cell with the Machine data definition, or update the Machine data.
o Pushing this button resets the tool frame and wobj frame in the scene to
its initial positions corresponding to data definition

Comau Robot Setup dialog box – first buttons
For C3G version of controller:


• Load Machine Data – Used to load the .rcs file
related to this robot. Typically it is located in the
D:\users\student\student_files\robots\robot-prototype.co\rrs folder. (The
file is used by Robcad and might not be available if the .co was converted
to a .cojt).

• Create/Update System Frames - Creates all Comau system frames (if not
data:
of the Object Tree.

in the cell with the Machine data definition, or update the Machine data.
o Pushing this button resets tool frame and wobj frame in the cell on its
initial positions corresponding to data definition

Denso Robot Setup dialog box – first buttons
• Create/Update System Frames - Creates all Denso system frames (if not
data:
of the Object Tree.

in the cell with the machine data definition, or update the machine data.
• Work Definition - Create, edit, and remove robot user frames. The naming
convention for a work frame is <robot>.w<num>.
• Tool Definition - Create, edit, and remove robot tool frames. The naming
convention for a tool frame is <robot>.w<num>.

Duerr Robot Setup dialog box – first buttons
• Load Machine Data — If the robot is using specific machine data (for
example a robot with external axes): In the Setup dialog box, choose Load
Machine Data. Select the relevant const.RC and device.CFG files. Close the
dialog box by clicking OK.

• Create/Update System Frames — Creates all Duerr system frames (if not
data:
of the Object Tree.

Epson Robot Setup dialog box – first buttons
• Create/Update System Frames - Creates all Epson system frames (if not
data:
of the Object Tree.


Fanuc Robot Setup dialog box – first buttons

• Create/Update system frames — Creates all Fanuc system frames (if not
data:
o <robot>.w — robot controller world frame created in the Frames folder
of the Object Tree.
o Potential conflict between robot orientation on rail (between cell and

machine data) is NOT checked

IGM Robot Setup dialog box — first buttons
• Load Machine Data — In the Setup dialog box, choose Load Machine Data.
Select the relevant param.ini file. This is a critical step for this controller.
Close the dialog box by clicking OK.

There is no generic PARAM.INI file since it is a file from the real robot.
However, the actual type of the robot is not important to Process
Simulate. The robot controller is only reading the externals layout,
tools, and process configurations from this file.
• Create/Update System Frames — Creates all IGM system frames (if not
data:
o <robot>.w — the robot world frame.
o <robot>.w1 — Robot base frame created in the Frames folder of the

Object Tree.
o <robot>.w2 — predefined external work object frames. These system

frames are linked to each ExtAxRef external axis (as defined in
param.ini) and are automatically attached to the relevant link of the
relevant robot external device. They are named using the ExtAxRef
order.

o All tools in the study (modeled as either robot system frames ) are set to
their nominal position (as defined in the param.ini).
Names for locations to be downloaded cannot exceed 8 characters in

length.
Potential conflict between robot orientation on rail (between cell and

param.ini) is not checked.
IGM robots MUST have an external axis.

Kawasaki Robot Setup dialog box – first buttons
• Create/Update System Frames — Creates all Kawasaki system frames

(if not already existing) and places them in the scene with respect to the
machine data:
of the Object Tree.

Kuka Robot Setup dialog box – first buttons

• Load Machine Data — In Robot Setup dialog box, choose Load Machine
data. In the Load Machine Data dialog box, Browse and select the R1 and
STEU folders (mandatory).
Selecting the $config.dat file is optional.

If using the version 5.2, 5.4, or 5.6 of the Kuka controller, you do not
have the Config folder box on the Load Machine Data dialog box.
• Create/Update System Frames — Creates all Kuka system frames (if not
data:
o <robot>.bf0 — robot controller world frame created in the Frames
folder of the Object Tree.
o <robot>.sim_bf0 — rail base frame (also known as the ERSYSROOT

frame). Only available for robot on rail configurations.

o <robot>.base_easys, <robot>.object_easys ... <robot>.base_efsys,
<robot>.object_efsys — system frames for external manipulators. Only
available for robot with external manipulators (for example a turn table)
configurations.
o In case of major conflict between Process Simulate layout and the MADA
layout (number/type of external axes), a warning message is displayed.
o In case of conflict between robot orientation on rail, the user is prompt

whether he would like the application to align the robot position in the cell
with the MADA definition.

Nachi Robot Setup dialog box — first buttons

• Create/Update System Frames — Creates all Nachi system frames (if not
data:
of the Object Tree.
• Gun Definition — assign a gun number to the guns you use in simulation.
The type of gun is also set, such as pneumatic or servo. If this is not set, a
warning message is shown during download.

NC Code Robot Setup dialog box – first buttons

• Origin Definition (for machining, but not riveting) — used to setup origin
frames (which are like robot base frames). Origin frames can be named G54
through G59 with the “defined” keyword if the origin is already defined. Euler
angle is used for the orientation (phi, theta, psi).
o <robot>.g54 — robot controller world frame created in the Frames
• Create/Update System Frames — (Not currently used) Creates all NC Code

system frames (if not already existing) and places them in the scene with
respect to the machine data:

o <robot>.of_g53 — robot controller world frame created in the Frames

Panasonic Robot Setup dialog box – first buttons
• Create/Update System Frames - Creates all Panasonic system frames

machine data:
of the Object Tree.

• Tool Definition - Tool numbers range from 1 to 30. The tool coordinates
are relative to the robot TOOLFRAME. The naming convention for tools is
<robot>.t<toolNum> for a robot system frame and Tool<number> for a
work tool. Optionally, a tool name can be associated with the tool number.
• User Frame Definition - Frame numbers range from 1 to 32. The frame
coordinates are relative to the robot WORLDFRAME. The naming convention
for user frames is <robot>.uf<frameNum>. Optionally, a frame name can be
associated with the frame number. A user frame is only downloaded in the
header section and it cannot be changed within a program. An error message
is reported if more than one user frame is used in a robotic operation.

Reis Robot Setup dialog box – first buttons
• Create/Update System Frames — Creates all Reis Robstar system frames

machine data:
o <robot>.uf0 — robot controller world frame created in the Frames
folder of the Object Tree. This frame is the reference for the user frames
and is superimposed on the robot BASEFRAME.

• Tools Definition - Only mounted tool configurations are supported. Tools are
defined by name and should start with an uppercase T. Space or special
characters are not supported. Here are some examples of valid tool names:
T_time, Tcp, or T1. The naming convention for frames is _t_<Toolname> and
<ToolName> for work tools. The frame coordinates are relative to the robot
ToolFrame.
• User Frame Definition -

You can define user frames by name. The naming convention for user
frames is _uf_<name>. User frames can be either STATIC and DYNAMIC.
The dynamic option is available only for robot with an external axis. If the
dynamic type is selected, the created frame is attached to the last link of
the selected external device. The user frame coordinates are relative to the
robot RrsWorldFrame.

Staubli Robot Setup dialog box – first buttons
• Create/Update System Frames — Creates all Staubli system frames (if not
data:
of the Object Tree.

• Tool Definition - Use it to create, edit, and delete tools. The tool position is
relative to the robot TOOLFRAME. The naming convention for robot frames is
<robot>.ut_<tool>. The naming convention for Robot Toolbox work tools is
<tool>.
• Frame Definition - Use it to create, edit, and delete user frames. The
frame position is relative to the robot WORLD (BASEFRAME). The naming
convention for frames is <robot>.of_<frame>.

(ABB) Trallfa Robot Setup dialog box – first buttons
• Load Machine Data — In Robot Setup dialog box, choose Load Machine
data. In the Load Machine Data dialog box, click Add and choose a .i01
machine data file (mandatory).
• Create/Update System Frames — Creates all Trallfa system frames (if not
data:

o<robot>.bf — robot controller world frame created in the Frames
o<robot>.uf — UserFrame (Disp Base from a robot.i01 MADA file) o
<robot>.of — TrackFrame for conveyor
o<robot>.ut<n> or <robot>.t<n> — TcpFrame o
<robot>.uf<n> — DispFrame

Universal Robot Setup dialog box – first buttons
• Create/Update System Frames - Creates all Universal system frames (if not
data:
of the Object Tree.

• Tool Definition - Use it to create, edit, or delete tools. The tool position is
relative to the robot TOOLFRAME. The orientation is displayed in native
Universal Rotation Vector representation. The naming convention for robot
frames is <robot>.t_<toolName>. The naming convention for Robot Toolbox
work tools is <toolName>.

Yaskawa Robot Setup dialog box – first buttons
• Load Machine Data — If the robot is using specific machine data (for example
a robot with external axes): In the Setup dialog box, choose Load Machine

data. Select the relevant all.PRM, tool.CND, uframe.CMD, sgun.DAT,
spress.cnd, and clearnce.DAT files. Close the dialog box by clicking OK.
• Create/Update System Frames — Creates all Yaskawa system frames

machine data:
of the Object Tree.

Activities
In the Robot controller setup section, do the following activities:

• ABB — Setting up the controller
• Cloos — Setting up the controller
• Comau — Setting up the controller
• Denso — Setting up the controller
• Duerr — Setting up the controller
• Epson — Setting up the controller
• Fanuc — Setting up the controller
• IGM — Setting up the controller
• Kawasaki — Setting up the controller


• Kuka — Setting up the controller
• Nachi — Setting up the controller
• NC — Setting up the controller
• Panasonic — Setting up the controller
• Reis — Setting up the controller
• Staubli — Setting up the controller
• Trallfa — Setting up the controller
• Universal — Setting up the controller
• Yaskawa — Setting up the controller

Testing the RCS connection and fixing setup problems
Purpose
In this topic, you learn how to test the RCS connection and fix setup problems
for RCS-based robot controllers. For MOP-based robot controllers, this does
not apply.
Objectives
• Open the teach pedant for the robot associated to a robotic path and see if
the related RCS can be accessed.
• Use the RCS shell.
• Use RCS logs.

RCS connection testing basics
There are several ways to find problems in the setup:

• Look over your installation again (for example the information from earlier in
this course).
• Turn on log files and look at the resulting logs
• Look at the messages shown in the error dialog box during simulation.
• Turn on the RCS console dialog box and view the messages.
• Finally, work with GTAC to help resolve the problem.

RCS shell
First turn it on:

• From the ribbon, choose Robot tab→OLP group→Visible Shell On/Off .
Then view the results in the RCS shell dialog box:

• This dialog box opens whenever the Robot Setup or Teach Pendant dialog
boxes are opened.

RCS logs
First turn them on using the Robot Setup dialog box:

Simulation Settings:
• RRS Debug - turn on/off RRS debug mode. If on, simulation creates a
debug file named rcs<RobotVendor>.<robotName> with the dialog between
Process Simulate and the RCS. View the resulting log file in the C:\temp
folder.
• Simulation Debug Trace - activate/deactivate debug trace mode

• Reset Conveyor Position - reset conveyor to zero position (might be require
after using Jump To Location on tracking locations). Available on some
controllers such as Abb-Rapid.

Activities
In the Testing the RCS connection and fixing setup problems section, do the
following activities:
• Testing the RCS connection
• Using the RCS shell
• Using the RCS logs

RCS management
Purpose
In this topic, you learn how to manage the connection to the RCS for RCS-based
robot controllers. For MOP-based robot controllers, this does not apply.
Objectives
• Manage the RCS module.
• Reset RCS module.
• Decouple the RCS module.
• Know limitations on decouple mode.

RCS management basics
In order to simulate, use some functions of an RCS-based teach pendant, or

upload/download the RCS module must be loaded. Normally, it is loaded in
several ways:
• When the Teach Pendant dialog box is opened.
• When the Robot Properties dialog boxes is opened.
• When a robotic simulation is run which uses a non-default controller robot.

Reset RCS module
Drops and reestablishes the connection to the RCS (for example stops and
restarts the RCS module). This is useful if the RCS connection hangs. The other
way to do this is to use the Controller Settings dialog box.
This does not release the RCS license.
Using Reset RCS module:

1. Select the robot using a loaded RCS robot controller.
2. From the Quick access toolbar choose Reset RCS Module .

The Reset RCS Module command is not located in the ribbon. To
add it to the Quick access toolbar, choose Customize Quick Access
Toolbar command.
Unloading and load the RCS using Controller Settings:

1. From the ribbon, choose Robot tab→Setup group→Controller Settings
(or it can be found on the Controller tab of the Robot Settings dialog box).

2. Select a robot controller in the Controller Settings dialog box.
3. From the Controller Settings toolbar, choose Terminate RCS to terminate

the selected RCS connection.
Choose Terminate All RCS to end all the active RCS connections.
4. From the Controller Settings toolbar, choose Initialize RCS to start an

RCS connection to the selected RCS.
Choose Initialize All RCS to start RCS connection for all listed
RCS.

Disconnecting from the RCS (RCS decoupling)
For RCS-based controllers, you can perform several actions disconnected

(decoupled) from the RCS that normally require the RCS to be work. The main
caveat is that the motion is performed using the default controller instead of the
RCS.
It is possible to run robot-customized, non-RCS actions without launching the RCS
module and without an RCS license, since this is Siemens PLM development, not
dependent on the robot manufacturer.
For each robot controller, check or clear the following: in either the Robot
Controllers dialog box or the Robot Properties dialog box:
• Non Simulation Actions — For example, teach pendant and downloading
programs.
• Simulation Actions — For example, OLP commands, RCS simulation, and

ESRC functionality.

Not all RCS modules support decoupling. Grayed out boxes do not
support decoupling. For exact motion, the RCS module is still mandatory
for all controllers. For example, circular motion is replaced with linear
motion in decouple mode.
The default value for decoupling can also be setup in the

rrs.xml file on the controller line (in class located in the
D:\users\student\student_files\OLP_config_files\ folder).
For example to be disconnected by default: <Controller
Name="Fanuc-Rj" RCSDecoupleSimulationAction="True"
RCSDecoupleNonSimulationAction="True">
To break the connection to the RCS:


2. Deselect either the Simulation or Non Simulation check boxes, depending
on the action you want too perform.
3. Check Close.
To reestablish the connection to the RCS:

2. Select either the Simulation or Non Simulation check boxes, depending

on the action you want too perform.
3. Check Close.

Limitations of decouple mode
Limitations in the Robot Setup dialog box

• External axes mapping definition is not available
• When performing Create/Update System Frames, transformation from robot

WORLD frame to the robot BASE frame cannot be retrieved from the RCS
module, therefore this information is assumed to be Identity Matrix. If this
assumption is wrong, it might be necessary to manually relocate the robot
WORLD frame in the scene.
• In moving frames configuration, when performing Create/Update System

Frames, the information on the moving frames cannot be retrieved from the
RCS module. These system frames should therefore be created, located
and attached manually.
Limitations during downloading:

• Logical Axes Map information from the RCS module cannot be used. As
a consequence, external axes are downloaded in the same order and with
same indices as they are defined in Process Simulate. It might be necessary

to post-process the robot targets in the download file in case this assumption
is wrong.
• Conversion from Process Simulate to RCS configuration string is done

manually
Limitations during uploading:

• Logical Axes Map information from the RCS module cannot be used. As
a consequence, the following work around is implemented for the upload
of external axes:
• The application looks for defined external axes in the ABB externals string
(the ones which value is not 9E9)
• The nth axis that is defined is supposed to be mapped to the nth external axis
in Process Simulate.
• Conversion from RCS configuration string to Process Simulate configuration

to is done manually.

Activities
In the RCS management section, do the following activities:

• RCS management

Methods to define TCPF positions for a robot controller
Purpose
In this topic, you learn how to define TCPF positions for a robot controller.
Objectives
• Understand some tools and definitions related to the TCPF.

Business process

TCPF definition basics
Currently, there are two ways to define the TCPF positions for a robot controller:
• Method 1 and Method 2: Using the Teach Pendant (or Robot Properties
) – Defines it as engineering data stored in the scene. This is the way that
Robcad used to do it. you describe this method in more detail in the next
lesson.
Currently, there is only one way to define the BASEFRAME (REF FRAME)
positions for the RCS:
• Using the Robot Setup from Teach Pendant (or Robot Properties)

Robot controller specific frames and setup
Purpose
In this topic, you learn how to setup robot controller specific frames.
Objectives
• Access Robot Setup using method 2.
• Access Robot Setup using method 3.
• Continue learning about specific controller Robot Setup dialog boxes.
• Continue learning about the controller specific frames.

Business process

Robot setup basics
In this lesson you discuss controller specific frame creation and other specific
setup tasks. In this lesson you reference Method 1 and Method 2 as briefly
described in the previous lesson: clicking Robot Setup . This command can be
found in several places:
• Method 1: The Robot Properties dialog box.
• Method 2: The relevant Teach Pendant dialog box (for example ABB-Rapid,
ABB-Rapid-Volvo, Cloos-Carola, Comau-Pdl, Comu-Pdl-Volvo, Default,
Duerr, Epson-Spel, Fanuc-F100ia, Fanuc-Rj, Fanuc-Rj-Japan, Fanuc-Vw,
Igm-Ins, Kawsasaki-As, Kuka-krc, Kuka-Krc-Volvo, Kuka-Vkrc,
Nachi-Slim, NC-Code, Reis-Robstar, Staubli-Val, Trallfa-Robtalk,
Universal-URScript or YaskawaTeach Pendant dialog boxes).
• Method 3: From the ribbon, choose Robot tab→Setup group→Robot Setup

.

Robot controller created frames:
• Controller and instance specific frames are created in the Frames folder of
the Object Tree.
• Word reference frame — Process Simulate creates a robot system frame
named <robot>.w (before it created a scene frame <robot>_w). It is
superimposed on the robot BASEFRAME when all external axes are set to
zero. Although robot system frames are shown in the Object Tree, they are
stored with the robot instance (meaning they come with the robot if you put
the same robot instance in another scene).
• User reference frames — Some controllers all you to create a additional

reference frames, for example on the part.
• Tool frames — Tools, which may be superimposed on the TCPF, are

referenced by a controller either by a name or a number. There position is
stored relative to the robot TOOLFRAME. During simulation the tool frame

is placed on the locations in the path. The location’s downloaded position is
relative to a reference frame such as the world reference frame or a user
reference frame.
The robot must be setup before simulating, uploading, or downloading:

• Machine data must be setup for all RRS-based controllers (Although how it is
done is a bit different for each controller)
• Create system frames such as a the world (w) frame.
• System data such as tool frames, base frames
• Setup controller or robot specific simulation and download settings (needed

for downloading and accurate simulation)
• Setup basic motion parameters (needed for downloading and accurate

simulation)
• Teach robot configurations to each location (needed for downloading and

accurate simulation)

• Setup a program download template (needed for downloading only)

Accessing robot setup using method 2
Robot Setup is located on the Robot Properties dialog box. To open this dialog
box:
• Right-click a robot in the Graphic Viewer and choosing Robot Properties .
• In the Robot Properties dialog box, select the Controller tab. The controller
information must be filled in. For example:

• Choose the Robot Setup command.

Accessing robot setup using method 3
Robot Setup is located in every Teach Pendant dialog box. To open this dialog box:
• Right-click a robotic path in the Operation Tree (the robot must be assigned to
operation) and choose Teach Pendant .
• From the Teach Pendant dialog box, choose Robot Setup . For example:

Robot system frames
Robot system frames make up a large number of global frames in any robotics
study.
When system frames are created or updated, using the Create\Update System
Frames command, the frames are created or moved under a folder structure
named according to the robot instance name. The world frame is placed in
this folder while tool and base frames are separated into different sub-folders
named according to the RCS standard naming. The following pictures provide an
example of the folder structure that is created.

The Create\Update System Frames command only copies frames under this
folder structure if the world frame was not manually moved under another folder
already.

ABB Robot Setup dialog box — continued

• Download Settings – Set the type of program to download.
• Explicit Data Upload – Used to:

o Import data definition files (for instance the base.sys that is located
under the robot component folder in Robcad) into Process Simulate
o Maintain the list of explicitly uploaded files


o The selected files are copied under the robot private folder (same folder
as the one used to copy the machine data file needed for the RCS)
o The list of explicitly uploaded files are stored as a robot parameter
• Load Local Data Definitions – Used to import the Robcad .robdata.sys

file definitions into Process Simulate. The definitions are stored as a robot
parameter.
• Down Local Data Definitions – Copies all local data definitions into a
process simulate dataset stored in the database.
• Base Data Definition


o All data definition interface:
■ Edit existing (local) data by selecting from a list of data.
■ Create new data: select data from list for display by values, replace
the data name with a new data name, and validate it by clicking
Enter.
■ Add new data by clicking Store.
■ Delete ( local) data by clicking Delete.
o Tool data, Wobj data:

■ Robcad tools are supported (frame <robot>_<tooldata>_tf)
■ Robcad object frames are supported (frame

<robot>_<wobjdata>_of)
■ RobotToolBox WorkTool are also supported.

■ Naming convention for ABB is that WorkTool name should match
the ABB tool data name. For a given tool data, WorkTools have
priority upon Process Simulate frame tools.
• Process Data Definition – Spot data, Gun data, Bead data, Arc Data, etc.
o Spot data definition is different for pneumatic or servo guns.
o You can select between these two possibilities of parameters.
o Gun data is the same for pneumatic and servo guns.

• Custom Data Definition – described later in this course
• External Axis Map Setup

o For each Mechanical unit, you can define a device from devices list.
o For each Mechanical unit, logical axes can be associated the joint of
the selected device.
Program Templates – described later in this course

Comau Robot Setup dialog box — continued
For C3G:
For C4G:

For C5G:

The Comau has three controller versions: C3G, C4G, and C5G. The C4G and
C5G versions support glue and stud process. they also support defining tool data
and frame data instead of UFrame and UTool. The C5G version also supports:
two active guns, Base Data, eMotion, Servo Flyby, and SpotWare type selection.
• Program Templates — described later in this course

• User Frame & Tool Data (for C3G)
o <robot name>_uf1
o <robot name>_ut1
• Base Data (for C5G only)

o Creates or edits base frames named: <robot name>.wf<number>. For
example myrobot.wf1.
• Frame Data (for C4G and C5G only)

o Creates user frames name: <robot name>.of<number>. For example
myrobot.of1.
• Tool Data (for C4G and C5G only)

o Creates or edits tool frames: <robot name>.t<number>. For example
myrobot.t1.
• Download Settings — Can be used to filter what is output to the resulting file
output for the robot.

• Explicit Data Upload — Used to explicitly upload a tool file tt_tool1.lsv,
frame file tu_frame.lsv, base file tb_base.lsv, or servo distance file
SwD_dist_data.lsv.
• Robot World Setup — Setup the position and orientation of the robot world
frame.

Denso Robot Setup dialog box — continued
• Tools Definition — Create, edit, or delete tools. The tool position is relative
to the robot TOOLFRAME. The naming convention for robot tool frames is
<robot>.t<number>. For example myrobot.t1.
• Works Definition — Create, edit, or delete robot user frames with the
corresponding <robot>.w<num> frame.


Duerr Robot Setup dialog box — continued
• Explicitly Uploaded Data Files — allows uploading system (.TID) files.

This file is needed in order to initialize the RCS.
• Profile Data — allows defining velocity, acceleration, overlap, ramp, jerk,

and interpolation list of values data.
• Process Data — allows defining triggerPar (brush) data.
• Frame Data — allows defining tool frame, base frame, and object frame data.
o Creates or edits base frames named: <robot>.bf<number>. For example
myrobot.bf_1.
o Creates or edits object frames named: <robot>.of<number>. For

example myrobot.of_1.
o Creates or edits tool frames named: <robot>.tf<number>. For example

myrobot.tf_1.
• Local Machine Data — allows specifying const (.RC), device (.CFG), and
motion (.CFG) files.

The const (.RC) and device (.CFG) files are needed in order to
initialize the RCS.
Robcad tool frames are supported (frame <robot>_ut<num>) and

base frames have the same naming convention as in Robcad (frame
<robot>_uf<num>).

Epson Robot Setup dialog box — continued
• Local Coordinate Systems Definition — Create, edit, or delete user

frames The frame position is relative to the robot WORLD (BASEFRAME).

The naming convention for frames is <robot>.lcs<number>. For example
myrobot.lcs1.

Fanuc Robot Setup dialog box – continued

• Download Settings — several options for downloading such as
simulation commands, download point frame, RTCP location coordinates,
Utool/Uframe declaration insertion, and aborting download on error. These
values are stored in the user DownloadSettings.xml file located in the
.\eMPower\Olp\Robotics\Fanuc-Rj\Settings folder.
• Robot And Guns Setup

o Definition of the robot ID
o Definition of 2 guns with, for each gun:

■ Name (entered or picked)
■ Type: Pneumatic or Servo Gun (automatically deduced)
■ MultiPressure: YES / NO for Servo Gun and NONE / LOW-HIGH

/ LOW-MEDIUM-HIGH for Pneumatic guns
■ Backup: YES / NO
■ Backup Mapping

o The gun definitions are used in the Teach Pendant to show or not show
some process parameters.
o As for these definitions, the following rules apply:

■ You cannot define one pneumatic gun and one servo gun.
■ If you define one servo gun, it must be the gun 1.
■ You cannot use the same device to define the 2 guns.
• External Axis Mapping — this option is available when an external axis is

present on the robot.
• Tool & Base Definition

o Utool
■ Creates tool frames named: <robot>.ut<number>. For example
myrobot.ut1.
■ Robcad tools are supported (frame <robot>_ut<num>)
o Uframe

■ Creates or edits user frames named: <robot>.uf<number>. For
example myrobot.uf1.
■ Same naming convention as in Robcad (frame <robot>_uf<num>)
• Payload Definitions — used to either define or upload a payload definition

for the robot.
• Armload Definitions — used to define an arm load for the robot.
• Export Definitions — used to export tool data to a .LS file.
• Explicit Data Upload — used to upload a .VA file (for example upload
payload definitions from a SYMOTN.VA or SYSTEM.VA file)

IGM Robot Setup dialog box — continued
• Program Templates — described later in this course.
• Work Object Definition — Create work object frames. Work object numbers
after 1 are reserved for predefined external work objects. You can create,
edit, or delete the user defined work objects.
o Creates user frames named: <robot>.w<number>. For example
myrobot.w1.

• Tool Definition — Create tool frames.
o Creates or edits tool frames named: <robot>.t<number>. For example
myrobot.t1.
o Robcad tools are supported (frame <robot>.t<num>, . Only tool

numbers defined in the param.ini file are available (tool numbers start
from 1).

Kawasaki Robot Setup dialog box — continued
• Download Settings — Used to setup the default clamp command in

pneumatic or servo gun contexts.
• Gun Definition — allows the user to map a gun number to a specific gun
device in the scene

• Data Definition — allows removing, loading, and exporting the AUX data
file. Also allows editing speed, accuracy, timer, clamp application, clamp
condition, and gun parameters.
• Tool Setup
o Creates or edits tool frames named: <robot>.tl<number>. For example
myrobot.tl1.
o Users can upload one or all Tool definitions from a robot.aux file
• Work Setup
o Creates or edits user frames named: <robot>.w<number>. For example
myrobot.w1.
o User can upload one or all work definitions from loaded robot.aux file
• FTool Setup
o Creates or edits FTool frames named: <robot>.ftl<number>. For example
myrobot.ftl1.
o Users can upload one or all FTool definitions from a robot.aux file


Kuka Robot Setup dialog box — continued

• Load Robot Backup — Reads a robot backup .ZIP file and copies the files
to the robot private folder.


• Tool & Base Definition (VKRC only) or Tool & Base (KRC only)
o Creates or edits base frame named: <robot>.bf<number>. For example
myrobot.bf1.
o Creates or edits object frames named: <robot>.b<number>. For example

myrobot.b1.

myrobot.t1.
o Upload base or tool from MADA by clicking Upload.
• External Manipulator Setup — This option is available when an external

axis is defined for the robot. The display and edit external moving bases
attached to an external manipulator.
• Settings — contains download, upload, and display settings.
• Download Settings — (VKRC only) set the type of program to download.

• Load Definition — Setup the payload
• Gun Definitions — allows defining a gun.

Nachi Robot Setup dialog box — continued

• Tool Definition — Create tool frames.
myrobot.t1.
o Upload base or tool by clicking Upload.
• Stationary Tool Definition — Stationary tool numbers are from 0 to 3 and

are named rt<number> for a robot system frame or RemoteTool<number>
for a work tool.
o Tool definitions can be uploaded (selected one or all) from ROBOT.CON
file.
• Accuracy Definition — If accuracy definitions are not available on robot

instance, then values are loaded from machine data file (if such file is
available). When Restore values is clicked values are loaded form machine
data file (if such file is available) Simulation Settings / Synchronize RCS
should be run after manually changing an accuracy definition.
• Axis Load Definition — If axis load definitions are not available on robot
instance then values are loaded from machine data file (if such file is

available). Simulation Settings / Synchronize RCS should be run after
manually changing an axis load definition.
• Smooth Definition — If smoothness definitions are not available on robot

instance then values are loaded from machine data file (if such file is
manually changing a smooth definition.
• Acceleration Definition — If acceleration definitions are not available on

robot instance then values are loaded from machine data file (if such file is
manually changing an acceleration definition.
• Servo Gun Welding Conditions — If servo gun welding definitions are not
available on robot instance then values are loaded from machine data file (if
such file is available).
• Welding Sequences — Different dialog boxes are shown depending on if a

servo gun or pneumatic gun is mounted on the robot. Welding sequences
can be between 1 and 64.

• Simulation Settings — For this portion of the course, you only learn about
Synchronize RCS in the Simulation Settings dialog box:
o When clicked, axis loads, tool payloads, accuracy, acceleration and
smooth definitions, defined on the robot instance, are sent to the RCS
module.
o This command should be used whenever payloads or motion parameter

definitions are manually changed in Robot Setup, in order that the Nachi
RCS module is using the updated definitions. The Nachi RCS module is
storing those updated definitions in its RCS machine data files.
o It might be a good practice to use it once after loading a study to ensure

the definitions from Robot Setup are identical to the ones defined in the
RCS machine data files (a discrepancy may happen in case the study
was not saved after changing some data definitions and synchronizing
the RCS).

NC Code Robot Setup dialog box – continued
• Origin Definition (for machining, but not riveting) — used to setup origin
frames (which are like robot base frames). Origin frames can be named G54
through G59 with the “defined” keyword if the origin is already defined. Euler
angles are used for the orientation (phi, theta, psi).
o Creates a base frame named: <robot>.g53. For example myrobot.g53.
o Creates a user frames named <robot>.g53 through <robot>.g59. For

example myrobot.g54.

• Download Settings — there are various download settings such as circular
interpolation method, robot number, line numbering, program file extension,
coordinate mapping, and multi-file settings.
Tools must be defined using Robot Toolbox WorkTools (not as a robot frame)
using the naming convention Tool1 for tool number 1.

Panasonic Robot Setup dialog box — continued
• User Frame Definition — Create, edit, or delete user frames Frame numbers
are from 1 to 32. Coordinates are relative to robot WORLDFRAME. The

naming convention for user frames is<robot>.uf<frameNum>. Optionally, a
frame name can be associated using the frame number.
A user frame is only downloaded in the header section and cannot be
changed within a program. An error message will be reported in case more
than 1 User Frame is used in a robotic operation

Reis Robot Setup dialog box — continued
• Download Settings – Allows setting various settings for download including

language and the display of comments.
• Tool Definition
o Creates or edits tool frames named: <robot>.t_T<number>. For example
myrobot.t_T1.

o Only mounted tool configuration is supported.
o Tool Coordinates are relative to the robot ToolFrame
• User Frame Definition

o Creates or edits user frames named: <robot>.uf<number>. For example
myrobot.uf_1.
o Reis controller supports User Frames defined by name.
o There are two types of UserFrames: STATIC and DYNAMIC. The

dynamic option is available only for a robot with external axis. If the
dynamic type is selected, the created frame should be attached to the
selected external device’s last link
o User Frame Coordinates are relative to the robot World Frame

Staubli Robot Setup dialog box — continued
• Download Settings – several options for downloading such as simulation

commands. These values are stored in the user DownloadSettings.xml file
located in the .\eMPower\Olp\Robotics\Staubli-Val\Settings folder.
• Tools Definition — create, edit, and delete tool frames. The tool position is
relative to the robot TOOLFRAME.

o Creates or edits tool frames named: <robot>.ut<number>. For example
myrobot.ut_1.
• Frames Definition — create, edit, and delete user reference frames. The
frame position is relative to the WORLD (BASEFRAME).
o Creates or edits user frames named: <robot>.of<number>. For example
myrobot.of_1.

(ABB) Trallfa Robot Setup dialog box — continued
• Download Settings — Select the ROBOT_ID to select the system files and
set the binary file name of the downloaded file.
• Tcp Tool Definition

myrobot.t1.

o Update all or one tool from the robot.i01 MADA file.
• Disp Base Definition

o Creates or edits base frames named: <robot>.uf<number>. For example
myrobot.uf1.
o Update all or one disp from the robot.i01 MADA file.

Universal Robot Setup dialog box — continued
to the robot TOOLFRAME. The orientation is displayed in native Universal
Rotation Vector representation. The naming convention for robot tool frames
is <robot>.tf_<number>. For example myrobot.t1.

Yaskawa Robot Setup dialog box — continued
• UTool/UFrame Definition

o Creates or edits tool frames named: <robot>.tl<number>. For example
myrobot.tl1.
o Creates or edits user frames named: <robot>.user<number>. For

example myrobot.user1.
o UFrames have the same naming convention as in Robcad (frame

<robot>.user<num>)
• Robot and External Axes Setup — This option is available for robots with
an external axis defined.
• System Information — Allows entering or editing pulse (encoder) factors,

offsets, and order.
• Gun Definition — Allows associating a gun device with a gun file number.

Controller specific frames
Almost every controller needs a different frame created to represent the TCPF.
The TCPF information must exist in the scene and in the teach pendant. There
are several ways to define the TCPF:
• The frame can either be directly created in the scene and then the coordinates
read from the scene to the teach pendant.
• The TCPF can defined in the teach pendant which creates the frame in the
scene automatically.
• The information can be read from files output from the actual robot controller
(with many Process Simulate teach pendants).
o <Robot name>_.wf — robot world frame created automatically

when the RCS is initialized. It is the robot origin frame and is
typically at the intersection of J1 and J2. It’s not needed for
downloading.

o BASEFRAME — robot origin frame that is part of the robot’s
kinematic definition. It should match the <Robot name>_.wf.
o REFFRAME — part of the robot’s kinematic definition and is

related to the BASEFRAME. The Robot Setup dialog box is
used to define a special ESRC frame at the desired position) of
the reference frame. The positions of all downloaded locations
are according to the reference frame. The car part origin, or
somewhere on the tooling, are good places for this. Two stations
serviced by one robot may each have their own reference frame
or a moving line may have multiple reference frames.
o TCPF — frame that is part of the robot’s kinematic definition. The

Robot Setup dialog box is used to define a special ESRC frame
at the exact position of the TCP.
Here are example ESRC frames used in the activities:

ESRC user/object
ESRC base TCPF (name of
reference name
frame (for special ESRC
Robot (controller) example default (for example
frame attached
default is
is BASEFAME) to the TCPF)
REFFRAME)
Abb irb6600_wobj0_uf irb6600_tool1_tf
Cloos cloos_cls76swr.t1
Comau comau_sm_nh3_ comau_sm_nh3_ comau_sm_nh3
(C4G and C5G) 165_30.wf1 165_30.of1 _165_30.t1
Denso my_robot.w1 my_robot.t1
Duerr duerr_rp125160.bf_1duerr_rp125160.of_1duerr_rp125160.tf_1
Epson epson_c4_a901.lcs1epson_c4_a901.t1
fanuc_r2000ia fanuc_r2000ia
Fanuc _165f_if.uf1 _165f_if.ut1
IGM igm_330_1.w1 igm_330_1.t1
Kawasaki kawasaki_zzx300s.wk1awasaki_zzx300s.tl1
kuka_kr200l150 kuka_kr200l150 kuka_kr200l150
Kuka
.bf1 .b1 .t1
Nachi nachi_sra210_01a_fd.t

NC (machining) sim01_mill_3ax sim01_mill_3ax
_head.of_g53 _head.of_g54
NC (riveting)
Panasonic panasonic_tm_180 .puaf1 nasonic_tm_180 .t1
0 0 1
Reis reis_rv16_0699.uf0 reis_rv16_0699.uf_ 1reis_rv16_0699.t_
T
Staubli staubli_rx170.of_1 staubli_rx170.ut_1
(ABB) Trallfa trallfa_tr5003.bf trallfa_tr5003.uf1 trallfa_tr5003.t1
Universal universal_ur5.tf_1
this table as reference to perform theyaskawa_es200n
Yaskawa
Use activities. Note thatyaskawa_es200n
each robot 's
_a00.user1 Reference
settings and teach pendant have several differences. _a00.tl1
the online help
for setup, configuration and usage details of specific controllers.
It is the users’ responsibility to set these frames on the real robot (It is not
done automatically since two programs could use the same def file. The
tool definition could be added to program download template as well as
the home pose.

Activities
In the Robot controller specific frames and setup section, do the following activities:
• ABB — Tool and base data setup
• Cloos — Tool and base data setup
• Comau — Tool and base data setup
• Denso — Tool and base data setup
• Duerr — Tool and base data setup
• Epson — Tool and base data setup
• Fanuc — Tool and base data setup
• IGM — Tool and base data setup
• Kawasaki — Tool and base data setup


• Kuka — Tool and base data setup
• Nachi — Tool and base data setup
• NC — Tool and base data setup
• Panasonic — Tool and base data setup
• Reis — Tool and base data setup
• Staubli — Tool and base data setup
• Trallfa — Tool and base data setup
• Universal — Tool and base data setup
• Yaskawa — Tool and base data setup

Setting controller specific motion attributes
Purpose
In this topic, you learn how to set controller specific motion attributes.
Objectives
• Know the available methods to edit controller specific motion attributes.
• Edit controller specific attributes in the Path editor.
• Know the basic robot controller specific motion attributes.

Do I do this

Basic controller specific motion attributes
In this lesson, you look at setting up controller specific motion attributes required
for downloading. There are several ways to do this:
• In the Teach Pendant edit locations one at a time.
• In the Path Editor edit a single location.
• In the Teach Pendant or Path Editor simultaneously edit several locations.
• By applying a path template. (This is described in a lesson later in this

training).
Disclaimer: This lesson provides selected details for each specific teach pendant.
It should not be considered a replacement to the online help or other more
complete reference sources for these robot controllers or the robotic languages
themselves

ABB motion attributes
• Motion Type — Four choices including:

o MoveJ — use joint motion
oMoveL— use linear motion

oMoveC — use circular motion o
MoveABSJ Home
• Zone Data — Several choices:

oFine Point — like fine on the default controller
o z0 — like fine on the default controller

oz1 to z29 — like medium on the default controller o
z30 to z119 — like coarse on the default controller
o z120 and up — like no decel on the default controller


• Speed Data — Two ways to record speed:
o V (Tcp Speed) v5, v10, v20, etc., v7000, vmax
These definitions can come from your SYS file.
o T (Motion Time) measured in seconds
• Tool Data — ESRC TCP frame definitions
• Wobj Data — ESRC location reference frame definitions
These definitions can come from your SYS file.

Cloos motion attributes
• Motion Type — Three choices including:

o GP — use joint motion (only on via locations)
o GC— use linear motion
o ARC — use circular motion (full circle motion not supported)
• Zone — Several choices:

ofine — like fine on the default controller
ostv1 — like medium on the default controller o
stv5 — like course on the default controller
o stv10 — like no-decel on the default controller

osetdd10_20 — like no-decel on the default controller o
setdd50_50 — like no-decel on the default controller


All zones that can be used on the locations should be defined in the
MotionParameters.e file of the Cloos robot component with a special
naming:
o Joint Zones: stv<SmoothTransitionValue> For example:
■ zone_define stv1 rel_dist cartesian 25;
o Cartesian Zones: setdd<Dist1>_<Dist2> For example:

■ zone_define setdd10_20 rel_dist cartesian 65;
■ zone_define setdd50_50 rel_dist cartesian 65;
Although the exact MotionParameters.e zone name is internally

stored on the location, in the Teach Pendant and Path Editor, zone
information appears in Carola terms, for example:
o Zone stv10 maps to STV(10) on the controller.

o Zone setdd10_20 maps to SETDD(10,20) on the controller.
The available zones are filtered using the location motion type:
o For GP, only stv zones are available.
o For GC and ARC. only setdd zones are available.
STV(0) and SETDD(0,0) are mapped to the fine zone.
• Speed — Ways to record speed:

o For GP joint speed can range from 0.1 to 100
o For GC and ARC linear speed in mm/sec can range from 0.1 to 1000.
• Tool — ESRC TCP frame definitions

Comau motion attributes
• Motion Type – Several choices:

o Joint – use joint motion
o Joint POS : Home
o Linear – use linear motion
o Circular – use circular motion
• Term Type (Zone/Termination Type) – Three choices:

o Fine
o Course
o No Settle
• FlyType (Zone/Termination Type) – Several choices:

o Off – like fine on the default controller

oFor cart FlyParam (in mm) of Norm (in %): o
1 to 4 – like fine on the default controller
o6 to 29 – like medium on the default controller o
31 to 74 – like coarse on the default controller o
76 to 99 – like nodecel on the default controller
• Speed — After setting the Speed Control, you can enter the speed.
• Speed Control – Several choices:

o Const (in %) - Percent of max speed.
o Lin (in m/s)
o Rot (in rad/s)
• Tool Data — ESRC TCP frame definitions
• Frame Data — ESRC location reference frame definitions


Denso motion attributes

o MoveP — use point-to-point motion (joint motion).
o DriveA — use point-to-point motion (joint motion) and select a robot

pose.
o MoveL— use linear motion
o MoveC — use circular motion (full circle motion not supported)
• Zone — Enter the number (in mm) for the zone. This is how many mm away
the robot can stop near the target location and still have “arrived”.
o0 — uses no smoothing and is like fine on the default controller.
o1 to 30 — like medium on the default controller. o
31 to 120 — like course on the default controller.
o A value greater than 120 is like no-decel on the default controller.


No section is required in the motionparameters.e file for zones, since
the above mapping is automatic.
• Speed — Enter as a percent

Duerr motion attributes
• Motion Type
o PTP – use joint motion
o LIN – use linear motion
o CIRC – use circular motion
• Overlap (Zone)
These definitions can come from your TID file.
o FINE
o LOW
o MID
o COURSE

oNODEC50
oNODEC100 o
NODEC150 o
NODEC200
• Vel (Velocity or Speed)
These definitions can come from your TID file.
o V200
o V300
o etc.
o V1400
o V1500

• Object — ESRC location reference frame definitions

Epson motion attributes
• Motion Type – Three choices including:

o Go – use joint motion
oMove– use linear motion

oArc3 – use circular motion o
• Zone – Several choices:

o Fine (no param) – like fine on the default controller
o CP – like no decel on the default controller
• Speed
• Speed Type – Joint speed is recorded as a percentage of the max speed,

linear speed is recorded in mm/s, and rotational speed is recorded in deg/s.

• Tool — ESRC TCP frame definitions. Tool 0 is the robot TOOLFRAME.
• Local CS — ESRC location reference frame definitions. Coordinate system 0

is the robot World Frame.
• Config — You should enter these motionparameters.e config and turns

entries to properly record the configurations on the locations:
o config_family cf_over_head_pos;
o joint_config_family j3 joint_cf_elbow_up;
o joint_config_family j5 joint_cf_pos;
o default_turns j1 0 -90.0, j2 0 -180, j4 0 -180.0, j6 0 -180.0;

Fanuc motion attributes
• Motion Type – Three choices:

o Joint – use joint motion
o Linear – use linear motion
o Circular – use circular motion
• Def Type (Location type)

o Pose — Download location as joint values
o Cartesian — Download location as the XYZ values for the TCPF.

However for locations linked to robot poses, the Coord Type is forces
to Pose.
• Term Type (Zone/Termination Type) – Several choices:

o CNT0 to CNT10 (or Fine) – like fine on default controller
o CNT11 to CNT40 - like medium on default controller


o CNT41 to CNT80 - like course on default controller
o CNT81 to CNT100 (or CD) - like no decel on default controller
• Speed
• Speed Type – Two ways to record speed:

o Percent of max speed.
o Time measured in seconds.
• UTool — ESRC TCP frame definitions
• UFrame — ESRC location reference frame definitions

IGM motion attributes
• Motion Mode (Motion Type)

o Non-linear – uses joint motion with joint speed in % for jog (via)
locations.
o Linear – uses linear motion with Cartesian position speed for for jog (via)
or work (seam) locations.
o Circular – uses circular motion with Cartesian orientation speed for work
(seam) locations.
• Passpoint (Zone) — flyby in percent:

o 0–10 — fine (0 means no flyby)
o10–25 — medium o
25–45 — course
o 45–100 — no-decel

• Velocity (Speed in cm/min)
• Torch — ESRC TCP frame definition. This is set only once for the continuous
feature operation.
• WRK-Co — ESRC location reference frame (work object) definitions.
• Location type
o For via locations the Location type is set to Jog by default. By default,
Jog locations have a Non-Linear Motion Mode, a Velocity of 100%,
and you can set the Passpoint (zone).
o For seam locations the Location type is set to Work by default. By

default, Work locations have a Linear Motion Mode, Velocity in cm/min
must be set, and you cannot set the Passpoint (except on the first
location in a seam) since the default Passpoint is 0% (fine).
• Substation — This is set only once for the continuous feature operation. If it
is not set, you get an warning message during download.

• Library — This is set only once for the continuous feature operation. If it is
not set, you get an warning message during download. It is placed in the
initialization section of the downloaded program. It is the name of the library
step program to be referenced by this step program. All welding sequence
calls, such as the WSC function, are taken from this library by the real robot
controller. If it is left blank, no library reference is used.

Kawasaki motion attributes
• Move (Motion Type) – Two choices:

o AC_JOINT – use joint motion
o AC_LINEAR – use linear motion
• Acc/Accu (Accuracy/Zone) – Several choices:

o1 mm to 4 mm – like fine on default controller
o6 to 29 – like medium on default controller o
31 to 74 – like course on default controller
o 76 and up – like no decel on default controller
• Speed – One way to record speed:

o Index value – 0 through 9 (where 9 is 100%).


• Work — ESRC location reference frame definitions

Kuka motion attributes
• Motion (Motion type) – Four choices:

o Ptp – use joint motion
o Ptp axis : Home
o Lin – use linear motion
o Circ – use circular motion
• Zone – Several choices:

o C_PTP
■ 0 to 10 – like fine on default controller
■ 10 to 40 – like medium on default controller
■ 40 to 80 – like course on default controller
■ 80 to 100 – like no decel on default controller


o C_DIS
■ 0 to 2 – like fine on default controller
■ 2 to 7 – like medium on default controller
■ 7 to 15 – like course on default controller
■ Greater than 15 – like no decel on default controller
o C_VEL – like no decel on default controller
o C_ORI – like no decel on default controller
• Speed (Velocity) – One way to record speed:

o Joint Speed measured as a percentage
o Linear Speed measured in mm/sec.
• Tool Nr — ESRC TCP frame definitions


• Base Nr — ESRC location reference frame definitions

Nachi motion attributes
• Motion Type
o MOVE P – use joint motion
o MOVE L – use linear motion
o MOVE C – use circular motion
• Coord Type (Location type)

o Joints — Download location as joint values

However for locations linked to robot poses, the Coord Type is forces to
Joints.
• Accuracy (Zone)
o 1 (0 mm, 0 %) — similar to fine on the default controller. Downloaded
as ACCU1.

o 2 (5 mm, 5 %) to 4 (25 mm, 15 %) — similar to medium on the default
controller. Downloaded as ACCU2–ACCU4
o 5 (50 mm, 25 %) to 7 (200 mm, 75 %) — similar to course on the default

controller. Downloaded as ACCU5–ACCU7
o 8 (500 mm, 100 %) — similar to no nodecel on the default controller.

Downloaded as ACCU8
• Speed
• Speed Type
oJoint Speed — Sets the unit for Speed to %.
o Linear Speed — Sets the unit for Speed to mm/s.

oRotation Speed — Sets the unit for Speed to deg/s. o
Time — Sets the unit for Speed to sec.


• Stationary Tool — ESRC location reference frame definitions

NC motion attributes
• Interp (Motion type)

o G00 - PTP
o G01 - LIN
o G02/G03 - CIRC
■ G02 = CW circle
■ G03 = CCW circle
• Abs/Incr (Coordinate Mode)

o G90 – ABS coordinates are be downloaded as absolute values
o G91 - INCR coordinates are be downloaded as offset from the precedent

value
• Zone (must be defined in the robot’s MotionParameters.e file)


Zone name is selected from the list of allowed zones by reading the
MotionParameters.e file under the robot component directory. For example:
zone_define G93 no_smooth;

G92
G93
G194
Zone fine is downloaded as the first no_smooth zone in the list of available
zones
Otherwise the fine zone is downloaded as G09
• Feed — Integer speed in feed rate unit mm per min (available only on linear
locations) which ranges from 1 to 150,000.
• Tool — ESRC TCP frame definitions must be created by user as Robot

Toolbox work tools ( not as robot frame) with the naming convention Tool1
for tool number 1, Tool2 for tool number 2 ... Tool64 for tool number 64

• Origin — ESRC location reference frame definitions selected from defined
origins G292_1-G292_10 and default origin G53

Panasonic motion attributes
• Motion Type — Three choices including:

o MoveP — use point-to-point motion (joint motion).
o MoveL — use linear motion .
o MoveC — use circular motion (full circle motion not supported).
• Smooth — it is like zone on the default controller and can range between -1
and 9. These values are defined in the motionparameters.e file. For example,
a smooth value of 6 is defined in the file as zone z6.
o -1 — means to use the default smooth value of 4. The default smooth
value can be changed by the user changing the definition of the medium
zone in the motionparameters.e file.
o 0 (z0) — uses no smoothing and is like fine on the default controller.
o 4 (z4) — uses a Cartesian speed of 40 and is like medium on the default

controller.

o z7 has a Cartesian speed of 70 and is like course on the default controller,
but it not mapped to course when switching to the default controller.
o z9 has a Cartesian speed of 99.5 and is like no-decel on the default

controller, but it not mapped to no-decel when switching to the default
controller.
All other zones are defined as z<smooth value> in the

MotionParameters.e file of the Panasonic robot component.
• Cartesian zones: For example:

o zone_define fine no_smooth;
o zone_define medium speed cartesian 40.0 ;
o zone_define z0 no_smooth;
o zone_define z1 speed cartesian 10.0 ;

• Speed Type — Select the type of speed
• Speed — Enter the speed

Reis motion attributes
• Motion Type
o #PTP — use joint motion
o #CP_LIN — use linear motion
o #CP_CIRC — use circular motion
• FlyBy (Zone)
o #OFF — like fine on default controller (for all motion types)
o #ON — like nodecel on default controller for #PTP motion type. For
other motion types it uses the closest distance Cartesian zone defined
in the MotionParameters.e file.
medium speed cartesian 5.0;
zone_define
sp_zone1 speed cartesian 10.0;
zone_define
sp_zone2 speed cartesian 20.0;
zone_define

zone_define coarse speed cartesian 75.0;

zone_define nodecel speed cartesian 99.5;
zone_define nodecel speed joints 99.0 99.0 99.0 99.0 99.0 99.0;
fine
medium
sp_zone1
sp_zone2
sp_zone3
sp_zone4
sp_zone5
sp_zone6
course

nodecel
• Speed types:
oPTP Speed — speed for joint motion in %.
oCP Speed — speed for linear or circular motion in mm/sec. o
Tool — ESRC TCP frame definitions
o Frame — ESRC location reference frame definitions

Staubli motion attributes

o PTP — use joint motion
o LIN— use linear motion
o CIRC — use circular motion
• Coord Type (Location type)

o Joints — Download location as joint values

However for locations linked to robot poses, the Coord Type is forces to
Joints.
• Zone — Several choices:

o fine — like fine on the default controller
o zcl10r15 — like medium on the default controller


o zjl15r20 — like course on the default controller
o zcl20r30 — like no-decel on the default controller
All zones that can be used in the trajectories should be defined in

the MotionParameters.e file of the Staubli robot component with a
special naming convention: fine or z<Blend>l<Leave>r<reach>
For example:
fine: zone fine (Blend off)
zcl10r15: zone with Cartesian blend (flyby type), leave value of 10mm
and reach value of 15mm
zjl15r10: zone with Joint blend (flyby type), leave value of 15mm
and reach value of 10mm
Although the exact MotionParameters.e zone name are internally
stored on the location, in the Teach Pendant and Path Editor, zone
information appears in Staubli terms, for example:

zone_define zjl15r20 dist cartesian 17;
The zone name appears as:

fine
zcl10r15
zjl15r20
zcl20r30
Zone fine is downloaded as first no_smooth zone in the list of
available zones
• Ways to record speed:

oJoint Speed percent max speed o
Lin Speed measured in mm/s
o Rot Speed measured in deg/s


• User Frame — ESRC location reference frame definitions

(ABB) Trallfa motion attributes
• Motion Type
o RC — joint motion
o CC — linear motion
o CIRC — circular motion
• Interpolation Type — Zone

o Int0: Fine
o Int1: NoDecel
• Vel — Speed
• Tcp Nr. — ESRC TCP frame definitions
• Disp Nr. — ESRC location reference frame definitions


Universal motion attributes

o MoveJ — use joint motion (only on via locations)
o MoveL— use linear motion with an option blend. The default is no blend
(fine).
o MoveP — use linear motion with a mandatory blend.
o MoveC — use circular motion (full circle motion not supported)
• Blend — it is like zone on the default controller and can range between 0 and
1000. These values are defined in the motionparameters.e file. For example,
a blend value of 50 is defined in the file as zone z50.
o 0 (z0) — uses no blend and is like fine on the default controller.
o z50 has a Cartesian speed of 50 and is like medium on the default

controller.

o z500 has a Cartesian speed of 500 and is like course on the default
controller, but it not mapped to course when switching to the default
controller.
o z1000 has a Cartesian speed of 1000 and is like no-decel on the default
controller, but it not mapped to no-decel when switching to the default
controller.
All zones that can be used on the locations should be defined in

the MotionParameters.e file of the Denso robot component with a
special naming:
o Cartesian Zones: For example:
■ zone_define fine no_smooth;
■ zone_define z1 dist cartesian 1;

• Speed — Enter in degrees per second

Yaskawa motion attributes
There are some differences between XRC, NX, and DX versions of the Yaskawa
controller, such as supported robots. However, the motion attributes are the same:
• Motion Type
oMOVJ — move joint
o MOVL — move linear
o MOVC — move circular

oMOVC (start) — move circular start o
MOVS — move s
• Destination Type
o ABS, P1, P2, P3, etc.
• Fly Level (Level\Zone)

o Cont — like no decel on default controller

o PL=0 — like fine on default controller
o PL=1 — like medium on default controller
o PL=2 to PL=8 — like coarse on default controller
• Speed
• Speed Type Speed types:

o VJ — for joint motion type (a % of maximum speed)
o V — for linear or circular motion type (Cartesian position speed)
o VR — for linear or circular motion type (Cartesian orientation speed)
• User — ESRC location reference frame definitions

Activities
In the Setting controller specific motion attributes section, do the following

activities:
• ABB — Specific Teach Pendant motion attributes
• Cloos — Specific Teach Pendant motion attributes
• Comau — Specific Teach Pendant motion attributes
• Denso — Specific Teach Pendant motion attributes
• Duerr — Specific Teach Pendant motion attributes
• Epson — Specific Teach Pendant motion attributes
• Fanuc — Specific Teach Pendant motion attributes
• IGM — Specific Teach Pendant motion attributes
• Kawasaki — Specific Teach Pendant motion attributes


• Kuka — Specific Teach Pendant motion attributes
• Nachi — Specific Teach Pendant motion attributes
• NC — Specific Teach Pendant motion attributes
• Panasonic — Specific Teach Pendant motion attributes
• Reis — Specific Teach Pendant motion attributes
• Staubli — Specific Teach Pendant motion attributes
• (ABB) Trallfa — Specific Teach Pendant motion attributes
• Universall — Specific Teach Pendant motion attributes
• Yaskawa — Specific Teach Pendant motion attributes

Program creation
Purpose
In this topic, you learn how to create a program.
Objectives
• Create a robotic program in this system.

Business process

Program creation basics
You create a program for the default controller earlier in this training. You know
create a program for the robot specific controller and used for other portions of
this training.

Activities
In the Program creation section, do the following activities:

• Creating a robot program and using default signals (review)

Process simulation and robot configurations
Purpose
To learn more about robot configurations and how to view and modify them.
Objectives
• Robot configurations
• Teaching and clearing robot configurations
• Simulating robot paths

Business process

Robot configuration basics
Process or motion attributes are simulated in the same way as they would appear
on the factory floor.
The creation of robot configurations is critical to the download process, since they
store the robot configuration from the RCS and are tied to the robot BASEFRAME
(or user reference frame specified on the location). Whereas, global locations
are in reference to the working frame of the scene and do not store the robot
configuration.
To prepare for download, the process must be "taught". This step must be
performed in order to apply the configuration data to the locations.
There are multiple techniques to generate robot configurations (attributes on top
of the locations). All process attributes are preserved on the location, and all
configuration parameters (turns, flips) are stored as well.
The configuration can also be viewed on the Teach Pendant or Path Editor.
After teaching a solution, the robot uses it during subsequent simulations and
downloads.

Teaching and clearing robot configurations
To add robot configurations to locations, use one of these methods:

1. Method 1: Select a location, choose Robotics→Robot Configuration ,
select a configuration, and click Teach.
2. Method 2: Add the path to the Sequence Editor or Path Editor, click Auto
Teach , and then run the simulation as usual
When running Auto Teach from the Sequence Editor, you must
first select the robot, choose Robotics→Set Robots for Auto Teach
, and click OK.
To remove robot configurations from locations, use one of these methods:

1. Method 1: Select a location, choose Robotics→Robot Configuration ,
select a configuration, and click Clear.
2. Method 2: Select one or many locations, choose Robotics→Clear Teach

Location , and click OK. The Robotics→Clear Teach Location option

clears turns and solutions, causing simulations as well as downloads to use
the locations' initial, pre-taught values

Simulate robot paths
• Analyze path and cycle time
• Teach
o Configuration and turns
o Needed for download


Activities
In the Process simulation and robot configurations section, do the following

activities:
• Process Simulate and robot configurations

Summary

• Got an overview of OLP features.
• How to setup a basic robotic scene that you can use to learn about ESRC.
• How to select a controller and view the teach pendant.
• How to do some basic setup of a robot and robot controller.
• How to test a teach pendant and fix some setup problem.
• How to reset the RCS and decouple it.
• How to setup specific controller frames using the Teach Pendant and other
specific setup.
• How to set specific controllers motion attributes using the teach pendant.
• How to create a program.


• How to simulate a process and create configurations.

Lesson 4
Upload and download

Upload and download

Upload and download
Purpose
To describe how to upload and download.
Objectives
• How to select and create program templates for downloading.
• How to download a process.
• How to look at the files produced by the Download command.
• How to upload a process directly in Process Simulate.

Program templates for downloading
Purpose
In this topic, you get an overview of program templates used to format downloaded
files.
Objectives
• Edit program templates.
• Know how to select a program template.
• Know the template locations.
• Use example robot specific template keywords.
• Use example templates.

Business process

Program template basics
In this lesson you discuss program templates. The template defines the header
format including which keywords is included. It can describe some elements you
want in program (for example who generates/when/from which scene). Several
key words are provided (listed in the documentation).

Editing program templates
Usage:
1. Click the Robot Setup from the Controller tab of the Robot Properties
dialog box.
2. From the Robot Setup dialog box, click Program Templates Edition.

3. Edit the template by double-clicking on the file.
• Use this menu to edit the available program templates or to add/remove
program templates.
There are two levels of templates:

• Global templates — by default are stored in the C:\Program
Files\Tecnomatix\eMPowerRobotics\OLP\<Controller
Name>\Templates\Programs folder. However, this
can be changed by specifying a CustomizedPath
in the rrs.xml file for the version of the controller
used like the training course (for example
D:\users\student\student_files\OLP_config_files\<Controller
Name>\Templates\Programs).
• Private templates — stored in a ProcessSimulateRobotInfo

dataset associated to the robot occurrence in Teamcenter.

Program template selection
Usage:
1. Click the Robot Setup from the Controller tab of the Robot Properties
dialog box.
2. From the Robot Setup dialog box, click Program Template Selection.
3. Select the active program template.
4. Click Close.
If no specific templates are selected, the defaults shipped with the

software are used during download.

Template locations
The download file templates are located in specific folders depending on the
controller used:
• ABB
By default, located in C:\Program
Files\Tecnomatix\eMPower\Robotics\OLP\Abb-Rapid\Templates\
programs folder (unless the CustomizedPath is defined in the rrs.xml file).
o default.tprg — default template for a prog file (contains the main
program)
o default.tmod— default template for a mod file (contains a module of

the program)
• ABB (Volvo)
Files\Tecnomatix\eMPower\Robotics\OLP\Abb-Rapid-Volvo\Templates\.
programs folder (unless the CustomizedPath is defined in the rrs.xml file)
and is named either *.tmod, default.tmod or default.tpl.

• Cloos
Files\Tecnomatix\eMPower\Robotics\OLP\Cloos-Carola\Templates\
o default.ttxt — default template for a txt file (contains the program)
o default.tpkt — default template for a pkt file (contains the locations)
• Comau
Files\Tecnomatix\eMPower\Robotics\OLP\Comau-Pdl\Templates\
There are separate templates for C3G, C4G, and C5G versions of the
controller. There are also separate templates for applications such
as glue, spot, stud.
o default.tpdl — default template for a pdl file (contains the program)
o default.tlsv — default template for a lsv file


o default.tolp — default template for a olp file (contains the tool, frame,
and base definitions)
• Comau (Volvo)
Files\Tecnomatix\eMPower\Robotics\OLP\Comau-Pdl-Volvo \Templates\
programs folder (unless the CustomizedPath is defined in the rrs.xml
file) and is named either *.proc, *.tolp, *.tpl, *.tpdl, *.tlsv, default.tpdl, or
default.tlsv.
• Default
Files\Tecnomatix\eMPower\Robotics\OLP\Default\Templates\
o default.tpl — default template for a pl file (contains the program and
locations)
• Denso
Files\Tecnomatix\eMPower\Robotics\OLP\Denso-PacScript\Templates\

o default.tpcs — default template for a prog file (contains the program)
o default.tolp — default template for a olp file (contains the tool definitions)
• Duerr
Files\Tecnomatix\eMPower\Robotics\OLP\Duerr-Ecotalk\Templates\
There are different templates for the RPC and RC2 versions of the
controller.
o default.ttis — default template for a tis file (contains the program)
o default.ttid — default template for a tid file (contains the locations and
tool definitions)
• Epson

Files\Tecnomatix\eMPower\Robotics\OLP\Epson-Spel\Templates\
o default.tprg — default template for a prog file (contains the program)
o default.tpts — default template for a pts file (contains the locations)
• Fanuc
Files\Tecnomatix\eMPower\Robotics\OLP\Fanuc-Rj\Templates\
There are different templates for the applicatiosn such as arc and seal.
o default.tls — default template for a ls file (contains the program)
• IGM

Files\Tecnomatix\eMPower\Robotics\OLP\Igm-Ins\Templates\
o default.tipa — default template for a ipa file (contains the program and
locations)
• Kawasaki
Files\Tecnomatix\eMPower\Robotics\OLP\Kawasaki-As\Templates\
o default.tprg — default template for a prg file (contains the program)
o default.tolp — default template for a olp file (contains the tool, ftool,
and work definitions)
• Kuka

Files\Tecnomatix\eMPower\Robotics\OLP\Kuka-Krc\Templates\
odefault.tsrc — default template for a src file (contains the program)
odefault.tdat — default template for a dat file (contains the locations) o
default.tolp — default template for a olp file (contains the tool, base,
and load definitions)
• Kuka (Volvo)
Files\Tecnomatix\eMPower\Robotics\OLP\Kuka-Krc-Volvo \Templates\
programs folder (unless the CustomizedPath is defined in the rrs.xml file)
and is named either default.tpl, default.tdat, or default.tsrc.
• Nachi
Files\Tecnomatix\eMPower\Robotics\OLP\Nachi-Slim\Templates\

o default.tpl — default template for an A file (contains the program)
• NC Machining
Files\Tecnomatix\eMPower\Robotics\OLP\NC-Code\Templates\
o default.tsi — default template for a si file (contains the program)
o default.tolp — default template for a olp file (contains the tools used)
• NC Riveting
Files\Tecnomatix\eMPower\Robotics\OLP\NC-Code-Riveting\Templates\
o default.tA01 — default template for a A file (contains the program)
o default.tpro — default template for a pro file (contains the program with
a different header)

o default.tolp — default template for a olp file (contains the tools used)
• Panasonic
Files\Tecnomatix\eMPower\Robotics\OLP\APanasonic-Csr\Templates\
o default.tcsr — default template for a prog file (contains the program)
• Reis
Files\Tecnomatix\eMPower\Robotics\OLP\Reis-Robstar\Templates\
o default.tsrc — default template for a src file (contains the program)
• Staubli

Files\Tecnomatix\eMPower\Robotics\OLP\Staubli-Val\Templates\
odefault.tpjx — default template for a pjx file (contains the program)
odefault.tpgx — default template for a pgx file (contains the path) o
default.tdx — default template for a tdx file (contains the path)
• Trallfa (ABB)
Files\Tecnomatix\eMPower\Robotics\OLP\Trallfa-Robtalk\Templates\
o default.trt3 — default template for a rt3 file (contains the program)
o default.tpos — default template for a pos file (contains the locations)
• Universal

– By default, located in C:\Program
Files\Tecnomatix\eMPower\Robotics\OLP\Universal-URScript\Templates\
o default.tscript — default template for a x file (contains the program)
• Yaskawa
Files\Tecnomatix\eMPower\Robotics\OLP\Yaskawa-Inform\Templates\
o default.tjbi — default template for a jbi file (contains the main program)
o default.tpl — default template for a pl file (contains a sub program)
Template keywords
The sample templates shipped with the controllers are a reference for the
available keywords. Some keywords are common to all controllers (for example

<RobotName>), some are specific to the controller (these ones should be in the
sample templates). Here are the common keywords:
• Body
• Data
• Date
• FileBaseName
• ProgName
• Study
• TecnomatixSoftware
• TecnomatixControllerVersion
• Time
• RobotName

• UserName

Example robot specific template keywords
Additional ABB template keywords:

• Robtarget
• GundataTitle
• Gundata
• SpotdataTime
• Spotdata
• SpeeddataTitle
• Speeddata
• ZonedataTitle
• Zonedata

• TooldataTitle
• Tooldata
• LoaddataTitle
• Loaddata
• WobjdataTitle
• Wobjdata
• BeaddataTitle
• Beaddata
• WelddataTitle
• Welddata
• WeavedataTitle

• Weavedata
• CustomdataTitle
• Customdata
• MainBlockBody
• MoveBlockBody
• Robtarget
• JointTarget
Additional Comau template keywords:

• LocVar
• DataVar
• SchedulerCalls
• JointPosition

• CartPosition
• AllAxesNumber
• ExtAxesNumber
• JointMask
• ToolNumbers
• ToolNumbersRmt
• FrameNumbers
• FrameNumbersRmt
• ImplPayLoadMass
• ImplPayLoadCenter
• ImplinertiaX

• ImplinertiaY
• ImplinertiaZ
• ImplPayLoadMassRmt
• ImplPayLoadCenterRmt
• ImplinertiaXRmt
• ImplinertiaYRmt
• ImplinertiaZRmt
Additional Duerr template keywords:

• Velocitydata
• AccelerationData
• InterpolationData
• OverlapDclData

• GTriggerParData
• RampDclData
• JerkDclData
• BaseData
• ToolData
• ObjectData
• PointData
• TriggerPointData
• TriggerFrameData
Additional Epson template keywords:

• FirstExtAxis
• JointsNumber

• Points
• PointsNumber
• SecondExtAxis
• ThirdExtAxis
• Tools
Additional Fanuc template keywords:

• LineCount
• DefaultGroup
• ControlCode
• GunNumber
• MainBlockBody
• PosBlockBody

Additional IGM template keywords:
• StartStep
• WorkObjects
• Tool
Additional Kawasaki template keywords:

• Tool
• FTool
• Work
• Load
Additional Kuka template keywords:

• TecnomatixControllerVersion
• E6Pos

• E6Axis
• BaseData
• MovingBaseData
• ToolData
• LoadData
Additional Nachi template keywords:

• ToolDefinitions
• StationaryToolDefinitions
Aditional NC (machining)template keywords:

• Tools
• Origins
• FileName

• ProgramNumber
Additional NC Riveting template keywords:

• Tools
Additional Reis template keywords:

• Tools
• UserFrames
• ToolDefinitions
Additional Staubli template keywords:

• FileBaseName
• toolSection
• frameSection
• mdescSection

• jointSection
• jointSection
• programsSection
• databaseSection
Additional Trallfa template keywords:

• DispBase
• Tcp
Additional Yaskawa / Motoman template keywords:

• NPos
• Coords
• ProgComment
• Attr

• Group
• Main

Example download template use
In this Fanuc example a header and footer in the template with line number
is setup like this:
/MN
1:UFRAME_NUM = 1;
2:UTOOL_NUM = 1;
3:PAYLOAD[1];
4:! Start Program;
<MainBlockBody>
<FOOTER_LINE_N_1>:! End Program;
<FOOTER_LINE_N_2>:ABORT;
/POS
In order to have the following downloaded text:
/MN
1:UFRAME_NUM = 1;
2:UTOOL_NUM = 1;

3:PAYLOAD[1];
4:! Start Program;
5:J P[1:"lo1"] 100% FINE;
6:L P[2:"lo2"] 500mm/sec FINE SPOT[S=1];
7:L P[3:"lo3"] 500mm/sec FINE;
8:L P[4:"lo4"] 500mm/sec FINE;
10:J P[6:"lo6"] 100% FINE;
12:J P[8:"lo8"] 100% FINE;
13:J P[9:"lo9"] 100% FINE BACKUP=O;
14:L P[10:"lo10"] 100mm/sec FINE;
15:L P[11:"lo11"] 100mm/sec FINE;
16:L P[12:"lo12"] 500mm/sec FINE;
17:! End Program;
18:ABORT;
/POS

Activities
In the Program templates for downloading section, do the following activities:

• Creating a new program template
• Selecting a program template

Process download
Purpose
In this topic, you learn how to download a program.
Objectives
• Perform a basic download.

Business process

Download basics
To download a program, you must have ESRC robot configurations and

minimum motion attributes on each location in the path (program). This is
what was done in the previous activities in the training. To download to an
RRS-based controller, you also need to connect to the RCS.
Any process created in a Process Simulate application can be transformed into

a robot program by downloading it to a text file (robot program) in the robot
controller’s language. The robot programs include:
• Custom file layouts and content from templates
• Header
• Process attributes (per path or location)
• Motion attributes (for example tool, motion type, and zone/accuracy)
• Control statements (for example If, Then, and For)


• Logic statements (for example send signal and wait signal)
• Other statements that are part of the ESRC or added through XML
customization
Thus, the work put into process design is automatically reflected in fully-verified
robot programs. The generated programs may be further edited if desired, and
then downloaded to the actual robots on the factory floor.
To download:
1. Set the robot specific robot controller for the path. (Done in a previous activity
in this training).
2. Setup robot specific required TCP frames, reference frames, and base
frames. (Done in a previous activity in this training).
3. With the robot specific robot controller set, open the Teach Pendant or Path
Editor.
4. Make sure that you have specified the required attributes such as TCP frame,
motion type, and zone on the locations. (Done in a previous activity in this
training).

5. From the ribbon, choose Robot tab→Program group→ Robotic Program
Inventory .
6. From the Robotic Program Inventory, create a robot program and set it as the
default program for the robot. (Done in a previous activity in this training).
The program can contain one or several paths.
7. With the robot specific robot controller set, auto teach all locations to store
the robot configurations (solutions) on the locations. (Done in previous
activities in this training)
8. From the Robotic Program Inventory, and select the program from the list.

9. Start the download: From the Robot Program Inventory click Download
Program
10. Check the contents in the Download dialog box and store results.

Your Download dialog box may look different than this graphic, depending on
the robot language you use.
The previously selected template is automatically applied.

Downloaded files for each controller
Each controller has different files that are downloaded. these files a specific to
the real robot controller.
ABB Controller
• <prog>.prg contains the main program
• <prog>.mod contains a module of the program
Cloos Controller
• <prog>.txt contains the program (including the definition of the arc data
lists, main procedure, and local procedures). Main and local procedures are
modeled as robotic operationsIf you download only one robotic operation,
only a main procedure is generated. If you download a robotic program, the
operation named main (not case sensitive) becomes the main procedure,
and all others are local procedures.

• <prog>.pkt contains the coordinates and assigned number for each location.
Cloos robots use same RPY angles as Process Simulate. During download
and upload only encoder coordinates are supported.
• <prog>.olp contains the definition of the tools used.
Comau Controller
• <prog>.pdl contains the program
• <prog>.lsv
• <prog>.olp contains the tool, frame, and base definitions.
Default Controller
• <prog>.pl contains the program
Duerr Controller
• <prog>.tis contains the program
• <prog>.tid contains the locations and tool definitions


Epson Controller
• <prog>.prg contains the program, and paths, divided into several “function”
section. Robotic operations with locations are represent “functions with
motion instructions. Scheduler robotic operations are used to represent
“functions without motion instructions.
• <prog>.pts contains the coordinates of the locations
• <prog>.olp contains the definition of the used tools
Fanuc Controller
• <prog>.ls contains the program
IGM Controller
• <prog>.ipa contains the program (including the definitions of all locations)
Kawasaki Controller
• <prog>.prg contains the program

• <prog>.olp contains (in .AUX syntax) the current definitions of the TOOL,
FTOOL and WORK used in the program.
Kuka Controller
• <prog>.src contains the program
• <prog>.dat
• <prog>.olp contains the tool, base, and load definitions.
Nachi Controller
• <progName>-A.(progNumber) contains the program structure
• < progName>-P.(progNumber) optional file contains the positions defined

as “Storage type” = “Pose File”
• <progName>.(progNumber).olp contains the definition of the tool and

stationary tool used.
NC Maching Controller
• <progName>.si contains the program.

• <progName>.(progNumber).olp contains the definition of the tools used.
NC Riveting Controller
• <progName>.A(progNumber) contains the program.
• <progName>.pro contains the program with a different header.
Reis Controller
• <prog>.src contains the program.
• <prog>.olp contains the definition of the tools and UFiles used in the program.
Staubli Controller
• <prog>.pjx contains the program in XML format
• <prog>.pgx and <prog>.dtx contains the path in XML format. Each

downloaded operation produces separate .pgx and .dtx files.
• <prog>.olp contains the definition of the tools used in the program.


Trallfa Controller
• <prog>.rt3 contains the program structure
• <prog>.pos contains the location coordinates
• <prog>.off
• <prog>.olp contains the definition of the used TCP and DISP BASE
Yaskawa Controller
• <prog>.jbi contains the main program
• <prog>.pl contains a sbu program

Activities
In the Process Download section, do the following activities:

• Process Download

Examining output files
Purpose
In this topic, you examine the files output by the download of the program.
Objectives
• Look at the contents of some files downloaded from the system.

Output file basics
In this lesson you examine the files output from the download. The same
procedure could be used to examine files from the robot to be uploaded into
Process Simulate.

Downloaded files for each controller
Each controller has different files that are downloaded. these files a specific to
the real robot controller.
ABB Controller
• <prog>.prg contains the main program
• <prog>.mod contains a module of the program
Cloos Controller
• <prog>.txt contains the program (including the definition of the arc data
lists, main procedure, and local procedures). Main and local procedures are
modeled as robotic operationsIf you download only one robotic operation,
only a main procedure is generated. If you download a robotic program, the
operation named main (not case sensitive) becomes the main procedure,
and all others are local procedures.

• <prog>.pkt contains the coordinates and assigned number for each location.
Cloos robots use same RPY angles as Process Simulate. During download
and upload only encoder coordinates are supported.
Comau Controller
• <prog>.pdl contains the program
• <prog>.lsv
• <prog>.olp contains the tool, frame, and base definitions.
Default Controller
• <prog>.pl contains the program
Duerr Controller
• <prog>.tis contains the program
• <prog>.tid contains the locations and tool definitions


Epson Controller
• <prog>.prg contains the program, and paths, divided into several “function”
section. Robotic operations with locations are represent “functions with
motion instructions. Scheduler robotic operations are used to represent
“functions without motion instructions.
• <prog>.pts contains the coordinates of the locations
• <prog>.olp contains the definition of the used tools
Fanuc Controller
• <prog>.ls contains the program
IGM Controller
• <prog>.ipa contains the program (including the definitions of all locations)
Kawasaki Controller
• <prog>.prg contains the program

• <prog>.olp contains (in .AUX syntax) the current definitions of the TOOL,
FTOOL and WORK used in the program.
Kuka Controller
• <prog>.src contains the program
• <prog>.dat
• <prog>.olp contains the tool, base, and load definitions.
Nachi Controller
• <progName>-A.(progNumber) contains the program structure
• < progName>-P.(progNumber) optional file contains the positions defined

as “Storage type” = “Pose File”
• <progName>.(progNumber).olp contains the definition of the tool and

stationary tool used.
NC Maching Controller
• <progName>.si contains the program.

NC Riveting Controller
• <progName>.A(progNumber) contains the program.
• <progName>.pro contains the program with a different header.
Reis Controller
• <prog>.src contains the program.
• <prog>.olp contains the definition of the tools and UFiles used in the program.
Staubli Controller
• <prog>.pjx contains the program in XML format
• <prog>.pgx and <prog>.dtx contains the path in XML format. Each

downloaded operation produces separate .pgx and .dtx files.
• <prog>.olp contains the definition of the tools used in the program.


Trallfa Controller
• <prog>.rt3 contains the program structure
• <prog>.pos contains the location coordinates
• <prog>.off
• <prog>.olp contains the definition of the used TCP and DISP BASE
Yaskawa Controller
• <prog>.jbi contains the main program
• <prog>.pl contains a sbu program

Activities
In the Examining output files section, do the following activities:

• ABB — Examining a PRG file
• Cloos — Examining a PKT file
• Comau — Examining a PDL file
• Denso — Examining a file
• Duerr — Examining a TIS file
• Epson — Examining a PRG file
• Fanuc — Examining a LS file
• IGM — Examining a IPA file
• Kawasaki — Examining a PG file


• Kuka — Examining a SRC file
• Nachi — Examining a -A file
• NC — Examining a SI file
• Panasonic — Examining a file
• Reis — Examining a SRC file
• Trallfa — Examining a RT3 file
• Universal — Examining a PKT file
• Yaskawa — Examining a JBI file

Direct process upload
Purpose
In this topic, you learn how to upload a program into this system.
Objectives
• Upload a real robotic path into this system.
• Use Robot Operation Merge .

Upload basics
The Upload Program command receives information from a robot (in specific
controller syntax) and saves it as robotic operation and/or program.
Here is how (NOT an activity):
1. Select a robot from the Graphic Viewer.
A robot controller other than Default must be chosen.
2. From the ribbon, choose Robot tab→Program group→ Robotic Program

Inventory .
Do NOT select a program in the list.
3. From the Program Inventory dialog box, click Upload Programs .


This picture shows the file types for Fanuc-Rj. The file types shown
depend on the controller chosen.
4. In the Open dialog box, browse to the desired folder and select the
desired file. The available Files of type are specific to the chosen robot
controller.
5. Click Open.
For each file, Process Simulate runs the upload mechanism to read
the file and create a robotic operation and/or robotic program.

Overview of Robotic Operation Merge
The Robotic Operation Merge command, on the Robot tab of the ribbon, is
used to merge two robotic operations into a single operation. After merging the
source operation with the target operation, the updated target operation contains
the new set of information.
This is useful if, for example, you have used Download Program to load your
program on a shop-floor robot. You can then edit and fine-tune the program on
the robot itself and use Upload Program to store the updated program back to
Process Simulate. In order to make use of your shop-floor improvements, you
can merge the changes in the shop-floor program (the source) into your original
program (the target).

The Robotic Operation Merge dialog box enables you to manually select which
source locations to merge with which target locations. Alternatively, you can
perform an automatic merge of the entire source operation with the target
operation. The automatic merge may be performed either by merging source and
target locations sharing the same name or merging locations in close proximity.
You can also edit the order of locations in the target operation. Additionally, you
can specify which source data to merge with the target.

Robotic Operation Merge basics
1. From the ribbon, choose Robot tab→OLP group→Robotic Operation

Merge .
If you select an operation before picking Robotic Operation Merge

, this operation appears in Target Operation.
2. Click in Target operation and select the target operation in the Operation
Tree (or other relevant viewer). This is the operation you wish to update with
information from another operation.

Robotic Operation Merge can be performed on several operation
types including weld operations, seams, and continuous operations.
3. Click in Source operation and select the source operation in the Operation
Tree. This is the operation from which you wish to retrieve information.
4. Click OK. The Robotic Operation Merge dialog box appears displaying the
Target Operation as a tree together with its locations in blue text in the left
pane and the Source Operation tree together with its locations in red text
in the right pane.
5. Click Select Operations to replace the selected operations with a different

source and target operation.
6. Configure either manual or automatic matching, as follows: If you wish to

match locations manually, select a source location and a target location and
click Match .
7. If you wish to match source operations with target operations automatically,

click Automatic Match . The system matches up pairs of locations either

by name or by distance (depending on the criteria set in Robotic Operation
Merge Settings ) and displays them as matched pairs.
If you set manual matches before invoking automatic match, the

system retains your manual matches and matches all the other
locations automatically.
8. If necessary, click Erase Match to unmatch selected matched pairs. For

each matched pair, the source location is removed from Match, the distance

from Distance, Merge is cleared, and is removed from the source location
(unless this is still matched with another target location).
9. Click Execute. The system performs the merge and the Robotic Operation
Merge dialog box reloads the target operation.

Summary

• How to select and create program templates for downloading.
• How to download a process.
• How to look at the files produced by the Download command.
• How to upload a process directly in Process Simulate.

Lesson 5
ESRC OLP commands

ESRC OLP commands

ESRC OLP commands
Purpose
To describe how to use the OLP commands section of the emulated robot specific
controllers (ESRC).
Objectives
• How use the standard OLP commands of emulated robot specific controllers
(ESRC).
• Various commands supported in simulation on all controllers which must be

entered as free text.
• The list of the supported OLP commands for several of the robot controllers.
• Compared the various methods available in Process Simulate.

Standard OLP commands
Purpose
In this topic, you learn about the standard OLP commands.
Objectives
• Be aware of Basic OLP commands and be able to use some of them.

Business process

OLP command basics
Much of what is downloaded is stored on the locations in the path as OLP

commands. This is where logic statements are placed for download to the
program file. In this lesson, you learn all sorts of OLP commands which can be
used in Process Simulate. While some commands can only be simulated, others
can be simulated and downloaded.
Here are some examples of OLP commands:
• Boolean output signals could have a value of 0 or 1 (different syntax for each
controller described later)
• Analog output signals could have a value such as 5 or 1.4 (different syntax
for each controller described later)
• Macros
• Other commands
o payload
o pause, abort

osend Boolean signals o
send analog signals
owait delay or signal expressions o
register assignment
o call, if call
o if jump label (LBL)

Basic OLP commands
On the Teach Pendant after clicking Add, the Standard Commands menu is
available. These commands are available during simulation, but either do not
download or download as comments. They work the same as their default
controller equivalent.
Several examples of OLP commands were discussed in the TR43115
Process Simulate on Teamcenter Basic Robotic Simulation and TR43215
Process Simulate on Teamcenter Intermediate Robotics (CEE) courses.
The Standard Commands Menu:

Standard commands not mentioned here are described later in this course.
• File submenu:
o # OpenFile — Opens a file for editing. The Mode setting enables you to
Append or Overwrite file content. Also, set a Handle to be used in the
next WriteLine and CloseFile commands and a Name for the path to
the file to be opened.

o # CloseFile — Closes an open file. Set the Handle of the file that was
opened with the OpenFile command.
o # WriteLine — Enables you to write a line of text in an open file. Set the
Handle of the file that was opened with the OpenFile command and write
the text in the Expression box. Use double quotes to print the value of a
variable or a signal, for example, type "E1" to write the value of signal E1.
• Graphics submenu:
o # Blank — Blank an object during simulation.
o # Display — Display an object during simulation.
• Paint submenu: (Review from the TR43115 Process Simulate on Teamcenter

Basic Robotic Simulation course)
o # OpenPaintGun — Marks the location where painting should start.
o # ClosePaintGun — Marks the location where painting should stop.
o # ChangeBrush — Marks the location where the painting style should

be changed (for example paint fan 1, 2, 3, etc.)

• PartHandling submenu:
o # Attach — Attach a selected component to another component or
link during simulation.
o # Detach - Attach a selected component to another component or

link during simulation.
o # Grip — moves the gripper to the specified pose and attaches the part
to it. This OLP command is automatically added to grip locations in Pick
and Place Operations and is preferable to the Attach command for part
handling. (Review from the TR43215 Process Simulate on Teamcenter
Intermediate Robotics (CEE) course).
o # Release — moves the gripper to the specified pose and detaches

the part from it. This OLP command is automatically added to release
locations in Pick and Place Operations and is preferable to the Detach
command for part handling. (Review from the TR43215 Process
Simulate on Teamcenter Intermediate Robotics (CEE) course).
• ProgramFlow submenu:

o # Macro — executes the specified macro located in the <robot
controller>.macros file located in the Macros folder defined in
File→Options . The file can contain any OLP command for the
selected robot controller. (Review from the TR43215 Process Simulate
on Teamcenter Intermediate Robotics (CEE) course).
o # CallPath — in the middle of executing a path (for example pa1),

another path (for example pa2) can be executed. Once pa2 is finished, it
selects up where it left off in pa1. (Review from the TR43215 Process
Simulate on Teamcenter Intermediate Robotics (CEE) course).
o # CallProg — similar to CallPath, except for programs instead of paths.
• RobotCycleTime submenu:
o # CycleStart — specify when the cycle time calculation should begin.
o # CycleEnd — specify when the cycle time calculation should end.
o # TimerOn — Define when a user defined timer should start track time
associated to a certain part of the simulation. Each timer includes a
user-defined name.

Internal (built-in) timers include motion to location time, wait
device time, weld time, weld count, wait time, and wait signal time.
o # TimerOff — Define when a certain timer should be stopped during

a specific cycle.
• Synchronization submenu:
o # SendSignal — In line simulation mode, the robot sends a robot signal
to the PLC (PLC input). (Review from the TR43115 and TR43215
courses).
Both boolean and analog signals are supported. Any integer

value can be assigned to a signal. In event-based simulations the
Destination is always left blank.
o # SetSignal — Enables you to compose an expression for the value of

the selected robot output signal.

o # WaitSignal — In line simulation mode, the robot waits for a robot signal
from the PLC (PLC output). (Review from the TR43115 and TR43215
courses)
o # WaitTime — The robot waits the specified number of seconds before

the next command is performed.
• ToolHanding submenu:
o # Connect — (add an external axis to the robot during simulation)
connect the specified joint from the specified device as an external axis
of the robot. For example, when simulating a grinding robot with a tool
changer with several sized grinding tools.
o # Disconnect — (remove an external axis of the robot during simulation)

disconnect all external axis joints of the specified device from the robot.
For example, when simulating a grinding robot with a tool changer with
several sized grinding tools.
o # DriveDevice — Moves the selected device to the selected target pose.

(Review from the TR42115 course)

o # GunToState — Instructions for moving the gun to its specified pose, as
specified in the Gun State parameter. TR43115 Process Simulate on
Teamcenter Basic Robotic Simulation and TR43215 Process Simulate on
Teamcenter Intermediate Robotics (CEE) courses
In the case of a servo gun, this moves the servo gun to the
position specified by the external axis depart value. If no depart
value is defined, the servo gun moves using the Gun State
parameter.
o # Mount — Mount a new tool on the robot. For example, when

simulating a grinding robot with a tool changer with several sized grinding
tools.
o # UnMount — Unmount the existing tool on the robot. For example,

when simulating a grinding robot with a tool changer with several sized
grinding tools.
o # WaitDevice — The robot waits until the selected device reaches the
selected target pose. (Review from the TR42115 course). (Review from
the TR43115 course).

o # Drive Device Joints — Move the selected joint(s) of the selected
kinematic device to the specified joint value(s).

Activities
In the Standard OLP commands section, do the following activities:

• Looking at and using a basic OLP command

Free text standard commands
Purpose
In this topic, you learn how to enter standard commands as free text in the OLP
commands section of the controller teach pendant.
Objectives
• Have an ideas of some of the OLP commands that can be entered as
standard.
• Enter basic OLP commands as free text.

Business process

Free text basics
This lesson describes various commands supported in simulation on all controllers

which must be entered as free text.
Other simulation supported Default controller commands:
These commands can be entered as free text:
• ; <String> – Allows textual comments to be inserted into the OLP command
list.
• #DriveDeviceToValues <DeviceName> – Drive the specified joint of the

specified device.
• # DriveDeviceToValuesSync <DeviceName> – Like # DriveDeviceToValues

except, the device motion can be synchronized with the robot’s movement to
the next location in the path.
• # CallToolPath <opName> <toolName> - Calls the specified operation while

verifying that the assigned tool on this operation is the specified tool.

• # Note <message> - Displays the message in the Process Simulate error
window after the simulation is stopped including the location where it was
executed. Use double quotes to evaluate variables and signals
• Setting the value of signals and variables with expressions

o # SetSignal <signal> <expression> (or # SetSignal <signal> =
<expression> )
o # SetVariable <var> <expression>

OLP command conditions
The information referenced here is for the default controller. Each robot
controller supports these conditions and may support additional options as
well. For example the Fanuc controller Process Simulate also supports
Jump to label abilities.
Basic syntax
The following basic syntax is supported in the condition commands:
• Logic operators: AND, OR, NOT (case sensitive)
• Parentheses
• Robot signals (case sensitive)
• False
• Decimal and integer values
• Arithmetic operators: +, - , *, /

OLP commands are not case sensitive.
(default controller) If then else syntax

Use the #If command to make the execution of a command depend on the result
of a condition. If the condition returns true, the lines between Then and #Elseif
are executed. If the condition returns false, the #Elseif commands are executed,
otherwise it executes the #Else commands. If you do not need it, you can also
omit the #Else and #Elseif commands.
Most controllers support the IF statement natively, but each controller has
its own syntax for it that is described later in this training.
• # If <condition> Then
• # Elsif <condition> Then
• # Else
• # Endif
• For example:

o # If (a + b) > c Then
o # callPath pa1
o # Elsif a OR b Then
o # callPath pa2
o # Else
o # callPath pa3
o # Endif
Switch syntax
The #Switch command enables you to make easier and clearer choices when
presented with several possibilities. This way you do not have to use lengthy
if-then-elseif chains.
This is similar to the case statement in the C programming language.
• # Switch <expression>

• # Case <val1>, <val2>
• # Default
• # Endswitch
• For example:
o # Switch (a+b)
o # Case 1
o # callPath pa1
o # Case 2, 3
o # callPath pa2
o # Default
o # callPath pa3
o # Endswitch

For loop syntax
The #For loop passes over a range between a beginning and an end value using
the specified step size. The loop variable has to be of data type integer.
• # For <var> From <start> To <end> Step <step> Do
• # For <var> From <start> To <end> Do
• # Endfor
• For example:
o# For j From 1 To 10 Step 2 Do
o# callPath pa1 o
# callPath pa2 o
# Endfor
While loop syntax

The #While loop is executed as long as the condition is true.

If the condition never becomes false, it runs forever.
• # While <expression> Do
• # Endwhile
• For example:
o # While a < 100 Do
o # callPath pa1
o # Endwhile

Entering robot specific comments
(Robot) Controller Comments begin with

ABB-Rapid !# (exclamation mark and pound sign)
Cloos-Carola ! (exclamation mark)
Comau-Pdl - - (two minus signs)
Default // (two slashes)
Denso-PacScript ‘ (single quote/apostrophe)
Duerr-Ecotalk - - (two minus signs)
Epson-Spel ‘ (single quote/apostrophe)
Fanuc-Rj // (two slashes)
Igm-Ins # (pound sign)
Kawasaki-As ; (semi-colon)
Kuka-Krc ; (semi-colon)
Nachi-Slim ‘# (single quote/apostrophe and pound sign)
Nc-Code (machining) ( ) (comments within parenthesis)
Nc-Code-Rivieting ( ) (comments within parenthesis)
Panasonic-Csr / (one slash)
Reis-Robstar C # (the letter C and a pound sign)

Staubli-Val // (two slashes)
Trallfa-Robtalk ;@ (semi-colon and “at” sign)
Universal-URScript # (pound sign)
Yaskawa-Inform // (two slashes)

Activities
In the Free text standard commands section, do the following activities:

• Entering basic OLP commands as free text

Defining robot specific signals
Purpose
In this lesson, you learn the naming rules for creating robot signals for specific
robot controllers. If the signal is not named properly, Process Simulate ignores it.
Recall from the intermediate robotics training:

• A PLC output signal is connected to a robot input such as a digital input (DI).
• A PLC input signal is connected to a robot output such as a digital output (DO).
• In Process Simulate, you enter the signals from the perspective of the PLC,
so the robot waits for output signals (DI) and sends input signals (DO).
Objectives
After you complete this lesson, you should be able to:

• Creating robot signals for specific robot controllers.

Business process

ABB signal definition
Signal names for ABB must be strings. For example mysignal1 and do15 are
valid, but DI[15] is not valid.

Cloos signal definition
• Supported boolean input signals:

o IN<num> – for example IN1 is referenced in an OLP command as 1.
• Supported boolean output signals:

o OUT<num> – for example OUT2 is referenced in an OLP command as 2.

Comau signal definition
Signal names should be either $DOUT[n] or $DIN[n] for digital output or digital
input.
For example: $DOUT[2] and $DIN[1]
As always:
Robotic output signals are represented as PLC input signals.
Robotic input signals are represented as PLC output signals.

Denso signal definition
There are no special naming conventions for signals on this controller. The signal
name can be any string. For example MySignal.

Duerr signal definition
This section is to be determined.

Epson signal definition
For Epson OLP commands, signals can be referenced by a signal number such
as 5 or a signal name such as Sig15R.
Epson signal commands use three types of numeric signals:
• Boolean
• Byte
• Word
Signal numbers are mapped to Process Simulate signal names.
If the signal name is used in the command (and not the signal number), it
is used as is without being mapped.
In Process Simulate, signal numbers are mapped to signal name names like this:
• Boolean input signals are mapped to INB[<SignalNumber>]. For example
INB[1] for signal 1.

• Boolean output signals are mapped to OUTB[<SignalNumber>]. For
example OUTB[1] for signal 1.
• Byte input signals are mapped to IN[<SignalNumber>]. For example IN[1]

for signal 1.
• Byte output signals are mapped to OUT[<SignalNumber>]. For example

OUT[1] for signal 1.
• Word input signals are mapped to INW[<SignalNumber>]. For example

INW[1] for signal 1.
• Word output signals are mapped to OUTW[<SignalNumber>]. For example

OUTW[1] for signal 1.

Fanuc signal definition
Signal Name Limitations:

• Supported numeric input signals:
o AI – for example AI[1]
o GI
• Supported numeric output signals:

o AO – for example AO[1]
o GO

o DI – for example DI[1]
o RDI
o SDI

o UI

o DO – for example DO[1]
o RDO
o SDO
o UO

IGM signal definition
This section is to be determined.

Kawasaki signal definition
Signals are mapped like this:

• WX (wait signal) 1 or –1 is modeled as robot input signal in1 (PLC output
signal). A positive value means to wait for ON, whereas a negative value
means to wait for OFF
WX signals can only be negative if the robot setup Send type is set to
Keeping (default).
• OX (output signal) 2 or –2 is modeled as robot output signal out2 (PLC input

signal)
Robot output signal behavior setup

In Robcad, this information used to be stored in a .sy file. In Process Simulate, it
is stored on the robot instance. In the Robot Setup dialog box, there are some
simulation settings related to OX (output signal) simulation:

Send type (robot output signals = PLC input signals)
• Keeping — only set OX signals mentioned in the step to ON if positive or
OFF if negative (default). Both positive and negative values are allowed.
• Each Step — set OX signals mentioned in the step to ON, and all other
signals to OFF. Only positive values are allowed.
Send timing
• At Motion Start — send OX signals before moving to the location (default)
(PREOUT is set to ON)
• At Target Reached — send OX signals when the location is reached

(PREOUT is set to OFF)

Synchronization is implemented in this order:
• If OX Send timing is set to At Motion Start:
o Send lo1 OX signals
o Start moving to lo1
o When lo1 is reached:

■ Wait for lo1 WX signals
■ Wait for lo1 timer
• If OX Send timing is set to At Location Reached:

o Start moving to lo1
o When lo1 is reached:

■ Send lo1 OX signals
■ Wait for lo1 WX signals
■ Wait for lo1 timer


Kuka signal definition
In KRC fold, signal names are strings such as mysignal.

In Krl, signal names follow this format:$IN[1] and $OUT[1].

Nachi signal definition
Names used for signals are not allowed. Output signals start with a O and a
number, while input signals start with an I and number. For example
1. Output signal example: O54 (for Output 54)
2. Input signal example: I54 (for Input 54)

Panasonic signal definition
On the Panasonic controller, a signal can be referenced by its name,

number, or both. However, in Process Simulate, you must reference the
signal by either its name, such as o1#MySignal, or its number, such as o1#7.
In the examples in this training, you reference the signals by number.
• Supported input signals:

o i1#<num> – for Boolean input signals. For example i1#1
o i4#<num> – for 4-bit integer input signals. For example i4#1
o iH#<num> – for high-speed input signals. For example iH#1
• Supported output signals:

o o1#<num> – for Boolean input signals. . For example o1#1

o o4#<num> – for 4-bit integer input signals. . For example o4#1

Reis signal definition
For Reis OLP commands, signals can:

• Must be Boolean signals
• The signal corresponds to 1 bit of the byte
• Signal name must have a prefix:

o "i" for input signals
o "o" for output signals
o "m" for marker signals
• Signal name must follow this format:

o i5_<bit index in the byte>
Signal examples: i5_0, i5_1, i5_2, ... i5_7.

• Input signal name example: i5_0

• Output signal name example: o5_0

Trallfa signal definition
Input signals begin with the word INPUT and contain a number. Output signals
begin with the word OUTPUT and contain a number.
• Input signal name example: INPUT2
• Output signal name example: OUTPUT2

Universal signal definition

o DI[<num>] – standard digital input signal. For example DI[1]
o TI[<num>] – tool digital input signal. For example TI[1]
o AI[<num>] – tool analog input signal for example AI[1]

o DI[<num>] – standard digital input signal. For example DI[1]
o TI[<num>] – tool digital input signal. For example TI[1]
o AI[<num>] – tool analog input signal for example AI[1]

Yaskawa signal definition
Output signal names

•OT#(<Output number>) — For example OT#(12)
• OG#(<Output group number>)
• OGH#(<Output group number>)

•SOUT#(<Specific output number>)
Input signal names

• IN#(<Input number>) — For example IN#(12)
• IG#(<Input group number>)
• IGH#(<Input group number>)
• SIN#(<Specific input number>)


In order to use Yaskawa-Inform signal names (that include parentheses)
in default controller commands, a special syntax should be used. The
parentheses in the signal names should be replaced with "&op;" and
"&cl;". For example: IN#(12) should be entered as IN&op;12&cl; Here
is the result:
• # IF IN#&op;12&cl; THEN
• # SetVariable B000 IN#&op;12&cl;

Activities
In the Defining robot specific signals section, do the following activities:

• Defining robot specific signals

Sending and waiting for robot specific signals
Purpose
In this lesson, you learn to send/wait for signals using robot specific
(downloadable) terms.
Objectives
• Send and wait for signals using robot specific (downloadable) terms.

Business process

ABB: Sending and waiting for signals
These commands must be entered as free text or using a custom XML

(described later in this course).
• SetDO (with optional delay) use like SendSignal on the default controller.
Changes the value of a digital output signal. For example SetDO do15, 1;
• Set use like SendSignal on the default controller. Set a digital output signal.
For example Set gripper;
• Reset use like SendSignal on the default controller. Resets a digital output
signal to zero. For example Reset do15;
• SetAO / SetGO use like SendSignal on the default controller. Changes the
value of an analog output signal or a group signal. For example SetAO ao2,
5.5;

• WaitDI (with optional \MaxTime and \TimeFlag options) use like WaitSignal
on the default controller. Waits until a digital input signal is set. For example
WaitDI di4, 1;

Cloos: Sending and waiting for signals

• SET — Set a Boolean robot signal to true. For example

o SET(12), SET(8..12,16)
• RESET — Set a Boolean robot signal to false. For example

o RESET(12), RESET(8..12,16)
• WAITI — Wait for a Boolean robot signal expression. For example:

o WAITI (IN(4))
o WAITI (NOT IN(4))
o WAITI (IN(4) AND IN(6))
o WAITI (NOT IN(4)) OR (NOT IN(6))


Comau: Sending and waiting for signals

• $DOUT[n] := <boolean expression> — digital output (as well as $SDOUT

— system digital output and $FDOUT — functional digital output), works
like SendSignal
For example $DOUT[17] := TRUE
• $DIN — digital input.
• WAIT FOR <signal expression>, use like wait for signals

For example: WAIT FOR $DIN[1] = ON

Denso: Sending and waiting for signals

• <signal name> = <expression> — Set a signal to a value. For example, to

set MySignal to true or false:
o MySignal = 1
o MySignal = 0
• SET <signal>, <time>, <mode> — Set a Boolean robot signal to true. For
example:
o To set MySignal to true:
Set MySignal
o To set MySignal to true, wait 1000ms, then set MySignal to false:

Set MySignal, 1000

o To send a pulse signal with a delay of 1000 ms:
Set MySignal, 1000 <AnyAsyncMode>
• RESET <signal> — Set a Boolean robot signal to false. For example:

o To set MySignal to false:
Reset MySignal
• WAIT <signal expression> — Wait for an expression to become true. For

example
o To wait until MySignal is true:
Wait MySignal = ON
o Wait MySignal = ON, 300

Duerr: Sending and waiting for signals

• SET <Signal> <Low/High>, use like SendSignal on the default controller
• GET <Signal> <Low/High>
• RECEIVE <Signal> <Low/High>, use like WaitSignal on the default controller

Epson: Sending and waiting for signals

• On
o On <BoolOutSignalNb> sets an output signal to 1. For example On 9
o On <SignalName> sets an output signal to 1. For example On Sig15R
o On {<BoolOutSignalNb>|<SignalName>}, <Time> sets an output

signal to 1 during indicated time in seconds and reset it back. For
example On 5, 10
• Off
o Off <BoolOutSignalNb> sets an output signal to 0. For example Off 14
o Off <SignalName> sets an output signal to 0. For example Off IRB240w.

o Off {<BoolOutSignalNb>|<SignalName>}, <Time> sets an output
signal to 0 during indicated time in seconds and reset it back. For
example Off TotoSig, 5.
• Oport
o Oport(<BoolOutSignalNb>) returns output signal value. For example a
= Oport(5)
• Sw
o Sw(<BoolInSignalNb>) returns input signal value. For example If
Sw(5) Then Exit EndIf
• In
o In(<ByteInSignalNb>) returns input byte signal value. For example var1
= In(2)
• InW
o InW(<WordInSignalNb>) returns input word signal value. For example
wordN = InW(8)

• Out
o Out(<ByteOutSignalNb>) returns output byte signal value. For example
Print Out(0)
o Out <ByteOutSignalNb>, <SignalVal> sets output byte signal value.

For example Out(3), In(2)
• OutW
o OutW(<WordOutSignalNb>) returns output word signal value. For
example If OutW(3) = InW(5) Or InW(6) Then a=a+1 EndIf
o OutW <WordOutSignalNb >, <SignalVal> sets output word signal

value. For example OutW(3), InW(5)
• Wait
o Wait <Time> waits for the time in seconds. For example Wait 5
o Wait <Condition> wait for the condition to equal True. For example
Wait Sw(5) = On

o Wait <Condition>, <Time> wait for the condition to equal True and the
time in seconds. For example Wait InW(4) > 8, 10

Fanuc: Sending and waiting for signals

• <Boolean output signal>[<num> or <register>] = PULSE — pulse signals
• <Boolean output signal>[<num> or <register>] = PULSE, <duration> sec —

Pulse signals with explicit duration
• <Boolean output signal>[<num> or <register>] = <Boolean expression> —

Send Boolean signals
• <analog output signal>[<num> or <register>] = <arithmetic expression> —

Send analog signals
• WAIT <signals expression> — wait signals

IGM: Sending and waiting for signals

• DOUT
• AOUT
• WAIT
• PULSE

Kawasaki: Sending and waiting for signals
These Kawasaki I/O commands are supported:

• BITS <sigNum>, <range> = <val> Sets signals to be equal to the specified
value (up to 16 signals). For example:
o Set one signal value: BITS 23, 1 = 1 is mapped to SendSignal out23,
1 on the default controller.
o Set three signal values: BITS 23, 3 = 0 is mapped to SendSignal

out23,0 and SendSignal out24, 0 and SendSignal out25,0 on the default
controller.
• SWAIT <sig1>, <sig2>,… Suspends program execution until the specified

condition is set. For example:
o SWAIT 1 is mapped to Wait Signal in1 == TRUE on the default controller.
o SWAIT 2, 3 is mapped to Wait Signal (in2 == TRUE AND in3 == TRUE)

on the default controller.

o is mapped to Wait Signal (in1 == TRUE AND in4 ==
SWAIT 1,-4,-4
FALSE AND in5 == FALSE) on the default controller.
• TWAIT <delay> Delays program execute the specified number of seconds
• SIGNAL <sig1>, <sig2> Turns on/off external output signals (OX). For
example:
o SIGNAL 1,-2 is mapped to SendSignal out1,1 and SendSignal ou2,0 on
the default controller.

Kuka: Sending and waiting for signals

• OUT <num> '<signal_name>' STATE=<TRUE|FALSE> (CONT)

example: OUT 1 'mysignal' STATE=TRUE CONT
• PULSE <num> '<signal_name>' STATE=<TRUE|FALSE> (CONT)

TIME=<time> sec
o For example: PULSE 1 'mysignal' STATE=TRUE CONT TIME= 2.2 sec
• SYN OUT <num> '<signal_name>' STATE=<TRUE|FALSE> at

<START|END|PATH=<distance> mm> DELAY= <delay> ms
o For example: SYN OUT 2 'mysignal' STATE=FALSE at PATH=3 mm DELAY=
100 ms

• SYN PULSE <num> '<signal_name>' STATE=<TRUE|FALSE> at
<START|END|PATH=<distance> mm> TIME=<time> sec DELAY= <delay>
ms
o For example: SYN OUT 2 'mysignal' STATE=FALSE TIME= 3 sec AT END
DELAY= 100 ms
• WAIT FOR (NOT) ( <IN|OUT|CYCFLAG|TIMER|FLAG> <num>

'<signal_name' ) (CONT)
o For example: WAIT FOR NOT ( IN 1 'mysignal' ) CONT
o Move to format 5.4.33
• WAIT FOR (NOT) ((expr) <AND|OR...> (Expr) ... ) (CONT), as WaitSignal

$IN[<Num>] or $OUT[<Num>]
o Expr in Krl = WAIT FOR (NOT)
$<IN|OUT|CYCFLAG|TIMER|FLAG>[<Num>]
For example: WAIT FOR ( $IN[1] and $IN [2] )
o Move to format 5.4.33


KRC Fold commands:
• ($)OUT <Num> State = <TRUE|FALSE> (CONT) '<Signal Name>', use like
SendSignal OUT<Num>
o For example : OUT 3 State = TRUE 'signal 1'
o is simulated as SendSignal OUT3
• WAIT FOR (NOT) <IN|OUT|CYCFLAG|TIMER|FLAG> <Num>

'<SignalName>'
o For example: WAIT FOR (IN 2 'signal 2') and (not OUT 3 '')
o is simulated as WaitSignal $IN[2] True and OUT 3 false
• PULSE <Num> State = <TRUE|FALSE> Time = <Duration> sec (CONT)

'<SignalName>', as pulse signal OUT<Num>
o For example : PULSE 3 State = TRUE Time = 0.1 sec 'signal 3'
o is simulated asPulse Signal OUT 3 (set to value 1, then set to

value 0 after 0.1 sec)
KRL commands

• WAIT FOR <Signal> == TRUE/FALSE, used like WaitSignal from the default
controller
• (SET) <Signal> = <expression>, used like SendSignal from the default

controller (only if <Signal> is defined as a robot output signal)
• (SET) <Signal> = <expression>, used like SendSignal from the default

controller (only if <Signal> is defined as a robot output signal)
• PULSE(<signal>, TRUE/FALSE, <duration>)

Nachi: Sending and waiting for signals

Sending Signals
• SET - Output signal ON (FN32)
o For example: SET[O12]
• SETO - Consecutive output signal ON/OFF (FN100)

o For example: SETO [O1, O512, 1]
• SETM - Output signal ON/OFF (FN105)

o For example: SETM [O17, 1]
• RESET - Output signal OFF (FN34)

o For example: RESET [O12]
Waiting Signals

• WAIT - Input signal wait with timer (FN552)
o For example: WAIT [I7, 3.0, 7]
• WAITI - Input signal wait (positive logic) (FN525)

o For example: WAITI [I7]
• WAITJ - Input signal wait (negative logic) (FN526)

o For example: WAITJ [I7]
• WAITA(D)
o For example: WAITA[Group2, &B00000101, 60.0, 10] - Wait group input
(AND) with timer (FN553)
o For example: WAITAD[Group2, 63, 60.0, 10] - Wait group input BCD
(AND) with timer (FN558)
• WAITO(D)
o For example: WAITO[Group2, &B00000101, 60.0, 10] - Wait group input
(OR) with timer (FN554)

o For example: WAITOD[Group2, 63, 60.0, 10] - Wait group input BCD
(OR) with timer (FN559)
• WAITE(D)
o For example: WAITE[Group2, &B00000101, 60.0, 10] - Wait group input
with timer (FN555)
o For example: WAITED[Group2, 63, 60.0, 10] - Wait group input BCD
with timer (FN558)
Example for class:

• SETM O54,1
oSETM is a constant string
oO54 is the output to control (for example Output 54) o
1 or 0 for on or off
• WAITI I54
o WAITI is a constant string

o I54 is the input to wait for (for example Input 54)

Panasonic: Sending and waiting for signals

• OUT or OUT2, <output signal>, <value> — Set a robot signal to a value.

For example
o OUT, o1#4, 1
• PULSE <output Boolean signal>, <time>— Set a robot signal to a value for a
specified amount of time. For example
o PULSE, o1#4, 10
• IN or IN2 <variable>, <input signal>— Get signal value.
• WAIT_IP <input signal>, <value>, <time out> — Wait for a robot signal to
acquire a value within specified amount of time. For example
o wait for i1#5 to become true
WAIT_IP, i1#5, 1

o wait for i1#5 to become true with a 25 second timeout
WAIT_IP, i1#5, 1, 25

Reis: Sending and waiting for signals

• WRITE_BIT (MARKER, OUTPUT)

o For example:WRITE_BIT #MARKER,Level:1,Byte:17043,Bit_No:7
o Simulated as SendSignal m17043_71
• WAIT_BIT
o For example: WAIT_BIT
#MARKER,Level:1,Byte:17043,Bit_No:7,Max_Time[s]:2.00,Label:" "
o Simulated as WaitSignal m17043_7 1, with timeout 2 seconds
o Calls to a label at timeout are not simulated in the first step.

Trallfa: Sending and waiting for signals

• WAIT INPUTnum ON/OFF - as WaitSignal INPUT[num]
• OUTPUTnum ON/OFF - as SendSignal OUTPUT[num]

Universal: Sending and waiting for signals

• set_standard_digital_out(<num>, True/False) — Set a Boolean robot signal

to true. For example to set DO[4] to true:
o set_standard_digital_out(4, True)
• set_tool_digital_out(<num>, True/False) — Set a Boolean robot signal to

true. For example to set TO[4] to true:
o set_tool_digital_out(4, True)
• set_standard_analog_out(<num>, <real>) — Set a Boolean robot signal to

true. For example to set AO[4] to 6.5:
o set_standard_analog_out(4, 6.5)
• get_standard_digital_in(<num>) — get the value of a Boolean robot signal.

For example, for DI[5]:

o get_standard_digital_in(5)
• get_standard_digital_out(<num>) — get the value of a Boolean robot

signal. For example, for DO[5]:
o get_standard_digital_out(5)
• get_tool_digital_in(<num>) — get the value of a Boolean robot signal. For

example, for TI[5]:
o get_tool_digital_in(5)
• get_tool_digital_out(<num>) — get the value of a Boolean robot signal.

For example, for TO[5]:
o get_tool_digital_out(5)
• get_standard_analog_in(<num>) — get the value of a Boolean robot signal.

For example, for AI[5]:
o get_standard_analog_in(5)
• get_standard_analog_out(<num>) — get the value of a Boolean robot

signal. For example, for AO[5]:

o get_standard_analog_out(5)
Waiting for a signal with a Universal robot

The "get" instructions read the value of the signal and do not "wait" for the signal
to change its value. There is no wait signal instruction in URScript, instead you
must use a combination of a"get" instruction and a while loop. For example, to
want for DI[0] to become true:
while get_standard_digital_in(0) == False
sync()
end
Although the sync() instruction is not simulated in Process Simulate: you can add
it to a location and it is ignored. On the Universal controller, sync() uses up the
remaining physical time a thread has in the current frame.

Yaskawa: Sending and waiting for signals

Supported I/O Instructions:

• DOUT
• AOUT
• WAIT
• PULSE

Activities
In the Sending and Waiting for Robotic Specific Signals section, do the following
activities:
• Adding Digital Input and Digital Output OLP Commands to Locations

More controller specific OLP commands
Purpose
In this topic, you learn about more robotic specific commands supported by the
ESRC controllers beyond signals and send/wait commands.
Objectives
• Convert something designed for the default controller for a robot specific
controller.
• Describe more commands that are supported for the various controllers.
• Know some additional robot controller specific OLP commands for each
controller

Business process

Controller specific OLP command basics
The support in this area of ESRC is continuing to improve. However, one strength
of ESRC is that it gives you the power to extend the robot controller’s support of a
robot language using XML customization. This is described later.
For the latest list of supported robot specific commands, see the GTAC support
website (support.industrysoftware.automation.siemens.com/gtac.shtml). The
latest ESRC controllers and related documentation can be downloaded from the
updates area of the website.

Class discussion to put it all together
In the intermediate (CEE) robotics training, you created a main program for a
robot with OLP commands to follow one robotic path if part style 1 was detected in
the fixture and a different robotic path if part style 2 was detected. You created
this logic and simulation using the default controller. Which looked like this:
• # CycleStart
• # CallPath ROBOT R1 TO POUNCE
• # If selectStyle1 AND NOT selectStyle2 Then
• # CallPath ROBOT R1 WELD (STYLE 1)
• # EndIf
• # CallPath ROBOT R1 WELD (STYLE 2)
• # EndIf

• # CycleEnd
Although this logic works in Process Simulate simulations with any controller
selected, all # OLP commands are download as either comments or not placed
in the downloaded file at all.
Making the logic downloadable
Use what you have learned about robot specific signal naming, change the robot
signal so that it is compatible with your selected robot controller. For example for
some controllers, selectStyle1 is not a valid signal name.
If you are not sure of what is acceptable for the naming of a robot path, it should
be 8 or less characters and not contain spaces or special characters. So ROBOT
R1 WELD (STYLE 1) is probably not the best choice if you want to download it.
Use the descriptions in the following pages to replace the # default controller
commands with robotic specific commands for commands to be downloaded.
For example #IF, #CalPath, and #EndIf.
In some cases the # default commands do not have a robot specific equivalent,
since they Process Simulate simulation specific. For example #CycleStart and
#CycleEnd. (These commands are used to create an Excel simulation report).
See the reworked examples later in this lesson for farther explanation.

ABB-Rapid — Beyond signals and send/wait commands
Additional OLP Commands:

On the Teach Pendant after clicking Add, the following menu is available beyond
the basic OLP commands:
• Free Text
• GridLoad
• Line Tracking – WaitWobj, and DropWobj
• Paint – SetBrush, SetColor, EnableEquip, DisableEquip, and

UseBrushTab
AbbRapid Specifics:
• Baseware,Spotware, and Dispenseware are supported
Free text commands only supported in simulation:

• Any basic OLP command described earlier, including the following ones
which must be entered as free text:

Relative motion simulation commands
o # MoveRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>]
■ Move the robot with an offset expressed in location object frame
coordinates system.
■ The offset is relative to: RefLoc if the optional <RefLoc> parameter is

specified (RefLoc should be the name of a location inside the current
robotic operation), otherwise to the current location, or (if defined at
operation level), to the current robot TCPF
■ The optional rotational part of the offset are rotation angles in

degrees expressed in location object frame coordinate system
(rotations are performed one after the other in the rotating frame)
■ The current location motion type, speed, zone are used to move to
the offset position
o # MoveJRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same

as # MoveRelBase, except that motion type to the offset position is
forced to Joint

o # MoveLRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same
forced to Linear
o # MoveRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>]

■ Move the robot with an offset expressed in location self coordinates
system.

robotic operation), otherwise, to the current location, or (if defined at
operation level), to the current robot TCPF.

degrees expressed in reference location self coordinate system
the offset position.

o # MoveJRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same as
# MoveRelTool, except that motion type to the offset position is forced
toJoint
o # MoveLRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same

as # MoveRelTool, except that motion type to the offset position is
forced to linear.
Motion Parameters: By default, the current modal motion parameters

(speed, zone, tool, etc.) is used. It is also possible to define explicit motion
parameters with following syntax: # MoveRelBase <X> <Y> <Z> [Speed
Data = v500] [Zone Data = z100]. These explicit motion parameters is
inherited on any subsequent relative motions
Robot specific fee text commands supported in simulation and download:


• WaitUntil (with optional \MaxTime and \TimeFlag options) use like
WaitSignal on the default controller. Waits until a condition is met. For
example WaitUntil di4 = 1;
• WaitTime use like Delay on the default controller. Waits a given amount
of time. For example WaitTime 0.3;
• WaitWobj (with optional RelDist), both on tracking and non-tracking locations.

Wait for a work object on a conveyor. For example WaitWObj wobj_on_conv1;
• UseBrushTab as storing the current active Brush Table for further use in
Change Brush trigger simulation
• SetBrush as opening or closing the paint gun depending on the brush

number and the current active Brush Table
• ConfJ (configuration joint) / ConfL (configuration linear) — Specify whether

the robot’s configuration is to be controlled during joint or linear motion. If not,
the robot can sometimes use a different configuration than programmed. For
example ConfJ \Off; or ConfJ \ On;

• Singarea — Defines interpolation around singularities. For example Sing
\Wrist; (avoid singularity) or SingArea \Off; (stop at singularity)
• GripLoad — Defines the payload for a robot. For example GripLoad piece1;
• ActUnit / DeActUnit — Activates or deactivates a mechanical unit. For

example: ActUnit orbit_a;
• Assign a value (<var> := <constant or expression>;) For example: reg1 :=

5; or regt := reg2 — reg3;
• variable assignation from function call (<var> := <FunctionCall>).
• IF <condition> <action>; (compact if)
• IF <condition>THEN ... ELSEIF <condition> THEN ... ELSE ... ENDIF — If

the condition is met then perform some instructions. For example, IF reg1 >
5 THEN Set do1; ENDIF
• IF <FuntionCall> THEN ... ELSEIF <condition> THEN ... ELSE ... ENDIF

• WHILE <condition> DO ... ENDWHILE — Repeats the instructions as long
as the condition is true. For example WHILE reg1 < reg2 DO reg1 := reg1 +
1; ENDWHILE
• FOR <var> FROM <start> TO <end> [STEP <step>] DO ... ENDFOR —

Repeats a given number of times. For example FOR j FROM 1 TO 10 DO
routine1; ENDFOR
• TEST <var> ... CASE <val1>,<val2>: ... DEFAULT: ... ENDTEST —

depending on the value of an expression, do something. For example TEST
reg1 CASE 1,2,3: function1; ENDTEST
• TEST <FunctionCall> ... CASE <val1>,<val2>: ... DEFAULT: ... ENDTEST
• RETURN — Finishes execution of a routine. For example Return;
• RETURN <expression> — If the routine is a function, then the function value

is also returned. For example Return value1;
• EXIT / STOP use to terminate or stop the program execution. For example
EXIT; or Stop;

• GOTO <label> — Jump to someone in the program. For example GOTO sub1;
• SpeedData v_tcp assigment (<SpeedData>.v_tcp:=<expression>), use to

temporarily modify the tcp speed with the speed data
• Present(<ParamName>), automatically replaced by TRUE or FALSE

depending on whether the parameter <ParamName> was provided in the
function call
• DInput(<sigName>), GInput(<sigName>), AInput(<sigName>), used to

return the value of input signal <sigName>
• <Name>; simulated as, in priority order:

ocall to robot module procedure <Name>
o call to macro <Name>
o call to operation <Name>

ocall to operation <Robot><Name> o
call to operation <Robot>_<Name>


ocall to robotic program <Name>
ocall to robotic program <Robot><Name> o
call to robotic program <Robot>_<Name>
MOP simulation (RCS disconnected/decouple mode):

• If the RCS in simulation is disconnected, a MOP simulation replaces the
RRS based simulation.
• All commands supported in RRS simulation (see above) are also simulated in
a MOP simulation, except:
o ConfJ/ConfL
o SingArea
o GripLoad
o ActUnit/DeActUnit
• Motion parameters are mapped as follows:


o SpeedData→Cartesian Speed:
■ ...use SpeedData.VTcp
■ ...apply modal OverrideSpeed factor if any (from VelSet motion

property)
■ ...apply modal MaxSpeed parameter if any (from VelSet motion

property)
o ZoneData→ Zone:
■ ZoneData.FinePoint = true : fine
■ ...Otherwise use ZoneData.PathZoneTcp:
■ ...PathZoneTcp < 1 : fine
■ ...1 <= PathZoneTcp < 30 : medium
■ ...30 <= PathZoneTcp < 120 : coarse
■ ...PathZoneTcp >= 120 : nodecel


Class discussion continued for ABB
Here is one possible way to rework the default controller OLP commands for
this robot controller:
• # CycleStart
• Call r1pounce;
• If selectStyle1 AND NOT selectStyle2 Then
• Call r1style1;
• EndIf
• If selectStyle2 AND NOT selectStyle1 Then
• Call r1style1;
• EndIf
• # CycleEnd

In this example, the robot paths and robot signals need to be renamed in the
study to match what is shown in these OLP commands.

Cloos-Carola - Beyond signals and send/wait commands

• Free Text

• JUMP/LABEL For example:

o L002:
RESET(1)
JUMP L002
• CALL For example:

o CALL SYNC

• IF THEN ELSE For example:
o IF IN(1) THEN JUMP L002 ELSE JUMP L003
o IF IN(1)
BEGIN
SET(12)
RESET(13)
END
ELSE
BEGIN
SET(13)
RESET(12)
END
• Variable assignment. For example

o PKT:=1

Comau-Pdl — Beyond signals and send/wait commands

• Free Text

• DELAY <val>, use as a delay in ms

For example: DELAY 5
• $TIMER := <val>, use as a timer value memorization
• $<Var> := <val> or $ARM_DATA[<num>].<Var> := <val>, used for system

variable assignment

$ARM_DATA — robot arm data
o Special case for following recognized variables (handled as modal

motion parameters modification)
■ $ARM_ACC_OVR — arm acceleration override
■ $ARM_DEC_OVR — arm deceleration override
■ $ARM_OVR — arm override
■ $ARM_SPD_OVR — arm speed override
■ $EMT_STRESS (with e-Motion option)
■ $FLY_TYPE — type of fly motion
■ $FLY_PER — percentage of fly motion
■ $FLY_DIST — distance in fly motion
■ $FLY_TRAJ — type of control on Cartesian fly


■ $GEN_OVR — general override
■ $LIN_SPD — linear speed
■ $ORNT_TYPE — type of orientation
■ $PROG_ACC_OVR — program acceleration override
■ $PROG_DEC_OVR — program deceleration override
■ $PROG_SPD_OVR — program speed override
■ $ROT_SPD — rotational speed
■ $SPD_EMT (with e-Motion option)
■ $SPD_OPT — type of speed control
■ $TERM_TYPE — type of motion termination
• Other system variable assignments are sent as is to the RCS via

RcsModifyRcsData

• <var> := <expression>, use it like an assigned variable
For example: count := count +1
• <var> := <FunctionCall>
• WAIT FOR <signal expression> OR ($TIMER[i] > <val>) (as well >= <val>),
use it like a wait for signal with a time out (time out equal to val - current
timer memorized value)
$TIMER is the clock timer
• IF <condition>THEN ... ELSE ... ENDIF

For example:
IF $DI N[2] = OFF THEN
MOVE TO feeder
ELSE
MOVE TO discard
ENDIF

• IF <FunctionCall> THEN ... ELSE ... ENDIF
• WHILE <condition> DO ... ENDWHILE

For example:
WHILE counter < num_errors DO
couter := counter +1
ENDWHILE
• REPEAT ... UNTIL <condition>

For example:
REPEAT
UNTIL counter > 5
• FOR <var> :=<start> TO <end> [STEP <step>] DO ... ENDFOR

For example:
FOR test := 1 TO num_hoses DO

ENDFOR
• SELECT (<var>) OF ... CASE (<val1>, <val2>) : ... ELSE: ... ENDSELECT
For example:
SELECT tool_type OF
CASE (1):
$TOOL := utool_weld
style_weld
CASE (2):
$TOOL := utool_grip
style_grip
ELSE:
tool_error
ENDSELECT
• SELECT (<FunctionCall>) OF ... CASE (<val1>, <val2>): ... ELSE: ...

ENDSELECT
• GOTO label / label ::


For example: GOTO ex1
• RETURN — return program control from the current routine to the place
where it was called.
• RETURN <Expression> — return a value
• <Name>; simulated as, in priority order:

ocall to operation <Name>

ocall to operation <Robot><Name> o
call to operation <Robot>_<Name>
o call to robotic program <Name>


o System variables assignation
o Speed:
■ SpeedControl = SPD_NORM
◇ speed : joint speed in % and joint acceleration in %
■ SpeedControl = SPD_LIN
◇ speed : cartesian speed
o Zone
■ $FLY_TYPE = $FLY_OFF, : fine
■ 0 < fly param ($FLY_DIST or $FLY_PER) < 5 : fine


■ 5 < fly param ($FLY_DIST or $FLY_PER) < 30 : medium
■ 30 < fly param ($FLY_DIST or $FLY_PER) < 75 : coarse
■ 75 < fly param ($FLY_DIST or $FLY_PER) < 100 : nodecel
Class discussion continued for Comau

• # CycleStart
• Call r1pounce
• If $DOUT[10] AND NOT $DOUT[20] Then
• Call r1style1
• EndIf
• If $DOUT[20] AND NOT $DOUT[10]Then


• Call r1style1
• EndIf
• # CycleEnd

Denso-PacScript - Beyond signals and send/wait commands

• Free Text

• GOTO <label> — For example:

o L002:
...
GOTO L002
• JUMP <label> — For example:

o L002:

SET ...
JUMP L002
• CALL <proc> or RUN <task> — For example:

o CALL SYNC
• IF < > THEN < > ELSEIF or ELSE END IF — For example:
o IF MySignal THEN JUMP L002 ELSE JUMP L003 END IF
o IF MySignal1 THEN JUMP L002 ELSEIF MySignal2 JUMP L003 END IF
• SELECT CASE
• DELAY <time> — Wait for a certain amount of time to pass.
• Arithmetic functions:+, -, /, *, and Mod
• Logic functions:And, Not, Or and Xor

Duerr-EcoTalk — Beyond signals and send/wait commands

• Free Text

• GET_VARIANT(<VarianteName>), interpreted as the current value of the

VARIANT input signal .<VariantName>. (GET_VARIANTE is also accepted)
• GET_REPAIRTYPE(<RepairTypeName>), interpreted as the current value of

the REPAIRTYPE.<RepairTypeName> input signal
• Signals:
o RECEIVE_HANDLERPOS(<Part> <Handler> <State>)

■ IF GetSignal (out_<Handler>_pos) != <Part>*10 + State) THEN ;
Check if a signal is already in LB
■ WaitSignal out_ <Handler>_pos == <Part>*10 + State ; Wait for

a signal to set
■ ENDIF
o var = RECEIVE_HANDLERPOS(<Part> <Handler> <State>) —

Simulated by:
■ IF GetSignal(out_<Handler>_pos) == -1) THEN Var = FALSE ;
Handler inactive
■ ELSEIF GetSignal(out_<Handler>_pos) == <Part>*10 + State) THEN

Var = TRUE ; Check if a signal is already in a logic block
■ ELSE
■ WaitSignal out_<Handler>_pos == <Part>*10 + State ; Wait for a

signal to set
■ Var = TRUE

■ ENDIF
■ IF Handler == All THEN
■ IF GetSignal(out_h1_pos) == -1 AND GetSignal(out_h2_pos) ==

-1) AND … THEN Var = FALSE ; All handlers inactive
■ ELSEIF GetSignal(out_h1_pos) == <Part>*10 + State OR

GetSignal(out_h2_pos) == <Part>*10 + State OR … THEN ; Check
if a signal is already in LB
■ Var = TRUE ; A signal is set
■ ELSE
■ WaitSignal out_h1_pos == < Part >*10 + State OR out_h2_pos ==

< Part >*10 + State OR… ; Wait for a signal to set
■ Var = TRUE
■ ENDIF

o IF RECEIVE_HANDLERPOS(<Part> <Handler> <State>) [THEN] —
Simulated by:
■ tmpvar = RECEIVE_HANDLERPOS(<Part> <Handler> <State>)
■ IF tmpvar THEN ...
o SET_POSCODE(<Part> <State>) — Simulated by:

■ SendSignal(<Part>*10+<State>)
o SET_ORDER(<Part> <Handler> <State>) — Simulated by:

■ SendSignal(out_<Handler>_order, <Part>*10+<State>)
■ WaitTime(0.11)
■ SendSignal(out_<Handler>_order, 0)
o var = RECEIVE_ORDER(<Part>) — Simulated by:

■ SendSignal(out_<Handler>_order, <Part>*10+<State>)
■ WaitTime(0.11)

■ SendSignal(out_<Handler>_order, 0)
■ IF GetSignalValue(in_order) == 0 THEN ; Check if a signal is

already in a logic block
■ WaitSignal(in_order) != 0
■ GetSignalValue(in_order)
■ END_IF
• Conditional/Unconditional blocs:
In some cases there is different syntax for the EcoRC2 and EcoRPC
controllers:
o IF <cond> ... ELSEIF <cond> ... ELSE ... ENDIF
o WHILE <cond> .... ENDWHILE
WHILE <cond> DO ... END_WHILE
o REPEAT <Num> ... ENDREPEAT

LOOP <Num> DO ... END_LOOP

oDELAY <duration>
DELAY(<duration>)
oLABEL <Lab> o
GOTO <Lab>
o CALL "<name>"()
CALL <name>()
o RETURN
o <Var> = <Expression>
• CALL "<Name>"() or CALL <Name>(), simulated as (in priority order):

o call to operation <Name>
o call to operation <Robot><Name>


ocall to operation <Robot>_<Name> o
call to robotic program <Name>
• Line tracking specific commands

o WAIT_CONVEYOR(<pos>)
o WAIT_PAINTPOSITION(<pos>)
o TRACKING(<On|Off>)
• Unknown instructions — The unknown instructions are sent through the RCS
as an "instruction" command.
Following Ecotalk constants can be used in the simulation:
• Ecotalk Constants
o Low: 0

o High: 1
o HalfOpen: 1
o FullOpen: 2
o HalfClosed: 3
o Wait: 4
o FullClose: 5
o Delete: 6
o Finish: 7

• All commands supported in RRS simulation (see above) are also simulated
in a MOP simulation.

Class discussion continued for Duerr
• # CycleStart
• Call r1pounce;
• If selectStyle1 AND NOT selectStyle2
• Call r1style1;
• EndIf
• If selectStyle2 AND NOT selectStyle1
• Call r1style1;
• EndIf
• # CycleEnd


Epson — Beyond signals

• Free Text

Program control simulation commands (syntax is not case sensitive). Variables

assignment:
• Boolean <VarName>
<VarName> = {True|False}
• Integer <VarName>
<VarName> = <value>

• String <VarName>
<VarName> = <value>

Fanuc-RJ — Beyond signals and send/wait commands

• Free Text
• Motion menu
o UFRAME_NUM
o UTOOL_NUM
o PAYLOAD
o JOINT_MAX_SPEED
o LINEAR_MAX_SPEED
o JOINT_MAX_SPEED_REG

o LINEAR_MAX_SPEED_REG
• Branch menu
o LABEL
o JUMP_LABEL
• I/O menu
o PULSE
o Wait Signals
o Digital Output
o Robot Digital Output
o User Digital Output
o System Digital Output
o Group Signal Output


o Analog Signal Output
• Conditions menu
o Skip Condition
• Control menu
o UALM
o PAUSE
o ABORT
o WAIT
o TIMER
• Arc menu
o Weave Start
o Weave End

o Track TAST
o Track End
• MESSAGE
• REMARK
• RSR ENABLE
• RSR DISABLE
• Register Assignment

Commands interpreted at location:

• PAYLOAD [<num>] — payload

• PAUSE as simulation stop
• ABORT as simulation stop
• WAIT <delay> sec — wait time
Commands interpreted during pre-calculation (3 locations ahead [RCS 6.x] or 4

locations ahead [RCS 7.x]) :
•
• CALL <prog>, simulated in priority order as :

o call to macro <prog>
ocall to operation <Name>

ocall to operation <Robot><prog> o
call to operation <Robot>_<prog>
o call to robotic program <prog>


o call to robotic program <Robot><prog>
o call to robotic program <Robot>_<prog>
• CALL <prog>(<param1>, ..,<paramN>), simulated as a call to Robot Module

<prog>.
• END as a return to calling program
• IF <Boolean expression>, CALL <prog> — conditional call
• LVC Olp commands

o LVC START — enable Learning Vibration Control
o LVC END — disable Learning Vibration Control
Commands that forces a No Advance / Full Arrival motion:

• JMP LBL [<num>:<comment>] — Jump
• IF <Boolean expression>, JMP LBL [<num>:<comment>] — Conditional

Restricted Jump
© Siemens AG 2018

Limitations:
• L P[2]
• LBL[1]
• WAIT 0.1(sec)
• IF RDI[1] = ON, JMP LBL[1]
• L P[3]
• L P[4]
• L P[5]


o Payload

o Cartesian Speed / Joint speed : direct mapping
o TermType→Zone :
■ FINE : fine
■ CNT81-CNT100 : nodecel
■ CNT41-CNT80 : coarse
■ CNT11-CNT40 : medium
■ CNT0-CN10 : fine
■ CD : nodecel
Class discussion continued for Fanuc


• # CycleStart
• Call r1pounce;
• If DO[10] = ON AND NOT DO[20] = ON,
• Call r1style1;
• If DO[20] = ON AND NOT DO[10] = ON,
• Call r1style1;
• # CycleEnd

IGM-Ins — Beyond signals and send/wait commands

• Free Text

coordinates system.


the offset position

forced to Joint

forced to Linear

system.




toJoint

forced to linear.

parameters with following (controller specific) syntax: # MoveRelBase <X>
<Y> <Z> [Speed Data = v500] [Zone Data = z100]. These explicit motion
parameters is inherited on any subsequent relative motions.

• Supported operating Instructions

o SET
o CLEAR
o INC
o DEC
o ADD/SUB

o MUL/DIV
o AND/OR/NOT/XOR
Class discussion continued IGM

(A reworked version is not currently provided with this training)
• # CycleStart
• # Callpath r1pounce;
• # Callpath r1style1;
• #EndIf

• # EndIf
• # CycleEnd

Kawasaki-As — Beyond signals and send/wait commands

• Free Text
coordinates system.


the offset position

forced to Joint

forced to Linear

system.




toJoint

forced to linear.

(speed, zone, tool, etc..) is used. It is also possible to define explicit motion
<Y> <Z> [Speed = 2] [Accu = 4]. These explicit motion parameters is
inherited on any subsequent relative motions.

o payload

o Speed value in % is converted to mm/s (via cart_max_lin_speed entry
in MotionParameters.e) for linear motions
• Accuracy:

o If ACCU<i> zone is defined in the MotionParameters.e file, this actual
zone is used
o Otherwise conversion from accuracy value (in mm) to default zones is

as follows:
o 0 < val < 5: fine

o5 < val < 30: medium o
30 < val < 75: coarse o
75 < val: nodecel
Class discussion continued for Kawasaki

• # CycleStart

• #EndIf
• # EndIf
• # CycleEnd

Kuka-Krc — Beyond signals and send/wait commands

• Free Text
• Gripper – Check Grp and Set Grp
• I/O – Wait Time, Out, Pulse, Syn Out, Syn Pulse, Wait For signal, and Wait
For Expr.
• Misc – KRC (Fold) Comment and KRL Comment
Kuka Krc Specifics:

• Only Basis and Spot motions are supported.

In addition to the KRC Fold commands supported in simulation (see below), the
following additional KRC Fold commands are also supported in download:
• data> <time> NAME:<name> CHANGES: <changes>
• ANOUT OFF CHANNEL_<channel>=<value>
• ANOUT OFF CHANNEL_<channel>
• ANOUT ON CHANNEL_<channel>=<factor> * TECHVAL[<no>] OFFSET =

<offset> DELAY=<delay> [sec]
• ANOUT ON CHANNEL_<channel>=<factor> * VEL_ACT OFFSET = <offset>

DELAY=<delay> [sec]
• CHECK GRP <num> STATE= <OPN|CLO> at <START|END> DELAY=

<Delay> ms
For example: CHECK GRP 1 STATE =OPN at END DELAY = 5 ms

• <START|END> CONST_VEL PATH=<path> mm
• IBUS OFF
• INIT.GUN<gun_num>
For example: INIT.GUN1
• PROGRAM.GUN <gun_num> PRG = <prog> PART = <move> mm FORCE =

<pressure> daN
o For example: PROGRAM.GUN 1 PRG=2 PART = 3mm FORCE = 10 daN
• STOP WHEN PATH=mm (ONSTART) CONDITION
• SET GRP <num> STATE= <OPN|CLO> (CONT) at <START|END> DELAY=

<Delay> ms
o For example: SET GRP 1 STATE =OPN at START DELAY = 5 ms
• SET GRP <Number> STATE= <OPN|CLO>

o For example: SET GRP 2 STATE =CLO

• TRIGGER WHEN PATH=<path> mm (ONSTART) DELAY=<delay> ms DO
PULSE <no> '<signal_name>' STATE=<TRUE|FALSE> TIME=<time> sec
• TRIGGER WHEN PATH=<path> mm (ONSTART) DELAY=<delay> ms DO

OUT <no> '<signal_name>' STATE=<TRUE|FALSE>
KRC Fold commands:

• WAIT Time = <Time> sec, as delay
o For .example : WAIT Time = 3 sec
• ANOUT CHANNEL_<Num> = <Value>, used like SendSignal

$ANOUT[<Num>]
o For example: ANOUT CHANNEL_1 = 0.1
o is simulated as SendSignal $ANOUT[1] 0.1
• SET GRP <num> STATE= <OPN|CLO> CONT

o For example: SET GRP 1 STATE =OPN CONT at START DELAY = 5 ms
o is simulated as call to H50(GRP_APO, <num>, <STATE>, GCONT)


• SET GRP <Number> STATE= <OPN|CLO>
o For example: SET GRP 2 STATE =CLO
o is simulated ascall to H50(GRP, <num>, <STATE>, GCONT), with

<STATE> = 1 for OPN and 2 for CLO
• CHECK GRP <num> STATE= <OPN|CLO> at <START|END> DELAY=

<Delay> ms
o For example: CHECK GRP 1 STATE =OPN at END DELAY = 5 ms
o is simulated as a delay and then a call to H50(CHK_APO_UP, <num>,

<STATE>, GCONT), with <STATE> = 1 for OPN and 2 for CLO
KRL commands
• assignation of following special system variables (as RRS motion parameters
change):
o $VEL.CP
o $VEL.ORI1
o $VEL.ORI2

o $ACC.CP
o $ACC.ORI1
o $ACC.ORI2
• $ECO_LEVEL = [#OFF, #LOW, #MEDIUM, #HIGH] (a special RRS Energy

service and is only active with the KUKA RCS versions 8.3 or higher)
• $CYCFLAG[num] = <Any Signal Expression>, an alias variable assignment

(storing the expression instead of the expression value)
• <var> = <Any Signal Expression>, used like either SendSignal from the
default controler (if <var> is defined as a robot output signal) or as a variable
assignment.
• IF <condition>THEN ... ELSE ... ENDIF
• IF <FunctionCall> THEN ... ELSE ... ENDIF
• WHILE <condition> ... ENDWHILE


• REPEAT ... UNTIL <condition>
• LOOP....ENDLOOP
• FOR <var> = <start> TO <end> [STEP <step>] ... ENDFOR
• SWTCH <var> ... CASE <val1>,<val2>: ... DEFAULT: ... ENDSWITCH
• SWITCH <FunctionCall> ... CASE <val1>,<val2> ... DEFAULT ...

ENDSWITCH
• WAIT SEC <Time>, as a delay
• WAIT FOR <expression>

o For example: WAIT FOR $IN[1] OR NOT $IN[2], as WaitSignals
• HALT to exit program
• EXIT to exit from a loop
• GOTO <label> jump to label. ( jump from outside into a loop instruction bloc
is forbidden )

•<label>: destination of a goto instruction
• RETURN
• RETURN <Expression>
•Varstate("<varName>")
Priority order:
• [Name](), simulated as:
ocall to macro [Name]
o call to operation [Name]

ocall to operation [Robot][Name] o
call to operation [Robot]_[Name]
o call to robotic program [Name]
o call to robotic program [Robot][Name]


o call to robotic program [Robot]_[Name]

o System variables assignment (like $ACC.ORI1, etc.)

o Cartesian Speed / Joint speed : direct mapping
• Zone:
o FINE→fine
• C_PTP
o 0-10 : fine
o 10-40 : medium

o 40-80 : coarse
o 80-100 : nodecel
• C_DIS
o0-2 : fine
o2-7 : medium o
7-15 : coarse o
> 15 : nodecel
• C_VEL→nodecel
• C_ORI→nodecel
Energy Simulation:
Starting from Kuka RCS 8.3, the RRS simulation of energy consumption is
supported in Process Simulate.

In order to get energy consumption information during simulation, it is necessary
that the machine data are created with KUKA.WorkVisual so that they contain the
energy capacity values (see the Kuka RCS documentation for more information).
It is possible to save energy at the expense of cycle time by using the Kuka
system variable $ECO_LEVEL, with possible values #OFF, #LOW, #MIDDLE and
#HIGH. Changing the $ECO_LEVEL does not affect the trajectory but optimizes
velocities and accelerations. $ECO_LEVEL has no influence on LIN or CIRC
motions, it only affects PTP and SPLINE motions.
Energy consumption during the motion execution is generally made of 2 parts:
1. Moving the payload against the inertia
2. Holding the payload against gravity
Reduction of acceleration and speed means less energy consumption for 1),
but, as it creates larger cycle-times, it means more energy consumption for 2).
Therefore a higher $ECO_LEVEL does not always imply a reduction of the overall
consumed energy. It is therefore advised to increase the $ECO_LEVEL step by
step to get optimized results.
When simulation is reset, energy saving mode ($ECO_LEVEL) is automatically
deactivated.

Class discussion continued
• # CycleStart
• Call r1pounce;
• If $OUT[10] AND NOT $OUT[20] Then
• Call r1style1;
• EndIf
• If $OUT[20] AND NOT $OUT[10] Then
• Call r1style1;
• EndIf
• # CycleEnd


Nachi-Slim — Beyond signals and send/wait commands

• Free Text

coordinates system.


the offset position

forced to Joint

forced to Linear

system.




toJoint

forced to linear.


• Constants
• Integer variables
o V1% = 10
o V%[1] = 10
o V2%=V1%+1
• Real variables

o V1!=2.5
o V![1]=2.5
o V2!=V1!*103.45
• String variables
o V1$="Execution state"
o V$[1]="Execution state"
• DELAY <time>
• Simple sentence IF
o IF <condition>THEN *<label name>
o IF <condition>THEN *<label name> ELSE *<label name>
• Compound sentence IF
o IF <condition> THEN

o[ELSEIF <condition> THEN] o
[ELSE]
o ENDIF
• SWITCH command
o SWITCH
o CASE
o BREAK
o CASE
o BREAK
o ENDS
• WHILE command
Restricted o
© SiemensWHILE
AG 2018 <condition>
o ENDW
• FOR command
o FOR <VAR=init val.> TO <end value> STEP <incr>
o NEXT
o STOP
o END
Class discussion continued for Nachi

• # CycleStart
• Call r1pounce
• If O10 AND NOT O20 Then
• Call r1style1

• EndIf
• If O20 AND NOT O10 Then
• Call r1style1
• EndIf
• # CycleEnd

NC-Code — Beyond signals and send/wait commands

• Free Text
Class discussion continued for NC

• # CycleStart

• #EndIf
• # EndIf
• # CycleEnd

Panasonic-Csr - Beyond signals and send/wait commands

• Free Text

• SET, <variable>, <value>— Set a robot signal to a value. For example

o SET, o1#4, 1
• CLEAR, <variable> — Set a robot signal to 0. For example

o CLEAR, o1#4
o All LL variables are set to 0

CLEAR, LL#ALL

• DELAY, <time> — Wait for an amount of time to pass. The time can range
between 0.01 and 99.99 seconds. For example:
o CALL SYNC
• JUMP, <Label> — For example:

o L002:
RESET(1)
JUMP, L002
• RET Simulated as return. For example:

o RET
• STOP For example:

o STOP
• IF <Value 1>, <Condition>, <Value 2>, <Execution statement 1>, <Execution

statement 2> — For example:
o If signal is true then jump to L002, else jump to L003
If i1#7, =, ON, JUMP, L001, JUMP, L002

• ADD or SUB or MUL or DIV or MOD, <variable>, <value> — Add, subtract,
multiply, divide, and remainder. For example:
o Add 5 to the integer signal
Add, i4#7, 5
o Subtract 5 from the integer signal

Sub, i4#7, 5
• INC or DEC, <variable> — Increment or decrement a variable. For example:

o INC, i4#7
o DEC, i4#7
• Logic functions:And Not or Or or Xor, <variable 1>, variable 2>

These are bitwise, not Boolean, operations.

Reis-Robstar — Beyond signals and send/wait commands

• Free Text
• I/O – WRITE_BIT, WAIT_BIT, and WAIT
• Control Flow – CALL, PROGRAM, LABEL, BRANCH, TEST_BIT, TEST

#VARIABLE, TEST #INPUT, and TEST #MARKER
• Arithmetics – COPY, ADD, SUB, MUL, DEIV, MODULO, NEG, and

ABS_VALUE


coordinates system.


the offset position

forced to Joint

forced to Linear

system.



toJoint

forced to linear.


• Reis coordinates
o Translation: X,Y,Z

o Rotation:
A corresponds to Process Simulate RZ
B corresponds to Process Simulate RY
C corresponds to Process Simulate RX
• Comments with "C" and lines starting with "\" should be ignored during
simulation.
• WAIT
o For example: WAIT [s]:1.50
o Simulated as a 1.5 second delay
• CALL
o Ex1: CALL Name:”SubProgName”
o Ex2: CALL Name:”S:/Prog/SubProgName”
o Simulated as (in priority order):

■ call to macro <SubProgName>

■ call to operation <SubProgName>
■ call to operation <Robot><SubProgName>
■ call to operation <Robot>_<SubProgName>
■ call to robotic program <SubProgName>
■ call to robotic program <Robot><SubProgName>
■ call to robotic program <Robot>_<SubProgName>
• PROGRAM
o For example: PROGRAM Name:"File1"
o Simulated similar to CALL command
• LABEL
o For example: Label "Text1"
o Simulated as storing a label name


• BRANCH
o For example: BRANCH Label:"Text1"
o Simulated as an unconditional jump to label Text1
• TEST_BIT
o For example: TEST_BIT #INPUT,#=1,Byte:255,Bit_No:7,Label:"Text1"
o Simulated as: if input signal “i255_7” == 1, then Jump to label

“Text1”.
• TEST #VARIABLE
o For example: TEST #VARIABLE,Op_1:Var1,#=,Byte:255,Label:"Text1"
o Simulated as: if (Var1 == 255), then jump to label “Text1”
• TEST #INPUT / #MARKER

o For example: TEST #MARKER,Op_1:5,#>=,Byte:100,Label:"Text1"

o Simulated by 8 signals m5_0, m5_2 ...value addition: if (m5_0 + 2*m5_1
+ 4*m5_2 + …+ 2^7*m5_7) >= 100, then jump to label “Text1”
• COPY
o For example: COPY Source:124,Dest_Var:Index
o Simulated as: Index = 124
• ADD
o For example: ADD Op_1:Var1,Dest_Var:Var2
o Simulated as: Var2 = Var2 + Var1
• SUB
o For example: SUB Op_1:Var1,Dest_Var:Var2
o Simulated as: Var2 = Var2 - Var1
• MUL
o For example: MUL Op_1:Var1,Dest_Var:Var2

o Simulated as: Var2 = Var2 * Var1
• DIV
o For example: DIV Op_1:Var1,Dest_Var:Var2
o Simulated as: Var2 = Var2 / Var1
• MODULO
o For example: MODULO Op_1:Var1,Dest_Var:Var2
o Simulated as: Var2 = Var2 % Var1
• NEG
o For example: NEG Variable:Var1
o Simulated as: Var1 = -Var1
• ABS_VALUE
o For example: ABS_VALUE Variable:Var1
o Simulated as: Var1 = |Var1|


• # CycleStart
• Call name: “r1pounce”
• If o10_0 AND NOT o20_0 Then
• Call name: “r1style1”
• EndIf
• If o20_0 AND NOT o10_0 Then
• Call name: “r1style1”
• EndIf
• # CycleEnd


Staubli-Val — Beyond signals and send/wait commands

• Free Text

Any basic OLP command described earlier, including the following ones which
must be entered as free text:
• # MoveRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>]
o Move the robot with an offset expressed in location object frame
coordinates system.
o The offset is relative to: RefLoc if the optional <RefLoc> parameter is


o The optional rotational part of the offset are rotation angles in degrees
expressed in location object frame coordinate system (rotations are
performed one after the other in the rotating frame)
o The current location motion type, speed, zone are used to move to the
offset position
• # MoveJRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same as #

MoveRelBase, except that motion type to the offset position is forced to Joint
• # MoveLRelBase [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same as

# MoveRelBase, except that motion type to the offset position is forced to
Linear
• # MoveRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>]
o Move the robot with an offset expressed in location self coordinates

system.
o The offset is relative to: RefLoc if the optional <RefLoc> parameter is


o The optional rotational part of the offset are rotation angles in degrees
expressed in reference location self coordinate system (rotations are
performed one after the other in the rotating frame)
o The current location motion type, speed, zone are used to move to the
offset position.
• # MoveJRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same as #

MoveRelTool, except that motion type to the offset position is forced toJoint
• # MoveLRelTool [<RefLoc>] <X> <Y> <Z> [<RX> <RY> <RZ>] — Same as #

MoveRelTool, except that motion type to the offset position is forced to linear.

parameters with following syntax: # MoveRelBase <X> <Y> <Z> [Speed
Data = v500] [Zone Data = z100]. These explicit motion parameters is
inherited on any subsequent relative motions

• Constants
• Boolean variables, for example:

bool test1
test1 = true
• Numeric variables, for example:

num test1
test1 = 10.12
• delay (num seconds) — Puts the current task on hold for seconds, for
example:
delay(20)
• wait (<bool condition>) — Puts the current task on hold until condition is true.

• watch (<bool condition>, <num seconds>) — Puts the current task on hold
until condition is true or seconds have elapsed.
• call program([parameter1][,parameter2]) — Runs the specified program with

the specified parameters, for example:
call Op2(i,j)
• while <bool condition>

<instructions>
endWhile
for example:
i=0
while (k<10)
i=i+1
endWhile
• do
<instructions>
until <bool condition>

for example:
i=0
do
i=i+1
until (i==10)
• for <num counter> = <num beginning> to <num end> [step <num step>]
<instructions>
endFor
for example:
for i= 0 to 10 step 1
test1 = test1 +I
endFor
• if <bool condition>
<instructions>
[else
<instructions>]

endIf
for example:
if i== 0
test1 = 10
else
test1=20
endIf
• switch <num selection>

case <num case1> [, <num case2>]
<instructions1-2>
break
[case <num case3> [, <num case4>]
<instructions3-4>
break ]
[default
<Default Instructions>

break ]
endSwitch
for example:
option = 273
switch option
case 271
a = 10
break
case 272
a = 20
break
case 273, 274, 275, 276, 277, 278
a = 120
break
default
a =0
break

endSwitch

Trallfa-Robtalk — Beyond signals and send/wait commands

• Free Text
• Robtalk menu
o Gun/Brush pick
o Move Offs

• Block Instructions
o JUMP num

oLABEL num o
IF condition
instructions
o IF num condition THEN ... ELSE num ... ENDIF num

Conditions
■ INPUT num ON/OFF
■ REG num op expression
■ VAR num op expression
or any combination of the above, such as: INPUT 1 ON AND INPUT 2

OFF OBJPOS [XYZ] [<>] expression
when used in association with a JUMP action, this condition is simulated
as tracking the current location
Operators
■ <

■ >
■ =
■ #
oCALL SUB num - as call to operation <MainProgramName>_SUB<Num> o
CALL PATH num - as call to robotic operation

<MainProgramName>_PATH<Num>
o CALL PROG Name - simulated as (in priority order):

■ call to robot module procedure <Name>
■ call to macro <Name>
■ call to operation <Name>
■ call to operation <Robot><Name>
■ call to operation <Robot>_<Name>


■ call to robotic program <Name>
■ call to robotic program <Robot><Name>
■ call to robotic program <Robot>_<Name>
INTERNAL_HALT
• Other instructions
o MOVE OFFS num — Cannot execute if a MOV OFFs num ;@@ [ x, y, z,
a, b, c, r] was not executed first.
oMOVE OFFS num ;@@ [ x, y, z, a, b, c, r] with r is an external axis (rail) o
LET VAR num = expression
o LET REG num = expression

oWAIT OBJPOS X|Y|Z >|< value - as a wait for specific conveyor position o
WAIT TIME duration - as a delay of duration ms


o PARAM VEL REG num — as setting modal linear speed to registry value
• Gun/ Brush instructions

oBRUSH num condition
o BRUSH num
oGUN ON|OFF condition o
GUN ON|OFF
Limitations:
• Following commands are not supported in simulation:
o #include filename
o REL
o MOVE NEGOFFS
o MOVE POSREG

o LET POSREG num = position expression
o INC POSREG num [XYZ] BY expression

o Gun/Brush instructions with condition
o Wait conveyor while tracking (IF OBJPOS)

Universal-URScript - Beyond signals and send/wait commands

• Free Text

• Sleep(t) —Wait for certain amount of seconds to pass. For example:

o Sleep(10)
• Set_flag <num> — Output F[<num] signal or variable assignment. For

example:
o Set_flag(2)
• Get_flag <num> — F[<num] is read. For example:


o Get_flag(2)
• While(condition) — For example:

o
sync()
end
• IF <Condition> Elif <condition> … Else … End, Execution statement 1>,

<Execution statement 2>
o
If a > 3:
a = a + 1
elif b < 7:
b = b * a
else:
a = a + b
end
end
• Halt For example:

o Halt

• Return Simulated as return. For example:
o Return
• <function>(parameter1, paramter2) — Call a function with parameters. For

example:
o result = add(1,4)
No switch/case instruction is supported

Yaskawa-Inform — Beyond signals and send/wait commands

• Free Text
Yaskawa Inform Specifics:

• Download is using Program Template mechanism
Free text commands:

Any basic OLP command described earlier, including the following ones which
must be entered as free text:
• Supported Operating Instructions
o SET
o CLEAR
o INC

o DEC
o ADD/SUB
o MUL/DIV
o AND/OR/NOT/XOR
• Supported Control Instructions

o JUMP *<LabelNum>, as
■ jump label *<LabelNum>
o JUMP LABEL:<LabelVar>, as
■ jump to *<LabelNum>, where <LabelNum> is the numerical value
of <LabelVar>
o JUMP JOB:<Name>, as
■ call to <Name> (see CALL below for more information)
o JUMP *<LabelNum> IF <Condition>


o JUMP LABEL:<LabelVar> IF <Condition>
o JUMP JOB:<Name> IF <Condition>

■ same as above, only if condition is TRUE
o CALL Job:<Name>, simulated, in priority order, as:

■ call to macro <Name>
■ call to operation <Name>
■ call to operation <Robot><Name>
■ call to operation <Robot>_<Name>
■ call to robotic program <Name>
■ call to robotic program <Robot><Name>
■ call to robotic program <Robot>_<Name>
o CALL Job:<Name> IF <Condition>


■ Same as above, only if condition is TRUE
o CALL <VariableName> (IF <Condition>) or CALL <SignalName> (IF

<Condition>)
■ Same as above, where the called job name is the numerical value of
<VariableName> or <SignalName>
o TIMER T=<Expression>
■ Same as WaitTime
<Expression>
If <Expression> is a numerical value, the unit is second. If
the <Expression> is a variable, the unit is 1/100 of a second.
o RET <Expression>
■ Same as return with <Expression> value
CWAIT and NWAIT: These commands are understood but not simulated.

• Line Tracking specific commands
o SYSTART CV#(<conveyor number>) STP=<pos>
o SYEND CV#(<conveyor number>)
Limitations:
• In the case of JUMP JOB:<job name> UF#(<user frame no>) the UF# part
is not simulated
• Spline motions are simulated as linear motions (both with RCS and MOP
simulation).

If the RCS in simulation is disconnected, a MOP simulation replaces the RRS
based simulation.
• Speed
o SpeedType = VJ

ospeed : joint speed in %
o SpeedType = V
ospeed : Cartesian position speed o
SpeedType = VR
o speed : Cartesian orientation speed
• Zone
oFlyLevel
oCONT : nodecel o
PL0: fine
o PL1: medium
o PL2–PL8: coarse

• # CycleStart
• Call r1pounce
• Call r1style1 If OUT#(10) AND NOT OUT#(20)
• Call r1style1 If OUT#(20) AND NOT OUT#(20)
• # CycleEnd

Robot Program Viewer
Purpose
In this lesson, you learn how to use the Robot Program Viewer.
Objectives
• Use the Robot Program Viewer.

Robot Program Viewer basics
The Robot Program Viewer displays the commands sent to the robot controller
when simulating robotic operations.
You use it to view robotic programs or operations you have designed in Process
Simulate after they have been compiled and displayed in the syntax of their target
robot controller. The viewer may include collapsible blocks of code and colored
keywords/regions for ease of debugging.

Support is provided for all available controllers.
If necessary, you can open multiple instances of the Robot Program Viewer to
view multiple programs of a single robot or of different robots simultaneously.

If there are errors that would cause the download to fail, the relevant command
is marked in the program panel (upper panel) with a vertical red line and details
of the error are provided in the notifications panel (lower panel). For example, if
the robot speed has been omitted on a location, it is likely that when downloading
the program to the robot, a critical failure will occur and the download will abort.
After making the required changes in your program, you can reload it in the Robot
Program Viewer to confirm the improvement (and prevent download failures).

You can use this tool to:
• Follow highlighted motions/commands in the program panel as their execution
is simulated.
• View notifications created by the (simulated) download process. There are

three categories:
o Notes - General information.
o Warnings - Errors that will not cause the download to abort.
o Errors - Critical errors that will cause the download process to fail.
You cannot edit programs in the RobotProgramViewer.
Messages created by downloading a specific motion instruction or OLP

command display the serial number of the relevant instruction/command
program line in the Line column. General messages in the download process
display a dash ("-") in the Line column.

Use the viewer
To use the Robot Program Viewer:

1. From the ribbon, choose Home tab→Viewers group→Robot Program
Viewer .
You can open multiple Robot Program Viewer dialog boxes.
This allows you to maintain a view of several paths from the same robot
or from different robots to be able to better debug complex scenarios that
include several paths and robots.
2. If you had previously selected a program/operation, this is automatically

loaded in the Robot Program Viewer when you it launches. Otherwise,
select a robotic program in the Robotic Program Inventory or an operation
in the Operation Tree.
3. Click Add .
The currently selected program/operation is added to the Robot Program
Viewer. Process Simulate converts the operation and displays it in the syntax
of the controller of the robot to which the program is assigned.

In the Program panel, motion instructions/commands with download errors
are marked with vertical red lines, warnings with yellow lines, and messages
with blue lines.
4. You can do any of the following:

• Double-click a motion instruction or OLP command marked with a
colored vertical line to view only the notifications associated with that
command in the lower panel.

• Double-click a notification in the lower panel to jump to the relevant line
in the program panel.
• Click a notification tab to hide its contents. This enables you to

concentrate on the other notifications.
5. You can set breakpoints on locations, OLP commands (one per command)
and end of operations. Left-click in the margin of the viewer to insert
breakpoints to pause the simulation at those points.
A red dot in the margin indicates the inserted breakpoint. Right-click the
breakpoint to disable it (white dot with red rim) or delete it. Right-click a
disabled breakpoint to make it active again.
When you run the simulation with the Robot Program Viewer dialog box
open, it stops at each breakpoint to enable you to analyze the program for
debugging purposes. Continue the simulation the same way you would as
after pressing the Pause button.
If you close the viewer, the simulation runs continuously without stopping at
breakpoints, but they remain in place for when you re-open the viewer, for the
duration of the session. Once you close the study or exit the application, the
breakpoints are not persisted.

For complex OLP commands, it is not possible to set breakpoints on
their nested commands.

If you add a breakpoint while displaying the same code in more than
one viewer, the breakpoint appears in all the viewers.
6. Optionally, set a robotic operation as the current operation.

When simulating the program in the Sequence Editor, the Robot Program
Viewer dialog box steps through the program, highlights the relevant line in
the program, and displays a yellow arrow to the left of the currently executing
command.

Activities
In the Robot Program Viewer section, do the following activities:

• Use the Robot Program Viewer

Summary

• How use the standard OLP commands of emulated robot specific controllers
(ESRC).
• Various commands supported in simulation on all controllers which must be

entered as free text.
• The list of the supported OLP commands for several of the robot controllers.
• Compared the various methods available in Process Simulate.

Lesson 6
Calibration

Calibration

Calibration
Purpose
To describe how to use the Process Simulate calibration tools.
Objectives
• An overview of the concepts of calibration.
• How to create a calibration and use it to calibrate the position of a path

relative to a robot.

Calibration introduction
Purpose
In this topic, you get an overview of the concepts of calibration.
Objectives
• Use calibration within this system.
• Know what calibration is.
• Create and use calibration sets.
• View and use calibration results.

Calibration basics
In general, Process Simulate calibration attempts to:

• Eliminate and/or compensate for any differences that may exist between the
Process Simulate and actual studies, in order to ensure precise download of
robot-program destinations from Process Simulate to the actual robot.
• Enable downloading a robot program from an Process Simulate scene to

several robot studies on the factory floor which are theoretically identical but
in practice have differences in layout and component performance.
• Enable transferring on-line teach programs from one robot scene to another
scene that is theoretically identical, without requiring manual corrections
of robot destinations.

What is calibration?
Calibration is the process of bringing the modeled Process Simulate scene into
conformity with the real-world scene. This is done by creating a filter which
describes how the real-world scene differs from the Process Simulate. This filter is
called a "calibration set".
Calibration is needed by those users who require high accuracy in the downloaded
program locations, or in programs with a large number of locations, in order to
avoid manual touch ups. Calibration would not be required in a program with few
locations needing high accuracy; manual touch ups in this case would be more
efficient.
The calibration process involves measuring the real scene in some manner, and
bringing that information into Process Simulate. The robot itself is the primary
method of scene measurement. However, external systems such as theodolites
can be used to bring XYZ coordinate data into Process Simulate.
The Process Simulate Calibration command, located on the Robot tab of
the ribbon, is used to build the calibration set to improve the accuracy of the
downloaded program. In this class, you see how to use these tools to achieve a
good OLP result.


Calibration sets
After creating objects in Process Simulate, it is possible to measure the equivalent

real objects on the shop floor. In this case, you may wish to calibrate (transform)
the source points to be as close as possible to the destination points, as measured
and stored in Process Simulate. The Calibration command accepts multiple
pairs of points (each pair consists of a source point and an destination point)
and uses an algorithm to adjust the position and orientation of the source pairs
so that the average distance between the sources and destinations is as small
as possible. The algorithm calculates the optimum transformation for all the
pairs - there is an improvement for most of the pairs but one or two may not be
improved. Siemens recommends using not more than ten pairs to maintain
system performance.
After adding all the desired pairs, the system calculates the transformation and
you can apply it if you are satisfied. You can Apply more transformations and
Unapply them. At the end of your session, you can store the calibration set.
There must be at least three calibration pairs to enable calibration calculation
(because three pairs define a plane).

The user can produce more than one calibration set for the same Process Simulate
scene, in order to account for more than one actual scene. Each set has a unique
identity. Any set can be used when a robot program is downloaded. In addition, a
program can be uploaded from the actual robot scene with the use of one set, and
then can be downloaded to another actual scene with the use of another set.

The math behind calibration
Calibration uses the root mean square to calculate the adjustment factor to be
applied on the locations in the path.
In mathematics, root mean square (abbreviated RMS or rms) is a statistical
measure of the magnitude of a varying quantity. It can be calculated for a series
of discrete values or for a continuously varying function. The name comes from
the fact that it is the square root of the mean of the squares of the values. It
is a power mean with the power t = 2.
The rms for a collection of N values is:
and the corresponding formula for a continuous function f(t) defined over the
interval is:

Calibration results
The calibration calculation runs in real time, updating the Calibration Results
automatically when new calibration pairs are added, removed, activated, or
deactivated. The system displays the following results.
• dX, dY, and dZ - Displays the transformation distance results on the X, Y,

and Z axes.
• Rx, Ry, and Rz - Displays the transformation rotation results around the
X, Y, and Z axes.
• Maximum distance - Displays the distance between a transformed object and

the original object for the calibration pair with the largest average distance.
• Average distance - Displays the average distance between all the

transformed objects and the original objects.

• RMS - Displays the RMS (root mean square) distance between all the
transformed objects and the original ones.

Robot to part calibration
Purpose
In this topic, you learn how to create a calibration and use it to calibrate the
position of a path relative to a robot.
Objectives
• Perform a basic robot to part calibration.

Business process

Robot to part calibration basics
Scene calibration is used to calculate the actual location of the robot relative
to the workpiece.
What you need to do is independently create a path on the real robot and the
Process Simulate robot that includes the robot touching the same three points
on the workpiece. Then you would upload the path from the real robot and use
the calibration window to reconcile them. In doing so, you create a calibration set
that can act as a filter to adjust the downloaded path from Process Simulate to
better fit to environment of the real robot.
Calibration Pairs are used to effect the RMS calculation by means of pairs of
download and upload locations: locations placed in the Process Simulate scene
are downloaded to the actual robot they are corrected according to the actual,
relative placement of the robot and workpiece, and the corrected locations are
uploaded back to the Process Simulate scene.
The Calibration command is used to perform the RMS calculation based on
user-supplied data, and then display the results of the calculation and apply
the results to a chosen component as a transformation to the location of that
component.

Calibration steps overview
1. In Process Simulate, create (for example three) locations in a path to define

the workpiece calibration. These points are typically on known common
“landmarks” such as point on the fixture blocks.
2. Verify the locations in the path can be reached by the robot.
3. On the real robot, teach the same three locations into a new program.
4. Upload the program from the real robot into Process Simulate.
5. Using the Process Simulate Calibration dialog box, create a calibration set
with these two paths as input.
6. Apply the calibration set to the desired robotic path created in Process
Simulate to properly locate it relative to the robot.
7. Verify motion, cycle, and configuration location information through simulation.
8. Download the desired robotic path to the real robot.


Activities
In the Robot to part calibration section, do the following activities:

• Creating a calibration set
• Using a calibration set

Summary

• An overview of the concepts of calibration.
• How to create a calibration and use it to calibrate the position of a path

relative to a robot.

Lesson 7
OLP command customization


Purpose
To describe how to do OLP command XML customization.
Objectives
• Got an overview of the capabilities in this area.
• How to create an enhanced OLP command.
• How to create a custom command and macro

Overview of customizing robot controllers
Purpose
In this topic, you get an overview of the basic areas of the robot controller interface
customization XML file.
Objectives
• Know the customizable user interface's layers and dialog standards.
• Create and use a OLP command customization file.

Business process

OLP command customization basics
Controller Customized OLP Customized Robot Path

Configuration Motion Template
Configuration
ABB Yes Yes Yes
ABB Volvo (Volvo Yes No Yes
only)
Cloos Yes No Yes
Comau Yes Yes Yes
Comau Volvo (Volvo Yes No Yes
only)
Default Yes Yes Yes
Denso
Duerr Yes No Yes
Epson Yes No Yes
Fanuc F100iA Yes No Yes
(CFLEX)
Fanuc Yes Yes Yes

Fanuc Japan Yes No Yes
(Japan customers
only)
Fanuc VW (VW Yes No Yes
only)
IGM Yes Yes Yes
Kawasaki Yes No Yes
Kuka Yes Yes Yes
Kuka BMW (BMW Yes No Yes
only)
Kuka Volvo (Volvo Yes No Yes
only)
Kuka VKRC (VW Yes No Yes
only)
Nachi Yes Yes Yes
NC Code Yes Yes Yes
NC Code BMW Yes No Yes
(BMW only
NC Code Danobat Yes No Yes
(Danobat only)
NC Code Riveting Yes Yes Yes

NC Code Riveting Yes No Yes
Embraer (Embraer
only)
Panasonic
Reis Yes Yes Yes
Staubli Yes No Yes
(ABB) Trallfa Yes No Yes
Universal Yes (TBD) Yes
Yaskawa Yes No Yes
(Motoman)
Siemens PLM Software, together with its customers, has invested a lot of effort,
based on broad knowledge gained over many years, to offer advanced OLP
programming capabilities. The availability of the Teach Pendants, and in more
recent versions, the greater use of the Path Editor, provides your users a much
greater scope of functionality than in the past. Nevertheless, there is always room
for user customization and the flexible application of customer "flavors".

Open System Complex User Requirements:
As the environment becomes ever more complex, the only solution that can serve
users' needs is an open solution. This is due to the following constraints:
• There are very few robotic program specialists.
• Multi-variant production requires complex synchronization.
• The system must be flexible enough to add commands which utilize correct
syntax but are still easy to use.
• No API or C/C++ programming.
Use of ESRC Enhances Verification Capabilities:

ESRC technology allows simulation and verification of many of the commands.
The customizable User Interface, based on ESRC, is designed to take advantage
of these capabilities.

The customizable user interface's layers
In Process Simulate, you use XML files to support customization of OLP

commands and motion commands ... WYSIWYG. Here are the four primary
sections of the OLP configuration file:
• The first layer, the User Interface Layer, defines the dialog that can be
opened from within the Teach Pendant during the session.
• The subsequent Simulation Layer includes the instructions as they have to

be executed during the simulation (CEE type). Define the behavior using the
parameters and controls in the User Interface dialog.

• The Download Layer is the last and probably most important of the three
layers. Here users define the actual controller specific commands from a
form in the dialog from the User Interface layer.
• Finally there are Upload Capabilities to reuse the definition and present
the data in a form to the user.
Automatic Generation of OLP Commands Dialogs – the User Interface Layer:

The entire customization is done by the user in a configuration file. The exact
order of elements and the obligatory and optional elements can be found in the
example later in this course.
The system automatically generates an OLP command dialog with the appropriate
information from the configuration file.
Simulation and Download Layers:
Parameters used in the User Interface (UI) dialog are then used to generate the
needed OLP strings for the simulation needs as well as for the download to the
real controller.
It is possible to define multi-line commands, meaning several lines of actual OLP
code.
Changes Without Re-launching Process Simulate

When making changes in the configuration file, there is no need to close the
Process Simulate application. A simply opening the Customized Command XML
Checker command loads the latest configuration files. (Closing the Teach
Pendant and re-opening it also loads the latest configuration files).

Dialog standards
All OLP command dialogs are generated with the same layout.
Dialog Size:
The size of the dialog should be automatically calculated according to
configuration file data.
Custom OLP Command Example:
This is not an exercise. A detailed exercise on this topic can be found
later in this course.
• With the desired robot controller set for the assigned robot: Right-click a
robotic operation and choose Teach Pendant .
• From the Teach Pendant, click Add.
• Slide across Customized and notice the two custom commands.

• Look at the Gripper Instructions command.
• Look at the Collision command.
Custom Motion Example:

This is not an exercise. A detailed exercise on this topic can be found
later in this course.

• With the desired robot controller set for the assigned robot: Add the path to
the Path Editor (and the Customized Motion, Customized Debug, and
Process type Columns).
• Open the Teach Pendant dialog box.

• Look at the custom user interface results in the bottom half of the Teach
Pendant dialog box.

Custom OLP commands XML file
Purpose
In this topic, you get an introduction to the customized OLP commands .XML file.
Objectives
• Know the basic sections of an OLP command customization OLP file.

Customized XML basics
The rest of this section of the course deals with OLP command
customization. Later in this course you tackle motion command
customization and path template customization.
For each controller there may be several OLP configuration, motion

configuration, and path template configuration files. By default, the
OLP configuration files are located in the OlpConfiguration subfolder
(C:\Program Files\Tecnomatix\eMPower\Robotics\OLP\<Controller
name>\OlpConfiguration. However, this can be changed by
specifying a CustomizedPath in the rrs.xml file for the version
of the controller used like the training course (for example
name>\OlpConfiguration).
Users can assign any names they want to the XML configuration files.
You can use the CustomizedPath in the rrs.xml file to change the location of the
OlpConfiguration folder, like was done for the training.

OLP configuration file basic elements
In this section you learn about the basic elements of the OLP configuration XML
file.
The XML file must start and end with the RobotController element. This tab
contains three other elements which represent the three main parts of the file:
• RobotController - This element must occur only once and be the root.
It contains these attributes:
o The Name must appear in the RobotController element. It should be the
robot controller as specified in the rrs.xml file. Example value: Fanuc-Rj
o Version (of the controller) can also be specified
• RoboticParams
• OlpCommands
• OlpDialogs
Here is the basic skeleton:



Robotic parameters section of the file
Purpose
In this topic, you learn how to setup the robotic parameters section of the file.
Objectives
• Understand the robotic params section of the file.
• Define a list of value.
• See several TxObject value type examples.

Robotic params dection basics
This element includes all the robotic parameters (Param elements) which are
used by customized OLP/Motion commands. Process Simulate reads this section
from within all the relevant XML files (per controller per version) into one cache
which is used by all customized commands. Therefore it is necessary for each
robotic parameter name to be unique.
It is used to define the parameters (for example the parameter’s type, list of
values, min, max values, etc.)
Basic Description:
Each parameter (Param element) should have a name, a type and (optionally)
a value. It contains these attributes:
• Name - This element determines the name of the parameters
• ValueType - This element must occur only once. Values are either:
o Int – a number
o Double – a number

o String – text
o TxObject - Tecnomatix objects, such as robot gun, etc.
• MaxVal – for numbers only (double and int)
• MinVal – for numbers only (double and int)
• Default - Example value: “2”
• Multiline – for strings only

Defining a list of values
• ComboDef – Defines a list of values. Should contain at least one ElmDef.
• ElmDef – defines of the values of the list

More on TxObject ValueTypes
TxObjects must be only:

• compound,
• part_instance,
• part_physical_appearance,
• part_prototype_assignment,
• compound_resource,
• resource_instance,
• resource_prototype_assignment and any physical object in a component

scope.
TxObject selection filtering options:

• Allow any object to be selected

• Allow only specific pick types using the PickTypes element
• Allow only filtered objects from a list using the ShowList attribute of the
PickTypes tab

• Allow only objects based on the type using the TxValidatorType attribute
of the Param tab.

OLP commands section of the file
Purpose
In this topic, you learn how to setup the OLP commands section of the file.
Objectives
• Understand the OLP commands section of the file.
• Understand the layers.

OLP commands section basics
This element includes all the OLP commands (Command elements) which are
used by customized OLP commands. The Process Simulate application reads
this section from all relevant XML files (per controller per version) into one cache
which is used by all customized commands. Therefore, each OLP command
name must be unique.
• Command – This element represents one customized OLP command
and it contains the command name and parameters names. Contains the
RoboticParamRef and Layers elements. Attributes for this element:
o Name - Example value: “Do Something”
• RoboticParamRef – Contains the Param elements used in the command.
• Layers - This element is optional, but can occur only once. This
element contains the primary layers: UILayer, SimulationLayer, and
DownloadLayer.

Layers
The Three Layers:

• UILayer – This element represents one customized OLP command in the
Teach Pendant or Path Editor. It is optional, but it can occur only once. It
contains the Lines (and items) for the user interface to be shown.
• SimulationLayer - This element is optional, but can occur only once. It

defines how the customized OLP command is simulated. During simulation,
when the controller encounters a customized OLP Command, replaces it with
its simulation layer and interprets this simulation layer instead. Inside the
simulation layer, users can write any elementary command (one per <line> ...
</line> section) that is understood by the controller:
o "default controller" standard commands (ex : # SendSignal sig1, #
WaitTime 2, # Blank PaintFanEntity,....)
o native controller syntax supported by the controller simulation (ex : IF

var1 = 3 THEN, call to macros, call to robot module procedure,....)

o Inside the simulation layer, it is fully permissible to mix "default controller"
commands with commands in native controller syntax.
• DownloadLayer – It defines what is output when the program is downloaded.

It has the same capabilities as UILayer and supports several lines. This
element is optional, but can occur only once.
The content of a layer:

• Line - Defines a line break. It contains Item elements.
• Item - Only allowed below Line elements. Contains the Type attribute as
well as either a parameter name (when the type is parameter) or a constant.
Attributes for this element:
o Type – Values are either const, optional, or parameter, or
dynamicParameter

OLP dialogs section of the file
Purpose
In this topic, you learn how to use the OLP dialogs section of the file.
Objectives
• Use OLP command XML structure.
• Create a basic OLP command file.

OLP dialogs section basics
The OlpDialogs element contains a list of dialogs, each of which allows you to
create one or more OLP commands. It contains one or more Dialog elements.
• Dialog - Attributes for this element:
o Title - Shows the title of the dialog in the Teach
Pendant. Each ‘|’ is a new subdirectory. For example:
Title="MyTest|Customized|ChooseLocation"
o Description - A short description inside the dialog for the user. For
example: Description=”Please select a location”

o Icon – The icon of the dialog. For example: Icon=”gripperOp.ico”
These icons should be placed in the

.\eMPower\Robotics\Olp\CustomizedIcons folder (or in a
folder relative to this folder, such as a sub-folder). This folder
is used by all controllers and custom dialogs. You can use the
CustomizedPath in the rrs.xml file to change the location of the
CustomizedIcons folder, like was done for the training.

• OlpCommandRef – Contains the OlpCommand element.
• OlpCommand – References Command elements from the OlpCommands

element.

OLP command XML structure example
<RobotController Name=””>
<RoboticParams>
<Param Name=”” ValueType=”” Default=””>
<ComboDef>
<ElmDef>xxx<ElmDef/>
</ComboDef>
</Param>
</RoboticParams>
<OlpCommands>
<Command Name=””>
<RoboticParamRef>
<Param>xxx</Param>
</RoboticParamRef>
<Layers>
<UILayer>

<Line>
<Item Type="">xxx</Item>
</Line>
</UILayer>
<SimulationLayer>
<Line>
</Line>
</SimulationLayer>
<DownloadLayer>
<Line>
</Line>
</DownloadLayer>
</Layers>
</Command>
</OLPCommands>

<OLPDialogs>
<Dialog Title="" Description="">
<OlpCommandRef>
<OlpCommand>xxx</Param>
</ OlpCommandRef >
</Dialog>
</OLPDialogs>
</RobotController>

Signal example
Purpose
In this topic, you learn how to create custom OLP commands, for various robot
controllers, for send signal and wait signal.
Recall from the intermediate robotics training:

• A PLC output signal is connected to a robot input such as a digital input (DI).
• A PLC input signal is connected to a robot output such as a digital output (DO).
• In Process Simulate, you enter the signals from the perspective of the PLC,
so the robot waits for output signals (DI) and sends input signals (DO).
Objectives

• Create custom OLP commands to send signals and wait for signals in the
robot specific language.

Send signal and wait signal basics
In this lesson you create a custom command for send signal and wait signal in the
robot controller’s specific language (for example it is downloadable).
The below examples assume that you have a PLC input and robot signal
defined (DO) and a PLC output and robot signal defined (DI). In the
activity, you use the signals created in an earlier activity in this advanced
robotics training.
For ABB-Rapid:
•Signals names: di1, do2
• Send Signal: SetDO do2, 1;
•Wait Signal: WaitDI di1, 1;
For Cloos-Carola:
• Signals names: IN1, OUT2


•Send Signal: SET(2)
•Wait Signal: WAITI(IN(1)) For
Comau-Pdl:
• Signals names: $DIN[1], $DOUT[2]
• Send Signal: $DOUT[2] := TRUE

•Wait Signal: WAIT FOR $DIN[1] = ON For
Denso-PacScript:
• Signals names: MySignal1, MySignal2
• Send Signal: MySignal2 = 1

•Wait Signal: Wait MySignal1 = ON For
Duerr-Ecotalk:
• Signals names: di1, do2

•Send Signal: SET do2 1
•Wait Signal: RECEIVE di1 1
For Epson-Spel:
• Signals names: INB1, OUTB2
• Send Signal: On 2
•Wait Signal: Wait Sw(1) = On For
Fanuc-Rj:
• Signals names: DI[1], DO[2]
• Send Signal: DO[2] = ON

•Wait Signal: Wait DI[1] = ON; For
Igm-Ins:

•Send Signal: DOUT do2 1
•Wait Signal: WAIT di1 1
For Kawasaki-As:
• Signals names: in1, out2
• Send Signal: SIGNAL 2

•Wait Signal: SWAIT 1
For Kuka-Krc:
There are two options. However, you use the KRL syntax in the activity.
• Fold syntax
o Signals names: DI[1], DO[2]
o Send Signal: OUT 1 ‘DO[2]’ State= TRUE
o Wait Signal: Wait FOR (IN 1, ‘DI[1]’)
• KRL syntax

o Signals names: $IN[1], $OUT[2]
o Send Signal: $OUT[2] = TRUE

o Wait Signal: Wait FOR $IN[1] For
Nachi-Slim:
•Signals names: I1, O2
• Send Signal: SETM O2,1

•Wait Signal: WAITI I1
For Panasonic-Csr:
• Signals names: i1#1, i1#2
• Send Signal: OUT, o1#2, 1

•Wait Signal: WAIT_IP, i1#1, 1 For
Reis-Robstar:

•Signals names: i1_0, o2_0
• Send Signal: WRITE_BIT o2_0 1

•Wait Signal: WAIT_BIT i1_0 1 For
Staubli-Val:
• Send Signal: SetDO do2, 1

•Wait Signal: WaitDI di1, 1
For Trallfa-Robtalk:
• Signals names: INPUT1, OUTPUT2
• Send Signal: OUTPUT2 ON

•Wait Signal: WAIT INPUT1 ON For
Universal-URScript:

• Signals names: DI[1], DO[2]
• Send Signal: set_standard_digital_out(2, True)
• Wait Signal:
sync()
end
For Yaskawa-Inform:
• Signals names: IN#(1), OT#(2)
• Send Signal: DOUT OT#(2) ON
• Wait Signal: Wait IN#(1) ON

Activities
In the Signal example section, do the following activities:

• ABB — Creating a custom command to send and wait for signals
• Comau — Creating a custom command to send and wait for signals
• Denso — Creating a custom command to send and wait for signals
• Duerr — Creating a custom command to send and wait for signals
• Fanuc — Creating a custom command to send and wait for signals
• IGM — Creating a custom command to send and wait for signals
• Kawasaki — Creating a custom command to send and wait for signals
• Kuka — Creating a custom command to send and wait for signals
• Nachi — Creating a custom command to send and wait for signals


• NC — Creating a custom command to send and wait for signals
• Panasonic — Creating a custom command to send and wait for signals
• Reis — Creating a custom command to send and wait for signals
• Staubli — Creating a custom command to send and wait for signals
• Trallfa — Creating a custom command to send and wait for signals
• Universal — Creating a custom command to send and wait for signals
• Yaskawa — Creating a custom command to send and wait for signals

Custom OLP command and macro example
Purpose
In this topic, you learn how to create a custom OLP command that calls a macro
from the macro file.
Objectives
• Use a combination of a macro file and a custom OLP command.

Macro file example
A possible macro could look like this – although it should be mentioned that this
macro is specific (“hardcoded”) for a predefined equipment name:
Macro METHOD1_RIVET
# Destination xyz_riveter_rr_01
# Drive CLOSE
# Destination xyz_ riveter _rr_01
# WaitDevice CLOSE
# WaitTime 2
# Destination xyx_ riveter _rr_01
# Drive OPEN
# Destination xyz_ riveter _rr_01
# WaitDevice OPEN

Macro files must be stored in the defined macro folder under the system
root (as defined in File→Options ) and named with a .macro file
extension.
The advantage of this solution is the fact that the original .cojt including only
kinematics can be used.
The disadvantage of using this kind of macro is being it not flexible at all for any
kind of equipment change.
A much more and realistic way is turning the xyx_ riveter _rr_01 into a smart
component (which provides built in joint value sensors and the ability to move to a
pose using a signal). The entries and exists of this smart component could be
connected to generic signal names which follow your company standard.
Then you can reference these signals in your macro.
• Digital Output Signals:
o do9 used to move to open
o do10 used to move to close
o di7 used to verify moved to close OK


o di8 used to verify moved to open OK
Then a module or macro could be written in the following form:

Macro METHOD2_RIVET
# Send do10 1
# WaitSignal di7
# WaitTime 2
# Send do10 0
# Send do9 1
# WaitSignal di8
# Send do9 0

OLP command XML file requirement for example
The following would be added to the SimulationLayer of the OLP Command

XML file:
<SimulationLayer>
<Line>
<Item Type=”const”>METHOD2_RIVET<Item>
</Line>
The .macro file must already exist, since this tool checks for the file before
offering it as a choice.

Summary

• Got an overview of the capabilities in this area.
• How to create an enhanced OLP command.
• How to create a custom command and macro

Lesson 8
Motion and robotic path template
customization

Motion and robotic path template customization

Motion and robotic path template customization
Purpose
To provide a description on how to do motion and robotic path template
customization.
Objectives
• How to create an enhanced motion XML
• How to create a robotic template XML
• Other selected custom XML topics

Motion command customization introduction
Purpose
In this topic, you learn to create and use motion command customization XML files.
Objectives
• Create and use motion customization files.
• Use custom motion type configurations.
• Use additional functionality concerning custom motion commands.

Business process

Motion customization basics
Recall from earlier in the advanced robotics training that motion customization is
not supported on all ESRC robot controllers:
Controller Customized Motion Configuration
ABB Yes
ABB Volvo (Volvo only) No
Cloos No
Comau Yes
Comau Volvo (Volvo only) No
Denso
Duerr No
Epson No
Fanuc F100iA (CFLEX) No
Fanuc Yes
Fanuc Japan (Japan customers only) No
Fanuc VW (VW only) No
IGM No
Kawasaki No
Kuka Yes

Kuka BMW (BMW only) No
Kuka Volvo (Volvo only) No
Kuka VKRC (VW only) No
Nachi No
NC Code Yes
NC Code BMW (BMW only No
NC Code Danobat (Danobat only) No
NC Code Riveting No
NC Code Riveting Embraer (Embraer No
only)
Panasonic
Reis Yes
Staubli No
(ABB) Trallfa No
Universal (TBD)
Yaskawa (Motoman) No
A lot of companies have implemented their own standards to create a combination
of existing “official” robot motion commands with their own enhancements.
Process Simulate supports these requirements in the same way as for the

Customized OLP user interface. This user customization must be kept the flexible
to allow customer "flavors" without the need to hard code them.
For each combination of location and process types (a column under the controller
name section), a different dialog can be used to edit the relevant robotic parameter.
• For weld locations, these options are shown:
• For via locations, these options are shown:
By choosing a value, users can customize the location.

Custom motion type configuration
As explained in the introduction, specific user defined process related commands

can be defined in all existing robot controllers. In order to support these
commands, the customized User Interface mechanism includes motion
parameters. since they may influence several columns, a specific new column
in the Path Editor is used called “PROCESS TYPE”.
For each controller there may be several OLP and motion configuration files. By
default, the motion configuration files are located in the MotionConfiguration
subfolder (C:\Program Files\Tecnomatix\eMPower\Robotics\OLP\<Controller
name>\OlpConfiguration. However, this can be changed by
specifying a CustomizedPath in the rrs.xml file for the version
of the controller used like the training course (for example
name>\MotionConfiguration).

Description
All the syntax of the OLPConfiguration elements can be used here as well.
Representation of Layers of motion commands:
Customized motion commands are stored in the Database only one time, but for
each motion command, there are three different representations. (User Interface,
Simulation and Download)
The purpose of this service is to retrieve the right motion command representation
according the user needs.
In the XML file, for each location type and each process type, there is three layers:
1. UILayer – The user interface layer shows what is shown in Process Type
column of Path Editor.
2. SimulationLayer - The simulation layer describes what needs to be simulated
3. DownloadLayer - The download layer describes what needs to be

downloaded.
User Interface Layer:


1. When the user clicks in the ProcessType column in the Path Editor, the
service read the XML (only the first time and saves it in a cache for reusability)
and an appropriate list of process types (according to the suitable location
type) is shown for the user to choose.
2. When the user chooses a value – a custom user interface is opened with
the current values displayed.
3. After setting the desired values and click OK, the values are set on all the
referenced location attributes.

The Customized Motion and Customized Debug columns can
be added to the Path Editor as well. If the location has not been
customized, there won’t be a value in these boxes.

Additional elements of motion command files
Purpose
In this topic, you learn about some additional elements of custom motion
command XML files (as apposed to custom OLP command XML files).
Objectives
• More motion command options.

Motion command basics
For motion command XML files the RobotController element contains the
RoboticParams and Location elements.
Location – This element represents the type of the location you select and
contains a Type attribute which can have these values: VIA, WELD, Seam Start,
Seam End, Seam Middle
• Process – This element is one of the values of the list of values shown for
the selected location type. This is the value that is shown in the Process Type
column. Several of these elements can be placed within a Location element.
o Force - Once users select a process type for a location, the application
forces new values for specific robotic parameters.
o Dialog – Contains the Title and Description attribute and the

RoboticParamRef element. See the description provided earlier in this
course.
o UILayer - See the description provided earlier in this course.
o SimulationLayer - See the description provided earlier in this course.


o Motion – The type of motion with the following Types: 1 Joint, 2 Linear,
3 Slew, 4 Circular Via, 5 Circular2, 6 Circular Radius, 7 Circular Full,
and 8 Spline.
This element contains the DownloadLayer

Motion command customization example
Purpose
In this topic, you learn how to create a custom motion command XML file.
Objectives
• Create and use a custom motion XML file

Motion example basics
Your custom motion XML shows a specific list of values for the Process Type
based on location type. For example for Weld locations, the user has the ability to
select either Style1 or Style2 for the Process Type (in the Path Editor).
Each Process type can have its own dialog which can be opened from the
Customized Motion column of the Path Editor.
One or all layers can be filtered based on the assigned motion type.
For example:
• Weld (location type)
o Style1 (process type) — Weld location dialog for Style1
■ PTP (motion type)
◇ User Interface layer
◇ Simulation layer
◇ Download layer
■ Lin (motion type)


◇ Download layer
■ Circ (motion type)

◇ Download layer
o Style2 (process type) — Weld location dialog for Style2

■ PTP
◇ Download layer

• Via (location type)
o Style 2 (process type) — Via location dialog for Style2
■ PTP (motion type)
◇ Download layer
■ Lin (motion type)

◇ Download layer
■ Circ (motion type)


◇ Download layer
o Style3 (process type) — Via location dialog for Style3

■ PTP
◇ Download layer
Simulation and Download layers:

When a location is marked as “customized”, the controller uses the XML
simulation/download layer, instead of performing the default simulation/download.
Each layer consists of hard coded strings, and robotic parameters (not necessarily
the ones which appear in the dialog). Process Simulate reads the related section
in the XML file and converts it with the following rules:
• The hard coded string - stays as is.
• The regular parameters – the service should find their value on the location,

• The controller parameters – the service gets their values by API from the
controller.
• Finally, Process Simulate returns one string to the controller with everything it
needs (or an empty string if it required)

Activities
In the Motion command customization example section, do the following activities:

• ABB — Creating customized motion commands
• ABB — Using customized motion commands
• Comau — Creating customized motion commands
• Comau — Using customized motion commands
• Fanuc — Creating customized motion commands
• Fanuc — Using customized motion commands
• IGM — Creating customized motion commands
• IGM — Using customized motion commands
• Kuka — Creating customized motion commands


• Kuka — Using customized motion commands
• Nachi — Creating customized motion commands
• Nachi — Using customized motion commands
• NC — Creating customized motion commands
• NC — Using customized motion commands
• Reis — Creating customized motion commands
• Reis — Using customized motion commands

Robotic path template customization introduction
Purpose
In this topic, you learn how to create a custom robotic path template .XML file.
This is supported by all ESRC robot controllers.
Objectives
• Know the capabilities and syntax of the file.
• Create and use a path template file.

Business process

Path template basics
It is often necessary to configure location parameters (tool, speed, zone, etc.)

to define a path for a specific process. Additionally, approach and depart via
locations with the same parameters are added to the path. Each action can add
locations to the selected path, and/or change location orientation and robotic
parameters, and OLP commands. For example, in a gluing operation, the user
configures the gluing start, stop, and robot speed. These are process specific
parameters to be applied to each gluing path.
Process Simulate enables you to define actions in an XML template and apply
the actions to multiple operations. You can set parameters and OLP commands
for locations, add approach and depart via locations, and set their coordinates.
You can define many actions in the XML template and apply them with a single
click, saving repetitive manual configuration, increasing productivity, and reducing
errors.
The robotic templates are stored as XML files in dedicated folders. Since each
robot controller has its own OLP commands (standard, specific, and customized)
and motion parameters (regular, complex, and customized), each controller
requires its own path template configuration files.

For each controller there may be several OLP configuration, motion
configuration, and path template configuration files. By default, the path
template configuration files are located in the PathTemplateConfiguration
subfolder (C:\Program Files\Tecnomatix\eMPower\Robotics\OLP\<Controller
name>\PathTemplateConfiguration. However, this can be
changed by specifying a CustomizedPath in the rrs.xml file for the
version of the controller used like the training course (for example
name>\PathTemplateConfiguration).
The following are examples of simple actions:
• Action A: For the first seam location with the Polishing process type:
o Set RRS_MOTION_TYPE to 2.
Recall that motion type 1 is joint motion and 2 is linear motion.

Other internal names for attributes, such as RRS_MOTION_TYPE
can be found using the Robotic Parameters Viewer tool. This tool
is described in the Final Comments lesson of the course.
o Add the OLP command OpenPaintGun


o Add the OLP command SetPaintBrush 3
o Change the location color to be Yellow
• Action B: For the last seam location with the Polishing process type:
o Set RRS_MOTION_TYPE to 2
o Add the OLP command ClosePaintGun
o Change the location color to be Red
The user can apply actions on chosen operations.

Basic Steps:
• Create custom path template XML file.

• Use the custom path template XML in Process Simulate by choosing
Operation tab→Templates group→Apply Path Template Action .

Capabilities
• Execute configurable templates of actions on list of operations
• Perform multiple actions to manipulate the paths at once
• Support different actions:
• Adding removing robotic parameters
• adding/removing of OLP commands
• Adding locations
• Set Paint gun off / on
• Support different templates for each controller, with and without parameters

Description
For robot path template XML files the RobotController element contains the
ActionList and ActionFilter elements.
• ActionList — This element contains a list of Action elements.
• ActionFilter
• Action — this element has several attributes such as:

o Name — The name of the action, this must be unique. The following
example shows that when the name includes ‘|‘, this is a sub menu, and
when it includes ‘-‘ at the end, this is a separator
o SeamRange — Defines the seam operations (under the selected

continuous compound operation) upon which this action should be
performed. The possible values are: All (including all via and seam

locations, this is the default value), First, Last, n1, Last – n1, ”n1-n2”,
”n1,n2,n3”.
o LocRange —Defines the locations on which this action should be

performed. The possible values are: All (this is the default value), First,
Last, n1, Last – n1, ”n1-n2”, ”n1,n2,n3”, Operation. The Operation value
does not work with any other filters; use it only for OLP commands, color,
and motion for the selected operation level.
o LocIndex (with values such as First, Last, All)
o LocationTypes — Filters the locations by their support for customized

motion. The possible values are: Via, Weld, Seam Start, Seam End,
Seam Middle.
o Processtypes — Filters the locations by the process type defined in the

customized motion XML file (see also in Process Type column in the
Path Editor). This attribute can take more than one value.
o MotionTypes — Filters the locations by motion type. This attribute can

take more than one value.

o Description — The description of the action to be shown in the Apply
Path Template Action window in Process Simulate.
o etc.
Action content overview:

The Action element can contain several elements:
• Param — This is fully defined (min, max, list, type, etc.) in the customized
motion XML file. This attribute is mandatory unless you use the RemoveAll
attribute.
• Olp — For a standard or controller specific controller, the system creates a

free text command at the location. For a standard customized controller, the
system creates a composite command at the location. If there is already an
OLP command with the same name at the location, a new OLP command
is added.

• Color — The possible values are: Red, green, yellow, blue, magenta, cyan,
orange, white, pink, gray, brown, wood, dark green, dark red, dark brown,
light blue, black.
• MoveLoc — This element describes the moving of locations in single or

several coordinates. For weld locations, only the Rx, Ry, Rz coordinates
are set. If, however, these coordinates are bigger or smaller than the range
defined in the Option window, they are set to the minimum or maximum value
(unless IgnoreLimitations is set to True).

• Relocate — This element describes relocating locations according to the
difference between two TCP frames. For example, if you change a weld gun
for another gun with a different x-axis.
o Add the following to the customized motion XML file:
o Also add the following to the customized motion XML file:
o To create this UI:

• AddLoc — This element describes the creation of a new via location and
setting its coordinates in degrees (double) value. In the AddLoc element, the
user should define what to do with the new via location. Outside the AddLoc
element, the system checks again that the filter is on the fixed operation. It
then continues with the new output of the filter.
If several locations pass the action filter, each location entering the
operation may change the location pointed to by RefLoc.

• ActionRef — This element describes a reference to a single existing action
and is for reusing of the XML action definitions.
ActionFilter content example:


A filter determines what object types the action is shown.

Path template customization example
Purpose
In this topic, you learn how to create an example robot path template customization
.XML file.
Objectives
• Learn more about how to create a Path Template file.

Path template example basics
In this lesson, you describe how to create an example robotic path template
customization file and use it in Process Simulate.
For example:
You want to define a path template XML to:
• Give the abilities to apply all defined path templates
• Give the abilities to apply specific path templates:

o Change the color of all via locations in the path to black
o Add a location before the first location in the path, offset -100 along the
X-axis, and 100 along the Y-axis.
o Add a location before a location, offset -5 along the X, add an _01 suffix
to the name, and set its color to yellow. Also on these locations: set the
zone to z30, the speed to v1000, and the motion type to 1 (joint motion).

o Add a location after a location, offset -5 along the X, add an _02 suffix to
the name, and set its color to blue. Also on these locations: set the zone
to z80, the speed to v600, and the motion type to 1 (joint motion).

Example path template
In the basic robotics training, you used a default controller path template. Here are
the contents of that file named RobotSim.xml (which is part of the training data):
You do not need this XML file for this course. It is provided for reference.
<RobotController Name="Default" Version="All">

<ActionList>
<!– *************************************** –>
<!– Add spot approach and retract locations–>
<Action Name="Spot-weld Templates|Add Spot Approach Loc" LocRange="First"
Description="For the selected weld operation: \n - Add a via before the first weld
\n - Set the app/ret locs to fine zone, joint motion type, \n with a speed of 100%">
<AddLoc Name="approachViaLoc" Placed="Before" RefLoc="FIRST"
RelX="-100">
<Param Name="Zone" Dynamic="True" Value="fine"/>
<Param Name="Motion Type" Dynamic="True" Value="PTP"/>

<Param Name="Speed" Dynamic="True" Value="100"/>
</AddLoc>
</Action>
<Action Name="Spot-weld Templates|Add Spot Retract Loc" LocRange="Last"
Description="For the selected weld operation: \n - Add a via before the first weld
\n - Set the app/ret locs to fine zone, joint motion type, \n with a speed of 100%">
<AddLoc Name="retractViaLoc" Placed="After" RefLoc="LAST" RelX="-100">
</AddLoc>
</Action>
<!– Setup spot weld locations–>
<Action Name="Spot-weld Templates|Setup Spot-weld Locs"
LocationTypes="Weld"
Description="For the selected weld operation: \n - Set the seam locs to nodecel
zone, linear motion type, \n with a speed of 150 mm/sec (350 IPM)">

<Param Name="Motion Type" Dynamic="True" Value="LIN"/>
</Action>
<!– Apply all spot templates–>
<Action Name="Spot-weld Templates|Apply All" LocRange="All"
Description="Add Spot Approach Loc, \n Add Spot Retract Loc, \n and Setup
Spot-weld Locs">
<ActionRef>Spot-weld Templates|Add Spot Approach Loc</ActionRef>
<ActionRef>Spot-weld Templates|Add Spot Retract Loc</ActionRef>
<ActionRef>Spot-weld Templates|Setup Spot-weld Locs</ActionRef>
</Action>
<!– *************************************** –>
<!– Add arc approach and retract locations–>
<Action Name="Arc-weld Templates|Add Arc Approach Retract Locs"
LocRange="First"

Description="For the selected continuous feature operation: \n - Add a via before
and after the seam \n - Set the app/ret locs to fine zone, joint motion type, \n
with a speed of 100%">
RelZ="100">
</AddLoc>
<AddLoc Name="retractViaLoc" Placed="After" RefLoc="LAST" RelZ="100">
</AddLoc>
</Action>
<!– Setup arc seam locations–>
<Action Name="Arc-weld Templates|Setup Arc-weld Seam Locs"
LocationTypes="Seam Start,Seam End,Seam Middle"

Description="For the selected continuous feature operation: \n - Set the seam locs
to nodecel zone, linear motion type, \n with a speed of 150 mm/sec (350 IPM)">
<Param Name="Zone" Dynamic="True" Value="nodecel"/>
</Action>
<!– Apply all arc templates–>
<Action Name="Arc-weld Templates|Apply All" LocRange="All"
Description="Add Arc Approach Retract Locs \n and Setup Arc-weld Seam Locs">
<ActionRef>Arc-weld Templates|Add Arc Approach Retract Locs</ActionRef>
<ActionRef>Arc-weld Templates|Setup Arc-weld Seam Locs</ActionRef>
</Action>
<!– *************************************** –>
<!– Add paint approach and retract locations–>
<Action Name="Paint Templates|Add Paint Approach Retract Locs"
LocRange="First"

Description="For the selected continuous feature operation: \n - Add a via before
and after the seam \n - Set the app/ret locs to fine zone, joint motion type, \n
with a speed of 100%">
RelZ="100">
</AddLoc>
<AddLoc Name="retractViaLoc" Placed="After" RefLoc="LAST" RelZ="100">
</AddLoc>
</Action>
<!– Setup paint seam locations–>
<Action Name="Paint Templates|Setup Paint Seam Locs" LocationTypes="Seam
Start,Seam End,Seam Middle"

Description="For the selected continuous feature operation: \n - Set the seam locs
to nodecel zone, linear motion type, \n with a speed of 150 mm/sec (350 IPM)">
<Param Name="Zone" Dynamic="True" Value="nodecel"/>
</Action>
<!– Apply all paint templates–>
<Action Name="Paint Templates|Apply All" LocRange="All"
Description="Add Paint Approach Retract Locs \n and Setup Paint Seam Locs">
<ActionRef>Paint Templates|Add Paint Approach Retract Locs</ActionRef>
<ActionRef>Paint Templates|Setup Paint Seam Locs</ActionRef>
</Action>
</ActionList>
<ActionFilter>
</ActionFilter>
</RobotController>

Activities
In the Robotic path template customization example section, do the following

activities:
• ABB — Creating robotic path templates
• ABB — Using robotic path templates
• Comau — Creating robotic path templates
• Comau — Using robotic path templates
• Denso — Creating robotic path templates
• Denso — Using robotic path templates
• Duerr — Creating robotic path templates
• Duerr — Using robotic path templates
• Epson — Creating robotic path templates


• Epson — Using robotic path templates
• Fanuc — Creating robotic path templates
• Fanuc — Using robotic path templates
• IGM — Creating robotic path templates
• IGM — Using robotic path templates
• Kawasaki — Creating robotic path templates
• Kawasaki — Using robotic path templates
• Kuka — Creating robotic path templates
• Kuka — Using robotic path templates
• Nachi — Creating robotic path templates
• Nachi — Using robotic path templates


• NC — Creating robotic path templates
• NC — Using robotic path templates
• Panasonic — Creating robotic path templates
• Panasonic — Using robotic path templates
• Reis — Creating robotic path templates
• Reis — Using robotic path templates
• Staubli — Creating robotic path templates
• Staubli — Using robotic path templates
• Trallfa — Creating robotic path templates
• Trallfa — Using robotic path templates
• Universal — Creating robotic path templates


• Universal — Using robotic path templates
• Yaskawa — Creating robotic path templates
• Yaskawa — Using robotic path templates

Other XML customization topics
Purpose
In this topic, you learn about several other interesting features of the custom
XML files.
Objectives
• Using custom debugging
• Use multi editing of customized motion.
• Use the picture attribute.
• Add your own online help for customized dialogs.
• Centralize all xml files under single shared folder.
• Encrypt your customized xml files.


Custom XML debugging
For Custom OLP commands:

From the Teach Pendant right-click the command in the OLP commands list and
choose Show Layers or Customized Upload Parameter Checker.
For Custom Motion:
Can be done in the Path Editor by picking in the Custom Debug column and
choose Show Layers or Custom Checker.

Multi editing of customized motion
In order to set values for customized motion only once for several locations:
In the Path Editor, select several locations and click Set Locations Properties .
In the Set Locations Properties dialog box, set the process type for all locations,
and then select the Customized motion row, and click in order to open the
window.


Picture attribute
The picture in the dialog changes dynamically according to the combo box
selection. This aids you in Selecting the correct gun.
Picture is an optional attribute. Its value is the relative path from the
CustomizedPictures folder.
By default, the Picture path is relative to
..\eMPower\Robotics\Olp\CustomizedPictures, unless a CustomizedPath
is set in the rrs.xml file.
Under this folder, the user can manage pictures with nested sub folders as
desired. For example:
…\eMPower\Robotics\Olp\ CustomizedPictures \Laser\appzc5299228.jpg for
<ElmDef Picture =" Laser\appzc5299228.jpg ">Weld 10Am</ElmDef>
This attribute is available in Custom OLP files only.
The ..\eMPower\Robotics\Olp\CustomizedIcon folder was discussed

earlier. It is where the custom icon that shows in the upper left corner of
the dialog box is placed by default.



Add online help to customized dialogs
You can add your own online help to your customized dialogs.
To do this, add the Help attribute to the Dialog element adds a help button to the
user interface. This attribute is available in Custom Motion and OLP files.
The Help path is relative to .\eMPower\Robotics\Olp\CustomizedHelp (unless

you have set the CustomizedPath in the rrs.xml file).
If you wish to launch a URL, add the shortcut to the folder and the XML (using
the shortcut name and ".url").
• You can now launch the desired item over the net (internet or intranet).
• You can store all items on a single server and use shortcuts to access them.

Centralize all XML files in a shared folder
You can centralize all XML files in a single shared folder.

Once you place all the .XML files under a shared folder in single location,
you can point to this folder by adding the CustomizedPath attribute to the
Version element in the rrs.xml file. Typically, this folder would be a shared
drive such as or \\ilhzsomebody\Kuka-Krc. This folder would contain all of the
.XML customization folders that are found under the install folder (for example
C:\Program Files\Tecnomatix\eMPower\Robotics\OLP\Kuka-Krc (of course it
would not include the executables for the robot controller).
You do not learn aboutDataConfiguration, since it is beyond the scope of

this course. It is a way to create your own data types which can be used
in your custom .XML files.

Encryption of customized XML files
To protect customized .XML files, it is possible to use encryption. To do so, select

the Encrypt button from the Customized Commands XML Checker dialog box
(click Customized Command XML Checker in Process Simulate) and select
the .XML files to encrypt. The encrypted files are created with the .XMLC suffix
and can be safely shipped to contractors and suppliers. Process Simulate handles
both .XML and .XMLC files transparently.


Simulation keywords
Simulation keywords:
The following simulation keywords are supported and automatically substituted in
macros, robot modules, and XML simulation layers:
• ${Robot}
• ${ActiveGun}
• ${ActiveGunMainJoint}
• ${ActiveGripper}
• ${AutoTeach}: TRUE in AutoTeach simulation mode, FALSE otherwise
• ${MoveToSingleLocation}: TRUE if the Move To Location command has

been issued, FALSE otherwise
• ${Robot.Tcpf.X}, ${Robot.Tcpf.Y}, ${Robot.Tcpf.Z}: actual position of the

robot TCPF with respect to the active Object Frame in mm

• ${CurrentSimulationTime}: current simulation time in seconds
• ${UserName}: replaced with login name
• ${Date}: replaced with dd/mm/yyyy
• ${Time}: replaced with hh:mm:ss

Summary

• How to create an enhanced motion XML
• How to create a robotic template XML
• Other selected custom XML topics

Lesson 9
Other customizations


Purpose
To learn other types of customizations related to robotics.
Objectives
• Attributes of mfg features and locations.
• Showing custom attributes in the Path Editor.

Attributes of mfg features and locations
Purpose
In this lesson, you learn about mapping and viewing attributes of mfg features
and locations.
Objectives
• See an overview of the process.
• Create the file. to map attributes from mfg features to locations.
• View the attributes in the Mfg Viewer.
• View the attributes in the Robotic Parameters Viewer.

Basic data flow for locations and mfg features
There are topics in this training that describe how to perform each of these steps:
Configuration and setup of Process Simulate
1. Customize your environment and add additional object types and attributes.
See the TR41213 Process Designer/Process Simulate Data Management,
Variants, and Importing course.
2. Define additional tabs for the Properties dialog box to view custom attributes
in a more friendly way. See the TR41213 Process Designer/Process Simulate
Data Management, Variants, and Importing course.
3. Setup the RoboticParametersToMfgAttributes.xml file to map attributes

from mfg features to locations. Described in this training.
4. Setup the configuration file to show custom location attributes in the Path
Editor. Described in this training.
5. Define custom motion parameter or path template XML files that reference
the custom location attributes. Described in this training.

6. Setup custom download templates. Described in this training.
Data flow within Process Simulate

These steps are describes in the Process Simulate Basic Robotic Simulation and
Process Simulate Advanced Robotic Simulation courses.
1. Define new mfg features in Teamcenter, Process Simulate, or in an external
system and import via a Excel spreadsheet in Process Simulate.
2. Associate mfg features to parts and operations.
3. View mfg feature attributes in the Mfg Viewer.

Custom mfg feature attributes are available in the Mfg Viewer Customize
dialog box automatically.
4. Edit mfg feature custom attributes in the Excel spreadsheet or Properties

dialog box
5. Project the mfg features to create locations.
6. Edit the location custom attributes in the Path Editor.


7. View Mfg feature attributes in the Robotic Parameters Viewer.
8. Use the custom motion parameter and path templates.
9. Apply a custom download template.
10. Teach the locations to create the downloadable configurations.
11. (Optional) Download the waypoints file.
12. Download the main program file. This file can contain custom location
information.

Importing weld points or rivets

Configuring a mapping file
To map your own attributes, a RoboticParametersToMfgAttributes.xml file must

be created in the .\sysroot\General folder.
Attributes referenced in this file are case sensitive.
It follows this structure:

• RoboticParametersToMfgAttributesMapping — This tag has all
the mapping information within it. It can contain any number of
ParameterToAttributePair tags.
• ParameterToAttributePair — There is one of these tags for each

attribute mapping. It contains one RoboticParameterName tag and one
MfgAttributeNameMfgTypeName tag.
• RoboticParameterName — It can either refer to an existing attribute on

the location (shown in the Robotic Parameters Viewer), or It defines a new
attribute on the location.

• MfgAttributeName — The attribute name from the Mfg feature must be
entered exactly as it is shown in the Mfg Viewer (case sensitive).
o MfgTypeName — Specify the name of the mfg feature type to be used
that contains the mfg feature attributes.

Mapping attributes from mfg features to locations
There is no one file to specifically define location attributes (robotic parameters).

However, referencing a location attribute using one these techniques, defines
the location attribute:
• In a motion customization XML file (described earlier)
• In the mfg feature to location attributes mapping file

(RoboticParametersToMfgAttributes.xml)
You can map an attribute's initial value from an mfg feature to a location. This can
be done after the mfg feature is projected and the mapping file is setup.
• Unless overwritten, the value of the robotic parameter remains the same as
its related Mfg (and updates automatically when the Mfg value is changed).
• If you change the corresponding value on the location, it no longer

corresponds to the value of the Mfg attribute and the modified value on the
mfg is indicated by italic font in the Path Editor.

Weld point mapping example using standard attributes
For example, define relations between these mfg attributes and location attributes
on Process Simulate on eMS:
Because these are standard location attributes, they are already setup in
the Robotic Parameters Viewer, Path Editor, and Teach Pendant. So you
only need to setup the connection from the Mfg Viewer.
• Weld Time
o Shown as actionTime on a WeldPoint mfg in the Mfg Viewer.
o Shown as SW_TIME_ON_PT on a location in the Robotic Parameters

Viewer.
o Shown as Weld Time on a location in the Path Editor.
o Shown as Weld Time on a location in the Teach Pendant.
• Cool Down Time

o Shown as holdingTime on a WeldPoint mfg in the Mfg Viewer.

o Shown as SW_WAIT_TIME on a location in the Robotic Parameters
Viewer.
o Shown as Cool Down on a location in the Path Editor.
o Shown as Cool Down on a location in the Teach Pendant.
Here is the RoboticParametersToMfgAttributes.xml required mapping file.

<?xml version="1.0"?>
<RoboticParametersToMfgAttributesMapping>
<ParameterToAttributePair>
<RoboticParameterName>SW_TIME_ON_PT</RoboticParameterName>
<MfgAttributeName MfgTypeName="PmWeldPoint">actionTime</MfgAttributeNa
</ParameterToAttributePair>
<RoboticParameterName>SW_WAIT_TIME</RoboticParameterName>
<MfgAttributeName MfgTypeName="PmWeldPoint">holdingTime</MfgAttributeN
</RoboticParametersToMfgAttributesMapping>

Continuous mapping example using custom attributes
The following is an example of mapping a continuous Mfg attribute to a seam
operation attribute on Process Simulate on Teamcenter:
• Weld Time
o Shown as bl_sequence_no on a ArcWeld mfg in the Mfg Viewer.
o Shown as Test_ParamInt on a location in the Robotic Parameters

Viewer.

<RoboticParameterName>Test_ParamInt</RoboticParameterName>
<MfgAttributeName MfgTypeName="ArcWeldRevision">bl_sequence_no</MfgAtt

Rivet mapping example using custom attributes
For example, define relations between these mfg attributes and location attributes
on Process Simulate on eMS:
• Type
oShown as Type on a Rivet mfg in the Mfg Viewer.
oShown as Type on a location in the Robotic Parameters Viewer. o
Shown as Type on a location in the Path Editor.
• Diameter
oShown as Diameter on a Rivet mfg in the Mfg Viewer.
oShown as Diameter on a location in the Robotic Parameters Viewer. o
Shown as Diameter on a location in the Path Editor.


<RoboticParameterName>Type</RoboticParameterName>
<MfgAttributeName MfgTypeName="Rivet">type</MfgAttributeName>
<RoboticParameterName>Diameter</RoboticParameterName>
<MfgAttributeName MfgTypeName="Rivet">diameter</MfgAttributeName>

Adding attributes to the Mfg Viewer
After you have configured your custom attributes for mfg features, you can now
add them to the Mfg Viewer just like the out of the box attributes:
1. In Process Simulate, load a study.
2. In the Mfg Viewer click Customize .
3. In the Customize dialog box, browse under a group of attributes such as

MfgFeature, ContinuousMfg, or WeldPoint.
4. Select some attributes.
5. Click Add and click OK.

Activities
In the Attributes of mfg features and locations section, do the following activities:
• Looking at the existing mapping file

Showing custom attributes in the Path Editor
Purpose
In this lesson, you learn how to configure and show custom location attributes
(mapped from mfg features) in the Path Editor.
Objectives
• Look at the configuration file.
• Add the attributes to the Path Editor.
• See the attributes in the Set Location Properties dialog box.

Setting up the Path Editor for custom attributes
This XML file defines the attributes that are grouped by controller in the
Customize dialog box of the Path Editor. The name of the file is not important.
These files are located in the C:\ProgramData\Tecnomatix\Process
Simulate\14.1\Robotics\PathEditor\AvailableColumns folder.
When the software starts, all XML files are read from the folder and the content
combined. If more than one XML file is used and the same section name appears
in more than one file or if the section name is one of the already used groups such
as General, Default, or Fanuc-Rj, then the attributes are merged and appear
under the same node in the Customize dialog box.
Structure of the XML file:
• The Root tag starts and ends the file and can have as many Section tags
as needed.
• The Section tag represents a group of attributes. It can contain an unlimited

number of Column tags. It contains this attribute:

If Column tags (location attributes) are not defined in a Section, they
are displayed under the General node in Customize dialog box.
o The SectionName attribute is the name of the group of attributes such

as General, Default, or Fanuc-Rj.
• The Column tag describes a single column (attribute). It is a mandatory tag

and contains these attributes:
o Id — The ID is the attribute name as shown in the Robotic Parameters
Viewer. For custom attributes, this is the value shown in the mapping file.
For example: RRS_MOTION_TYPE.
o Header — The displayed header of the column. For example: you may
want the header for RRS_MOTION_TYPE to be Motion Type.
o Units — (Optional) The supported units are: angular, linear, mass,

time, and none. The units define whether the attribute value represents
a length, angle, etc. When units are specified, the attribute value is
converted according to the specified unit type and unit system that is
currently in use. For example: an attribute representing an angle is

stored internally in radians. To display it in degrees, you change the
current angular units in the Options dialog box to degrees (default).
o Alignment — (Optional) The attribute can be displayed: left, center

or right justified. The default is left justified. Alignment definitions are
not case sensitive.
o ValueType — The ValueType declares how the attribute values are

stored. The combination of the ValueType and of the DisplayType
should define the display format. The type definition is not case sensitive.
The available ValueTypes are:
■ Frame — The name of the selected frame is displayed.
■ String — Displayed as a string, or by the defined string per value if

the DisplayType is a Combobox.
■ Obj — The object ID is displayed.
■ Double — Displayed as a double (floating) number, or by the

defined string per value, if the DisplayType is a Combobox.

■ Bool — Displayed as a Boolean ("True" or "False"), as an integer
("0" or "1"), or by a defined string per value. It depends on the
DisplayType definition.
■ Int — Displayed as integer, or by a defined string per value. It

depends on the DisplayType definition.
o Access —The access to the attribute value can be "R" for read only,
"RW" for read and write, or "RX" for read and execute.
• Display — (Optional) A tag that contains both the value limitations (min and
max values) and the displayed text for attribute value. It is located under the
Column tag and contains the following optional attributes:
o MaxVal — The maximum displayed value. If the attribute value is bigger
than this value, the word "Illegal" is displayed instead of the attribute
value. This attribute is relevant for the integer, double float, and time
ValueType only.
o MinVal — The minimum displayed value. If the attribute value is smaller

than this value the word "Illegal" is displayed instead of the attribute

value. This attribute is relevant for the integer, double, float, and time
ValueType only.
o DisplayType — (Optional) Its main purpose is editing the attributes

and defining the value's representation. The display type can be one
of these types:
■ Combobox — used to define arrays (multi value attributes). Using
the combobox DisplayType requires the definition of the ComboDef
tag.
■ Int — used for Boolean and int ValueType.
■ Double — used for double (and floating) ValueType.
■ String — used for string, obj, and frame ValueType.
• The ComboDef tag contains the ElmDef tag. This is used for displaying
meaningful string value instead of the value of the attribute. The ComboDef
is located under the Display tag. The ElmDef tag contains two attributes:
o Name — The meaningful display value.

o Value — The attribute’s real value that causes the above name to be
displayed. If for a given attribute value no set of ElmDef is defined, the
real value is displayed instead.
<Root>
<Section SectionName="Fanuc-Rj">
<Column Id="KRC_GUN_WAIT" Header="gun wait" >

<Display MaxVal="500" MinVal="0" DisplayType="combobox">
- <ComboDef>
<ElmDef Name="no wait" Value="0" />
<ElmDef Name="wait" Value="1" />
</ComboDef>
</Display>
</Column>
</Section>
</Root>

Training sample file
<Root>
<Section SectionName="Default">
<Column Id="Diameter" Header="Diameter" ValueType="double" Access="RW">

<Display DisplayType="double"/>
</Column>
<Column Id="Length" Header="Length" ValueType="double" Access="RW">

</Column>
<Column Id="Stack_Max" Header="Stack Max" ValueType="double" Access="RW"

</Column>
<Column Id="Stack_Min" Header="Stack Min" ValueType="double" Access="RW"

</Column>
<Column Id="Cycle" Header="Cycle" ValueType="string" Access="RW">

<Display DisplayType="string"/>
</Column>

<Column Id="Sealant" Header="Sealant" ValueType="string" Access="RW">
</Column>
<Column Id="Type" Header="Type" ValueType="string" Access="RW">

</Column>
</Section>
</Root>

Adding attributes to the Path Editor
After you have configured your custom attributes for locations, you can now add
them to the Path Editor just like the out of the box attributes:
1. In Process Simulate, load a study.
2. In the Path Editor click Customize .
3. In the Customize dialog box, browse under a group of attributes such as

General, Default, or Fanuc-Rj.
4. Select some attributes.
5. Click Add and click OK.

Activities
In the Showing custom attributes in the Path Editor section, do the following
activities:
• Setting up and seeing custom attributes in the Path Editor

Summary

• Attributes of mfg features and locations.
• Showing custom attributes in the Path Editor.

Lesson 10
Final comments

Final comments

Final comments
Purpose
To various other interesting topics related to robotics that have not been covered
in the previous courses.
Objectives
• An overview of creating an OLP procedure
• How to put it all together.

Creating an OLP procedure (putting it all together)
Purpose
In this topic, you get an review of the multi-step OLP procedure.
Objectives
• Review the multi-step OLP procedure.

A multi-step OLP procedure
An OLP/calibration procedure definition should be a goal of anyone attempting

an OLP procedure of any size. It enables the OLP provider to efficiently program
and calibrate a line of robots without wasting the time allowed for the task. An
overview of a sample procedure is outlined below.
A Multi-Step OLP Procedure:
1. Prepare the OLP materials — This step is also accomplished by the
Process Simulate user, who create the program files, and prepare the OLP
documentation, which is a reproduction of the scene layout, gun mounting,
and locations of calibration points.
2. Verify robot and scene installation — This step is done by the robot
programmer, who uses the OLP materials to verify that the robot, tool, and
scene infrastructure match the Process Simulate layout.
3. Generate robot program and download — The final step is combined

action by the process designer and robot programmer. The user creates the
robot program, which is input by the robot programmer.


Putting it all together
At the beginning of this class you had little or no knowledge of Process Simulate.
Through class you have been exposed to many Process Simulate features and
had time to practice what you have seen. You must continue to use this tool after
class in conjunction with other users in your company, additional training classes,
and Siemens PLM Software services personnel in order to become an expert.


Where do you go from here?
If you want to learn about Process Simulate on Teamcenter, try these classes:
• TR43101 – Process Simulate on Teamcenter Part Flow Simulation
• TR43106 – Process Simulate on Teamcenter Human Simulation
• TR43115 – Process Simulate on Teamcenter Basic Robotic Simulation
• TR43215 – Process Simulate on Teamcenter Intermediate Robotics (CEE)
• TR43315 – Process Simulate on Teamcenter Advanced Robotics (OLP)

Final notes
Normally at some point you would begin developing simulative operations (paths)
and organizing them within a process. However since the steps to develop and
analyze paths for different types of operations are a little different (and are a
little different for each type of simulative operation), there are other courses
to describe it.
• Device and robotic processes – Covered in more detail in these
courses:MT43115, MT43215, and MT43315.
• Human process – Covered in more detail in this course: MT43106.
• Assembly processes without the constraint of a human or a robot – Covered

in more detail in this course: MT43101.

Summary

• An overview of creating an OLP procedure
• How to put it all together.


MT43315 S 141 v5 Advrobotics

Uploaded by

Copyright:

Available Formats

MT43315 S 141 v5 Advrobotics

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MT43315 S 141 v5 Advrobotics

Uploaded by

Copyright:

Available Formats

What are the main topics covered in the document?

What are the main topics covered in the document?

What are the steps involved in creating an OLP procedure?

What are the steps involved in creating an OLP procedure?

Process Simulate on TC Advanced Robotics

Restricted © Siemens AG 2018

Page 1 Siemens PLM Software

Restricted © Siemens AG 2018

Page 2 Siemens PLM Software

Restricted © Siemens AG 2018

Page 3 Siemens PLM Software

• Creating Robot Programs

• Inverse Kinematics Solution Selections (Robot Configurations)

Page 4 Siemens PLM Software

• Testing the Teach Pendant and Fixing Setup Problems

• Robot Controller Specific Signals, Commands, Frames, Setup, and Motion

• Templates, Uploading, and Downloading

• ESRC OLP Commands

• OLP Command XML Customization

• Motion XML Customization

• Robotic Path Template XML Customization

• Other XML Customization Topics

• Other Related OLP Topics

Page 5 Siemens PLM Software

Learning tracks for the Tecnomatix application are

• TR43106 – Process Simulate on Teamcenter Human Simulation

• TR43115 – Process Simulate on Teamcenter Basic Robotic Simulation

• TR43215 – Process Simulate on Teamcenter Intermediate Robotics

• TR43315 – Process Simulate on Teamcenter Advanced Robotics

Restricted © Siemens AG 2018

Page 6 Siemens PLM Software

Restricted © Siemens AG 2018

Page 7 Siemens PLM Software

Restricted © Siemens AG 2018

Page 8 Siemens PLM Software

• An overview of the Process Simulate data model.

• The basics of robot models.

• How to setup the RCS, RRS, and robot controller.

• The steps for process generation and process to program.

Page 9 Siemens PLM Software

• How to prepare the scene for OLP.

• Some sources of error in OLP.

Restricted © Siemens AG 2018

Page 10 Siemens PLM Software

Restricted © Siemens AG 2018

Page 11 Siemens PLM Software

This course focuses on portion of Process Simulate known as Process Simulate

• Downloading — the process of exporting a text file of the program from

o For example: Downloading from Process Simulate exports a file from

Page 12 Siemens PLM Software

o For example: Uploading to Process Simulate imports a file into the

Here is the basic process. A program can be originated in Process Simulate or

Restricted © Siemens AG 2018

Page 13 Siemens PLM Software

• Program — A collection of paths (and or locations) used for downloading.

Page 14 Siemens PLM Software

Restricted © Siemens AG 2018

Page 15 Siemens PLM Software

Restricted © Siemens AG 2018