Importing a Robot Program

This procedure describes how to load an existing robot program into a V5 workcell so that the program is represented as a robot task.

This requires a V5 .CATProcess document into which you wish to load the program. It must contain at least one Robot task, although that task can be empty. You must also have the robot used in the program already loaded into the resource list.

Unparsed robot language commands can also be added to the comment fields with a "Robot Language:" prefix which will distinguish them from standard comments. The Robot Language: prefix will automatically be added while importing and removed during robot program creation.

Click Import Robot Program
Select the robot task into which you wish to import the program.
A dialog box appears asking for the location of the robot program.

Select either:

a native robot language file or
an XML file that complies with OLP XML file format rules.

If you select an XML file, OLP will validate the XML format. The set of XSchema rules implemented in the default OLP.xsd file will be applied to the contents of the selected XML file. In case of unrecognized XML tag names or incorrectly specified tag values (including tag sub-structure, data types, and data ranges), an error message will appear and uploading will cease.

Users can derive their own schemas from OLP.xsd either by extension or by restriction or they can include OLP.xsd into their schemas. Users can extend OLP.xsd to verify that user customizable portions of OLP XML (e.g., ParameterData, AttributeList, and Action tags -- and all of their children) are correctly formatted.

An Upload Progress bar appears and the following messages may be displayed:
Uploading Activities, please wait.

Creating activity <current_number> of <total_number> from XML.

Preparing to show upload report.
The validation also provides information about where in the program the fault occurred. An example error message appears below.

If you select a native robot language file, a dialog box appears asking for the location of the robot program translator (or parser file).
Click Open.
The Uploading Method dialog box appears, asking whether the coordinates should be set relative to a part or the robot base coordinates.

Select the desired uploading method.

If you select Robot Base Coordinates, select OK and the program is imported.
If you select Part Coordinates, you must also select a part or profile and may select more than one. (To select more than one, keep selecting the Next button until all the desired profiles/parts have been selected.)

Select OK.
The robot program appears in the form of a V5 robot task.

The operations in the task can include IO activities, delay activities, or spot welding activities. In addition, tags and the attributes of an operation can be imported or uploaded.

In addition, if comments have been added to the program, including comments written in Kanji characters, they can be roundloaded -- that is, imported into V5, exported into a native robot language or XML, and re-loaded into V5. In V5, comments appear in Attributes sub-node of the Task List node on the PPR tree.

	Uploading Fixed TCP Positions In most cases, Fixed TCP targets will be uploaded in part coordinates, and is applicable in both uploading from a translator and uploading from XML file cases. Only in a case of fully-generated XML description, that includes all properly set XML attributes for "Tag" XML element, will it be possible to upload Fixed TCP positions in Robot Base coordinates. That means that in the case of an XML file roundload (upload of previously downloaded XML file) both upload methods of "In Robot Base Coordinates" and "In Part Coordinates" will produce the same correct result. When using an uploader to create Fixed TCP targets, that upload needs to be expressed in part coordinates, since robot programs generally do not contain sufficient information to create entire "Tag" XML element description (including all of its attributes). You will be prompted to map object frame profile names, as specified in the XML file, with the parts in the PPR tree. For a Fixed TCP case, it is essential to map the object profile name associated with a robot motion activity that has a stationary tool profile type, with the part to which the Fixed TCP tag point is going to be attached, as shown in the dialog box.
	Creating Tags To allow unambiguous tag creation, two XML attributes are available for "Tag" XML element: "PathToPart" and "AttachmentType". Here is the entire XML description of the "Tag" XML element (using XML pseudo code): <Tag TagGroup="STRING(TagGroup.1)" AttachedToPart="STRING(Box.1)" AttachmentType="Local OR ModifyReference" PathToPart="STRING(SK16.1/Base.1/Box.1)">STRING(Tag1)</Tag> Attribute definitions are: TagGroup -This attribute specifies the name of existing tag group which contains this tag. If that name does not exist, a new tag group will be created. AttachedToPart - This attribute reveals the part name that owns the tag group described above. AttachmentType - This attribute allows only two values: "Local" and "ModifyReference". "Local" states that tag group is going to be attached to the defined part and that it will not be saved along with that part in its product document. The tag group is listed under the TagList under the Resource List with a link with the AttachedToPart. "ModifyReference" states that tag group is going to be attached to the above part, that it will be located underneath that part in PPR tree (as its child), and that it will be saved along with that part in its product document. PathToPart - This attribute "/" separated string that points to the part location in the PPR tree, starting from the top level in resource or product list and going deeper, following lower branches until the part specified with AttachedToPart name is reached. This attribute is needed since AttachedToPart attribute is not sufficient. In the product and resource context there can be more then one part with the same name. So, name alone will not necessarily give accurate results. By specifying the PPR path to search that ambiguity will be eliminated. An enhancement checks to determine if a tag point with the same name and the same location exist in the owning tag group, and if so a new tag point would not be created, but the existing tag point would be reused instead. If an XML description contains the TagGroup attribute, a new tag group with the specified name will be created, but if that attribute is missing and the upload is not in part coordinates, a new unattached tag group will be created under the robot node in the PPR tree and named, by default, OLPTagGroup. If an upload is expressed in part coordinates and you have mapped object frames with V5 part names and at the same time the XML description contains AttachedToPart and/or PathToPart attributes, the parts that you have selected will take precedence and will be used as reference parts for upload. However, Tag group names will always be as defined in XML.
	Defining Object Frames in Fixed TCP It is important to note that object frames in V5 are always defined with respect to the World frame. That concept puts users in a difficult position when they need to create them with respect to the mount frame, as is needed in Fixed TCP case for most of the robot controllers. Furthermore, values that users set for object frame offsets in fixed TCP case are completely disregarded, if "Apply To All Targets" button is unchecked, since robot always ends up at the target location. In order to create an offset from the tag (a target location with an offset in case of tag target) when robot is moving in fixed TCP mode, robot motion activity referenced object frame profile needs to have "Apply To All Targets" button turned on during its creation.
	Identifying Frames of Reference for Tag Targets Frame of reference for a tag target, relevant for both upload and download, depends on the values of both object and tool frame profiles associated with the robot motion activity that contains that tag. There are four different cases here: If the object frame offset is zero and the tool is mobile (mounted on a robot), the frame of reference is robot base frame. If the object frame offset is non-zero and the tool is mobile, the frame of reference is the object frame (with its offset defined with respect to the World frame). In case of tag targets, if the `Apply To All Targets` button is turned on, robot target will be shifted from the tag location by the value of the object frame offset. If the object frame offset is zero and the tool is stationary (fixed TCP case), the frame of reference is robot's mount frame. If the object frame offset is non-zero, the tool is stationary, and `Apply To All Targets` button was turned on when the referenced object frame profile was created, the frame of reference is the object frame. In this case, the robot target will be shifted from the tag location by the value of the object frame offset. If the `Apply To All Targets` button was turned off, the frame of reference is the same as above - the robot's mount frame. NOTE: These frames of reference are relevant only for OLP XML. Individual robot language translators may use different frames of reference based on robot language specification.