A URCap program node cannot use the available API to read or set the active tool center point (TCP). The API separates TCP catalog access from active-TCP control: TCPModel exposes available TCP information, while TCPContributionModel lets a URCap contribute TCP definitions for selection in PolyScope.
Separate TCP definitions from the active TCP
| Interface or model | Supported purpose | Active-TCP control |
|---|---|---|
TCPModel |
Get information about currently available TCPs | Cannot read or change the active TCP |
TCPContributionModel |
Add URCap-provided TCPs to the TCP list presented in PolyScope | Does not select a TCP as active |
TCPConfiguration |
Available in other documented contribution contexts | The evidence does not establish a program-node path for active-TCP control |
Therefore, obtaining TCPConfiguration through GripperContribution or searching for a path through SystemConfiguration does not solve the program-node requirement described here. Contributing a TCP and activating that TCP are different operations.
Account for the position-teaching limitation
UserInteraction.getUserDefinedRobotPosition() can open the position interface and return the selected pose through RobotPositionCallback2. However, the program node cannot first read the active TCP, replace it for jogging, and restore it from either onOk() or onCancel(), because active-TCP read and write operations are not available through the stated API.
This prevents a reliable save-and-restore implementation. In particular, the node cannot determine which TCP must be restored after the user accepts or cancels position teaching.
Choose a controlled implementation path
- Use
TCPModelonly when the node needs information about available TCP definitions. - Use
TCPContributionModelwhen the URCap must add its own TCP definitions for user selection in PolyScope. - Require the user to verify the correct active TCP before teaching the position when automatic selection is essential to pose interpretation.
- If evaluating a script-based workaround, send the corresponding script command through a client interface only after accounting for active-TCP state outside this API and for every completion or cancellation path.
- Verify previously taught poses after any active-TCP change. A different active TCP affects prior taught poses and can cause unexpected motion or user confusion if the change is not visible.
The evidence confirms that a client-interface script can temporarily overwrite the active TCP, but it does not provide the command, state-reading mechanism, or transaction safeguards. Do not invent a command or assume restoration is possible without independently retaining and validating the original state.
FAQ
Can a URCap program node read the active TCP?
No. The stated API can expose available TCPs through TCPModel, but it cannot read which TCP is active.
Can getUserDefinedRobotPosition temporarily change the TCP?
No active-TCP setter is available through the stated API before calling getUserDefinedRobotPosition(). Consequently, its onOk() and onCancel() callbacks also cannot restore the previous active TCP through that API.
Can a script command change the active TCP temporarily?
A corresponding script command can be sent through a client interface, but the evidence does not specify that command. Treat this as a controlled workaround because changing the active TCP also affects prior taught poses, and the API cannot read the original active TCP for automatic restoration.
