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.

Connector – Cabinet

The part of the connector installed on the robot controller consists of two RAPID program modules — IKConnectorServer and IKConnectorPerformer. Both programs run in parallel tasks and exchange data through global variables declared with the PERS directive, having identical names and types. PERS variables are not reset after the controller is rebooted and, when their declared types and names match, they act as a single shared variable accessible from different modules.

The IKConnectorServer program module starts automatically when the controller is powered on and creates a server with the address 169.254.5.175 and port 5000. It then enters a loop where it waits for and processes incoming requests depending on their syntax and content. Three types of requests are supported:

• Retrieve robot data In response to this request, the program returns values describing the robot’s state, including motion performing state variables (state_processing, state_completed, and state_error) and the current position of the manipulator’s end effector (target_x, target_y, target_z, angle_x, angle_y, angle_z). The request string has the form GET_OUTPUT without any parameters, and the response string contains a comma-separated list of numbers.
• Update robot position In response to a request beginning with SET_TARGET, the program extracts parameters (comma-separated) from the rest of the string and updates the target position tcp_pos, the speed tcp_speed, and the trajectory smoothing parameter tcp_type.
• Retrieve gripper data The request string also has the form GET_OUTPUT and requires no additional parameters. The response string contains the values of the variables describing the gripper’s state (is_opened) and performing state (gripper_processing, gripper_completed).
• Toggle gripper The program updates the DO10_2 signal controlling the pneumatic interface, depending on the opcode — the single parameter of the TOGGLE_GRIPPER request.

Request handling for data retrieval is fully contained within the IKConnectorServer module, which is also the only request type from which a response is expected. In all other cases related to manipulator and gripper control, in addition to updating the operational parameters — target position and motion parameters for the manipulator, and the control signal value for the gripper — special flags are also updated. These flags are processed by the IKConnectorPerformer program module, which starts after IKConnectorServer and enters a loop where it checks the control flags for manipulator movement and gripper toggling. When these flags are set to TRUE, the corresponding operations are executed — movement to a new position (new_target) and/or gripper toggle (new_toggle):

• When a request to change the manipulator end effector position is received, the state variables state_processing and state_completed are set to TRUE and FALSE, respectively. The movement operation to the target position is then performed: MoveL tcp_pos, v5, fine, ikc_tool \WObj:=IKConnector. After the motion is completed, the state variable values are inverted.
• When a gripper toggle request is received, depending on the opcode 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 the pressure of compressed air; in the second, the air supply stops and the gripper closes. Before updating the signal, the variables gripper_processing and gripper_completed are set to TRUE and FALSE, respectively. After a 0.2-second delay — during which the gripper changes its state — these variables are inverted.

In fact, the separation between control connectors occurs within the part of the connector executed on the robot controller, by implementing two servers operating on the same IP address but using different ports. Request handling and control flag updates are performed sequentially in a single loop of the IKConnectorServer module, which, in turn, alters the behavior of the concurrently executed IKConnectorComponent module, where these flags are checked sequentially in its unified loop.

The secure access configuration for IKConnectorPerformer allows it to control the robot manipulator itself, including the pneumatic interface of the gripper, unlike the IKConnectorServer module. In manual controller mode — used for debugging the connector — IKConnectorPerformer is launched manually from the teach pendant using the “>” button while holding the deadman switch. To avoid errors, the program pointer should be moved to the beginning of the module code (PP to Main) before starting performing.

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

Connector – IndustrialKit

As discussed above, the robot controller manages two devices — its manipulator and the gripper mounted on it. To accomplish this, it uses two program modules running in two available parallel tasks, which, however, are divided not by devices — one task for the manipulator and another for the gripper — but by functional purpose: one task for handling requests and another for direct device control.

Since different servers are used on separate network sockets, interaction with each device can be handled by individual connectors that are part of separate device modules (for the robot and for the tool), executed on the PC side.

To communicate with the robot server, each connector uses its own instance of the SocketHolder structure. The successfully established connection is stored in its static variables and becomes accessible to all other connector functions:

• The robot connector transmits target position parameters and initiates movement execution, returning the result upon completion. In addition, to monitor the robot manipulator in real time, the connector requests data on the position of the end effector in space (its distance from the coordinate origin and its orientation). These values are stored in the statistics output and are used to define the end effector’s position in the virtual model (the joint rotation angles of the model are calculated by the model controller).
• The gripper connector connects to the same robot but controls only the gripper. It is not possible to obtain intermediate data on finger positions; however, the opening and closing process is so fast that it can be disregarded. Moreover, the assembly operation is performed with the gripper already closed, holding the shaft. Thus, the only data returned about the gripper’s current state are: closed, open, opening, or closing.

Continuous querying and reception of data from the robot to determine its motion execution state are combined with real-time synchronization of the virtual model and statistical data. On the other hand, the algorithmic structure based on continuous retrieval and processing of state data can easily be transferred to external software components, where there are no functions with a completion handler — control is reduced to the continuous calling of a function that returns the execution state (including waiting until the completion handler condition is met).