Robotics File-based Design Import

File-based Design Import (FBDI) enables content migration from V5 to 3DEXPERIENCE.

This topic specifies the import correspondences between V5 data types and 3DEXPERIENCE content types, and the import result. The statuses for import results are fully imported, partially imported, and not imported (-).

This page discusses:

V5 to 3DEXPERIENCE Data Import Table

The following table describes import correspondences between V5 file-based data and 3DEXPERIENCE content. The statuses for import results are fully imported, partially imported, and not imported (-).
V5 Data Type 3DEXPERIENCE Content Type Import Result
Device Controllers Device Controller Fully imported
Controller Data: Profiles (Tool, Motion, Accuracy, Object Frame) Device Controller Data Fully imported
Controller Data: Home Positions Device Controller Data Fully imported
Controller Data: Home Position Data: Tool Tips -
Controller Data: Travel Limits Device Controller Data Fully imported
Controller Data: Joint/TCP Speed/Acceleration Limits Device Controller Data Fully imported
Controller Data: Inverse Kinematics Device Controller Data Fully imported
Controller Data: Inverse Kinematics Data: Multiple Kinematics Chains -
Controller Data: Applicative Profiles -
Controller Data: Time Tables -
Frames of Interest (FOI) Migrated into either an axis frame or a port + axis frame Fully imported
Mounted Devices Engineering Connections Fully imported
Auxiliary Devices Control Device Fully imported
Robot Tasks Task Fully imported
Device Tasks -
Operations Not Migrated, but children of operations are migrated Partially imported
Robot Motion Activities Robot Motion Operation Fully imported
Other detailing activities not listed above -
Tags and Tag Groups Tags and Tag Groups Fully imported
RRS Connection Attributes RRS Connection Attributes Fully imported
Workspace Envelopes Fully imported

Considerations

You should take the following considerations into account:

Controllers

The following types of controller data are migrated from V5 to 3DEXPERIENCE:

  • Home Positions
  • Travel Limits
  • Joint/TCP speed/acceleration
  • Controller profiles (Tool, Motion, Accuracy, Object Frame)
  • Inverse kinematics.

V5 and 3DEXPERIENCE have different controller structures, as noted in the chart below. In general, migrating data into 3DEXPERIENCE reduces the number of instance controllers. The most important controller data is preserved.

Controller Data On V5 RC On V5 IC On 3DEXPERIENCE RC On 3DEXPERIENCE IC
V5 Robots V5 Devices
Home Positions Yes No Yes Yes
Travel Limits Yes No Yes Yes
Joint Speed/Accel Limits Yes No Yes Yes
TCP Speed/Accel Limits Yes Yes Yes Yes
Controller Profiles Yes Yes Yes Yes
Inverse Kinematics Yes No Yes No
D5 Robots D5 Devices
Home Positions Yes Yes Yes Yes
Travel Limits Yes Yes Yes Yes
Joint Speed/Accel Limits D5 No Yes Yes
TCP Speed/Accel Limits D5 No Yes Yes
Controller Profiles Yes Yes Yes Yes
Inverse Kinematics D5 No Yes No
  • Yes: Data is stored o the indicated controller type
  • No: Data is not stored on the indicated controller type
  • D5: Data is stored in the D5 data file and cannot be viewed/edited in V5.
  • IC: Instance Controller
  • RC: Reference Controller
Robot Controllers
During import of a robot, the V5 reference controller data is migrated onto the 3DEXPERIENCE reference controller. The V5 instance data from the highest level instance controller is migrated onto the single 3DEXPERIENCE instance controller. Data on other instance controllers is not migrated. If multiple instances of the 3DEXPERIENCE instance controller owner exist in V5, multiple V5 instance controllers will try to write to the same 3DEXPERIENCE instance controller. Only the data from the last instance controller to be processed is used in 3DEXPERIENCE. You can not control the order of instance controller processing.
Device Controllers
V6 devices have only a single reference controller and no instance controllers. During import of a device from V5, the highest-level instance controller is migrated onto the 3DEXPERIENCE reference controller. Data on other instance controllers and the reference controller is not migrated. The exception to this are V5 devices (devices whose mechanism is defined in V5), which do not store any information on V5 instance controllers. They migrate data from the V5 reference controller to 3DEXPERIENCE reference controller. If multiple instances of the reference device exist in V5, multiple V5 instance controllers try to write to the same 3DEXPERIENCE reference controller. Only the data from the last instance controller to be processed is used in 3DEXPERIENCE. You can not control the order of instance controller processing.
Note: If travel limits have not explicitly been defined for a robot in V5, the V5 Travel Limits command displays default values that may be drawn from the joint commands or other sources. The 3DEXPERIENCE Travel Limits command uses different logic to find these default values. As a consequence, an imported V5 robot that does not have defined travel limit values may display different values in that command between V5 and 3DEXPERIENCE.
Frames of Interest (FOI)

V5 FOIs are migrated based on their usage in 3DEXPERIENCE.

Tool and base frames are imported in 3DEXPERIENCE as a combination of axis system and ports, given they are used as part of being attached. The port is parented under first object found while traveling up the tree that has a mechanism.

Manufacturing frames are transformed into tags.

Other FOI are imported as axis systems, and are hidden.

Note: In order to successfully import a tool frame into 3DEXPERIENCE, a mechanism is also required. A tool frame is imported as a tool port, and a tool port is owned by a resource. A tool port cannot be created without specifying the resource type, and the mechanism provides the capability to define the type of resource.
Mounted Devices

V5 mounted devices are migrated into 3DEXPERIENCE as engineering connections. The connection is owned by the same resource that owns the instance controllers for the devices. If the lowest common parent for the driving device and the driven devices is not the instance controller owner, the migration of the V5 mounting cannot be done and a warning is displayed.

Migrating a mounted device involves converting the V5 attachment into a 3DEXPERIENCE engineering connection. A V5 attachment is between either a FOI or part on the robot and the origin of a weld gun. The position of the gun relative to the robot is stored as a transform. No FOI on the gun is used in the attachment.

A 3DEXPERIENCE engineering connect is an offset between two ports: a mount port and a base port. If the V5 robot has an FOI that is used in the attachment, the port created during migration of the FOI is used in the 3DEXPERIENCE engineering connection. Otherwise, a new axis system and port are created on the robot. A new axis system and port are always created on the weld gun.

Note: Mounting of V5 and D5 robots and guns are handled different in V5. D5 weld guns have their mount point at their origin while V5 weld guns have their tool point at their origin. The mount point for a D5 robot is defined in a mount frame in the D5 data that cannot be viewed with the V5 GUI.

Although you can choose the FOI for the gun base in the V5 Set Tool command, these selections are not persisted. Only the offset (transform) between the gun and robot is stored.

Location Object V5 Model V6 Model
Mount Point V5 Robot IK Data: Either mount part origin or mount offset (FOI) Axis/Port is created during import at the location.
Mount Point D5 Robot D5 UTool D5I creates axis/port during import. Mount finds it by name.
Base Point V5 Weld Gun FOI (But not used by mount plug) Axis/Port is created during import, coincident with the robot mount point.
Base Point D5 Weld Gun Origin Axis/Port is created during import, coincident with the robot mount point
Robot Tasks

Robot tasks in V5 process document are migrated into 3DEXPERIENCE Tasks. The only children of a robot task that are migrated are robot motion activities. Operations have no matching activity in 3DEXPERIENCE and migration skips them and move directly onto their children. No data on an operation is migrated other than its children. 3DEXPERIENCE robot tasks are created in a behavior representation under the same resource that owns the robot's instance controller.

Migration of Robot Tasks in Product Documents

With the correct settings, it is possible to define tasks in product documents. Tasks, like controllers, are copied whenever the document containing them is instantiated into another document. Only the copies in the document are displayed to the user when that document is open. All copies of tasks are imported to ensure that no task data is lost. To allow tasks to be differentiated, tasks imported from product documents have the document name appended to the task name. Tasks that come from process documents, even if they are copies of tasks from product documents, never have their name altered.

In the above example, the task and tags were created when the line document was open. The line was then parented under the zone. This created a copy of the task in the zone document. During import, two tasks are created in 3DEXPERIENCE, one from each document.

Migration of Robot Motion Activities

Four kinds of robot motion activities are migrated:

  • Tag
  • Tag target
  • Joint target
  • Home target

For each, the name, target, and sequencing migrate. The above diagrams for robot task migration also show how robot motion activities are migrated.

Migration of Device Move Activities

DELMIA V5 Workcell Sequencing allows for MoveDevice activities to be defined in the tree for an inverse or forward kinematic device. DELMIA V5 Assembly Process Simulation allows for a MoveCartesianActivity to be defined for an inverse kinematic device, and MoveHomeActivity and MoveJointsActivity activities for an inverse or forward kinematic device in the tree.

For inverse kinematic devices:

  • MoveDevice:

    A 3DEXPERIENCE RobotTask is created in the robot's rep-on-occurrence under the station with the same name as the V5 MoveDevice activity. A single 3DEXPERIENCE RobotMotion is created under this 3DEXPERIENCE RobotTask corresponding to the V5 MoveDevice activity. If the V5 MoveDevice has a Home target, the V6 RobotMotion has a target type of Home. If the V5 MoveDevice has a joint target, the V6 RobotMotion has a target type of Joint.

  • MoveCartesianActivity:

    A 3DEXPERIENCE RobotTask is created in the robot's rep-on-occurrence under the station with the same name as the V5 MoveCartesianActivity. A single 3DEXPERIENCE RobotMotion having a target type of Cartesian is created under this 3DEXPERIENCE RobotTask corresponding to the V5 MoveCartesianActivity activity.

  • MoveHomeActivity:

    A 3DEXPERIENCE RobotTask is created in the robot's rep-on-occurrence under the station with the same name as the V5 MoveHomeActivity. A single 3DEXPERIENCE RobotMotion having a target type of Home is created under this 3DEXPERIENCE RobotTask corresponding to the V5 MoveHomeActivity activity.

  • MoveJointsActivity:

    A 3DEXPERIENCE RobotTask is created in the robot's rep-on-occurrence under the station with the same name as the V5 MoveJointsActivity. A single 3DEXPERIENCE RobotMotion having a target type of Joint is created under this 3DEXPERIENCE RobotTask corresponding to the V5 MoveHomeActivity activity.

For forward kinematic devices:

  • MoveDevice:

    A V6 DeviceTask is created in the device's reference with the same name as the V5 MoveDevice activity. A single 3DEXPERIENCE DeviceMotion is created under this 3DEXPERIENCE DeviceTask corresponding to the V5 MoveDevice activity. If the V5 MoveDevice has a Home target, the 3DEXPERIENCE DeviceMotion has target type Home. If the V5 MoveDevice has a joint target, the V6 DeviceMotion has target type Joint.

  • MoveHomeActivity:

    A 3DEXPERIENCE DeviceTask is created in the device's reference with the same name as the V5 MoveHomeActivity. A single V6 DeviceMotion having target type Home is created under this 3DEXPERIENCE DeviceTask corresponding to the V5 MoveHomeActivity activity.

  • MoveJointsActivity:

    A 3DEXPERIENCE DeviceTask is created in the device's reference with the same name as the V5 MoveJointsActivity. A single V6 DeviceMotion having target type Joint is created under this 3DEXPERIENCE DeviceTask corresponding to the V5 MoveHomeActivity activity.

Migrating Tags and Tag Groups

V5 tag groups can be created in V5 process documents under the Resource/TagList. With the correct settings, tags can also be created in product documents. The above diagrams for robot task migration also show how tags and tag groups are migrated.

The rules for tag and tag group migration are:

  • If a tag group is migrated to 3DEXPERIENCE, all its tags are migrated with it.
  • If a tag group is owned by a product document, it is inserted under the same parent in 3DEXPERIENCE.
  • If a tag group is owned by a process document:
    • The tag group is created in 3DEXPERIENCE under the Resource, which is a child of the PPR Context, if no robot motion activities use any tag in the tag group.
    • Otherwise, the tag group is parented under the same resource that owns the task and that has the robot motion operations that use the tags. If multiple resources own multiple tasks that use tags from the same tag group, multiple copies of the complete tag group are created in 3DEXPERIENCE. These multiple copies are independent in V6 and changes to one tag group or tag do not affect the other copies.
Auxiliary Devices

In 3DEXPERIENCE, it is modeled as a control device. This is a product (without geometry) that is created specifically to own a controller that controls both the driving device and all its auxiliary devices. This replaces the separate instance controllers that otherwise would have been created. The control device is named after the instance name of the driving device. The driving device and its auxiliary devices must have the same immediate parent. If they do not, a warning is displayed during migration and no control device is created.

You cannot redefine auxiliary devices at higher levels in the tree. If this happens in 3DEXPERIENCE data, only the lowest auxiliary device definition is migrated.

  • Example: Suppose you have a station with a robot and two weldguns. While in V5:
    • The station is loaded and Gun1 is made an auxiliary device of the robot.
    • The station is added to a process document. Gun2 is added as an additional auxiliary device of the robot while the process document is open.
  • Result: When the process document is imported into 3DEXPERIENCE, the control device only controls the robot and Gun1.
Applicative Profiles

Applicative profiles are traditionally profiles that you create as a user. In addition to user-created profiles, certain DELMIA apps (such as Realistic Robot Simulation and Offline Programming) also create applicative profiles. A V5 applicative profile has a feature dictionary associated with it. In 3DEXPERIENCE, the profiles are distinguished between Applicative profiles (those that have a corresponding CATFct file) and User profiles (those that do not have corresponding CATFct file).

Importing RRS and OLP Applicative Profiles

Applicative profiles created by Realistic Robot Simulation and Offline Programming in V5 are automatically imported into 3DEXPERIENCE as Applicative profiles. Each instance of a V5 applicative profile is imported as 3DEXPERIENCE Applicative profile instance. Since V5 and 3DEXPERIENCE applicative profiles may have different formats (due to obsolete and/or new attributes), attributes are imported according to a predefined mapping specification provided by RRS and OLP. No special tasks need to be performed to import RRS/OLP applicative profiles.

Importing a User Profile

A V5 user profile can be imported into 3DEXPERIENCE in either of two different ways. A default implementation of the applicative profile is provided that imports the V5 applicative profile as a user profile in 3DEXPERIENCE. If you do not want to use the default implementation and prefer to modify the user profile structure, or if you want to import the V5 applicative profile as user profile in 3DEXPERIENCE, you must perform the mapping via the CAA interface implementation (DNBIApplicativeProfileFBDI).

To import user applicative profiles you must store the corresponding V5 feature dictionary (.CATFct file) in a framework CNext\resources\graphic folder.

If the feature dictionary file is missing in the V6 <installation directory>\resources\graphic folder, a warning is displayed in the Import Report dialog box. and the applicative profile is not imported.

Importing Weld Time Tables

Applicative profiles created in DELMIA V5 Spot Welding are automatically imported into 3DEXPERIENCE as Controller Specific Applicative profiles. Each instance of a V5 applicative profile is imported as a 3DEXPERIENCE Applicative profile instance. Since V5 and 3DEXPERIENCE applicative profiles may have different formats (due to obsolete or new attributes), attributes are imported according to a predefined mapping specification provided by the Spot Welding app.

Import of the V5 WSUWeldTimeTable applicative profile is mapped to the 3DEXPERIENCE FanucWeldTimeTable controller specific profile as shown in the following table:

V5 Parameter Name V5 Value Type Description V5 Attribute Type 3DEXPERIENCE Implementation
WeldTimeTable user profile

-Index

 Integer Weld Condition Number User profile Attributes Controller specific DNBSpotFanucWeldTable

-WeldConditionNumber
WeldTimeTable user profile

-OpenTime

 Real Weld gun open time User profile Attributes Controller specific DNBSpotFanucWeldTable

same attribute
WeldTimeTable user profile

-HoldTime

 Real Weld gun weld time User profile Attributes Controller specific DNBSpotFanucWeldTable

same attribute
WeldTimeTable user profile

-CloseTime

 Real Weld gun close time User profile Attributes Controller specific DNBSpotFanucWeldTable

same attribute

Importing Device Attributes

All relevant OLP device attributes are migrated to the controller applicative profile, and all obsolete OLP device attributes are ignored. All user device attributes are migrated in a user profile instance labeled ImportedDeviceAttributes.

Note: RRS Device attributes are not migrated towards any profile, but are instead mapped to attributes on Motion Controller Attributes.

For example, in the figure above, the attributes PulseValue.1, PulseValue.2, PulseValue.3, ZeroValue.1, ZeroValue.2, and ZeroValue.3 are OLP Device Attributes that are migrated to Motoman Controller Profile.1 in the figure below.

UserAttrDouble, UserAttrBool, UserAttrString, UserAttrLENGTH, and UserAttrInt.1 are not OLP Device Attributes and are instead migrated towards ImportedDeviceAttributes.

You can access the imported values by double-clicking on the profiles.

Workspace Envelopes

Workspace envelopes created in DELMIA V5 Device Task Definition are automatically imported into 3DEXPERIENCE via PLMAccess > Import > CATIA File. For each envelope processed in a V5 document, a corresponding envelope is created in 3DEXPERIENCE.

In 3DEXPERIENCE, the workspace envelope is created at the same level as the controller. When viewed in the tree, it is created under different parents based on the context in which it is imported.

Note that the location of the workspace in the tree in 3DEXPERIENCE is different from the location of the workspace in V5. In 3DEXPERIENCE, the workspace is at the same level as the controller. If a Robot.CATProduct that contains an envelope is imported to 3DEXPERIENCE, the envelope in the 3DEXPERIENCE tree is shown as a child of the robot (the controller and the envelope are at the same level).

RRS Connection Attributes

Two sets of RRS Connection Attributes are imported:

Instance RRS Connection Attributes
An instance of a robot in a V5 process document remembers the last settings used in an RRS connection. These settings are migrated onto the 3DEXPERIENCE instance robot controller. They can be viewed in 3DEXPERIENCE through the properties page of the controller attributes (the child of the controller, named after the mechanism) on the instance controller.
Reference RRS Connection Attributes
From a V5 process document, it is possible to set RRS connection attributes on a robot reference. These attributes are stored as Added Properties on the V5 robot reference. These attributes are migrated onto the reference controller of the 3DEXPERIENCE robot. They can be viewed in 3DEXPERIENCE through the properties page of the controller attribute on the reference controller.
Data Not Migrated into 3DEXPERIENCE
  • Placement frames
    • A placement frame is not imported, but the FOI/tags the frame points to are imported
    • Warning displayed
  • Devices with multiple mechanisms
    • The device's first mechanism is imported
    • Warning displayed
  • Time table
    • Warning displayed
  • Tool tips
    • Warning displayed
  • Applicative parameter profiles
    • Warning displayed
  • Device task
    • Warning displayed
  • Any activity not listed as migrated elsewhere in this section: e.g., follow path, call task, actions (weld, mount, grab), I/O, set/wait
  • Command values
    • In V5, Jog retained the command values of device instances. This allowed you to modify and save the design command values for each instance of the device. This is not supported in V6, therefore the data with different instance command values will not have the same behavior in V6 after import. You may see the parts jump when jogging such devices.