Skip to main content

Supported Features

Software​

Please see the Minimum Requirements section for supported software versions.

Study Modes​

Only Standard mode is supported in Process Simulate. Line Simulation mode is not supported.

Robots​

In general, outside of the known limitations below there are no expected issues with how robots are exported. During export, the CAD for the links of the robot are placed in the cad folder of the generated .zip. The kinematics and dynamics are encoded in the project.yaml. The dynamics for each joint will be taken directly from the robot model unless the Calibrate Robot DynamicsSetting in Export to RTR dialog, if selected, will attempt to automatically calibrate dynamics of the robots for use in the RTR engine. Using whatever controller and motion planner selected in Process... checkbox is enabled on export.

Supported​

  • 6 DoF robots
  • Joint working limits
    • If the "indicate joint working limits" checkbox is enabled in PS, the working limits of the robot will be reduced (percentage or absolute) according to the settings so that the desired limits are not violated. These limits are checked at each target during export and a warning is presented to the user if they are violated. The value is adjusted in the exported project.yaml. Note: For variable joint limits there may be some small numerical deviations from PS behavior, but fixed joint limits should match exactly.
    Joint Working Limit Settings

Unsupported​

  • Non 6 DoF robots including 7 DoF, SCARA, delta, gantry style robots.
    • Note: These robots may export and actually produce results in the engine, but the engine is not optimized to handle these types and may exhibit unexpected behavior.
  • Joints that are part of multiple variable joint polygons.
  • Concave polygons for variable joint limits.

Objects​

Supported​

  • 3D Objects (components, swept volumes, etc...)
  • 2D Objects (planes, safety zones, etc...)

Unsupported​

  • 1D Objects (lines, points, etc...)

Frames​

The only frames that are exported are ones that have a purpose within the exported operations. An example would be a frame that is a TCP used in an exported operation.

Parts/Appearances​

Appearances are supported and will be included in the export if they are displayed at time of export or are displayed during one of the exported operations with an OLP command (e.g # Display).

Point Clouds​

Point clouds are not currently supported since they fall under the category of a 1D object.

Motion volumes​

Motion volumes are supported as they fall under the category of a 3D object. They will be included in the export if they are displayed at the time of export or are displayed during on e of the exported operations with an OLP command (e.g. # Display).

Motion volumes can be very useful for defining keep out zones for the Resolver engine. Two good use cases are:

  • Robot A's paths are already determined for the process but there is a nearby robot (Robot B) that operates in parallel and motion plans are being generated by Resolver. It is recommended to display the motion volume of Robot A during operations to act as a keep out zone for Robot B. Remember to include the motion volume in a collision set with Robot A so the Resolver engine knows to avoid it.
  • A non-robot stateful device (e.g. clamps, turntables) in the scene is driven during operation and Resolver needs to avoid this space during transition. Currently, Resolver only supports a jump of stateful non-robot devices and does not support kinematics to simulate the motion. However, motion volumes can be used to block out the device's motion with OLP commands (# Display/# Blank).

Example of a swept volume being used to define a keep-out zone for a turntable's motion.

OLP Commands​

Below are the supported/unsupported lists of OLP commands that have been requested by customers. Note that this is not an exhaustive list of all Process Simulate OLP commands as many would not have any impact to the engine's results. If your operation uses an OLP command not provided in the lists below it is safe to assume it will be ignored. To make a request for additional features, please submit a Support Ticket.

Supported​

  • # Blank / # Display
  • # Attach / # Detach
  • # Grip / # Release
  • # WaitTime
  • # DriveDevice / # JumpDevice / # WaitDevice / # DriveDeviceJoints
    • Note: Unsupported if being applied to joints of the robot (native robot joints & external axis)
    • Note: In the case where a # DriveDevice command does not have an associated # WaitDevice command within a location's OLP command list, PS will execute the rest of the current operation but will not proceed to the next operation without the state change completing. The exporter will encode this same behavior in the query that is sent to the engine by adding the state change to the end of the target's operation.
    • Note: These commands on a single device (e.g. trunnion) from different operations (e.g. robots A, B, C) in parallel are not supported. We have seen customer use cases where all 3 robots command the shared trunnion jig to drive at the same time. This is not supported.
  • # Connect / # Disconnect
  • # Mount / # Unmount
  • Free text commands if the text matches one of the supported standard commands exactly. If the device lookup for the free text command returns more than 1 device, the Resolver connector will throw an error.

Not Supported​

  • # SendSignal / # SetSignal / # WaitSignal
  • # GunToState

In the import dialog, there is an option to "Copy existing OLP commands" which is enabled by default. If checked, on import of results the connector will attempt to look up the original operation and copy and existing OLP commands whether they were used in the engine or not. The location of these OLP commands in the operation may move if target order optimization or robot allocation are performed on the operation.

All of the supported actions will be encoded as one or more Actions or SubActions within the query. Any unsupported OLP commands will be encoded as DummyAction or DummySubActions.

Location Types​

Supported location types:

  • Via (TxRoboticViaLocationOperation)
  • Spotweld (TxWeldLocationOperation)

The importer relies on the exported operation to still exist in the PS study at the time of results import. The importer looks up the original operation and copies data from the locations including location type. It is important for successful end-to-end workflow that the exported operation remain unchanged until results from any Resolver runs that reference it have been imported. If you need to make an edit to the program while Resolver is running, it is recommended to make a duplicate until results have been imported.

Location Parameters​

The exporter will pass the following location parameters through to the engine:

  • Name
  • ExternalID
  • Config
  • Interpolation
  • Speed
  • TCP
  • OLP commands

All exported locations will be assumed as "process points" and therefore a zero smoothing value is applied to them. Air motions to and from these process points will have smoothing values if allowed (allowed by default).