The foundation of a robotic cell is a robot equipped with a set of tools mounted on the end of its manipulator (End Of Arm Tooling, EOAT). By directing and controlling its tools, the robot performs a manufacturing operation, transforming the workpiece into a finished product at a certain stage of production.

Since a robot is always used together with a tool, its manipulator is equipped with the appropriate fittings for mounting, and many modern models also include connectors for controlled tools, such as pneumatic or electrical ones. Each manufacturer implements its own methods for tool control and representation within the robot control program code.

Within the IndustrialKit paradigm, robots and tools are regarded as distinct, independent entities – robots are treated as tooling devices that, in addition to end-mounted working tools, also include various devices and machines that do not define spatial positions. All devices of the robotic production complex (RPC) are controlled by a unified global program at the level of the entire system, external to the individual controllers of robotic units. This approach standardizes and unifies the algorithmic structure, regardless of the actual device connections.

Thus, the development of modules for an ABB robot and its pneumatic gripper implies a corresponding functional separation at the connector level, while maintaining the independence of other components. Here, we will consider the creation of both independent components within the modules of each device and shared components that belong to their connectors.

Package Preparation

To synthesize the modules, a new STC package is created with two templates – one for the ABB Robot and another for the Schunk Gripper Tool. For the visual and physical modeling of these devices, a set of scene files containing their models is added to the package. For example, the model of the ABB IRB 140 manipulator consists of six links, from d0 to d5, while the gripper model consists of a pneumatic module Schunk GSM-P 64-E-090 and two fingers – Finger and Finger2.

A preliminary manipulator model can be generated using Industrial Builder and used for module testing; however, it will later be replaced with a realistic one. The gripper model is assembled from the Schunk pneumatic module, which can be freely obtained upon request from the official website, and two identical finger models created in CAD based on their actual dimensions.

Next, each added scene file is selected in the Resources section of the corresponding module, along with specifying the names of the connected nodes – the links for the robot and the fingers for the gripper.

The connection parameter set is identical for both devices: IP Address (String) and Port (Int). The default address for both modules is 169.254.5.175, while the port numbers differ – 5000 and 5001, respectively. The connection parameters, along with their default values, are defined in Link Parameters ().

In Origin Shift (), a zero-point offset is also specified for the robot – the position the manipulator points to when the coordinate system of the workspace is at zero – relative to the model’s zero point: x: 138, y: 0, z: 154.

The listings of the software components for each module are filled out in the Code section. For both the robot and the tool, these include pairs of listings – one for the connector and one for the controller. Their initial contents are generated from corresponding templates for further development. The final version of the code is discussed in the following sections.

Controllers

The robot performs movement to a point — a uniform type of action, but with many variable parameters. The tool, in turn, can perform a wide range of different actions. For this reason, robot model controllers include functions for inverse kinematics calculation, which link the parameters of the target position (location and rotation) to the parameters of displacement and rotation of the manipulator’s links, whereas tool controllers define a set of actions (SCNAction) applied to specific nodes depending on the value of the operation code.

The controller of the ABB IRB 140 manipulator model uses a slightly modified template function for calculating the positions of the manipulator links (nodes d0 – d5) with 6DOF kinematics. The controller code containing this function was generated using Industrial Builder, based on the link length parameters taken from the robot’s specification.

The modification of the inverse kinematics calculation function is due to the need to account for the forward offset of the links along the X-axis relative to the base rotation axis — the rotation axis of the first link does not intersect the mounting point of the second link.

The gripper model controller manages only the pair of fingers (Finger1 and Finger2), applying linear movement actions inward or outward depending on the operation code. A value of 1 opens the gripper, while a value of 0 closes it, as implemented in the corresponding controller function.

Connector – Cabinet

In ABB robot controllers, executable program Modules are distributed among Tasks. Depending on the task configuration, the execution order and capabilities of its program modules (written in the built-in RAPID language) are defined. For example, background tasks are launched automatically after the controller starts and run in parallel threads. In contrast, foreground task modules are started directly from the control panel and, unlike background tasks, can directly control the manipulator and connected devices. The program modules within one task form a single logical codebase, although separated into individual files — one of the functions in this code is designated as the Main entry in the task settings, serving as the starting point of execution.

To exchange data between different tasks, PERS variables are used. When such variables share the same name and declared type, they act as common, persistent variables accessible from multiple modules and remain unchanged after a controller reboot.

Robot and gripper control is handled in the main task T_ROB1 within the module IKConnectorPerformer, which runs a loop that sequentially checks the values of flag variables new_target and new_toggle. If one of these variables is set to TRUE, the corresponding subroutine is executed – moving to a target position or opening/closing the gripper:

• When changing the manipulator’s end-effector position, the state variables robot_processing and robot_completed are set to TRUE and FALSE, respectively. Then, the movement operation to the target position is executed: MoveL tcp_pos, v5, fine, ikc_tool \WObj:=IKConnector. After completing the movement, the state variable values are inverted.
• When toggling the gripper, depending on the operation code value, the DO10_2 signal is either set to 1 (Set DO10_2) or reset to 0 (Reset DO10_2). In the first case, the gripper opens under compressed air pressure; in the second, the air supply stops and the gripper closes. Before updating the signal, the variables tool_processing and tool_completed are set to TRUE and FALSE, respectively. After a delay of 0.2 seconds, during which the gripper changes its state, these variables are inverted.

All execution flags are PERS Bool variables, which makes their values accessible for modification by other concurrently running program modules.

The safety configuration of the T_ROB1 task, containing the executable module IKConnectorPerformer, allows direct control of the robot manipulator itself – including the pneumatic interface of the gripper – unlike the robot_server_task and tool_server_task, which contain IKConnectorServer modules. In manual operation mode, used for debugging the connector, IKConnectorPerformer is launched manually from the controller panel by pressing the “” button while holding the deadman switch. To avoid errors, the program pointer should be moved to the start of the module code (PP to Main) before execution.

Background tasks can be used to create two independent servers accessible on the industrial network under the same IP address but different ports. Each server communicates with its own controller instance running on the host computer. In the robot-executed part of the connector, two background tasks are used – robot_server_task and tool_server_task – each containing a single program module IKConnectorServer. These modules create a server with socket parameters – address 169.254.5.175 and ports 5000/5001 (robot/gripper, respectively) – and then enter a loop that waits for and processes incoming requests depending on their syntax and content.

All IKConnectorServer modules support a query for obtaining their current status, required for monitoring operations and collecting statistics. The query string has the form GET_OUTPUT and does not include additional parameters. The response string contains the current variable values:

• The robot module version returns the operation state variables – robot_processing, robot_completed, robot_error – as well as the current end-effector position (target_x, target_y, target_z) and orientation (angle_x, angle_y, angle_z).
• The gripper module version returns the operation state variables – tool_processing, tool_completed, tool_error – and the current gripper state (gripper_is_opened).

The request string for executing an operation differs between the robot and the gripper. It includes parameters but expects no response:

• Update robot position. Upon receiving a request starting with SET_TARGET, the program extracts the parameter set (comma-separated) from the rest of the string and updates the target position (tcp_pos), speed (tcp_speed), and path blending type (tcp_type). Then, the new_target flag is set to TRUE.
• Toggle the gripper. The program updates the toggle_state variable depending on the opcode – the sole parameter of the TOGGLE_GRIPPER request – and sets the new_toggle flag to TRUE.

Thus, the separation between connectors is implemented within the portion of the connector running on the robot controller. It is achieved by using two concurrent server threads that operate in parallel with the device control thread but communicate with it through shared PERS global variables. Updating the control flags in the IKConnectorServer modules of the background server threads alters the behavior of the executable module IKConnectorComponent, in whose main loop these flags are sequentially checked – and when a flag value is TRUE, the corresponding action is executed.

The source code of the connector program modules is provided below.

RAPID tool server module.

RAPID robot server module.

RAPID module to perform robot movement and gripper toggle.

Connector – IndustrialKit

As discussed above, the part of the connector executed on the robot controller manages two devices – the manipulator and the gripper mounted on it – through the manipulator’s pneumatic interface. To achieve this, it uses two server program modules running in parallel background threads and one main module responsible for direct device control. Since different servers operate on separate network sockets, communication with individual devices can be handled by independent connectors within the respective device modules (for the robot and the tool) running on the host computer.

To communicate with the robot’s server, each connector uses its own implementation of the SocketHolder structure. The successfully established connection is stored in its static variables, making it accessible to all other functions of the connector:

• The robot connector transmits the target position parameters and initiates movement to that position, returning the execution result. In addition, to enable real-time monitoring of the manipulator, the connector continuously requests execution and positional data of the end-effector in space (distance from the origin and tool orientation). These data are stored in the statistics output and used to update the position of the end-effector in the virtual model (the rotation angles of the manipulator model links are computed by the model controller).
• The gripper connector connects to the robot but controls only the gripper, continuously requesting data about the execution state of operations. It is not possible to obtain intermediate finger position data; however, the opening and closing actions occur so quickly that they can be neglected. Moreover, during the assembly process, the gripper already starts in a closed state, holding the shaft. Thus, the only statistical data generated for the gripper’s state are: closed, opened, opening, and closing.

Continuous polling and data acquisition from the device to determine its state are combined with synchronization of the virtual model and real-time update of statistical information. At the same time, the algorithmic structure based on constant state querying and processing can easily be adapted to external software components, where no completion handler functions are present – control is reduced to repeatedly calling a function that returns the device state, including waiting until a completion handler needs to be invoked.

Produced for Production

The STC package we developed can be used to synthesize modules for both external and internal use, depending on the template used to generate the code for the program components. We created two external modules for integration with RCWorkspace, and separately – a small utility for controlling the ABB robot and its gripper, called ABB App, which includes two modules in an internal execution configuration.

Before applying the modules for equipment connection and control, it is necessary to install the connector portion on the robot’s control unit. For this purpose, a set of tasks must be created, and the corresponding RAPID program module files loaded into them:

Task (Name)	Task in foreground	Type	Main entry	TrustLevel
robot_server_task	T_ROB1	SEMISTATIC	main	No Safety
tool_server_task	T_ROB1	SEMISTATIC	main	No Safety
T_ROB1	–		main

After launching all three tasks, the robot and tool become available for connection over the local industrial network (Ethernet) from the host computer via RCWorkspace or ABB App.