[PDF] INITIAL CONFIGURATION OF INDUSTRIAL ROBOT - Trepo

teessä A Ohjeessa käytetään Profinet-tietoliikenneprotokollaa robotin ja ohjelmoitavan logiikan väliseen virtual ABB IRC5 series industrial robot controller



Previous PDF Next PDF





[PDF] Application manual - PROFINET Controller/Device with IO - Login

The reader should have the required knowledge of: • PROFINET network • I/O system • IRC5 controller • RobotStudio References ABB documents Document  



[PDF] Application manual - PROFINET Controller/Device

IRC5 controller • RobotStudio References ABB documents Document ID Reference 3HAC050948-001 Technical reference manual - System parameters



[PDF] IRC5 robot controller and CI502 with safety I/O modules - ABB Group

22 fév 2019 · The table below explains the abbreviations used in the document Abbreviation Description CI502 ABB CI502-PNIO PROFINET IO Bus Module / 



[PDF] 3 PROFINET Master/Slave configuration - Serious Survivor

Additional copies of this manual may be obtained from ABB at its then current charge Copyright 3 4 2 Configuring IRC5 internal PROFINET slave, example



[PDF] 3 PROFINET Fieldbus Adapter configuration - Serious Survivor

Additional copies of this manual may be obtained from ABB at its then current charge 3 4 1 Configuring the PROFINET Fieldbus Adapter in IRC5 controller



[PDF] ProfinetConfigurator

5 6 1 Creating controller network configuration file using PROFINET-IO Configurator Express This node now represents the IRC5 controller master In the Bus 



INITIAL CONFIGURATION OF INDUSTRIAL ROBOT - Trepo

teessä A Ohjeessa käytetään Profinet-tietoliikenneprotokollaa robotin ja ohjelmoitavan logiikan väliseen virtual ABB IRC5 series industrial robot controller



[PDF] Abb Irc5 Manual

robotics technical reference manual rapid instructions, abb irc5 create device application manual profinet anybus device, abb irc5 controller manual portable 

[PDF] abb irc5 safety wiring diagram

[PDF] abb paint robot manual

[PDF] abb rapid error handling

[PDF] abb rapid manual

[PDF] abb robot configurator

[PDF] abb robot download

[PDF] abb robot ethernet communication

[PDF] abb robot event message 20082

[PDF] abb robot irc5

[PDF] abb robot manual

[PDF] abb robot programming book

[PDF] abb robot programming examples

[PDF] abb robot programming tutorial pdf

[PDF] abb robot system failure

[PDF] abb robot teach pendant manual

Tommi Laitila

INITIAL CONFIGURATION OF INDUSTRIAL

ROBOT CONTROLLER

Using offline programming tool

Faculty of Engineering and Natural Sciences

Bachelor thesis

September 2020

i

ABSTRACT

Tommi Laitila: Initial configuration of industrial robot controller

Bachelor thesis

Tampere University

Bachelor of Science (Tech) Mechanical engineering and industrial systems

September 2020Integrating a robot system as part of larger scale system requires vast knowledge on different

device interfaces and network technologies. Robot system commissioning procedure is a small

task compared to scale of the whole project, thus it is advised to minimize time spent to the task by

standardizing the procedure. This study deals with robot use scenario in industrial manufacturing and offline programming functionality aiding the commissioning and configuration procedure. Aim of this study is to produce a documented guide on configuration of a virtual ABB IRC5 series industrial robot controller. this study is in form of a literary review based on manuals of ABB robot products and user experience on ABB software as well as other literature on the field. Thesis will answer to ques- tions regarding use of robot solutions in automation hierarchy and both how to use RobotStudio software in configuration of virtual robot system and how to configure I/O communication interface for ABB robot controller using Profisafe protocol. the study focuses on the interfaces of industrial robot controller enabling communication with external devices. Additionally, communication technologies and safety functionality are a key part of this study. Offline programming tools are also covered in this thesis, since offline programming

has potential time saving features. The product of this thesis is included in appendix A. The initiali-

sation instruction in itself is written from application specific point of view to simplify the process of

robot configuration to its reader by filtering unnecessary information compared to original manuals reviewed during the writing process. Keywords: robotics, offline programming, automated work cell, factory automation The originality of this thesis has been checked using the Turnitin OriginalityCheck service. ii

TIIVISTELMÄ

Tampereen yliopisto

Tekniikan kandidaatti Kone- ja tuotantotekniikka

ja robotille asetetuista vaatimuksista. keskeinen osa. Avainsanat: robotiikka, offline -ohjelmointi, automatisoitu valmistussolu, tehdasautomaatio iii

CONTENTS

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Factory automation infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Automated production cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Industrial internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.5 Industrial robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.5.1 Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5.2 Motion supervision and safety . . . . . . . . . . . . . . . . . . . . . . 6

3 Offline programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Offline programming tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 Motion supervision and safety . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Robot programming language . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Interface requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Documentation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3 I/O communication requirements . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3.1 General communication . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3.2 Safety communication and functionality . . . . . . . . . . . . . . . . 11

4.4 Interface logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A Configuration of virtual robot system . . . . . . . . . . . . . . . . . . . 16 A.1 Cell layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2 Robot controller configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2.1 Motion configuration for external axis . . . . . . . . . . . . . . . . . . 17 A.2.2 I/O configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3 Tool and work object configuration . . . . . . . . . . . . . . . . . . . . . . . 19 A.4 Safety configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4.1 Safety I/O functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4.2 Safe zones and ranges . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4.3 Safe zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4.4 Safe ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.5 Implementation of robot program . . . . . . . . . . . . . . . . . . . . . . . . 23 iv v

LIST OF SYMBOLS AND ABBREVIATIONS

ABB Swiss Swedish electronics and industrial systems manufacturer

AGV Autonomously guided vehicle

FAN Field area network

FMS Flexible manufacturing system

I/O Digital signal based communication

IPC Industrial pc

IRC Industrial robot controller

PLC Programmable logic controller

Profinet Industrial internet protocol by Siemens

Siemens German electronics and industrial systems manufacturer

TCP Tool center point

1 1

INTR ODUCTION

Manufacturing industry is in a state of rapid modernisation. Many industries have re- lied on industrial automation in machining applications as part of factory processes for decades. Now that automated part handling applications make safe and efficient tend- ing of machining stations possible, the factories are operating almost without downtime. To achieve seamless information flow within industrial multi device processes, everything needs to be connected in order to keep track of every task the work parts go through. De- velopment in automated solutions requires adaptability and knowledge as well as stan- dardisation on automated device interfaces in order to provide seamless integration to variety of other devices and even large scale systems. This thesis is written in request of Fastems oy to lay background for further development of ABB industrial robot product integration to Fastems product families. Fastems oy is a Finnish Tampere based family owned company providing integrated factory automation solutions for aerospace, automotive and general manufacturing industry. Fastems deliv- ers a wide array of automated part handling logistics solutions, including robot solutions, designed to be used with 3rd party machining centers and other separate stations or logistics solutions. In addition to hardware based solutions, software offering includes Manufacturing management software, or MMS, and other various options for factory au- tomation. Aim of this study is to produce a basic instruction on initial configuration of a virtual ABB IRC5 series industrial robot controller. In chapter 2 this work provides the reader with basic information about simple machine tending cell operations and terminology. Communication and safety requirements as well as functional requirements for a modern part handling cell are explained in chapter 4. Offline simulation and offline programming as well as the software that is used in this study are presented in chapter 3. Appendix A is the requested product of this study as it describes the process of configuring virtual IRC5 industrial robot controller using RobotStudio software in form of step by step guide. 2 2

F ACTORYA UTOMATIONINFRASTR UCTURE

To lay background to the field this study is written on, this chapter will explain key points on factory automation, which is defined as the use of control systems for operation of machinery and processes (Baliga 2015). It covers means of producing goods, monitoring quality, managing factory production and in factory logistics with automated processes. The aim of factory automation is either to increase throughput of the factory, minimize human error and inaccuracy in manufacturing process or extend production run time be- yond working hours. There are key factory automation terms to support the context of this study, which are automated production cell, device, Industrial robot, industrial inter- net and interface. these key terms will be further defined in following sections. 2.1

A utomatedpr oductioncell

Production cell is a collection of resources, such as workers and tools, that are designated for specific work phases of produced products. Cells are focused to a specific area in the factory floor and usually form a network that supports the requirements of factory logistics. Cells may have a buffer storage and integrated logistics, for example in form of production line. Production cell can be partly automated or fully automated, later requiring no human interaction inside the cell. In modern factories, automated factory logistics are integrated to production cell network (Garcia-Diaz and Lee 1995). In this study, the cell is a production cell with integrated part handling process, in which a robot is tending multiple machining stations and a buffer storage shelf, thus providing the cell with automated logistics. Material flows in and out of the cell requires human interaction. This type of an automated cell can be referred as Flexible manufacturing system, or FMS, which is a system capable of producing wide array of products with multiple machining stations (Atkins and Escudier 2013). 2.2

De vice

In the context of industrial automation, a device is a single, usually a programmable part of production, cell, that performs a given function in the network of devices, for example, as a manipulator, a machine tool, a sensor or a safety device. Modern sensing devices, such as laser scanners or safety light screens, usually have their own computation ca- pability and an array of sensors. Such devices, depending on the level of computation 3 performance, may have an Ethernet based communication interface, improving the com- patibility and setup convenience of the device. If production cell process requires human Interaction, human safety functionality may be implemented with safety devices, such as scanners and light screens or other optical safety device defined by international standard (ISO 12100 2010). Device configuration is the process of setting up a device parameters to enable it to perform given tasks to meet the requirements. Configuration includes changing of com- munication parameters, so that other devices can communicate with the device. The installation of required software and the possible software options for industrial PC de- vices is also part of configuration process. Configurations are usually downloaded or set to to-be-commissioned devices with documented routine. 2.3

Industrial internet

Before industrial internet technologies were recognized as a standard mean for creat- ing factory wide network for devices, it was common to implement hard wired physical communication interfaces between devices for each input and output signal. Input and output signals, or I/O signals, are electrically transferred bits or analog signal, that are in key position when it comes to communication between processing units. Input signals are received process commands from other processing units output signal and output signals are used to send process commands to other processing units input side (Butter- field and Szymanski 2018). This procedure of I/O signal exchange may be referred as a handshake between the processing units. Since a single electrical bit is binary, meaning that it has two states, 0 and 1, the infor- mation that may be transmitted through single signal is very limited. Grouping I/O signals enables more complex communication, such as sending and receiving bytes, or arrays of bits that can be translated in other data types. For example, integers that contain more complex information than binary value, are transferred as defined groups of multi- ple binary signals or so called group inputs or outputs. Grouped signals deliver positive integers with maximum valueIdefined by binary transformation equation:

I= 2n(2.1)

Wherenrepresents amount of grouped binary I/O signals or bits. Most automation de- vices have an in-software logic to handle grouped signals as integers or bytes. Analog signals may be used to transmit more than two values, but signal noise, or secondary frequency, must be taken to account, since it complicates the readability of the signal. Analog signals are also vulnerable to magnetic disturbance and setup of analog signal as mean of passing data requires calibration. This is why analog signals are replaced by PWM or pulse width modulated digital signals. PWM signals are not in the scope of this thesis. 4 The focus regarding this work is on communication interface between two devices in a part handling process. In modern solutions, the communication between devices is han- dled over industrial internet, which is the communication network between connected devices used in industrial applications including servers and management systems, such as process control. Communication between production management and automated shop floor operations is done over a field-area network, or FAN, which can be described as a communication system interconnecting factory floor automated cells and devices, as well as process control hubs. Main requirements for FAN are fast real-time commu- nication and data transfer, high reliability and robustness of wiring and High bandwidth (Blecker 2006). FANs are divided into two groups. First group being the fieldbus, used as a replacement for hardwired I/O systems offering a real time communication link between controller and devices, usually over a trunk line to which all devices are connected. The second group, FANs, are considered more modern and are based on Ethernet technologies, and unlike fieldbus, the second group can be used to form branched networks with the standardized Ethernet wiring. Both FAN groups are further divided into different protocols, such as with Siemens, Profibus being a fieldbus based and Profinet being an Ethernet based protocol (Blecker 2006). In a simple case, FAN may be used to connect two devices enabling I/O handshake between devices, but it is common to have a single master device handshaking with multiple slave devices. 2.4

Interface

Interface represents both the border between two devices and how information is passed on between devices. Automated devices are controlled with digital I/O signals that are either hard wired, or sent through a FAN with set protocol. In order for information to be exchanged through FAN as it should, the signal addresses on both devices must be set according to each other. One device may have several Interfaces to every other device in common network. In this case PLC/IPC unit sends and receives information to and from robot and other cell devices with I/O signals and due to company practicality, all devices, including robots regardless of manufacturer send and receive to and from same addresses at PLC. If there is a new device manufacturer in integration, the robot control signals are set in addresses in accordance to the interface documentation. 2.5

Industrial r obot

As defined by the international standard for robot systems (ISO 8373 2012), an indus- trial robot is an automatically controlled programmable manipulator with several jointed or sliding segments in motion with 3 or more axis of freedom, capable of performing intended tasks based on sensing without human intervention and is designed to meet general safety and operation standards for industrial use. Industrial robots have various applications in various industries. For example, machine tools and centers were previ- 5 ously tended by workers, but in modern factories, tending of machines is conducted with automated manipulators, such as industrial robots or automated storage and retrieval systems. Other common applications for robots in addition to machine tending are weld- ing, painting, lifting and machining tasks along with many other uses extending to mobile robot solutions such as storage handling or factory wide logistics using autonomously guided vehicles, or AGVs (Branch 1996). There are several well known brands known from industrial robot products including Fanuc, KUKA, ABB and Yaskawa. 2.5.1

Coor dinatesystems

Robot"s tool endpoint positions are defined in both angular values and through means of forward kinematics as Cartesian coordinate system values with Euler angles or Quater- nion rotation values. Forward kinematics is used to compute robot endpoint in Cartesian coordinate system by known joint values, whereas backwards kinematics are used to compute robot position or geometric movement as join angle values (Sun et al. 2007). Some robot systems use Quaternion rotation to calculate rotation. Quaternion rotation differs from Euler angles by having 1 real value and 3 imaginary values ranging from -1 to 1 instead of 3 angle values ranging from -180 to 180 degrees to determine rota- tional relation to fixed coordinate system (Wittenburg 2016). Since it is easier for human to understand relation in 3d-space as Cartesian position values compared to axis spe- cific angle values, robot position related variables are commonly expressed as Cartesian

coordinates in ready made robot solutions.Figure 2.1.Visual representation of tool center point, or TCP (Operating manual - IRC5

Integrator"s guide2018)

As with many other devices capable of 3d motion, robots are coordinated by multiple co- ordinate systems within a single base coordinate system. Two most common uses for user defined coordinate systems in context with industrial robots are tool coordinate sys- tem, used to define tool end position related tool base frame, and work object coordinate 6 system used to translate motions and to save programmable robot positions to a different

3d space. tool center point, or TCP in short is presented in figure 2.1.

2.5.2

Motion super visionand saf ety

In order to make robot cell safe from device and human perspective, robot not only needs to be connected to standardized safety network, but also have self monitoring functions. Most industrial robot manufacturers provide safety integration to robot products by pro- viding tools for joint position and speed supervision, Cartesian position and speed super- vision, torque monitoring and support for safety integrated field area network. Though robots are ideally programmed to avoid known obstacles, risk for human error, software bug or electrical fault in controller must always be taken to account for possible errors. Safe zones and safe ranges are used for robot movement and position monitoring ensuring safety of the robot system. Safe zone is a defined 3 dimensional space that is used to supervise robot movement in Cartesian coordinate system through forward and backward kinematics, where as joint ranges are a set of joint specific angle sectors that define acceptable robot positions. Single or group of safe zones or joint ranges can be paired with safety output signals in order to pass information up to cell control level and they can be controlled with input signal giving necessary flexibility to monitoring of robot work space on cell control level. 7 3

OFFLINE PR OGRAMMING

In context to this study, online programming is process of programming a live robot unit, where as offline programming is a process of programming an accurate virtual simula- tion of a robot unit. In addition to finding logical bugs and debugging the program, in robot applications, offline programming functionality is used to simulate robot movements making it possible to notice motion errors, such as possible collisions, further prevent- ing mentioned errors after commissioning phase of physical robot (Holubek et al. 2014). With offline programming tools, work on robot system may begin before the physical robot arrives to factory, thus decreasing time spent setting robot up for testing phase. Accord- ing to ABB, offline programming is effective way of maximizing return on for companies investment when implementing new system by promising shorter ramp up on robot cell (ABB 2019). Companies specializing in integration and commissioning of robot systems benefit from offline programming by minimizing testing phase time or the actual time robot systems spend on factory floor. Shorter testing times enable higher throughput of projects thus increasing productivity and cash flow. 3.1

Offline pr ogrammingtool

RobotStudio is Microsoft Windows native engineering tool for online and offline program- ming and simulation of ABB IRC series industrial robot controller and IRB series industrial robots. RobotStudio is based on actual software from IRC controller, which enables accu- rate simulation of virtual robot (ABB 2019). With RobotStudio it is possible to build virtual robot cells in their entirety enabling accurate simulation of robot motions in 3d environ- ment with so called virtual twin. It is important to note that offline programming software licence costs may shorten the margin with simple projects. 3.2

User interface

Standard human-machine interface for IRC5 controller is a Flexpendant (3.2), which is a handheld corded human machine interface for manual manipulation of robot manipulator and controller. Though enabling all actions regarding configuration, programming and manipulation of IRC5 system, flex pendant is initially meant to be used as a human ma- chine interface for shop floor operation and service, where as RobotStudio is intended to be used in precommissioning and recommissioning phases as a simulation tool. Its possi- ble to do the same configuration and programming related functions as with flex pendant, 8 but with RobotStudio one has more screen area and enhanced ergonomics of preferred pc workstation, when using the offline or online functionality. The virtual flex pendant may

be simulated in RobotStudio, allowing realistic testing of virtual twin system.Figure 3.1.RobotStudio user interfaceFigure 3.2.ABB Flexpendant for robot manipulation

3.3

Motion super visionand saf ety

Visual Safe Move, a software included in RobotStudio, is used to configure robot safety functions both motion and communication wise. It enables definition of motion supervi- sion using the virtual 3d environment and definition of safety function connected signals with easy to use signal editor. By using offline programming capability, robot test safety may be increased by configuring safety functionality before operation with real robot (Ap- plication manual - Functional safety and SafeMove22018). Use of RobotStudio and Visual Safe Move are presented with detail in appendix A. ABB robot controller Safety functions may be integrated to ProfiSAFE, CIP safety and hard wired safety I/O networks (Application manual - Functional safety and SafeMove22018). 3.4

Robot pr ogramminglangua ge

ABB IRC5 controller is programmed with functional Rapid language, which based in C programming language. Motion programming may take place in RobotStudio 3d environ- ment or with actual physical robot. Structure of Rapid program is presented in figure 3.3. 9 Programs have some program specific parameters, such as options for program to allow motion sequences. Programs contain modules, which contain the logic and data of the program. Modules, as the name suggests, may be added to program to perform a specific motion task or procedure. Modules contain functions and data that may be called from any other module within the program. System modules may be used as data storage for

program variables (Operating manual - IRC5 Integrator"s guide2018).Figure 3.3.Rapid program structure (Operating manual - IRC5 Integrator"s guide2018)

Typical workflow for time effective commissioning of robot system is to first do initial mo- tion and logic programming before robot arrives to integrator company. Upon arrival, it may be fitted with required tools and peripherals, configured and loaded with programs created and tested using virtual environment. In optimal cases, all that is left, is to teach tool frames, work object frames and robot positions to physical robot system. 10 4

INTERF ACEREQ UIREMENTS

When company specializes in device integration, it is usual to have a standardized doc- umentation for Interface configuration procedures. In most cases, it is more convenient to have changes to device I/O mapping minimized with devices, that are higher in device network hierarchy. For example if a master devices I/O mapping is changed, all the lower hierarchy device mappings may need to be adapted to new changes. This is why newly added slave devices are configured to meet the requirements of higher hierarchy device and network, since in larger networks, local master devices pass information to higher hierarchy. Interface documentation includes all details and requirements for communication be- tween two devices as well as the functions of devices. It is essential that all control signals are passed correctly from PLC to the robot controller enabling the external con- trol of robot system. Digital control signals or input signals pass a binary value to robot controller. Controller directs the signal to a certain function in robot controller. For exam- ple, a function that enables the manipulator motors could be activated with a single digital signal. 4.1

Functional requirements

Regarding this study, ABB robot system is integrated to an automated manufacturing cell to act as a manipulator for integrated part handling process, in which a robot is tending multiple machining stations and a buffer storage shelf thus providing cell with automated logistics. Material flows in and out of the cell requiring human interaction. This type of automated cell can be referred as Flexible manufacturing system, or FMS, which is a system capable of producing wide array of products with multiple machining stations (Atkins and Escudier 2013). Hierarchically, in a modern factory, FMS cell is part of factory material flow network con- trolled by higher level production management system. Fastems manufacturing man- agement system MMS handshakes with factory level production management system by providing real time data to management. MMS is used to control cell sized, multi cell sized, or even small factory sized operations and schedule part production process. Each FMS cell has a PLC as master control device, which is used to connect all devices in the cell through FAN. In this study, IRC5 Industrial robot controller is a slave device, which is logically controlled by IPC/PLC unit. IRC5 is industrial robot controller for robot motion 11 and logic tasks. It may be used to control most ABB IRB series robots, robot peripherals, such as track units, and custom designed mechanisms fitted with ABB motors. It is im- portant to make sure that the robot system is capable of providing required functionality compatible to robot systems already used by Fastems. 4.2

Documentation requirements

Interface documentation is usually written from the perspective of electrical design to act as an instruction for those responsible for configuring PLC and Robot systems communi- cation parameters. Interface documentation may be viewed as an alternative to electrical documentation of the system. Configuring the robot controller"s I/O mapping and FAN settings are the first tasks during setup right after controller configuration. Both I/O map- ping and Configuration of system specific parameters may also be configured by using a virtual twin. After the configuration of interface, program template and other required files are loaded to robot controller and testing phase may begin. 4.3

I/O comm unicationrequirements

Configuring I/O communication is of greatest importance, since it contains means of con- trolling the robot controller externally. Considering this study, the request demands that PLC/IPC sends and receives information to and from robot with I/O signals over ProfiNet. Due to company practicality, in which robots regardless of manufacturer send and re- ceive to and from same device addresses at PLC. If there is a new robot manufacturer in integration, Robots control signals are set in addresses in accordance of PLC like any other cell device. I/O communication can be divided in two sections. General and safety communication. 4.3.1

General comm unication

General I/O communication includes signals that transfer information about current robot state out to PLC and information about task objects and status updates into robot con- troller status signals. These signals are listed in a table that includes function and device mapping on both PLC and robot controller for each signal. General communication is set over ProfiNet industrial internet protocol. 4.3.2

Saf etycomm unicationand functionality

Unlike general I/O signals, safety I/O signals main purpose is to ensure safe operation in robot cell. In case of unexpected situations safety signals transfer data that may stop robot task or trigger cell wide emergency stop. Additionally safety signals are required to transmit data regarding safe area violations, which is part of robot motion supervision functionality. 12 If one device in safety communication network enters fail state or safety function is trig- gered on any networked device, all designated cell devices halt and alarms are passed to process control level user interface. In case of using safety protocol such as ProfiSAFE, faulty communication triggers safety stop for all devices due to cyclic integrity analysis of network itself. (Rofar and Franekova 2006). 4.4

Interface logic

Interface logic is the immediate reaction or processing of a certain signal. Responses for PLC request signals are a good example on interface logic. When IRC receives an input signal dedicated as a request, requested function must be executed and output signal indicating the execution of function must be triggered in order to pass the information to PLC unit. This is a simple procedure of slave device replying to master device. Since all Fastems solutions are native to MMS process control system, it is vital to dis- play all alert and status messages from lower hierarchy devices, including IRC5 controller, to MMS. The passing of robot user interface messages to process control level system is considered part of interface logic. Communication to MMS layer may be done using Ethernet connection over network socket to the closest user interface station. Duringquotesdbs_dbs14.pdfusesText_20