Serial communication via the Tool Connector

All robots have a M8 tool connector, dedicated to end-of-arm tools. With the tool connector, users avoid having cables running along the robot arm.

The Tool Connector provides:

  • A power supply

  • 2 digital inputs

  • 2 digital outputs

  • 2 analog inputs

  • Optionally the 2 analog inputs can be used for RS485 communication

The Tool Connector can be used to control an end effector using a manual setup where the Tool Connector IO’s are manipulated from the PolyScope X user interface or by URScript.

Another approach is controlling the tool using a URCap. A URCap can add tool specific application nodes, program nodes or smart-skill contributions that will make the tool easier to work with from PolyScope X.

Many tools uses RS485 communication via the Tool Connector. This interface requires a backend URCap contribution to handle the RS485 communication. This How To will focus on this specific method.

Communicating RS485 via the Tool Connector

Three main steps are required to perform serial (RS485) communication with a tool connected to the Tool Connector:

  • Create a URCap with a backend contribution to handle the communication. See Creating a container backend Contribution

  • Configure the Tool Connector for serial communication

  • Access the Tool Connector device from the backend contribution for reading and writing serial data to/from the connected tool.

Configure the Tool Connector for serial communication

The Tool Connector can be configured for serial communication. This is done by enabling the “Tool Communication Interface” (TCI). When the TCI is enabled the Tool Connectors analog inputs will be used for serial communication.

TCI configuration

Enabling and configuring the TCI is done with URScript using the function set_tool_communication. See the URScript manual section 16.1.49. The voltage level for the Tool Connector power supply can be configured using the URScript function set_tool_voltage. See the URScript manual section 16.1.52.

How to contribute TCI configuration URScript

When adding a frontend contribution for controlling the end effector, like a smart skill, application node or a program node, URScript can be provided using the contribution behavior. For an example see the “Simple gripper” sample. In this sample, the application node is enabling and configuring the TCI using URScript from its behavior worker.

If no frontend contribution is added, the backend contribution can can commit URScript directly by sending URScript to the secondary controller socket. See Communicating with the robot controller.

The following is an example of Tool Connector configuration URScript that can be send to the secondary controller socket.

sec configName():
    set_tool_voltage(24)
    set_tool_communication(True, 1000000, 2, 1, 1.5, 3.5)
end

Access the Tool Connector device from the backend contribution

For a backend contribution to send and receive data via the Tool Connector it first needs to be made available in the backend contribution container. This is initiated by requesting the Tool Connector device, called ttyTool, in the URCap manifest. The following example show what must be added to a URCaps manifest.yaml for requesting the ttyTool device:

containers:
  - id: "simple-gripper-backend"
    image: "simple-gripper-backend:latest"
    devices:
      - type: ttyTool

When the Tool Connector is requested as above, the backend contribution will be able to access and use the device at the following fixed path in the container: /dev/ur-ttylink/ttyTool. See the “xmlrpc-gripper” sample. The sample backend implementation showcase an example of using ttyTool implemented in Python.

Special considerations

The described mechanism for accessing and using ttyTool is very simple and easy to use. However there is one drawback that must be taken into consideration. The ttyTool is considered af shared resource. All URCaps can request access to it and will be able to read and write to the device without taking into account whether other URCaps are doing the same. This poses a risk of multiple URCaps configure the device at the same time and communicating via the device over each other. It is left to the individual URCap implementation to handle this challenge.