Introduction

Purpose

This document provides an overview of integrating Realtime Robotics controller with Siemens PLC using the Function Blocks (FBs) and Data Blocks (DBs). It is designed for customers who need guidance on efficiently setting up and using the PLC library.

Prerequisites

• Siemens PLC model: There is no preferred PLC model, as our product works with Profinet communication. However, note that certain models, such as the S1200, may have limitations and cannot use the GRAPH functionality included in the library example.

• TIA Portal Version: V17 and greater

• Rapidplan version: V2.9

Audience

This document is intended for engineers and technicians who are familiar with Siemens PLC programming and the basics of function blocks and data blocks.

Hardware Configuration

Overview

Provides instructions for setting up and configuring the Siemens PLC hardware to work with Realtime Robotics controller

Steps for Setup

Step 1

Connect the PLC to the Profinet interface of the [Product Name] controller. The controller has two interfaces:

• Robot Interface: Communicates exclusively with the connected robots.

• Profinet/Ethernet IP Interface: Communicates with the PLC and other Profinet devices.

• Ensure that the PLC is connected to the Profinet interface, which can be configured directly on the controller.

Step 2

Set up IP addresses for the devices in TIA Portal. It is important to configure the PLC, Realtime Robotics controller (Profinet interface), and other Profinet devices to be on a different IP segment than the robot interface.

For example:

Step 3

In the hardware configuration (Device View) of TIA Portal, allocate I/O byte ranges for the Realtime Robotics controller:

• The first 16 bytes are reserved for Controller inputs.

• The next 32 bytes are allocated for ObjectStates inputs.

• The next 48 bytes are reserved for CommandModule inputs.

• Each robot connected to the controller has 64 bytes allocated for inputs and outputs.

  • The first robot (ID 0) uses the first 64 bytes.

  • The second robot (ID 1) uses the next 64 bytes, and so on, up to 16 robots.

Step 5

Adjust the Watchdog time to prevent loss of communication during Profinet exchanges. You can modify the Update time as needed (default is 2 miliseconds).

Step 6

Verify that all IP addresses, connections, and byte allocations are correctly configured in TIA Portal. To confirm communication between the PLC and the Realtime Robotics controller, check the third bit of the first byte (PNIOLoopback). This bit should blink, indicating successful communication between the PLC and the Realtime Robotics controller.

Function and Data Blocks Overview

Overview

This section explains the provided Function Blocks (FBs) and Data Blocks (DBs) in the PLC library. These FBs and DBs are essential for managing both the controller and robots, allowing seamless interaction between the PLC and the robots in the system.

Function Blocks (FBs)

RTR_Controller_Standard_FB

The Controller FB is responsible for overall control functions, including:

• Loading and unloading projects.

• Switching between configuration and operation modes.

• Handling controller-related commands such as system resets or status requests.

RTR_Robot_Standard_FB

The Robot FB manages robot-specific operations. For each robot in the system, a separate instance of the Robot FB is created (e.g., if there are two robots, two Robot FB instances are required). This FB handles:

• Connecting to the robot.

• Moving the robot to specific coordinates.

• Stopping robot movement.

• Retrieving the current TCP (Tool Center Point) or joint configuration values.

• Executing other robot-related commands such as jogging or resetting.

Data Blocks (DBs)

RTR_Controller_Standard_GDB

This Data Block stores all controller-related information, including:

• Controller commands.

• Status flags.

• Inputs and outputs for the controller's interactions with the PLC.

RTR_Robotx_Standard_GDB

Each robot has its own DB, which contains:

• Robot-specific commands and parameters.

• Robot status.

• Inputs and outputs, which allow the Robot FB to communicate with the PLC and execute tasks.

RTR_LookupTable_Standard

The Lookup Table DB stores comprehensive project details, including:

• Targets.

• Frames

• Objects

• Robot Presets

This lookup table is downloaded from the RapidPlan control panel and must be aligned with the current project loaded in the system.

RTR_Controller_Standard_FB Overview

Overview

The RTR_Controller_Standard_FB is the central unit managing the overall system. It controls the initialization of projects, mode transitions, and interaction with robots. Its primary role is to ensure smooth operation by coordinating with the RTR_Robot_Standard_FB and handling high-level commands.

Key Functionalities

Initialization

• Activates when the AUT (Automatic Mode) signal is high.

• Loads the user-specified project and establishes connections with robots.

• Switches to Operation Mode once all robots are confirmed as connected.

Command Processing

• Handles commands for:

  • Mode Changes: Switches between operation and configuration modes on user input.

  • Project Management: Loads or unloads projects based on user input.

• Monitoring Step: After executing commands, it returns to Monitoring Mode, awaiting further instructions.

• Error Handling: If a command fails, the FB enters an error state and outputs an error code. The Reset signal can be used to clear errors and restart the block.

Communication

• Coordinates with the RTR_Robot_Standard_FB to ensure all components are synchronized.

• Utilizes RTR_Controller_Standard_GDB to store and manage control commands, status updates, and input/output information.

Customization

This RTR_Controller_Standard_FB is a flexible template designed to handle the key commands needed for the example project. Users can modify and adapt the block to fit their specific application needs.

By default, when the machine is set to automatic mode, the block runs certain steps to bring the system into operation mode, making it ready to accept user commands. However, users are free to adjust these steps and other functionalities as needed to match their requirements.

RTR_Robot_Standard_FB Overview

Overview

The RTR_Robot_Standard_FB is dedicated to managing individual robot operations. It handles tasks such as movement, connection management, and configuration retrieval. The RTR_Robot_Standard_FB ensures each robot operates smoothly and in sync with the RTR_Controller_Standard_FB.

Key Functionalities

Initialization

• Activates when the AUT signal is high.

• Connects to the robot and informs the RTR_Controller_Standard_FB once the connection is established.

Command Processing

• Executes commands such as:

  • Movement Commands: Moves the robot to specified positions, including single or combined moves.

  • Connection Management: Connects or disconnects the robot as needed.

  • Control Acquisition/Release: Manages taking or releasing control over the robot.

  • Home Position: Moves the robot to a predefined home position, using a roadmap or planning move.

  • Configuration Retrieval: Obtains current TCP (Tool Center Point) or joint configuration values.

• Monitoring Step: Returns to Monitoring Step after command execution, awaiting further instructions.

• Error Handling: If a command fails, the FB enters an error state and outputs an error code. The Reset signal can be used to clear errors and restart the block.

Customization

This RTR_Robot_Standard_FB is a flexible template that includes commands necessary for the example project to work. Users can modify and adapt the block to suit their specific application needs.

By default, when the machine switches to automatic mode, the RTR_Controller_Standard_FB sends a connect command to the RTR_Robot_Standard_FB. The RTR_Robot_Standard_FB then connects to its assigned robot and reports back to the RTR_Controller_Standard_FB, allowing the system to move to operation mode. Once connected, the RTR_Robot_Standard_FB can receive and execute commands such as move, connect, or acquire control from a separate task manager program. It will execute the command and report back, enabling the task manager to respond accordingly.

Sample GRAPH Program Overview

Overview

The Sample GRAPH Program demonstrates how to utilize the provided function blocks (FBs) in a practical application. It manages the sequence of robot movements and actions by integrating the RTR_Controller_Standard_FB and RTR_Robot_Standard_FB. This program is designed to automate specific tasks by sending user commands such as movement, using parameters that have been pre-set.

Key Functionalities

Initialization

• The GRAPH program starts once the system is in Operation Mode and both the RTR_Controller_Standard_FB and RTR_Robot_Standard_FB are in the Monitoring Step, meaning they are ready to accept commands.

Move Command Execution

• The user sets move parameters like speed, smoothing, and movement type (e.g., joint or linear).

• After the parameters are set, the user specifies a target and triggers the SingleMove command.

• The RTR_Robot_Standard_FB then moves the robot to the desired target.

• The GRAPH program waits until the RTR_Robot_Standard_FB returns to the Monitoring Step, indicating that the robot has reached its target position.

• Once the robot has reached its desired target position, user can set further commands like actuating the gripper, etc.

Error Handling

If the robot encounters an issue, the program outputs an error code, allowing the user to take corrective actions.

Multi-Robot Support

In cells with multiple robots, separate GRAPH programs are created for each robot. No additional robot movement interlocking is needed since the controller manages robot coordination. However, process interlocks (e.g., Robot 1 picks up a part only after Robot 2 places it) can be added as needed.

Troubleshooting

Common Issues and Fixes

Connection Issues

• Profinet Interface Not Detected:
  This issue may occur if the Profinet interface of the controller is not recognized by the PLC.

  • Possible Causes & Solutions:

    • Device Name Not Assigned: Ensure the correct device name is assigned in the hardware configuration.

    • Interface Start Sequence Issue: Sometimes, when the controller restarts, the Profinet interface might start later than the robot interface, causing detection issues.

      • Solution: A temporary workaround is to run a script that disables all interfaces on controller except the Profinet for a few seconds, ensuring it is detected first. Once detected, other interfaces can be enabled. This issue is being actively worked on for a permanent fix.