2.4 Naming Conventions, Restrictions, and Recommendations

There are several rules you must follow when naming items in RapidPlan Create.

RapidPlan Create reserves these names so they are not available to users, regardless of case: "world", "origin", "floor", "home", “TCP”, “null”.

All robots, objects, targets, frames, and mates must have unique names.

Read-only names: Robot links, reserved names

Names are case-sensitive, e.g., “frame2” and “Frame2” are two different items.

Preset names and mate states must be locally unique within their robot. You can use duplicate names if they are used on different robots.

Naming Recommendations

Descriptive Names:

Giving your items descriptive names will provide clarity in your projects.

Robots:

Robot names should correspond with the names expected by the task planner. These can follow any naming scheme the user wishes to use.

Robot Presets:

If the project involves changing robot presets, these presets should be verified to make sure the robot is the correct one to apply the presets to. Robot Preset names can be re-used across different robots. To avoid confusion, a consistent naming scheme should be used to simplify the process. E.g. A user could have a Weld_Gun_Preset and Torch_Preset for every robot that can use those end effectors.

Note: For projects with only a single preset, the name does not need to be specifically set by the user. This name is only required when attempting to change presets.

Objects:

Clear and valid object state names should be used for all stateful objects in the workcell. This is because these names will be referenced by the SetObjectState command of the ASCII API 2.0, whenever the user wants to change the active state of an object in the workcell at runtime.

Note: Objects that will not be manipulated by this command do not need to be explicitly verified against the task planner, but descriptive names can help to provide clarity to the project.

Object States:

Object State(i.e., Mate State) names, along with Object names, are used by the SetObjectState command. These should be verified with the task planner, to ensure that each of these commands will be compatible. Similar to Robot Presets, these can be re-used for any stateful mate, so it can be very helpful to establish a convention for the different states (for example, ensuring all mates have an ‘Active’ and ‘Suppressed’ state for objects that the user wants to toggle at runtime)

Note: There is one specific name requirement for Mate States. The ‘Suppressed’ state name is reserved for removing components which descend from the mate from the workcell at runtime.

Targets:

Target names should be verified against the targets used by the task planner.