Call Path Basics

COPYRIGHT
Proprietary & Restricted Rights Notice
_____________________________________________________
This software and related documentation are proprietary to Tecnomatix Technologies Ltd.
2008 Tecnomatix Technologies Ltd. All rights reserved.
Portions of this manual are proprietary to Siemens Product Lifecycle Management Software Inc. Copyright
2008 Siemens Product Lifecycle Management Software Inc. All Rights
Reserved. All trademarks belong to their respective holders.
3D Labs is a registered mark or trademark of 3Dlabs, Inc. or its subsidiaries in the US and other countries.
Adobe is a registered mark or trademark of Adobe Systems Incorporated or its subsidiaries in the US
and other countries. Apache is a registered mark or trademark of The Apache Software Foundation
or its subsidiaries in the US and other countries. ATI is a registered mark or trademark of ATI
Technologies Inc. or its subsidiaries in the US and other countries.
AutoCAD is a registered mark or trademark of Autodesk, Inc. or its subsidiaries in the US and other
countries.
HP is a registered mark or trademark of Hewlett-Packard Company or its subsidiaries in the US and other
countries.
IBM is a registered mark or trademark of International Business Machines Corporation or its subsidiaries in
the US and other countries. Intel is a registered mark or trademark of Intel Corporation or its subsidiaries in
the US and other countries.
Java and iPlanet are registered marks or trademarks of Sun Microsystems, Inc. or its subsidiaries in the
US and other countries. Microsoft is a registered mark or trademark of Microsoft Corporation or its
subsidiaries in the US and other countries. Microstation is a registered mark or trademark of Bentley
Systems, Incorporated or its subsidiaries in the US and other countries. Netscape is a registered mark
or trademark of Netscape Communications Corp.or its subsidiaries in the US and other countries.
NVIDIA is a registered mark or trademark of NVIDIA Corporation or its subsidiaries in the US and
other countries.
Oracle is a registered mark or trademark of Oracle Corporation or its subsidiaries in the
US and other countries. Siemens is a registered mark or trademark of Siemens Corp. or
its subsidiaries in the US and other countries. TiCon is a registered mark or trademark
of MTM or its subsidiaries in Germany and other countries.
UNIX is a registered mark or trademark of The Open Group or its subsidiaries in the US
and other countries. VizStream is a registered mark or trademark of RealityWave Inc. or
its subsidiaries in the US and other countries.
RAMSIS is a trademark of Human Solutions. The Software is sub-licensed by Human Solutions GmbH,
Kaiserslautern, Germany. Body Builder is a trademark of Human Solutions. The Software is sub-licensed
by Human Solutions GmbH, Kaiserslautern, Germany

Call Path Basics

Material Flow Support for Called Path Execution

Only robotic controllers can control the execution of Called Paths. The line simulation engine
(CEE/OPC/PLCSim engine) is not aware of Called Paths and therefore these are not connected to the
material flow. Connecting Called Paths to the material flow process enables the system to pass parts
consumed by preceding/calling operations to the called path.

Connecting Called Paths to Material Flow Processes

In a line simulation, when a robotic controller executes a Called Path command (or any command that calls
a robotic operation from within another robotic operation), it notifies the robotic engine (which in turn notifies
the line simulation engine) that a Called Path is to be executed. The only data required by the line simulation
engine are the called operation and the calling operation. The engine then performs the material flow
calculation for the called operation (as it does for any operation) and assigns it the correct part appearances.
The system checks for the existence of the parts consumed by the Called Path (as with any operation):
At the beginning of execution of the Called Path
On each location (but not on events set on the operation)
After the line simulation engine completes the material flow calculations for the Called Path, the robotic
controller resumes control and execution proceeds as in previous releases. When the system completes
execution of the Called Path, it again notifies the line simulation engine. The line simulation engine
unassigns the part appearances from the Called Path and performs material flow finalizing procedures (as it
does when any operation finishes running).
Notes:
Connecting a Called Path operation to a material flow process is performed only if the Called Path
operation is not running concurrently as a regular operation or as a path called from within another
operation.
If an operation is currently running as a Called Path, the simulation engine blocks it from running regularly.
This behavior should be applied to all controller implementations, including the default controller, and for
all commands that call robotic operations (CallPath, CallProg, or a macro that contains one of these
commands).

Called Path Part Sources

To accurately calculate the material flow for the Called Path operation, the system determines from which
operations the Called Path can receive the parts it consumes. The parts consumed by the Called Path can be any
of the following:
Parts that are accumulated by the calling operation (are assigned to the calling operation or to one of its
preceding operations).
Parts that are accumulated by the Called Path itself (are assigned to one of its preceding operations).
Parts that are produced by the Called Path itself (if the part is listed in its Parts-to-Produce list).
It is important to distinguish between the Scheduler and the Robotic operation scenarios, as follows.

Call Path Basics

Scheduler Operation Scenario

In this case (used by default by Volvo), the calling operation has no functionality other than calling paths. The
operation itself has no location and the commands Call Path is set directly on it. Calling the operation performs
scheduling of other paths but no other real actions. The following figure demonstrates the implementation of
this scenario.

The scheduler operation Scheduler_Rob1 is responsible for the execution of Robot1 robotic operations,
while the scheduler operation Scheduler_Rob2 is responsible for the execution of Robot2 robotic operations.
The operations (paths) called by the schedulers appear in the regular Gantt structure. The links between them
imply the material flow between them.
Note: A Called Path operation can be connected to either another Called Path or to another regular operation
(that is not executed by a Call Path command).
It is the users responsibility to block running these paths in the regular fashion (by setting their transition
condition to False) and ensure that the operations are executed only through Call Path commands.
Note: When activating the segmentizer tool to divide robotic operations into multiple segments, the transition
condition that was set on the original operation should now be set as the transition condition for the last
segment.
The above figure shows that part p1 is produced by Rob1Op1 (p1 is included in the Rob1Op1 Parts-toProduce list). The part is moved to the operation succeeding Rob1Op1. This is also a Called Path and the part
is then moved to an external operation - a flow operation not controlled by the calling operation. The external
operation uses the part and moves it to Rob2Op1 which is also a Called Path (of another robot). The result
is that Rob2Op1 received the part from its own preceding operation.
In this scenario, the real material flow structure of the Called Path is defined in the regular Gantt view, while its
execution logic is defined in the OLP commands of the calling operations.
The following example demonstrates a more complex scenario:

Call Path Basics

In this scenario, Scheduler_Rob1 and Scheduler_Rob2 are linked and create double structures of material
flow (Called Paths and the schedulers). All the robotic operations consume parts p1 and p2. The Called
Paths receive p2 from their calling operation (the scheduler operations). p2 does not move along the links
(as p1 does), rather, the Called Path borrows p2 from the calling operation for the duration of path
execution only. Thus, p2 is lent to Rob1Op1, then borrowed by Scheduler_Rob1 for Rob1Op2, moves to
Scheduler_Rob2 (because of the link between Scheduler_Rob1 to Scheduler_Rob2), and is then lent again to
the paths. Additionally, p1 (the part that was produced by Rob1Op1) does not move to Scheduler_Rob2 and its
succeeding operation.
The scenario described above can be implemented even if each scheduler operation belongs to a different
compound operation. There can be no links between Rob1 operations and Rob2 operations (because they
belong to different compounds). Refer to the following figure:

Call Path Basics

Links between Station1 to Station2 are considered to be links between the last operations (the operations
that have no outgoing links) in the first compound (Station1) and the first operations (the operations that have
no incoming links) of Station2. As scheduler_Rob1 has no outgoing links, p2, which it consumes, is passed to
the first operations of Station2. Scheduler_rob2 is such an operation, and it receives p2. Because Rob2Op1
has also no incoming links, it can receive p2 directly from Station1 and does not need to borrow it from its
calling operation. p1 is passed to the Station2 operations because it is consumed by flowOp which has no
outgoing links in Station1, and is therefore considered as linked to the first operations of Station2
(Scheduler_Rob2 and Rob2Op1).

The Robotic Operation Scenario

In this case, a regular weld operation welds part p. Refer to the following figure:

In this scenario, weld_op starts welding part p. When it reaches via1, there are two conditioned Call Path
commands according to the current state, weld_x and/or weld_y. One of these is called and it continues
welding other sections of the same part p. After this, weld_op continues to its next weld points. In that case,
the user may want to block the Called Paths from participating regularly in the material flow (as illustrated
above). The operations weld_x and weld_y that require part p, borrow it from weld_op (the calling
operation).

Nested Called Paths

This behavior is relevant for executing Called Paths at all levels. If a Called Path that itself contains a Called Path
command calls another Called Path, the grandchild Called Path receives parts from its preceding operations,
as well as the parts that are accumulated by its calling operation - the grandfather calling operation.