Promia

The heart of Robotics

ABB User Manual Promia 50 application – Material Handling IRC5

RDNU0006_F_MH-Promia50_Eng.doc

User Manual Promia 50 application – Material Handling Document ID: RDNU0006 Revision: F

This document is intended for recto/verso printing. Document based on model RDDI0013_E

The information in this manual is subject to change without notice and should not be construed as a commitment by ABB. ABB assumes no responsibility for any errors that may appear in this manual. Except as may be expressly stated anywhere in this manual, nothing herein shall be construed as any kind of guarantee or warranty by ABB for losses, damages to persons or property, fitness for a specific purpose or the like. In no event shall ABB be liable for incidental or consequential damages arising from use of this manual and products described herein. This manual and parts thereof must not be reproduced or copied without ABB's written permission, and contents thereof must not be imparted to a third party nor be used for any unauthorized p urpose. Contravention will be prosecuted. Additional copies of this manual may be obtained from ABB at its then current charge.

© ABB ABB France s.a.s Robotics Division Rue de l’Equerre ZI des Béthunes 95310 Saint-Ouen l’Aumône FRANCE

2

RDNU0006 Revision F

User Manual Promia 50 application – Material Handling Document ID: RDNU0006 Revision: F

This document is intended for recto/verso printing. Document based on model RDDI0013_E

The information in this manual is subject to change without notice and should not be construed as a commitment by ABB. ABB assumes no responsibility for any errors that may appear in this manual. Except as may be expressly stated anywhere in this manual, nothing herein shall be construed as any kind of guarantee or warranty by ABB for losses, damages to persons or property, fitness for a specific purpose or the like. In no event shall ABB be liable for incidental or consequential damages arising from use of this manual and products described herein. This manual and parts thereof must not be reproduced or copied without ABB's written permission, and contents thereof must not be imparted to a third party nor be used for any unauthorized p urpose. Contravention will be prosecuted. Additional copies of this manual may be obtained from ABB at its then current charge.

© ABB ABB France s.a.s Robotics Division Rue de l’Equerre ZI des Béthunes 95310 Saint-Ouen l’Aumône FRANCE

2

RDNU0006 Revision F

Table of Contents Overview .................................................... ................................................................................................................ ..................................................................................5 ......................5 Product Documentation, M2004 ......................................................... ................................................................................................... .......................................... 7 Promia Documentation.................................................................................................................8

1 Safety 1.1 1.2 1.3

About the Safety section ......................................................... ................................................................................................... .......................................... 9 Safety standards applicable to IRC5 ........................................................... ...............................................................................10 ....................10 Safety terminology ........................................................ .......................................................................................................... .................................................. 11

2 Welcome 2.1 2.2 2.3 2.4

4.6 4.7

4.8

25

General information.........................................................................................................25 Loading the application software.....................................................................................25 Software architecture .................................................... ...................................................................................................... .................................................. 27 Organization of memory..................................................................................................28 Organization of RAPID files .................................................... ............................................................................................ ........................................30 30 Contents of the Site Site directories directories ......................................................... .......................................................................................3 ..............................31 1 3.6.1 Common base modules ......................................................... ..............................3 1

4 Operating principles 4.1 4.2 4.3 4.4 4.5

13

About the Welcome section .................................................... ............................................................................................ ........................................13 13 What is Promia?..............................................................................................................14 Integrator customizations ........................................................ ................................................................................................ ........................................16 16 Terms and concepts used in this manual........................................................................17 2.4.1 Robot program and path principles .......................................................... ...........17 2.4.2 Repositioning and recycling principles .................................................... ...........19 2.4.3 Commands and events.........................................................................................21 2.4.4 Tooling commands and events ........................................................ ....................21 2.4.5 Material handling management ....................................................... ....................22 2.4.6 Debug mode ...................................................... .................................................. 23

3 Organization of application software 3.1 3.2 3.3 3.4 3.5 3.6

9

33

General controls of the robot controller...........................................................................33 Main menu of FlexPendant ..................................................... ............................................................................................. ........................................34 34 Considerations related to single and multi-robot environments.......................................35 Running the program .................................................... ...................................................................................................... .................................................. 38 Production modes ......................................................... ........................................................................................................... .................................................. 40 4.5.1 "Production enabled" and "Production disabled" modes.....................................40 4.5.2 Active commands according to operation modes................................................41 4.5.3 Move to Safe Safe and Move to Home commands commands .................................................... .41 4.5.4 Catching and priority of program codes..............................................................45 Principles relative to actions and checks attached to a position......................................47 Continuous monitoring ............................................................ .................................................................................................... ........................................48 48 4.7.1 Dynamic monitoring............................................................................................48 4.7.2 Error management ....................................................... ........................................ 49 Behaviors in cases of exception......................................................................................50 4.8.1 Behavior during manual jogging ..................................................... ....................50 4.8.2 Behavior in case of repositioning .................................................... ....................50 4.8.3 Behavior in case of recycling .......................................................... ....................50

5 Man-Machine Interface

RDNU0006 Revision F

51

3

Overview 5.1 5.2 5.3

5.4 5.5 5.6

5.7

General description of the screen container....................................................................51 Choice of "Common Features" screens ...................................................... ..........................................................................53 ....................53 Production screen ......................................................... ........................................................................................................... .................................................. 55 5.3.1 Program area details .................................................... ........................................ 55 5.3.2 Message area details............................................................................................56 Error messages...............................................................................................................59 5.4.1 Common base application messages ........................................................ ...........59 Operator panel screen ............................................................ .................................................................................................... ........................................65 65 Promia information screens .................................................... ............................................................................................ ........................................66 66 5.6.1 General description of the information screen.....................................................66 5.6.2 Part detection screen............................................................................................68 5.6.3 Sequence screen .......................................................... ........................................ 70 5.6.4 PLC and Tool Event Screens...............................................................................76 5.6.5 PLC and Tool Command Command Screens ................................................... ....................78 Backup screen .................................................... ............................................................................................................... ............................................................79 .79 5.7.1 General description of screen .......................................................... ....................80

6 Editing paths 6.1 6.2 6.3

General information.........................................................................................................83 Insertion of a specific instruction of the the application ........................................................ .........................................................84 .84 Inserting a « Common base » instruction........................................................................85

7 Actions on paths common to all processes 7.1 7.2 7.3

7.4

7.5

7.6

7.7 7.8 7.9

4

105

General information.......................................................................................................105

9 Index and appendices 9.1 9.2

87

Programming anti-loop functions.....................................................................................87 Giving information about active path and active robot program ...................................... ......................................89 89 Programming PLC commands .......................................................... ........................................................................................9 ..............................90 0 7.3.1 SendPlc instruction ............................................................ ..............................9 0 7.3.2 MoveSendPlc instruction.................................................................................91 Programming events ..................................................... ....................................................................................................... .................................................. 92 7.4.1 PlcEvent instruction ........................................................ ..............................9 2 7.4.2 MovePlcEvent instruction .......................................................... ....................93 Programming tool commands ........................................................... .........................................................................................9 ..............................94 4 7.5.1 SendTooling instruction.................................................................................94 7.5.2 MoveSendTooling instruction ................................................... ....................95 Programming tool events ........................................................ ................................................................................................ ........................................96 96 7.6.1 ToolingEvent instruction .......................................................... ....................96 7.6.2 MoveToolingEvent instruction.....................................................................97 Programming handling sequences..................................................................................98 7.7.1 GripperAction instruction............................................................................99 Programming part detection functions...........................................................................100 7.8.1 CheckPart instruction ....................................................... ............................10 0 Programming the dynamic dynamic monitoring monitoring functions .................................................. ...........................................................102 .........102 7.9.1 MonitorInputs instruction..........................................................................102

8 Service programs 8.1

83

107

Index ......................................................... .................................................................................................................... ....................................................................107 .........107 Table of figures ................................................... ............................................................................................................. .......................................................... 109

RDNU0006 Revision F

Overview

Overview

About this manual This manual contains detailed instructions on how to use of the material handling functions of the Promia application. The manual gives the characteristics of the basic application, orientated to handling.

Usage This manual should be used during operator training workshops, and when creating or modifying programs based on the Promia application software.

Who is this manual intended for This manual is intended for: • Operators • Maintenance technicians • Robot programmers and integrators

Prerequisites The reader must: • Be familiar with use of the IRC5 FlexPendant • Be trained in basic robot programming.

References – Product Documentation Reference

Document

Product Manual, procedures Product Manual, references Startup - IRC5 and RobotStudio Online

IRC5 3HAC 021313-001 IRC5 3HAC 021313-001 3HAC 021564-001

How to read this manual To facilitate reading this manual, special formatting is used to indicate different types of information. Text that is...

is written with...

Example

names on elements in the user interface, like menus, dialog boxes and buttons

bold letters

In the Open File dialog File dialog box, click OK

names on keyboard keys

RDNU0006 Revision F

capital letters

To open the help, press the F1 key.

5

Overview quotes from computer or output, like error messages, written RAPID instructions and other computer code variables in quotes from computer input or output, like error messages, written RAPID instructions and other computer code Hypertext links to other information topics References to other information topics

monospace letters

MoveJ

Italic monospace letters

PROC RoutineName()

blue italic letters

italic letters

See The RobotStudio Online Operator’s Manual See the RAPID reference manual for further information.

Revisions Revision A B C D E F

6

Description First issue, December 2005 Updated with new MMC interface, December 2006 Update of master document 02/2007 Update of master document – Add new simplified backup functionality. 11/2007 Miscellaneous 04/2008 Add warnings about B-Start et recycling 05/2008

RDNU0006 Revision F

Product Documentation, M2004

Product Documentation, M2004

General information

The robot documentation is divided into different categories. The list is based on the type of information contained in each document, whether the products are optional or not. This means that each robot delivery will not contain all the documents listed, but only those corresponding to the equipment supplied. However, all the documents listed can be ordered from ABB. The documents listed are valid for the M2004 robot systems.

Hardware Manuals All hardware, robots and control cabinets will be deli vered with a Product Manual , which is divided into two parts: Product manual, procedures •

Safety information

•

Installation and commissioning (descriptions relative to mechanical installation, electrical connections and loading system software)

•

Maintenance (descriptions of all required preventive maintenance procedures, including intervals)

•

Repair (descriptions of all recommended repair procedures, including spare parts)

•

Additional procedures, if any (calibration, decommissioning)

Product manual, reference information •

Reference information (article numbers for documentation referred to in Product manual, procedures, lists of tools, safety standards)

•

Part list

•

Foldouts or exploded views

•

Circuit diagrams

RobotWare Manuals The following manuals provide a general description of the robot software and contain the applicable reference information. • RAPID Overview: Overview of RAPID programming language • RAPID Reference Manual, part 1: Description of all RAPID instructions. • RAPID Reference Manual, part 2: Description of all RAPID functions, including data types. • Technical reference manual – System parameters: Description of system parameters and configuration workflows.

RDNU0006 Revision F

7

Promia Documentation

Application manuals Specific applications (e.g. software or hardware options) are described in Application manuals. An application manual can describe one or several applications. An application manual generally contains the following information about: •

The purpose of the application (what it does and when it is useful)

•

What is included (e.g. cables, I/O boards, RAPID instructions, system parameters)

•

How to use the application

•

Examples of how to use of the application.

Operator manuals This group of manuals is aimed at those having first hand operational contact with the robot, i.e. production cell operators, programmers and troubleshooters. This group of manuals contains: •

Getting Started - IRC5 and RobotStudio Online

•

Operator manual - IRC5 with FlexPendant

•

Operator manual - RobotStudio Online

•

Troubleshooting manual for the controller and robot

Promia Documentation

General information Promia is a family of application software intended for the IRC5 robot systems. All of these software applications include a common part, linked to the material handling process, on which a part specific to a process can be added. For each process, the Promia documentation includes a user manual and an integration guide. The information supplied for a given process always includes the information relative to the handling process.

8

RDNU0006 Revision F

1 Safety 1.1 About the Safety section

1 Safety 1.1

About the Safety section

Introduction to Safety This section details the safety principles and the procedures to be applied when a robot or a robot system is in operation. It does not cover how to design for safety nor how to install safety related equipment. These topics are covered in the Product Manuals supplied with the robot system.

Personnel safety Any moving manipulator is a potentially lethal machine. When running the manipulator, it may perform unexpected and sometimes irrational movements. However, all movements are performed with great force and may seriously injure any personnel and/or damage any piece of equipment located within the manipulator working range.

Safety regulation Before starting to work with the robot, make sure you are perfectly familiar with the safety rules detailed in the Operator Manual – IRC5 with FlexPendant.

RDNU0006 Revision F

9

1 Safety 1.2 Safety standards applicable to IRC5

1.2

Safety standards applicable to IRC5

Safety standards The robot fully complies with the safety standards specified in the European machinery directives. The ABB robots controlled by the IRC5 comply with the following standards: Standard EN ISO 12100-1 EN ISO 12100-2 EN 954-1 EN 775 EN 60204 EN 61000-6-4 (option) EN 61000-6-2

EMC, generic emission EMC, generic immunity

Standard IEC 204-1 IEC 529

Description Electrical equipment of industrial machines Degrees of protection provided by enclosures

Standard ISO 10218

Description Manipulating industrial robots, safety Manipulating industrial robots, coordinate systems and motions

ISO 9787 Standard ANSI/RIA 15.06/1999 ANSI/UL 1740-1998 (option) CAN/CSA Z 434-03 (option)

10

Description Safety of machinery, terminology Safety of machinery, technical specifications Safety of machinery, safety related parts of control systems Manipulating industrial robots, safety Electrical equipment of industrial machines

Description Safety requirements for industrial robots and robot systems

Safety standard for robots and robot equipment Industrial robots and robot systems - General safety

RDNU0006 Revision F

1 Safety 1.3 Safety terminology

1.3

Safety terminology

Overview This section describes the various types of warning which may be given during the operations described in this manual. Each warning is explained in its own section with: •

A symbol for each hazard level (DANGER, WARNING or CAUTION) and the type of hazard

•

A brief description of the result of the hazard if the operator/service personnel does not eliminate the hazard

•

An instruction enabling the personnel to eliminate the hazard and perform the operation manually.

Hazard levels The table below defines the hazard symbols used in this manual. Symbol

Designation

Danger

Danger

Warning

Warning

Electrical shock

Meaning Warns that an accident will occur if the instructions are not followed, resulting in a serious or fatal injury and/or severe damage to the product. It applies to warnings that apply to danger with, for example, contact with high voltage electrical units, explosion or fire risk, risk of poisonous gases, risk of crushing, impact, fall from height etc. Warns that an accident may occur if the instructions are not followed, that can lead to serious injury, possibly fatal, and/or great damage to the product. It applies to warnings that apply to danger with, for example, contact with high voltage electrical units, explosion or fire risk, risk of poisonous gases, risk of crushing, i mpact, fall from height etc.

The electrocution or electrical shock symbol indicates electrical hazards which could result in severe personal injury or death.

Electrical shock

RDNU0006 Revision F

11

1 Safety 1.3 Safety terminology

Caution

Warns that an accident may occur if the instructions are not followed, that can result in injury and/or damage to the product. It also applies to warnings of risks that include burns, eye injury, skin injury, hearing damage, crushing or slipping, tripping, impact, fall from height etc. Furthermore, it applies to warnings that include function requirements when fitting and removing equipment, where there is a risk of damaging the product or causing a breakdown.

Electrostatic discharges (ESD)

The electrostatic discharge (ESD) symbol indicates electrostatic hazards which could result in severe damage to the product.

Tip

Tip symbols direct you to specific instructions, where to find additional information or how to perform a certain operation in an easier way.

Note

Note symbols alert you to important facts and conditions.

Caution

Electrostatic discharges(ESD)

Tip

Note

12

RDNU0006 Revision F

2 Welcome 2.1 About the Welcome section

2 Welcome 2.1

About the Welcome section

Overview The Welcome section provides an overview of the PROMIA application software. The 5.x versions of this application software are intended for the IRC5 robot systems, in both the single and multi-robot configurations. This section describes the main Promia functions, as well as the concepts and terms which will be used in this document.

RDNU0006 Revision F

13

2 Welcome 2.2 What is Promia?

2.2

What is Promia?

Promia Description The term "PROMIA" refers to the family of software applications organized around a “common base” which defines the interfacing principles with a PLC and the material handling functions. The software applications derived from the common base include interfaces with different processes and/or different specific equipments. In particular, Promia can be delivered as a Pro mia Arc application, orientated toward arc welding, and a PROMIA SRE application, orientated toward Spot Welding on electrical welding guns.

Main components of basic application software

Promia Common Base Safety Functions

Management of Part Codes Commands – events

Applicative Functions

Monitoring

User Screens

Tooling Control Cabinet

Figure 1.

Tooling Commands and Events

PLC

Gripper Material Handling Functions

& Tool

Block diagram of PROMIA application software

The basic application software manages the interface with an industrial PLC in order to handle the part codes, synchronizations through commands and events, and error reporting through monitoring functions. It also manages the interface with the grippers and tools through « handling sequences », also called "gripper actions" and « part detection monitoring » functions. Exchanges with a tooling control cabinet are managed by tooling commands and events. The safety functions consist of a pre-configuration for acknowledgement of remote start requests.

14

RDNU0006 Revision F

2 Welcome 2.2 What is Promia?

The applicative functions are the management of the movements to the "safe" and "home" positions, and the management of the service requests that are local to the robot controller. The user screens display the information relative to the application software functions. These screens are detailed later in this document.

In a multi-robot environment, the management of the part codes and the error reporting are common and global for all the robots. On the other hand, the commands, events and the handling interface are specific to each robot.

RDNU0006 Revision F

15

2 Welcome 2.3 Integrator customizations

2.3

Integrator customizations

Integrator tasks Promia is not directly operational in the form in which it is delivered and installed. Promia is a programming frame, not an end-user application. Promia becomes a customer final application once it has been customized by the integrator; it is their job to define the robot paths and adapt the Promia functions to the specific requirements of the user site. The information required for customization is detailed in the Promia application software integration guides.

16

RDNU0006 Revision F

2 Welcome 2.4 Terms and concepts used in this manual

2.4

Terms and concepts used in this manual

Overview This section describes the main concepts and terms used in this manual. The description starts with the general concepts related to execution of the robot paths and to the continuous monitoring performed by the application software, followed by the terms related to the dialogue with the PLC, and finally, the terms related to the various processes.

2.4.1 Robot program and path principles Robot program and path principle The various production tasks to be performed by a robot, or by a set of robots controlled by a single robot controller, are selected in accordance with information coming from the robot(s) environment. The robot controller can receive work requests from different components: •

The PLC, that sends part codes according to a pre-defined protocol,

•

A specific process equipment which requests a service operation (for example, tip dressing for a welding gun or cleaning of a welding torch),

•

A service request, local to the robot controller, through a pushbutton, for instance,

•

An external device (selector, for example).

The first three cases are handled on a standard basis by Promia. The fourth case can be implemented by an “internal code” mechanism described below in the manual. Each requested task is executed as a « robot program » which is itself divided into « paths ». To facilitate installation control and maintenance, the various paths begin and end by a fine point. They also include an "anti-loop" mechanism to ensure that they are not executed as a loop without returning to the main robo t program.

Significant positions and sequencing of robot programs In principle, the various robot programs begin and end by a specific position referred to as "home" position. T he new program codes are only taken into account on this point. The organization of the various robot programs then takes the form of a "daisy" with the home position at its center.

It is also possible to terminate the robot programs outside this point; this function is described in the Basic handling application software integration guides .

RDNU0006 Revision F

17


T_Service1 T_MoveToHome

Traj1 Progra m n°1

Home Position

Safe Position

f e a S T o t c r e i D v e o M T_

Traj2

Traj3

T_MoveToSafe

Traj5 Traj4

Program n°2

Figure 2.

Sequencing of paths ; « daisy » principle

The other significant position is the "safe" position which is a maintenance position where technicians can perform maintenance operations on the robot and/or its gripper or tool. This is also the starting point to get the cell ready for production and the final point reached at the end of p roduction. There are thus three specific paths: •

T_MoveToHome, which moves the robot from the safe position to the

home position, and is executed at production startup •

T_MoveToSafe, which moves the robot back from the home position

to the safe position, and is executed at the end of production •

T_MoveDirectToSafe, which moves the robot directly from its

current position (anywhere) to the safe position.

18

RDNU0006 Revision F


2.4.2 Repositioning and recycling principles

Description When a robot has been stopped during its execution, there are two different ways to resume the execution sequence: •

The robot resumes its path, after possible physical repositioning toward the position where the stop took place. This procedure is called "path regain" or “repositioning”,

•

The robot does not resume the normal path, either because the operator, after some manual jogging, is aiming directly at the next programmed position, or because the operator, using the Debug menu in the Program editor window, has placed the program pointer on an instruction different from the current instruction. In both cases, the recovery procedure is referred to as “recycling”.

Figure 3.

Debug menu

Programmed position n+1

Progarmmed position n+2

Recycling Programmed position n Figure 4.

RDNU0006 Revision F

Position where the robot stopped

Recycling without manual jogging

19


Current position

Recycling Jogging (1)

Repositioning

Programmed position n+1 Programmed position n Figure 5.

Position where the robot stopped

Programmed position n+2

Repositioning and recycling after manual jogging

The behavior of the active outputs and monitoring functions will differ according to the procedure (repositioning or recycling) used when resuming work. These are documented in the Operating Principles detailed in this User Manual.

20

RDNU0006 Revision F


2.4.3 Commands and events Description The synchronization with the cell environment is made through digital inputs/outputs that are exchanged with the PLC and referred to as « commands and events ». The commands are information signals sent by the robot to the environment. The events are information signals expected by the robot from the environment. The commands and events can be programmed on positions when creating or modifying paths. Appropriate instructions enable them to be programmed either a fine point or on a fly-by point.

Commands

Line or Cell PLC

Robot Controller

Events

Figure 6.

Commands and events

2.4.4 Tooling commands and events Description The synchronization with a tooling controller is made through digital inputs/outputs that are exchanged with the tooling controller and referred to as « tooling commands and events ». The « tooling commands » are information signals sent by the robot to the tool cabinet. The “tooling events” are information signals expected by the robot from the tool cabinet. The tool commands and events can be programmed on positions when creating or modifying paths. Appropriate instructions enable them to be programmed either a fine point or on a fly-by point.

Tooling Commands Tool Control Cabinet

Robot Controller

Tooling Events

Figure 7.

RDNU0006 Revision F

Tooling commands and events

21


2.4.5 Material handling management Overview The clamping components, whether these are fixed or integrated in a gripper, are made of monostable or bistable actuators, associated with sensors used to check their position. The actions on these components are referred to as « Handling sequences », or "Gripper actions". Some sensors are also used to detect the part picked up in the gripper. These signals are referred to as “Part detection” signals. Note: The handling sequences can also be used to control other components than the grippers. These are used for example to manage the tip extractors and the tip dresser flaps operated by the Spot Welding process. Depending on the complexity of the site, the handling sequences and the part detection sensors can be managed either by the robot or by the PLC. The two management modes can be used together (example: material handling managed by the PLC, but tip dresser flaps managed by robot sequences).

Material Handling managed by PLC In this configuration, the PLC manages the actuators and monitors the sensors. Programming in the robot paths is done through specific PLC commands and events. The management of the part sensors is in this mode entirely unknown from Promia. If so defined by the integrator, the handling sequences managed by the PLC can be controlled manually on the robot teach pendant when the robot is not executing any motion program.

Material Handling managed by robot The handling functions of the basic application can process up to 16 sequences (pneumatic actuators, suction cups …) using digital inputs/outputs for which the programming is entirely open to the integrator. Each time a sequence is controlled, correct operation of the sequence is verified by checking and monitoring the feedback inputs related to the programmed action. These sequences are typically programmed on fine points. Execution of a “sequence” then incorporates both the control and check actions. It is also possible to initiate control actions on a fly-by point and perform the associated checks on the following fine point.

22

RDNU0006 Revision F


2.4.6 Debug mode Definition The debug mode is used to test the robot programs, without a part, when the installation is not yet complete. This mode can be activated both in manual mode and in automatic mode and is used, among others, to verify the program structure, the accessibilities and the movements of the cables. This mode is activated by a specific input, DEVERM, included in the table of exchanges with the PLC. In the mode: •

the processes are inactive,

•

if material handling is managed by the robot, the part detection functions are replaced by wait times. The values of these times can be configured by the integrator,

•

if handling is managed by the robot, the handling sequence checks can be activated or inhibited in accordance with a specific configuration for each sequence. If inhibited, they are replaced by wait times. The values of these times can be configured by the integrator.

The transition from debug mode to real mode is immediate for the handling sequences and part detection functions. Reactivating the process is generally performed when the next program code is received.

RDNU0006 Revision F

23


24

RDNU0006 Revision F

3 Organization of application software 3.1 General information

3 Organization of application software 3.1

General information

Section content This section describes the architecture of the application software, the organization of the RAPID files and the organization of the memor y.

3.2

Loading the application software

ABB supply The robot controller supplied by ABB contains the pre-installed Promia application software. Reinstallation of the application software is described in the Promia integration guide.

P-Start When a user module common to several tasks has been modified, the application software must be reinitialized by a P-Start command. In the ABB menu, select " Restart"

Select " Advanced…"

RDNU0006 Revision F

25

3 Organization of application software 3.2 Loading the application software

Tap P-Start and validate by OK

Initiate by P-Start

26

RDNU0006 Revision F

3 Organization of application software 3.3 Software architecture

3.3

Software architecture

Composition of the controller software Once the Promia application has been installed, the software in the robot controller has the following architecture:

Trajectories Integrator Process Modules

Integrator Common Base Modules

Promia Process Modules

Promia Common Base Modules

ProcessWare

BaseWare

ABB RobotWare PROMIA internal software (cannot be modified) PROMIA customization

Figure 8.

Software architecture

The Promia delivery is divided into two distinct parts: •

The Promia internal application software, ensuring the functions described in this manual. These modules cannot not be modified by the customer or the system integrator,

•

A pre-configuration of the integrator modules, providing the necessary openings for integrator customizations and some examples of this customization.

The combination of RobotWare and PROMIA source code build up a reference, resulting in a specific Promia version. Any change made to any of these 2 components will result in a new reference and a new Promia version.

RDNU0006 Revision F

27

3 Organization of application software 3.4 Organization of memory

3.4

Organization of memory

Task implementation Two tasks are implemented for each independent mechanical unit: •

a foreground task, also called motion task, which contains the movement programs

•

a background task, which handles the continuous monitoring functions

Each of these tasks contains specific modules and modules which are shared between the 2 tasks. The non-modifiable modules of the common base of Promia are the same for each mechanical unit. The non-customizable process modules are only included in the tasks related to the mechanical units which use this process. The customizable modules of Promia are specific to each mechanical unit. If we consider a system with 3 mechanical units (3 robots) with the first one using nd a process 1 and the 2 and 3rd tasks using a process 2, the configuration will be as follows:

Mechanical Unit 1 Foreground Task

Background Task

Promia internal modules Foreground Common Base

Foreground+ Background Common Base

Background Common Base

Foreground Process 1

Foreground+ Background Process 1

Background Process 1

Customized Modules for Mechanical Unit 1

28

Foreground Common Base






RDNU0006 Revision F

3 Organization of application software 3.4 Organization of memory


Background Task







Customized Modules for Mechanical Unit 2 Foreground Common Base







Background Task







Customized Modules for Mechanical Unit 3

RDNU0006 Revision F

Foreground Common Base






29

3 Organization of application software 3.5 Organization of RAPID files

3.5

Organization of RAPID files

Organization on the FlashDisk The mass storage of a robot controller is a FlashDisk named hd0a. Located in the root of the FlashDisk is the RobotWare directory corresponding to the RobotWare versions installed, the APPL-PROMIA50.xxx directory containing the internal modules of Promia, and the robot systems that have been created. Most often, the flashdisk only contains one version of RobotWare, one version of PROMIA and one robot system. The modifiable modules of Promia are installed in SiteX sub-directories of the current robot system.

hd0a/ RobotWare_ x.yy.zzzz APPL-PROMIA50.xx Current robot System Backup home Site x Syspar

Figure 9.

Organization on the flashdisk

In a single robot system, there is only one site sub-directory, called “Site”. In a multi-robot system, there is a site directory for each of the independent mechanical units. These directories are then named Site1, for mechanical unit No. 1, Site2, for mechanical unit No. 2, and so on.

30

RDNU0006 Revision F

3 Organization of application software 3.6 Contents of the Site directories

3.6

Contents of the Site directories

The Site directories contain all the customizable modules of Promia for a gi ven mechanical unit. Their contents will vary according to the processes installed on the corresponding mechanical unit.

3.6.1 Common base modules List of customizable modules Module name (single robot environment)

Module name (multi-robot environment – mechanical unit ‘n’)

Main purpose of module

CEL_CONF.SYS

CEL_CONF.SYS

Definition of constants common to the cell ; loaded in foreground and background tasks

CEL_MENU.SYS

CEL_MENU.SYS

Definition of screen container menus and operator panel buttons (see section 5 Man-Machine Interface). Note : This module only appears on the site directory related to mechanical unit 1

DEF_SITn.SYS

Definition of the names used for sequences, part detection, commands and events ; these names will be used in the PROMIA screens ; loaded in foreground and background tasks

MAN_CNFn.SYS

Definition of signals used for part detection ; definition of handling sequence control and monitoring functions; loaded in foreground and background tasks

PERSO_AVn.SYS

Integrator customization on system events; actions to be performed at end of movements to the home and safe positions; loaded in foreground task only.

PERSO_ARn.SYS

Integrator customizations related to continuous monitoring; loaded in background task only.

LOCALIZATION .SYS

LOCALIZATION .SYS

Not really a customization module: Used to implement the English version of the application. Also contains the definition of the safe and home positions

PRG_MVT.MOD

PRG_MVn.SYS

Definition of paths and sequencing in programs.

DEF_SITE.SYS

MAN_CONF.SYS

PERSO_AVP.SYS

PERSO_ARP.SYS

RDNU0006 Revision F

31

their

3 Organization of application software 3.6 Contents of the Site directories

32

RDNU0006 Revision F

4 Operating principles 4.1 General controls of the robot controller

4 Operating principles 4.1

General controls of the robot controller

Available control devices

FlexPendant

Main switch Emergency Stop Motors On light & button Mode selector (Manual/Auto)

Figure 10.

Robot system control devices

Optionally, a « Move to Safe » luminous push button can be provided.

Dedicated keys on the FlexPendant There are two groups of dedicated keys on the FlexPendant: a group of programmable buttons and a group of “Execution Control” buttons.

Programmables Keys

Start Move backward

Move Foreward Stop

Figure 11.

RDNU0006 Revision F

Dedicated keys on the FlexPendant

33

4 Operating principles 4.2 Main menu of FlexPendant

4.2

Main menu of FlexPendant

Accessing the main menu The main menu of the FlexPendant is accessed by pressing the located at the top left corner of the FlexPendant.

button

Contents of the main menu

Figure 12.

ABB basic menu

The main menu displays two columns: •

The left hand column is aimed to programming and everyday operation,

•

The right hand column is more dedicated to configuration and maintenance operations.

Windows accessed from the ABB main menu are described in the IRC5 product documentation.

34

RDNU0006 Revision F

4 Operating principles 4.3 Considerations related to single and multi-robot environments

4.3

Considerations related to single and multi-robot environments

Promia is an application software designed to operate in both single and multi-robot environments. Some of the screen snapshot examples in this document are taken from a system with three robots controlled by the same robot controller. However, the principles described are also valid in a single-robot environment.

Single robot and multi-robot system In a single robot environment, the robot controller controls a single mechanical unit or a group of mechanical units that run simultaneously. There is only one foreground robot task containing the movement instructions for the robot. A multi-robot system enables one single robot controller to control several mechanical units independently. Software options are used, among others, to coordinate and synchronize the movements of the different mechanical units. In a multi-robot environment, there is a movement task for each independent mechanical unit. These tasks are, by default, called T_ROB1, T_ROB2, … T_ROBn for the robot arm type mechanical units and T_POS1, T_POS2, T_POSn for the positioner type mechanical units. For compatibility purposes, the movement task, in a single robot environment, is also called T_ROB1.

These movement tasks have a name which begins by « T_ ». These must not be confused with the path names which also traditionally begin by « T_ ».

RDNU0006 Revision F

35


Specific features of basic MMI in a multi-robot environment The main changes in RobotWare man-machine interface, compared to a single robot system are as follows: •

•

There is a programming environment for each robot. In the ABB menu, the choice of the Program Editor window must be followed by the selection of the foreground task to be edited (this selection window does not appear in a single-robot environment) :

Figure 13. •

The Production window displays several vertical tabs; there is one tab for each foreground task.

Figure 14.

36

Choice of program to be edited

Production window in a single-robot environment

RDNU0006 Revision F


Figure 15.

Production window in a multi-robot environment

During execution, the program pointer is reliably refreshed in the production window. This is not always the case in the Program Editor windows.

RDNU0006 Revision F

37

4 Operating principles 4.4 Running the program

4.4

Running the program

Running the program in manual mode If at least one of the robots controlled by the robot controller is not at its safe or home position, it will be necessary to initiate program execution in manual mode. •

•

Set the mode selector to "Manual"

In the ABB menu, select the Production Window in the left part of the menu. If the program pointer was previously reinitialized at the start of the program, the window displayed is as follows :

Figure 16. •

Program restarted at beginning (single or multi-robot)

If this is not the case, reinitialize the program using the PP to Main command. This command reinitializes the program pointers of all the foreground tasks and requests a confirmation :

Figure 17.

38

,

Confirmation of PP to Main (single or multi-robot)

•

Press the FlexPendant enabling device to set "Motors On" on the robot(s)

•

Start execution by pressing the

button.

RDNU0006 Revision F

4 Operating principles 4.4 Running the program Running program in automatic mode If all the robots are at the safe or home position, the program can be initiated in automatic mode: •

After having repositioned, if necessary, the program pointers to the start of the program, as above,

•

Set the mode selector to "Auto"

•

Acknowledge the warning message on the FlexPendant :

Figure 18.

,

Confirmation of automatic mode

•

Press the Motors On pushbutton. The indicator light comes on steady.

•

Start execution by pressing the

button.

If the robot controller is connected to a PLC, the Motors On and start of execution can be initiated from the PLC; see next section.

RDNU0006 Revision F

39

4 Operating principles 4.5 Production modes

4.5

Production modes

This section starts with a description of the « production enabled » and « production disabled » modes, and the way the corresponding PLC information are managed. This is followed by a detailed description the start of production and the end of production operations. Finally, this section explains the way program codes are managed by the application.

4.5.1 "Production enabled" and "Production disabled" modes Interface with the PLC and behavior of the robot controller Via a digital input, ENPRO, the robot is informed by the PLC if it is integrated, or not, in the production stream. When set, this input informs the robot controller that it is in the "PRODUCTION ENABLED" mode. When it is reset, the robot controller has to be in the "PRODUCTION DISABLED" state. The use of this function is optional and has to be defined in accordance with the needs of your site. If the Production enabled /disabled feature is not used, the “ENPRO” input must be declared as inverted in the I/O signal parameters. In both modes, the robot controller handles the position synchronization information (commands and events) which link the robot to its environment. On the other hand, according to the current mode, the robot controller reacts in a different way to remote commands and program codes sent by the PL C.

Behavior in «production enabled» mode The local and remote commands (Motors On (DMSP), start cycle (DDCY), move to safe, stop …) are active. The movement programs generated by the external code management system are executed. The production startup program ( T_MoveToHome path) is automatically selected once the robot reaches the safe position.

Behavior in «production disabled» mode Only the "move to safe" request is active. The remote commands (Motors On (DMSP), start cycle (DDCY), Service request) are ignored. The robot terminates the ongoing movement program, but does not read the external or internal program code which may be present on dedicated inputs. This will usually leave the robot at home position, unless a "move to safe" request is issued. Once at the safe position, there is no automatic selection of the production startup program (T_MoveToHome path). When the production disabled mode is detected by the robot (ENPRO input off), the « Production Disabled » message is displayed in the « Production » screen of the application.

40

RDNU0006 Revision F


4.5.2 Active commands according to operation modes Summary of the active commands according to the different operation modes

Command

Manual mode

Automatic mode, "production disabled"

Motors On button on robot cabinet

Inactive

Active

Active

Enabling device on FlexPendant (motors on)

Active

Inactive

Inactive

Inactive

Inactive

Active

Active

Active

Active

Active

Active

Active

Inactive

Inactive

Active

the

Remote Motors On request (DMSP) Stop

command

FlexPendant ( Start

on

Remote (DDCY)

the

button)

command

FlexPendant (

Automatic mode, "production enabled"

on

the

button)

start

command

4.5.3 Move to Safe and Move to Home commands Accessing the "Move to Safe" command The "Move to Safe" command is used, as a general rule, to bring the robots to their safe positions by pressing •

the « Move to Safe » pushbutton on the front panel of the robot cabinet, when this button exists,

•

the graphic button on the operator panel when this button does not physically exist (see 5.5 Operator panel screen) :

The "Move to Safe" command can also be run through a specific program code which can be sent by the PLC, like any other program code, to request the end of production.

RDNU0006 Revision F

41


Move to Safe at program startup When starting up programs, from the beginning, after having chosen for example "PP to Main" in the production window, the application software sends first all the robots to their safe positions in order to initiate production under known conditions, using the production startup program and the T_MoveToHome path. The production startup program is automatically selected once all the controlled robots are at their safe positions.

Behavior according to initial conditions Depending on the position of the robots when running progra ms from their main routine, there are two possible situations: •

If the robot is already at its safe position, the "Move to Safe" phase is unnecessary and the robot waits there until the other robots have reached their own safe positions.

•

If the robot is not at its safe position, a message on the « Production » screen of the application informs the operator that he must press the "Safe" pushbutton to initiate a movement to the safe position:

Figure 19. Return to safe position prompt (single robot example)

The operator has to order the movement to safe position (no other command is active). Depending on the hardware configuration, he can use either the “Safe” pushbutton on the controller or the dedicated button on the “Operator Panel” screen. There are here 2 possibilities: •

42

Either the robot is at its home position; in this case, the movement to the safe position is performed by the T_MoveToSafe path routine. This movement to the safe position can be executed in automatic mode provided all the robots are either at their home or at their safe position.

RDNU0006 Revision F

4 Operating principles 4.5 Production modes •

The robot is not at its home position and not at its safe position (position is considered as unknown). The movement to the safe position will run the T_MoveDirectToSafe path and must then be performed in manual mode. If necessary, a message in the production screen will request the operator to switch to manual mode; when this is done, the application displays a direct "move to safe" dialog. This dialog must be acknowledged for each robot requiring a direct movement to its safe position.

Figure 20.

Figure 21.

Switch to manual mode to initiate direct move to s afe operation.

Direct move to safe dialog to be acknowledged for robots 1 and 2.

When the robot controller is equipped with a lighted "safe" pushbutton, the indicator light flashes until all the controlled robots have reached their safe positions. The "safe" indicator light on the virtual operator panel (see 5.5 Operator panel screen) acts in the same way.

RDNU0006 Revision F

43


Execution of production startup program When all the robots controlled by the robot controller have reached their safe positions, the production startup internal program is automatically selected and will run the T_MoveToHome path. Execution of this program requires either an operator acknowledgement, or a remote validation from the PLC (through DDCY).

Figure 22.

Prompt: OK to Move to Home ?

In a multi-robot system, all the T_MoveToHome paths are generally synchronized. At the end of this path, the application is ready to accept any kind of program code requests.

End of production The end of production is achieved by generating a Move to Safe command. This command can be generated locally using the safe pushbutton (either physical or virtual), or remotely, by the “Safe” program code sent b y the PLC. When an end of production is requested locally, it is stored. The controlled robots complete their ongoing work program and will continue by running the T_MoveToSafe path routine. As long as all the robots have not completed their current work program, a new action on the local safe button or on the dedicated screen button will cancel the end of production request.

44

RDNU0006 Revision F

4 Operating principles 4.5 Production modes When the robot controller is equipped with a lighted Safe pushbutton, the indicator light flashes until all the robots have reached their safe position, or until the end of production request has been cancelled. The safe indicator light on the virtual operator panel (see 5.5 Operator panel screen) acts in the same way.

4.5.4 Catching and priority of program codes

Program code types The program codes management consists in selecting the work to be executed by the robot(s) in accordance with the state of the machine and the state of the robot environment. This selection can be made in two ways: •

By an external system, generally a line or cell PLC which generates "an external code" information transmitted to the robot controller according to a predefined protocol.

•

By an internal function which generates the « program code » according to information related to the process or to external information related to the robot environment. This involves the following codes: •

Move to safe commands,

•

service routines requested by the process

•

« internal » codes managed by the robot program

Catching of « program » codes The program codes are caught at the end of the preceding program. Though reset of the preceding external code may have been a nticipated, the external code is only read at this moment. If several work requests occur simultaneously, the choice is made in accordance with the priority algorithm defined below. Reading of the program code can sometimes be inhibited. This is the case when the system has gone into “production disabled” mode. This is also the case when the process has been temporarily deactivated. The deactivation is used to terminate a part which may have presented a problem, but does not allow any execution of new parts. The process must therefore be reactivated in order to allow catching of new program codes.

RDNU0006 Revision F

45


Program code priority The program codes are managed in accordance with the following priority levels (indicated in decreasing order of priority): (1) (2) (3) (4)

Move to Safe command Internal codes Service requests. External codes.

Fore more information on program code management, refer to the PROMIA integration guide.

46

RDNU0006 Revision F

4 Operating principles 4.6 Principles relative to actions and checks attached to a position

4.6

Principles relative to actions and checks attached to a position

Actions attached to a point and actions in movement Unless explicitly specified, most of the actions programmable on path using PROMIA are actions intended for programming on a fine point. We strongly discourage using these actions on fly-by points as the moment and the location when and where the action is actually performed are not predictable and may therefore not be repeatable. If programming on a fly-by point proves necessary to satisfy cycle time requirements, specific actions, synchronized with the movement, should be used. These actions are built using the MoveJ and MoveL instructions and contain the parameters relative to the movement and the action to be performed, as well as some synchronization parameters.

Information about expected feedbacks and errors As a general rule, any moment the robot waits for a feedback signal on a programmed position, a message is displayed on the TPU to inform the operator and the reason why the robot is waiting is also sent to the P LC. By default, no Stop is generated; the movements of the involved robot are automatically stopped since execution of the program is blocked as long as the information is not present. When the expected information appears, the program resumes its normal sequence. The PLC can however decide to generate a Stop via the robot controller inputs/outputs. In this case, the error must be acknowledged on the PLC and program execution must be restarted from the PLC. The list of error messages is given in section 5.4 Error messages. The list of corresponding codes sent to the PLC is given in the PROMIA integration guide.

RDNU0006 Revision F

47

4 Operating principles 4.7 Continuous monitoring

4.7

Continuous monitoring

4.7.1 Dynamic monitoring Description of « dynamic monitoring » Some robot environment information items must be monitored continuously while the robot is operating. This information can involve the cell environment or the process (part detection or robot interlocking, for example). This function is performed by the « dynamic monitoring » mechanism. Whenever a monitored information item is missing, the robot is immediately stopped on its path and an error message, sometimes time-delayed, is indicated on the TPU and reported to the PLC. When the information reappears, the robot automatically resumes its movement, without any operator action, unless the PLC has forced a Stop and prompts for an error acknowledgement and a cycle start action to restart execution. This behavior may be disturbing for certain process phases and the dynamic monitoring functions can therefore be enabled or disabled by programming during execution of certain sections of a path.

Dynamic monitoring types This mechanism performs continuous monitoring (between path points): •

of the states of the part detection sensors,

•

of the states of the controlled handling sequence sensors,

•

of events.

Each of these functions can be monitored separately. When the production startup program is executed, the states of the dynamic monitoring tasks take a default value configured by the integrator. In the basic configuration supplied by ABB, the dynamic monitoring relative to part detection and the handling sequences are activated by default. The dynamic monitoring tasks related to the events are disabled. This configuration is located in the robot Def_site module: !------------------------------------------! Flags d inhibition des contrôles dynamiques !------------------------------------------CONST bool Active_ctl_cpp:=TRUE;

!part detection

CONST bool Active_ctl_evo:=FALSE;

!tooling events

CONST bool Active_ctl_ev :=FALSE;

!PLC events

CONST bool Active_ctl_seq :=TRUE;

!gripper actions

The integrator can modify this configuration of the default states. For each of the variables, TRUE means enabled by default, and FALSE means disabled by default. The state of the enabled monitoring tasks can be modified in the robot programs using the MonitorInputs instruction.

48

RDNU0006 Revision F

4 Operating principles 4.7 Continuous monitoring

4.7.2 Error management Monitoring of ongoing errors The application displays and erases messages during execution of the programs and paths. There are three types of messages: •

information « messages »

•

simple error messages,

•

error messages requiring an operator acknowledgement.

Robot behavior Display and erasure of these messages is monitored continuously: •

The information messages have no effect on operation of the robot or the cell.

•

When a simple error message or an error requiring acknowledgement appears, execution of robot movements is blocked, and remains blocked as long as the message is displayed.

•

Once the condition which has generated the error disappears : •

the simple error message is erased and execution of the robot movement resumes without any operator action.

•

the fault message with validation disappears and a screen requesting operator validation is displayed. Execution of the robot movement will only resume after the message has been validated.

About the Man-Machine Interface relative to errors, see 5.3 Production. Be attentive to a program sequence of the following type: 1/ Display of an error message other than an information message 2/ Robot movement 3/ Erase the message The robot movement will be blocked since an error message is displayed. This blocked condition will only end when the message has been erased, and therefore after the end of the movement … which will never take place … A program sequence of this type will therefore lead to complete blockage of the robo t.

RDNU0006 Revision F

49

4 Operating principles 4.8 Behaviors in cases of exception

4.8

Behaviors in cases of exception

The behavior of the application software will vary according to the complexity of the e xception. On a simple exception, such as a stop or an emergency stop, followed by a restart with no j ogging or modification, the application software does not take any special action. On the other hand, when restarting after manual jogging or modification of the program pointer, the behavior will be very different depending on how the work will be resumed: repositioning or recycling. For the meaning of these terms, refer to 2.4.2 Repositioning and recycling principles.

4.8.1 Behavior during manual jogging Inhibition of the monitoring functions During a robot stop followed by a transition to manual mode, manual jogging of the robot will never be blocked by any check made by the application (either the check is performed on position or from continuous monitoring). If sequences are manually controlled, they are monitored, but only to display possible feedback errors in the dedicated handling sequence screen.

4.8.2 Behavior in case of repositioning During repositioning While the robot regains its path, the behavior is similar to the one during manual jogging: no check will block the repositioning operation and, if any sequences are controlled, they are monitored, but only for the purpose of displaying possible errors.

At end of repositioning At the end of the regain operation, the dynamic monitoring tasks are restarted in the same condition as they were prior to the exception, and any active checks made on position are reinitiated. The sequences are monitored in accordance with the control state programmed in the paths.

4.8.3 Behavior in case of recycling Re-initialization of checks When recycling starts, the monitoring tasks are reinitialized as follows: •

The dynamic monitoring tasks return to their default state, as defined by the integrator

•

The part detection information is reinitialized to the unknown (idle) state

•

The events are reinitialized to an unknown (idle) state

•

The sequences are monitored in accordance with their current control state (programmed or manually controlled).

The recycling movement is run at low speed.

50

RDNU0006 Revision F

5 Man-Machine Interface 5.1 General description of the screen container

5 Man-Machine Interface The screens of the Promia application software are not initiated from the ABB menu, but from a tab in the task bar, known as the Screen Container, which is always visible. The container starts up automatically at controller startup.

5.1

General description of the screen container

General aspect The container gives access to the application screens through a floating panel, located by default at the top right corner o f the screen.

Figure 23.

Screen container and floating panel

Floating panel The floating panel can be moved from top to bottom and from bottom to top to allow reading the screens which it covers with no interference. It comprises three elements: •

The right hand part acts as a « handle » to move the floating panel :

Figure 24.

RDNU0006 Revision F

Floating panel control handle

51

5 Man-Machine Interface 5.1 General description of the screen container •

The top button, to the left, displays a blue command bar used to select the screen of the application software to be displayed.

Figure 25. •

Application software screen selection button

The lower button, to the le ft, is used to toggle between the curr ent screen and the « Operator Panel » screen ; it is thus possible, using this button, to call up, at any time, the Operator Panel screen which contains a virtual « button set » used to request "Move to Safe position" or for service requests:

Figure 26.

Button used to toggle between current screen and Operator Panel screen.

Selecting a screen When the screen selection button is pr essed, a blue command bar appears ( over the current command, if one is displayed):

Figure 27.

Application software screen selection command bar

The selection button aspect changes; when the button is pressed again, the blue command bar disappears.

52

RDNU0006 Revision F

5 Man-Machine Interface 5.2 Choice of "Common Features" screens

5.2

Choice of "Common Features" screens The elements displayed in this blue command bar depend on the processes managed by the application software, especially in a multi-robot environment, where several processes are implemented. The command bar always contains however a first item used to select the screens of the common base application, and is referred to as the “Common Features”. This menu has three sub-menus which gives access respectively to the production screen, the information screens common to all the processes, and to a simplified backup screen:

Figure 28.

Selection of "Common Features" screens

These screens are described in the following sub-sections of this section.

RDNU0006 Revision F

53

5 Man-Machine Interface 5.3 Production screen

5.3

Production screen

The two areas of the production screen This screen contains a command bar and a display with two separate areas: •

the upper half, called the Program area, displays the state of the current programs and paths,

•

the lower half, called the Message area, displays the application software messages.

Program area

Messages area

Command bar

Figure 29.

The two areas of the Production screen

The command bar is used to control the display in the Messages area; it is described in the corresponding section.

5.3.1 Program area details The 12 fields of the program area Each line of the program area has two fields. The first line indicates the version of the application software installed and the processes controlled by the various robots of the cabinet. In the example below, robot 1 is a handling robot and r obots 2 and 3 are arc welding robots:

The second line displays the external code present on the inputs of the robot controller, "xCode" and the program codes currently accepted by the application software

RDNU0006 Revision F

55

5 Man-Machine Interface 5.3 Production screen In the example above, no external code is present and the codes executed by the application are a normal "Move to Safe", performed from home position, for robot 1, and a direct move to Safe for robots 2 and 3. Lines 3 to 6 contain, for each of the robots (4 maximum), the names of the current programs and paths, as defined by the integrator; see instructions DisplayProgram and DisplayPath in section 7.2 Giving information about active path and active robot program.

5.3.2 Message area details The Message Area has two operating modes: a "snapshot" mode and a "history" mode. The two modes are controlled from the command bar of the production screen.

Figure 30.

Example of snapshot message area

Description of command bar The command bar contains 3 icons used to control the display in the Message area: •

is used to display, in the Message Area, a snapshot of the messages, whatever their type is. This is the default mode. is used to display a history of error messages

•

is used in both modes to force refreshing of the messages,.

•

The active display mode is indicated in the corresponding icon as a tick symbol:

56

•

The icon indicates that the current display mode is the « snapshot » mode,

•

the

icon indicates that the current mode is the « history » mode.

RDNU0006 Revision F

5 Man-Machine Interface 5.3 Production screen

Figure 31.

Example of history area messages

Content of Message area The Message area contains an instant view or a history of the application software messages. The messages are time-stamped and the order of appearance of the messages is preserved. The

button can be used to reverse the order of the messages.

Format of messages All the messages displayed have a common format: •

an icon specifying the type of message

•

for an information message

•

for a simple error message

•

for an error message requiring validation

•

The time at which the message has appeared

•

The robot (movement task) at the source of the message

•

The text of the message itself; these texts, their meaning and the actions to be performed are detailed in the next section.

The movement tasks have a name which begins by « T_ ». This must not be confused with the path names which also traditionally begin by « T_ »

RDNU0006 Revision F

57

5 Man-Machine Interface 5.3 Production screen Validation of messages A message validation request is only displayed when the cause of the error has disappeared. A dialog comes up in the foreground of the screen container:

The movements of the robot(s) only resume after this dialog has been acknowledged by the operator.

58

RDNU0006 Revision F

5 Man-Machine Interface 5.4 Error messages

5.4

Error messages

The error messages are presented here according to their source (common base or process), then according to their seriousness.

5.4.1 Common base application messages List of errors requiring a validation Type of message

Wording

Description Source/Cause: Air detection signal (CPAIR) went low.

TCV1: AIR CHECK ERROR

TCV2: PROGRAM DOES NOT EXIST

Check/Correction: Check if the air is effectively cut off; if so, check the compressed air circuit; if not, check the sensor and wiring. Source/Cause: Program code received does not match any valid program number. Check/Correction: Check external received. Check your program.

code

List of simple errors Type of message

Wording

Description Source/Cause: Robot information went low.

TCS1: WAITING FOR MOVE ENABLE

TCS2: NO COMMUNICATION WITH PLC

TCS3: COOLING DEVICE ERROR

movement

enable

Check/Correction: Check input signal AEVRB. If input is used, check for possible causes of robot movement inhibition on the PLC. Source/Cause: PLC network failure Check/Correction : Check network link to the PLC Source/Cause : « air information went low.

cooler

operating »

Check/Correction : Check input di_ClimOk

RDNU0006 Revision F

59


Type of message

Text

SQS1: GRIPPER FEEDBACK LOST : n

Description Source/Cause: Dynamic check of sequences is active and at least one sensor for the specified sequence is not in its state expected Check/Correction: Check state of sensors and actuators for the specified sequence Source/Cause: Use of an undefined sequence (not defined in MAN_CONF module)

SQS2: UNDEFINED GRIPPER ACTION: n

CPS1: PART DETECTION LOST: n

Check/Correction: Use another sequence or configure the corresponding actions and checks in MAN_CONF module Source/Cause: Dynamic monitoring of part detection sensors is active and the specified part detector is not in its expected state. Check/Correction: Check state of part detection sensors in corresponding Promia screen Source/Cause: Dynamic check of events is active and specified monitored event has disappeared.

EVS1: PLC EVENT LOST : n

Check/Correction: Check state of events in Promia screen. Check link with PLC (if parallel link). On the PLC, check conditions which may cause the loss of this event. Source/Cause : Robot movement stopped since specified event is not present at the end of a MovePlcEvent instruction

EVS2: NO PLC EVENT WHILE MOVING : n

Check/Correction: Check state of events in corresponding Promia screen . Check link with PLC (if parallel link). On the PLC, check conditions which may have caused this event not to be sent.

60

RDNU0006 Revision F

5 Man-Machine Interface 5.4 Error messages List of information messages Type of message

Text

Description Source/Cause: All robot programs have been stopped

TCM1: ALL ROBOT PROGRAMS STOPPED!

Check/Correction: A Stop command, local or remote, has been generated. Also check, in ABB production window, if a Stop instruction has been programmed.

TCM2: PLEASE PRESS SAFE PUSH BUTTON

Source/Cause: After PP -> Main, robot is not at its safe position. Check/Correction: Order the return to the safe position by dedicated pushbutton (physical or virtual) Source/Cause: Debug mode has been selected through "DEVERM" input signal.

TCM4: MODE

DEBUG

Check/Correction: None. (information message) Source/Cause: Odd parity check (CPCO signal) is not consistent with the external code group signal (odd number of bits being set).

TCM5: ERROR

PARITY

Check/Correction: Check interface with PLC. Example of parity errors: code =1 and CPC0=1 + CVC1=1 code =3 and CPC0=0 + CVC1=1 Source/Cause: If external code is used: code reset has been correctly performed, but the external code group signal is 0.

TCM6: WAITING FOR CYCLE CODE

Check/Correction: None. (simple information) Possibly check interface with PLC.

RDNU0006 Revision F

61


Type of message

Text

TCM7: WAITING FOR CYCLE CODE RESET

Description Source/Cause : Wait for cycle code reset, that is transition to 0 of code signal, code validation signal, odd parity signal, and transition to 1 of CVC_0 signal (pulsed) Check/Correction: Check interface with PLC. Source/Cause: Robot motors are off.

TCM8: PLEASE SWITCH MOTORS ON

Check/Correction: None. (information message)

TCM9: PRODUCTION DISABLED

Source/Cause: ENPRO signal is 0 (if function is used in application). Check/Correction: None. (information message) Source/Cause: repositioning.

TCM12: REGAIN REQUESTED PRESS START

Transient

message

during

Check/Correction: None. (simple information ; restart request is also generated by basic software)

TCM14: WAITING FOR EVENTS TO SWITCH FROM

Source/Cause: Message to be used at start of a part program when the executed path has to be selected according to two different events and none of them is received. Check/Correction: Check interface with PLC. Check conditions preventing PLC from sending one of the two events. Source/Cause: Robot currently moving to its safe position.

TCM15 : MOVING TO SAFE POSITION


TCM16: MOVING TO HOME POSITION

Source/Cause: Robot currently moving from its safe position to its home position. Check/Correction: None. (information message)

62

RDNU0006 Revision F

5 Man-Machine Interface 5.4 Error messages Type of message

Text

TCM18: RELEASE CYCLE START PB

Description Source/Cause: Remote cycle start information (DDCY) still present when program resumes execution. Check/Correction: None. (information message) Source/Cause: Speed is limited since program is recycling.

TCM20: RECYCLING SPEED<=250MM/S:


TCM21: MOVE TO SAFE ONLY FROM HOME

TCM22: SERVICE ROUTINE ONLY FROM HOME

TCM23: SWITCH TO MANUAL MODE AND START

Source/Cause: Move to safe request (during production) is rejected since all the robots are not at their home position. Check/Correction: Execute a program which ends at home position and repeat the Move to safe request. Source/Cause: Service request rejected since all the robots are not at their home position. Check/Correction: Execute a program which ends at home position and repeat the service request. Source/Cause: Robot is not at its safe position, and not at its home position. Moving to the safe position will be a straight movement that can only be executed in manual mode. Check/Correction: Switch to manual mode, press the enabling device and reinitiate execution by

RDNU0006 Revision F

button.

63


Type of message

Text

TCM24: RESTART IMPOSSIBLE => STOP/START

Description Source/Cause: Robot is too far from the location where its movement has been stopped (by a dynamic check)

Check/Correction: Stop execution by

and

restart by

SQM1: WAITING FOR GRIPPER ACTION : n

Source/Cause: Robot is waiting for gripper sensor signals to be in accordance with the programmed gripper command (check on position). Check/Correction : actuators

SQM2: (INFO) GRIPPER FEEDBACK LOST : n

CPM1: WAITING FOR PART DETECTION: n

Check

sensors

and

Source/Cause: Robot has lost a gripper sensor info during a direct move to safe position, or after a start from a routine (pp->routine). Check/Correction: None; but note that if this problem persists when reaching the safe position, this will become a blocking condition. Source/Cause: Specified part detection signal is different from what is expected (check on position). Check/Correction: Check part detection sensors in the corresponding Promia screen. Source/Cause: Specified expected event is not present (check on position).

EVM1: WAITING FOR PLC EVENT : n

Check/Correction: Check corresponding Promia screen.

events

in

Check link with PLC (if parallel link). On the PLC, check conditions which may have caused this event not to be sent.

64

RDNU0006 Revision F

5 Man-Machine Interface 5.5 Operator panel screen

5.5

Operator panel screen

This screen replaces a set of physical buttons and lamps; it includes, by default, a lighted “safe” pushbutton and 4“service” pushbuttons. These 4 buttons are used to request the corresponding service routines. The operator panel screen can be customized in accordance with the installed processes.

Access This screen is accessed using the key at the bottom left of the floating panel of the screen container:

Default content of screen

RDNU0006 Revision F

65

5 Man-Machine Interface 5.6 Promia information screens

5.6

Promia information screens

This set of screens supplies information related to the application functions that are common to all the processes.

Access to common information These screens are accessed from the blue command bar which is called up by pressing the button at the top left of the floating panel of the screen container, and then through the Common Features Menu:

5.6.1 General description of the information screen 5 parts of screen The Promia information screen is made of 5 parts:

66

•

tabs used to choose the mechanical unit for which the information will be displayed

•

a title showing the title of the current screen

•

a line displaying additional information or the instructions to perform an operation,

•

the page displaying the information,

•

the menu area used to select the type of information to be displayed.

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens tab to select mechanical unit Screen title

Additionnal information or instruction

Page, information displayed

Menu, screen selection

Figure 32.

Structure of Promia information screens

Information displayed 5 different types of information can be displayed. Each type of information is displayed in a screen. Screens are selected from the « Menu » area. The first two screens are related to the handling functions and respectively display the part detection and sequence states. The following two screens are related to dialogue with the PLC or with the tool control cabinet and respectively display the PLC or tool event and command states. The 5th screen displays the execution context and, especially, the state of the active dynamic monitoring functions.

Persistence of type of information displayed Accessing from the “Common Features” screen selection menu always calls up the first screen (part detection). The change of screen is performed from the « Menu » area. The change of mechanical unit using the « Tabs » area preserves the current type of information and therefore the current screen; only the contents of the page is changed to reflect the information related to the selected mechanical unit.

RDNU0006 Revision F

67

5 Man-Machine Interface 5.6 Promia information screens General remark concerning names displayed in these pages The names displayed in these pages are read from the DEF_SITn modules as entered by the integrator. These modules are supplied by ABB with default names which are not necessarily relevant for a given site. The relevance of the display names is therefore strictly dependent on the customization defined by the integrator.

5.6.2 Part detection screen Content of pages The part detection screen includes only one page displaying the expected state of the 8 part detection sensors available for a mechanical unit. Each part detection sensor is represented by its name and a pictogram indicating the compliance of its actual state with respect to its expected state. If no name has been defined for a part detection sensor, the corresponding fields remain empty. In the examples below, only part detection sensor 1 name has been filled in. By default, following re-initialization of the corresponding robot program, or after execution of a CheckPart instruction without any argument, the part detection sensors are in an undefined state: their expected state is unknown and their actual state is not tested. Under these conditions, no compliance information is displayed:

Figure 33.

68

Part detection screen : undefined state

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens When a CheckPart instruction is executed, the expected state of the part detection sensors involved by this instruction is known. A pictogram is displayed to the left of their names to indicate compliance (green colour) or non-compliance (red colour) of the actual signal compared with its expected state. Example 1: Part detector 1 expected to be 1 and actual state is correct

Figure 34.

Part detection screen : correct state

Example 2: Part detector 1 expected to be and actual state is incorrect

Figure 35.

RDNU0006 Revision F

Part detection screen : wrong state

69


5.6.3 Sequence screen Content of pages The sequence screen includes two pages: •

a page displaying the general state of the sequences and used to select a sequence,

Figure 36. •

A page displaying the detailed state of the selected sequence and used to control it.

Figure 37.

70

Page showing general state of sequences

Page showing detailed state of a sequence

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens General state of sequences

Each sequence is represented by its name, its programmed state (state requested by program during execution), its actual state (state currently controlled) and by a pictogram indicating compliance of its actual state with respect to its expected state. By default, following re-initialization of the corresponding robot program (PStart), the sequences are in an undefined state: their controlled state is unknown and the sensors are not monitored. Under these conditions, no compliance information is displayed:

Figure 38.

RDNU0006 Revision F

General state of Sequences : undefined state

71

5 Man-Machine Interface 5.6 Promia information screens Once the movement program is reinitialized (pp->Main, Exec), the control state of the sequences which have been used in the program is displayed and monitored by the application software. The pictograms indicating the state of the sequences are refreshed. The « Programmed State » an d « Actual state » fields of t he defined sequences, but which are not used on the path, remain empty. Example1: Sequences 1 activated and monitored OK:

Figure 39.

Sequence Screen : correct state

Example2: Sequence 2 activated and monitored NOK:

Figure 40.

72

Sequence Screen : feedback error

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens Details and control of sequences To select a sequence to be zoomed-in or controlled, the operator simply « taps » two times on the corresponding line. The first tap shows the selected line highlighted:

The second tap on the line opens the detail screen showing the state of the sensors related to the sequence and identifies, if relevant, the faulty sensor.

Figure 41.

RDNU0006 Revision F

Detail screen of sequences, manual control not enabled

73

5 Man-Machine Interface 5.6 Promia information screens For each sensor, the screen displays its name, its expected status and, in real time, its physical state. It also displays the control state of the actuators controlled by the selected sequence. The “Sequence details” screen includes a specific command bar used for manual control of the sequence: the first two selections are used respectively to activate and deactivate the sequence. Their wordings correspond to those entered in by the integrator for this sequence. These controls are greyed in (see figure above) when manual control of the sequence is not enabled (individual inhibition of this sequence, program execution in progress, automatic operating mode, motors off or enabling device released). Note: In this screen, it is possible to manually control all the sequences defined, whether they are declared, or not, as usable in the path. You may, for instance, control a sequence trhat is managed by the PLC. When manual control of the sequence is possible (program stopped, manual mode, motors powered up, enabling device pressed, no specific inhibition for this sequence), the control keys become active:

Figure 42.

Sequence detail screen, manual control enabled

The current control state is indicated at the top right of the screen. The state of the sensors is refreshed in real time, even if the enabling device is released.

CAUTION: Controlling a sequence can have dangerous consequences on the environment: dropping the part, initiation of the movement of a large actuator (dressing flaps, for example). Before controlling the sequence, make sure the operation is safe for personnel and equipment.

74

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens Select « Close » to return to the general sequence screen. Any possible inconsistency between the programmed state and the state actually controlled is displayed as a warning:

RDNU0006 Revision F

75


5.6.4

PLC and Tool Event Screens

Content of pages The events screen includes two pages respectively displaying the state of the 16 PLC events and the 16 tool events related to the selected mechanical unit. The choice between « PLC events » and « tool events » is made in the « Events » sub-menu:

The two pages are similar. Only the screen title is different. Each event is represented by its number and its name:

Figure 43.

76

Events screen : Correct state

RDNU0006 Revision F

5 Man-Machine Interface 5.6 Promia information screens Only the events which are expected and not present, either in a path action, or in the dynamic monitoring, are indicated by an error pictogram:

Figure 44.

Events screen : error state

In the example above, event 1 is expected but missing.

RDNU0006 Revision F

77


5.6.5 PLC and Tool Command Screens Content of pages The Commands screen includes two pages respectively displaying the states of the 16 PLC commands and the 16 tool commands related to the selected mechanical unit. The choice between « PLC commands » and « tool commands » is made in the « Commands » sub-menu.

The two pages are similar. Only the screen title is different. Each command is represented by its number, its name and a LED when the com mand is set:

Figure 45.

78

PLC Command Screen

RDNU0006 Revision F

5 Man-Machine Interface 5.7 Backup screen

5.7

Backup screen

This screen is used to perform a simplified backup of the complete application. The backup is identical to the one performed in the standard ABB screen, but the backup paths are predefined by the integrator for 3 types of media: flashdisk, USB port and network. Caution: EACH NEW BACKUP ON A MEDIA OVERRIDES THE PREVIOUS BACKUP MADE ON THIS MEDIA. Note: These screens do not allow any access path modification. If the operator wishes to perform a backup out of the predefined paths, he must use the standard backup procedure, accessible from the ABB menu.

Access This screen is accessed from the blue command bar, which is displayed by pressing the button at the top left of the floating panel of the screen container , and then through the Common Features Menu:

RDNU0006 Revision F

79

5 Man-Machine Interface 5.7 Backup screen

5.7.1 General description of screen 4 parts of the screen This screen includes a menu bar used to select the media on which the backup will be performed, a reminder of the action to be performed, a reminder of the path of the directory on which the backup will be performed, and an action button to initiate the backup operation.

Figure 46.

« Simplified Backup » screen.

The 3 pictograms on the command bar are used respectively to select the FlashDisk, the USB port or a remote computer. If not customized by the integrator, the application software creates backups in the default directories for the FlashDisk (directory: REST_ABB) and the USB key (BACKUP_, followed by current date, for example Backup_2007_04_06). If the path for backup on a remote computer is not defined, the button in the corresponding screen is greyed in and disabled.

(

80

).

RDNU0006 Revision F

5 Man-Machine Interface 5.7 Backup screen Summary:

Pictogram

RDNU0006 Revision F

Media

Default directory

FlashDisk

/hd0a/ systemName /REST_ABB

USB

/bd0/Backup_CurrentDate

Network

None

Corresponding button

81

6 Editing paths 6.1 General information

6 Editing paths 6.1

General information The paths are edited using the " Program Editor" window. Each path is a routine the name of which begins, as a standard practice, by the characters ‘T_’. The standard program editing commands are available. The specific instructions of the application software can be chosen directly for insertion in the paths.

General procedure •

In the ABB menu, select the " Program Editor" window.

•

In a multi-robot environment, select the foreground task to be edited.

•

Select the module, then the routine to be edited.

•

Move to the line to be edited.

It is also possible to edit the program line currently executed from the Production window. In this case, select ‘ Debug’, then ‘Edit Program’:

Figure 47.

RDNU0006 Revision F

Debug Menu of the Production Window

83

6 Editing paths 6.2 Insertion of a specific instruction of the application

6.2

Insertion of a specific instruction of the application

Access to specific instructions The specific instructions of the application are located in the Most Common list 1 and 2 of the instruction panel that appears when using the ‘ Add Instruction’ menu. The « PROMIA » list contains the actions which are common to all the processes. The « PROCESS » list gives access to the actions specific to the pro cess.

Note: When opening the program editor, a button is displayed in the task bar with the name of the movement task and the name of the module currently being edited (here, T_ROB1, PRG_MVT).

The movement tasks have a name which begins by « T_ ». Do not confuse this with the paths names which also traditionally begin by « T_ »

84

RDNU0006 Revision F

6 Editing paths 6.3 Inserting a « Common base » instruction

6.3

Inserting a « Common base » instruction The actions common to all the processes, also called « common base » actions are displayed on 2 pages:

RDNU0006 Revision F

85

7 Actions on paths common to all processes 7.1 Programming anti-loop functions

7 Actions on paths common to all processes 7.1

Programming anti-loop functions

Principles of anti-loop management This function is used to prevent looped execution of a work path routine, in automatic mode, after having set the execution cursor on the first line of this routine (Menu: Debug Move PP to Routine of the Program Editor window, see Figure 3 Debug menu). This is achieved using two instructions, " EnablePath" and “PreventLoop”. During execution of the PreventLoop instruction, operation is as follows: •

If an EnablePath instruction has been executed previously, the PreventLoop instruction has no effect.

•

Otherwise

•

If the routine is executed in automatic mode, a message "LOOP ON PATH FORBIDDEN IN AUTO MODE!" is displayed. After the message has been acknowledged, the program is restarted from the « main » routine.

•

If the sequence is executed in manual mode, a message: "Beware: Starting Trajectory" is displayed and the application software prompts the operator to validate or abort execution. If the message is validated, the path is executed. If the operator chooses to abort, the program is restarted from the « main » routine.

These dialogs are displayed in the operator window:

Figure 48.

RDNU0006 Revision F

Acknowledgement of anti-loop message

87

7 Actions on paths common to all processes 7.1 Programming anti-loop functions Example of path call: PROC Programme( num prog) TEST prog CASE 1: DisplayProgram prog,"Prog 1"; ! pulse code acknowledge signal PulseDO\PLength:=1,ACQ_CODE1; EnablePath; Traj1;

….

Example of path: PROC Traj1() DisplayPath "Traj 1"; PreventLoop; MoveL *, … …. MoveJ *,… ENDPROC

Figure 49.

Calling a path

Programming an « EnablePath » instruction

Syntax: EnablePath

No parameter

Programming a « PreventLoop” instruction

Syntax: PreventLoop

No parameter

88

RDNU0006 Revision F

7 Actions on paths common to all processes 7.2 Giving information about active path and active robot program

7.2

Giving information about active path and active robot program

How to display current program and path In order to display the names of the current robot programs and paths, this information must be given at the right moment. The current robot program name is typically given using the DisplayProgram instruction in the corresponding “CASE” to the Programme routine. The current path name is typically given through a DisplayPath instruction at the beginning of the routine dedicated to this path. Example: see Figure 49: Calling a path.

Programming a "DisplayPath" instruction Syntax: DisplayPath

pathName

Mandatory parameter Name : pathName

Meaning : Name of path currently being executed

Programming a "DisplayProgram " instruction Syntax: DisplayProgram

programNumber

programName

Mandatory parameters Name :

RDNU0006 Revision F

Meaning :

programNumber

Number of the robot program currently being executed

programName

Name of the robot program currently being executed

89

7 Actions on paths common to all processes 7.3 Programming PLC commands

7.3

Programming PLC commands

Command management principles PLC commands are information signals sent by the robot to its environment (via a PLC). This logic information can be programmed on positions when creating or modifying paths. The PLC commands are only sent during program execution. They are generated when a SendPlc action is programmed on a fine point or a MoveSendPlc instruction is programmed on a fly-by point: •

The commands are reset during path teaching, i n case of recycling, when a movement program is aborted or after having moved the robot to its safe position.

•

The commands are programmed by blocks of 16. The commands not programmed in one instruction are reset. You must the re-program on an instruction all the commands previously set that you want to remain set.

7.3.1 SendPlc instruction Purpose and operation This path instruction entitles you to send up to 16 PLC commands on the same position. Generation of the commands may be delayed by using an optional argument \ Delay . This parameter defines the value of the delay in seconds. If this argument is used, generation of all the programmed commands is delayed. Example: SendPlc \O1;

Programming a SendPlc instruction

Syntax: SendPlc

[\Delay][\O1][\O2][\O3][\O4][\O5][\O6][\O7][\O8] [\O9][\O10][\O11][\O12][\O13][\O14][\O15][\O16]

Optional parameters: Name :

90

Meaning :

\Delay

Command generation delay, in seconds

\O1 ... \O16

Specifies that the corresponding command (1 to 16) must be set.

RDNU0006 Revision F

7 Actions on paths common to all processes 7.3 Programming PLC commands

7.3.2 MoveSendPlc instruction Purpose and generation Generation of commands can also be programmed using the MoveSendPlc movement instruction. This instruction is used to generate commands in the fly-by area, but cannot be used to delay generation of the commands. Example: MoveSendPlc \L,*\O1,v1000,z20,tool0,wobj0;

Programming a MoveSendPlc instruction

Syntax: MoveSendPlc

[\L] ToPoint [\Id] [\O1][\O2][\O3][\O4][\O5][\O6] [\O7][\O8][\O9][\O10][\O11][\O12][\O13][\O14] [\O15][\O16] speed zone tool wobj

Mandatory parameters : Name :

Meaning :

ToPoint

Position, target of the movement, where the programmed commands will be sent

speed

Programmed speed for the movement

zone

Definition of fly-by zone

tool

Reference of tool used for movement

wobj

Reference of object used for movement

Optional parameters : Name : \L

Meaning : Defines the type of the movement as linear. (by default, the movement is a joint movement)

\Id

Synchronization identifier for use in synchronous movement

\O1 ... \O16


The position is stored when creating the instruction and can subsequently be modified using the “Modify Position” command of the program editing window.

RDNU0006 Revision F

91

7 Actions on paths common to all processes 7.4 Programming events

7.4

Programming events

Event management principles Events are information expected by the robot from its environment. This logic information can be programmed on positions when creating or modifying paths. The events are only expected during program execution. They are expected as soon as a PlcEvent action is programmed on a fine point, or a MovePlcEvent instruction is programmed on a fly-by point: •

The events are not expected during path teaching.

•

Cancelling a movement program aborts the wait for programmed events.

•

The events can be monitored dynamically. In this case, the last expected programmed state is the one which is dynamically monitored.

•

By default, the dynamic monitoring on the events is inactive.

•

Only the events programmed in one instruction are expected. To check that previously received events are still present, you must program them again in further instructions.

7.4.1 PlcEvent instruction Purpose and operation This path instruction entitles you to wait for up to 16 PLC events on the same position. Example: PlcEvent \E1;

Programming a PlcEvent instruction Syntax: PlcEvent

[\E1][\E2][\E3][\E4][\E5][\E6][\E7][\E8]

[\E9][\E10][\E11][\E12][\E13][\E14][\E15][\E16]

Optional parameters : Name : \E1 ... \E16

92

Meaning : Specifies that the corresponding event (1 to 16) is expected to be set.

RDNU0006 Revision F

7 Actions on paths common to all processes 7.4 Programming events

7.4.2 MovePlcEvent instruction Purpose and operation The test of events can also be programmed in the fly-by point area using the MovePlcEvent movement instruction. If the tested events are present at the end of the movement, the robot continues its path normally; otherwise, it stops on its path while waiting for the programmed events to be set. Example: MovePlcEvent

\L,*\E1,v1000,z20,tool0,wobj0;

Programming a MovePlcEvent instruction

Syntax : MovePlcEvent

[\L] ToPoint [\E1][\E2][\E3][\E4][\E5][\E6][\E7] [\E8][\E9][\E10][\E11][\E12][\E13][\E14][\E15] [\E16] speed zone tool wobj

Mandatory parameters : Name :

Meaning :

ToPoint

Position, target of the movement, and where events test will be performed

speed


zone


tool


wobj




\E1 ... \E16

Specifies that the corresponding event (1 to 16) is expected to be set.


RDNU0006 Revision F

93

7 Actions on paths common to all processes 7.5 Programming tool commands

7.5

Programming tool commands

Tool command management principles The tool commands are information signals sent by the robot to a tooling control cabinet. This logic information can be programmed on positions when creating or modifying paths. Note: Tool commands can also be used as an extension of the PLC commands. The tool commands are only set during program execution. These commands are generated when a SendTooling action is programmed on a fine point or when a MoveSendTooling instruction is programmed on a fly-by point: •

The tool commands are reset during path teaching, in case of recycling, when a movement program is aborted or after having moved the robot to its safe position.

•

The tool commands are programmed by blocks of 16. The tool commands not programmed in one instruction are reset. You must the re-program on an instruction all the commands previously set that you want to remain set.

7.5.1 SendTooling instruction Purpose and operation This path instruction entitles you to send up to 16 tool commands on the same position. Generation of the commands can be delayed using the optional \ Delay argument. This parameter defines the value of the delay in seconds. If this argument is used, generation of all the programmed commands is delayed. Example: SendTooling\O1;

Programming a SendTooling instruction Syntax: SendTooling

[\O1][\O2][\O3][\O4][\O5][\O6][\O7][\O8] [\O9][\O10][\O11][\O12][\O13][\O14][\O15][\O16]

Optional parameters: Name :

94

Meaning :

\Delay

Command generation delay in seconds

\O1 ... \O16


RDNU0006 Revision F

7 Actions on paths common to all processes 7.5 Programming tool commands

7.5.2 MoveSendTooling instruction Purpose and operation Generation of the tool commands can also be programmed using the MoveSendTooling instruction. This instruction is used to generate tool commands in the fly-by point zone, but cannot be used to delay generation of the commands. Example: MoveSendTooling \L,*\O1,v1000,z20,tool0,wobj0;

Programming a MoveSendTooling instruction Syntax: MoveSendTooling

[\L][\Id] ToPoint [\O1][\O2][\O3][\O4][\O5][\O6] [\O7][\O8][\O9][\O10][\O11][\O12][\O13][\O14] [\O15][\O16] speed zone tool wobj

Mandatory parameters: Name :

Meaning :

ToPoint

Position, target of the movement, where the programmed commands will be sent

speed


zone


tool


wobj




\Id

Synchronization identifier for use in synchronous movement

\O1 ... \O16



RDNU0006 Revision F

95

7 Actions on paths common to all processes 7.6 Programming tool events

7.6

Programming tool events

Tool event management principles The tool events are information signals expected by the robot and generated by a tool control cabinet. This logic information can be programmed on positions when creating or modifying paths. Note: The tool events can also be used as an extension to the PLC events. The tool events are only expected during program execution. These events are expected as soon as a ToolingEvent action is programmed on a fine point, or when a MoveToolingEvent instruction is programmed on a fly-by point : •

The tool events are not expected during path teaching.

•

Cancelling a movement program aborts the wait for programmed events.

•

The events can be monitored dynamically. In this case, the last expected programmed state is the one which is dynamically monitored.

•

By default, the dynamic monitoring on the events is inactive.

•

Only the events programmed in one instruction are expected. To check that previously received events are still present, you must program them again in further instructions.

7.6.1 ToolingEvent instruction Purpose and operation This path instruction entitles you to wait for up to 16 tool events on the same position. Example: ToolingEvent\E1;

Programming a ToolingEvent instruction Syntax: ToolingEvent [\E1][\E2][\E3][\E4][\E5][\E6][\E7][\E8]

[\E9][\E10][\E11][\E12][\E13][\E14][\E15][\E16]

Optional parameters :

96

Name :

Meaning :

\E1 ... \E16


RDNU0006 Revision F

7 Actions on paths common to all processes 7.6 Programming tool events

7.6.2 MoveToolingEvent instruction Purpose and operation The tool events test can also be programmed in the fly-by point zone using the MoveToolingEvent movement instruction. If the tested events are present at the end of the movement, the robot continues its path normally; otherwise, it stops on its path while waiting for the programmed events to be set. Example: MoveToolingEvent\L,*\E1,v1000,z20,tool0,wobj0;

Programming a MoveToolingEvent instruction

Syntax: MoveToolingEvent

[\L] ToPoint [\E1][\E2][\E3][\E4][\E5][\E6][\E7] [\E8][\E9][\E10][\E11][\E12][\E13][\E14][\E15] [\E16] speed zone tool wobj

Mandatory parameters: Name :

Meaning :

ToPoint

Position, target of the movement, and where events test will be performed

speed


zone


tool


wobj




\E1 ... \E16



RDNU0006 Revision F

97

7 Actions on paths common to all processes 7.7 Programming handling sequences

7.7

Programming handling sequences

Handling sequence management principles The handling sequences have two states: « activated » and « deactivated ». They are controlled (actuator signals are set or reset) and monitored (feedback signals are checked) according to their desired state. The signals used to control and monitor the sequences are defined by the integrator. By default, sequences are controlled and monitored in the same instruction, GripperAction. However, a sequence can be checked without controlling it, or controlled without checking it. Control of the sequence without checking can be programmed indifferently on fly-by points or on fine points. The other modes require the use of fine points.

98

•

When the feedback signals associated to sequences are checked on a point, the robot does not leave the point as long as the check is not satisfying. If the feedback signals for sequence "n" are not in the expected state, a message « WAITING FOR GRIPPER ACTION: n » is displayed in the « Production » screen of the application, after a delay intended to mask the technical time for movement of the actuators. When the action is completed, the message is cleared and the robot resumes its sequence without any operator action.

•

The sequences are then dynamically monitored during movements between points. This dynamic monitoring can be deactivated. If dynamic monitoring of the sequences is active, the robot stops in the event of a faulty check and the message « GRIPPER FEEDBACK LOST: n » is displayed in the « Production » screen of the application. When the feedback signals return to their expected state, the message is cleared and the robot resumes its sequence without any operator action.

•

At the end of a regain to path (repositioning) operation, if dynamic monitoring of the sequences is active, the program cannot be restarted in its current path as long as all the sequences are not correct with respect to their programmed state.

•

If recycling is performed, with dynamic monitoring of the sequences active, the sequences are monitored with respect to the state currently controlled.

RDNU0006 Revision F

7 Actions on paths common to all processes 7.7 Programming handling sequences

7.7.1

GripperAction instruction

Purpose and operation This instruction is used to control and check, on the same position, up to 16 sequences. The instruction includes optional arguments used respectively to initiate control, in the « activated » state or in the « deactivated» state, of sequences 1 to 16: •

\ S1_A or \ S1_D

•

…

•

\ S16_A or \ S16_D

The optional argument \CheckOnly is used to check the sequences without controlling them. The optional argument \NoCheck is used to control the sequences without checking them. In this case, the GripperAction instruction can be used on a fly-by point. It is necessary to repeat the control states of the previously controlled sequences in order to continue to control them if so desired. Without an optional argument, this instruction can be used to reinitialize the state of the programmed sequences (to be used, for example, when dropping the tool if a tool changer is used). Example: GripperAction\S1_A;

Programming a GripperAction instruction Syntax: GripperAction

[\S1_A][\S1_D][\S2_A][\S2_D][\S3_A][\S3_D] [\S4_A][\S4_D][\S5_A][\S5_D][\S6_A][\S6_D] [\S7_A][\S7_D][\S8_A][\S8_D][\S9_A][\S9_D] [\S10_A][\S10_D][\S11_A][\S1_D][\S12_A][\S12_D] [\S13_A][\S13_D][\S14_A][\S14_D][\S15_A][\S15_D] [\S16_A][\S16_D][\Nocheck][\CheckOnly]

Optional parameters : Name :

RDNU0006 Revision F

Meaning :

\S1_A à \S16_A

Controls sequence 1 to 16 to its « activated » state

\S1_D à \S16_D

Controls sequence 1 to 16 to its « deactivated » state

\Nocheck

Indicates that the sequences specified in the instruction are controlled but not checked.

\CheckOnly

Indicates that the sequences specified in the instruction are checked but not controlled.

99

7 Actions on paths common to all processes 7.8 Programming part detection functions

7.8

Programming part detection functions

Part detection management principle The application software manages up to 8 part detection functions using logic inputs. The choice of name and assignment of the inputs managing the part detection functions is left to the integrator’s discretion. These signals are monitored with respect to their expected state: idle, set or reset. The expected states of all the part detection functions are placed in the idle state on program start up from its ‘ Main’ routine. They are then positioned in accordance with the path programs. This programming is only performed on a fine point; it is however possible, at any time, to reposition the expected states of all the part detection functions to the idle state and thus inhibit monitoring of these states. •

When monitoring the part detection functions on a point, if a signal does not correspond to the expected state, a message " WAITING FOR PART DETECTION: n ", is displayed on the « Production » screen of the application. The “n” represents the number of the faulty part detection function. When the signal takes the expected value, the message is cleared and the involved robot resumes its sequence with no operator action.

•

By default, dynamic monitoring of the part detection function is active and the state of the expected inputs is monitored continuously.

•

Between points, if there is loss of a part detection indication and if the function dynamically monitored, the robot stops and the message " PART DETECTION LOST: n " is displayed in the message area of the « Production » screen of the application. Once the error has been fixed, the robot resumes its sequence without any operator action.

•

At the end of a repositioning operation, if dynamic monitoring of the part detection functions is active, the program cannot be restarted on its current path as long as the part detection signals do not match the programmed state.

•

If recycling is performed, the states of all the part detection functions are positioned to the idle state.

7.8.1 CheckPart instruction Purpose and operation This instruction is used to program the expected state for the 8 part detection signals and to wait for the signals to match the expected states. For each part detection function, the programming is used to either:

100

•

wait for the corresponding input to be set,

•

wait for the corresponding input to be reset,

•

ignore the state of the corresponding input.

RDNU0006 Revision F

7 Actions on paths common to all processes 7.8 Programming part detection functions If at least one input is expected to be set or reset, the CheckPart instruction must be programmed on a fine point. If all the states are idle, the instruction can be programmed on a fly-by point. This instruction specifies, as optional arguments, the part detection functions to be checked and their expected state. The argument \DET1_1 indicates that the part detection sensor 1 is expected to be set (1), the argument \DET1_0 indicates that the part detection sensor 1 expected to be reset (0), and so on for the 8 part detection sensors. The expected state is “idle” for the part detection sensors not specified in the instruction. This means that when the expected state of a part detection sensor is modified, the programming for the other part detection sensors must be repeated in order to continue to monitor them if so desired. Example: CheckPart \CPP1_1;

Programming a CheckPart instruction Syntax: CheckPart

[\DET1_1][\DET1_0][\DET2_1][\DET2_0] [\DET3_1][\DET3_0][\DET4_1][\DET4_0] [\DET5_1][\DET5_0][\DET6_1][\DET6_0] [\DET7_1][\DET7_0][\DET8_1][\DET8_0]

Optional parameters : Name :

Meaning :

\DETx_1

Part detection input x expected to be 1

\DETx_0

Part detection input x expected to be 0

The application software does not monitor the state of the part detection sensors not specified in the instruction. Use of the instruction without optional argument thus results in inhibiting dynamic monitoring of the part detection sensors.

RDNU0006 Revision F

101

7 Actions on paths common to all processes 7.9 Programming the dynamic monitoring functions

7.9

Programming the dynamic monitoring functions

Dynamic monitoring management principle This function ensures continuous (between points) monitoring of the states of the signals corresponding to the part detection sensors, the handling sequences and the events. For more information, see 4.7.1 Dynamic monitoring. Each of the dynamic monitoring functions can be enabled or disabled at any moment using the instruction MonitorInputs.

7.9.1 MonitorInputs instruction Purpose and operation This instruction is used to define the active (enabled) dynamic monitoring functions. Two optional argument families can be used: two exclusive general arguments and 3 basic arguments whose effects are cumulative: •

Use of the instruction without argument or with argument \NONE inhibits all the dynamic monitoring functions.

•

Use of argument \BY_DEFAULT activates the default monitoring functions defined by the integrator (see 4.7.1. Dynamic monitoring).

•

Arguments \GRIPPER, \PART, \PLC and \TOOLING respectively activate dynamic monitoring of the handling sequences, the Part detection signals, the PLC events and the tool events. When using this type of argument, the monitoring functions that are not sepcified are inhibited.

Example: ! activates ! sequences

only

dynamic

monotoring

of

the

handling

MonitorInputs \GRIPPER;

102

RDNU0006 Revision F

7 Actions on paths common to all processes 7.9 Programming the dynamic monitoring functions Programming a MonitorIn puts instruction Syntax: MonitorInpu ts

[\NONE] [\BY_DEFAULT] [\BY_DEFAULT] [\GRIPPER] [\PART] [\PLC] [\TOOLING] Optional parameters:

Name :

RDNU0006 Revision F

Meaning :

\NONE

Disables all dynamic monitoring functions ; this is the default option (when instruction is used without argument)

\BY_DEFAULT

Enables default monitoring functions as defined by the integrator

\GRIPPER

Enables dynamic monitoring of handling sequences

\PART

Enables dynamic monitoring of part detection sensors

\PLC

Enables dynamic monitoring of PLC events

\TOOLING

Enables dynamic monitoring of tool events

103

8 Service programs 8.1 General information

8 Service programs 8.1

General information

The Promia application software manages 4 service programs, each of which can result from a request internal to the process (example: spot welding), a service frequency (example: arc welding), or a request generated by an external signal (pushbutton …).

Service request management principle A « service request 1 » is thus understood, whatever its source, as a service request prompting execution of service program 1. The same applies for a “service request 2” and so on. At a given moment, several service requests may be active. The 4 service requests are managed in accordance with a specific priority: Service request 1 priority > Service request 2 priority > Service request 3 priority > Service request 4 priority

RDNU0006 Revision F

105

8 Service programs 8.1 General information

106

RDNU0006 Revision F

9 Index and appendices 9.1 Index

9 Index and appendices 9.1

Index

A

Errors and messages Displaying ................................................... ... 57 List of common base errors requiring a validation .................................................... 59 List of common base simple errors.................59 List of simple common base messages...........61

PLC Events Definition ....................................................... 21 Programming.................................................. 92 Promia window ..............................................76 Program Display in Production screen.......................... 55 Robot program and path principle .................. 17 Running program in automatic mode............. 39 Running program in manual mode ................. 38 Program code Program code priority............................ ......... 46 sources of program codes ............................... 45 Promia Customizable modules ................................... 31 Description ..................................................... 14 Organization of memory ................................ 28 Software architecture............................. ......... 27

F

R

FlexPendant Basic menu .................................................. ... 34 Dedicated buttons ........................................... 33

Recycling Application software behavior ....................... 50 Definition ....................................................... 19 Repositioning Application software behavior ....................... 50 Definition ....................................................... 19

Anti-loop function Principle and management..............................87

D Debugging Definition........................................................23 Dynamic monitoring Description .................................................. ... 48 Programming ................................................ 102 Types of monitoring ....................................... 48

E

H Handling sequences Definition........................................................22 Manual control................................................73 Programming .................................................. 98 Promia window...............................................70 Hazard levels ................................................... ... 11 Home position definition ..................................................... ... 17

S

IRC5 Control devices...............................................33

Safe end of production request ............................... 44 Safe position definition of safe position............................... 18 Startup Execution of start program ............................. 44 Move to safe request....................................... 42 Safe and home requests .................................. 41

P

T

Part Detection Definition........................................................22 Programming ................................................ 100 Promia window...............................................68 PLC Commands Definition........................................................21 Programming .................................................. 90 Promia window...............................................78

Tool Commands Definition ....................................................... 21 Programming.................................................. 94 Promia window ..............................................78 Tool Events Definition ....................................................... 21 Programming.................................................. 96 Promia window ..............................................76

I

RDNU0006 Revision F

107

9 Index and appendices 9.2 Table of figures

9.2

Table of figures

Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Figure 10. Figure 11. Figure 12. Figure 13. Figure 14. Figure 15. Figure 16. Figure 17. Figure 18. Figure 19. Figure 20. Figure 21. Figure 22. Figure 23. Figure 24. Figure 25. Figure 26. Figure 27. Figure 28. Figure 29. Figure 30. Figure 31. Figure 32. Figure 33. Figure 34. Figure 35. Figure 36. Figure 37. Figure 38. Figure 39. Figure 40. Figure 41. Figure 42. Figure 43. Figure 44. Figure 45. Figure 46. Figure 47. Figure 48. Figure 49.

Block diagram of PROMIA application software ................................................... ......... 14 Sequencing of paths ; « daisy » principle................................... ...................................... 18 Debug menu ........................................................... .......................................................... 19 Recycling without manual jogging...................................................... ............................. 19 Repositioning and recycling after manual jogging..................... ...................................... 20 Commands and events...................................................... ................................................ 21 Tooling commands and events................................................... ...................................... 21 Software architecture ....................................................... ................................................ 27 Organization on the flashdisk........................................... ................................................ 30 Robot system control devices................................. .......................................................... 33 Dedicated keys on the FlexPendant..................................................... ............................. 33 ABB basic menu .................................................... .......................................................... 34 Choice of program to be edited ........................................................... ............................. 36 Production window in a single-robot environment .......................................................... 36 Production window in a multi-robot environment .................................................. ......... 37 Program restarted at beginning (single or multi-robot) .................................................... 38 Confirmation of PP to Main (single or multi-robot)......................................................... 38 Confirmation of automatic mode ........................................................ ............................. 39 Return to safe position prompt (single robot example) .................................................... 42 Switch to manual mode to initiate direct move to safe operation..................................... 43 Direct move to safe dialog to be acknowledged for robots 1 and 2. ................................ 43 Prompt: OK to Move to Home ? ......................................................... ............................. 44 Screen container and floating panel .................................................... ............................. 51 Floating panel control handle..................................................... ...................................... 51 Application software screen selection button.......................................................... ......... 52 Button used to toggle between current screen and Operator Panel screen. ...................... 52 Application software screen selection command bar ....................................................... 52 Selection of "Common Features" screens ..................................................... ................... 53 The two areas of the Production screen......................................................... ................... 55 Example of snapshot message area ..................................................... ............................. 56 Example of history area messages.................................................................................... 57 Structure of Promia information screens....................................................... ................... 67 Part detection screen : undefined state .......................................................... ................... 68 Part detection screen : correct state ..................................................... ............................. 69 Part detection screen : wrong state ...................................................... ............................. 69 Page showing general state of sequences ...................................................... ................... 70 Page showing detailed state of a sequence.................................................... ................... 70 General state of Sequences : undefined state .......................................................... ......... 71 Sequence Screen : correct state ........................................................... ............................. 72 Sequence Screen : feedback error ....................................................... ............................. 72 Detail screen of sequences, manual control not enabled .................................................. 73 Sequence detail screen, manual control enabled ..................................................... ......... 74 Events screen : Correct state ...................................................... ...................................... 76 Events screen : error state................................................................................................. 77 PLC Command Screen ..................................................... ................................................ 78 « Simplified Backup » screen.............................................................. ............................. 80 Debug Menu of the Production Window ...................................................... ................... 83 Acknowledgement of anti-loop message ...................................................... ................... 87 Calling a path ......................................................... .......................................................... 88

RDNU0006 Revision F

109

Promia

Recommend Documents