Automatization of the Code Generation for Different Industrial … · 2017. 9. 15. · minhas empreitadas e continuam sendo em mais uma, que está começando agora: o início de uma

Gus

tavo

Vas

conc

elos

Arn

old

Au

tom

ati

zati

on

of

the

Co

de

Ge

ne

rati

on

fo

r D

iffe

ren

t In

du

stri

al

Ro

bo

ts

Universidade do Minho

Escola de Engenharia

Novembro de 2007

Gustavo Vasconcelos Arnold

Automatization of the Code Generation for Different Industrial Robots

Universidade do Minho

Escola de Engenharia

Tese de Doutoramento em InformáticaÁrea de Especialização: Compiladores, Geração de Código e Robótica Industrial

Trabalho efectuado sob a orientação doProfessor Doutor Pedro Rangel Henriques e doProfessor Doutor Jaime Cruz Fonseca

Gustavo Vasconcelos Arnold

Automatization of the Code Generation for Different Industrial Robots

Novembro de 2007

É AUTORIZADA A REPRODUÇÃO PARCIAL DESTA TESE,APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃOESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE.

Abstract

This document presents GIRo (Grafcet - Industrial Robots), that is a generic environmentfor programming industrial robots off-line, that includes: a truly high-level and declarativelanguage (Grafcet); an easy-to-use front-end (Paintgraf); an intermediate representation(InteRGIRo); the translators from Paintgraf to InteRGIRo; the generic compiler, thattranslates InteRGIRo to the robot target code; and the editor for the robot languageinputs (to obtain the necessary information about the robot target language, to allow thegeneration of code to such robot).

GIRo focus on the modelling of the system, based on the Grafcet specification diagram,rather than on the robot details, improving the programming and maintenance tasks,allowing the reuse of source code, once this source code will be machine independent.

GIRo also allows the programmer to write programs in the robot language, if he isfamiliarized with the robot commands.

With GIRo:– the user can program robots in a high or low level;– the portability for the source code is granted;– the reuse of source code for different robots is allowed;– the programming and maintaining tasks are facilitated.GIRo is easy-to-use. So, GIRo is "giro1"!

1Portuguese (Portugal) slang that means cool.

Resumo

Este documento apresenta um ambiente genérico de desenvolvimento de programas off-linepara robôs industriais chamado GIRo (Grafcet - Industrial Robots). GIRo contém com osseguintes componentes: uma linguagem declarativa e de alto-nível (Grafcet); um front-endamigável (Paintgraf); uma representação intermédia (InteRGIRo); os tradutores para aInteRGIRo, a partir do diagrama Grafcet desenhado no Paintgraf; um compilador genéricode codígo que traduz a InteRGIRo para a linguagem de programação do robô destino; e umeditor, utilizado para juntar as características e instruções da linguagem de programaçãodo robô destino, a fim de permitir a geração de código para este robô.

GIRo foca na modelação do sistema, baseado no diagrama de especificação de automa-tismos Grafcet, ao invés das características físicas do robô. Desta forma, melhora-se astarefas de desenvolvimento e manutenção de programas, uma vez que é permitido a reuti-lização de código fonte, já que este é independente de plataforma.

Giro também permite que o programador escreva os seus programas na linguagem dorobô, caso o mesmo esteja familiarizado com os seus comandos.

Com o GIRo:– a programação de robôs pode ser feita em alto nível (Grafcet) ou em baixo nível

(linguagem do robô);– a portabilidade do código fonte é garantida;– a reutilização do codigo fonte para robôs diversos é permitido;– as tarefas de programação e manutenção são facilitadas.GIRo é fácil de utilizar. GIRo é "giro"!

Agradecimentos

Primeiramente, gostaria de agradecer a minha família (pais, irmãos e demais parentes)por todo incentivo, dedicação, suporte e conquistas. Sempre foram um porto seguro emminhas empreitadas e continuam sendo em mais uma, que está começando agora: o iníciode uma vida nova, com minha esposa e filhas, num país por nós desconhecido e atraente,o Canadá.

À minha esposa e filhas, por todo amor, carinho e alegria, além da paciência e com-preensão durante a fase final deste doutoramento.

Aos meus orientadores, professores Pedro Rangel Henriques e Jaime Cruz Fonseca,por todo apoio, incentivo, sugestões, revisões, amizade, companheirismo, e obviamente,orientações, tanto locais como à distância. Mesmo quando foi preciso voltar para o Brasil,não deixaram de acreditar em mim e de me apoiar e incentivar.

Ao SBLP’97 (Simpósio Brasileiro de Linguagens de Programação de 1997, em Campinas- SP), ponto de partida de conversas, amizades e projetos, tendo sido este evento o berçode muitos trabalhos de mestrado e doutorado de vários brasileiros. Foi lá que conheci JoséCarlos Ramalho, professor da Universidade do Minho, onde trocamos idéias e iniciamoscontatos para projetos futuros. E quantos projetos tiveram origem a partir deste encontro!

Aos amigos baianos e companheiros de apartamento Alfrânio (antigo colega de tra-balho), Fábio e Tiago (ex-alunos), por todo apoio, incentivo e amizade, surgidos nos bonstempos que passei em Braga.

Aos amigos brasileiros e portugueses que tive o prazer de conhecer e que tornarammuito agradáveis os momentos vividos em Portugal.

Aos treinadores e amigos Nuno Reininho e Francisco Costa, por terem apostado eaprimorado as "habilidades" esportivas de um "atleta" de mais de 30 anos, e principalmentepor terem ajudado a realizar um sonho adolescente: o de representar a minha instituiçãoem eventos esportivos nacionais.

Às funcionárias da secretaria (Cristina, Goretti, Helena e Paula) por todo auxílio,presteza e rapidez na resolução de quaisquer problemas.

À equipe técnica (Aragão, Carla, Jaime, João, e Jorge Faria), por todo suporte eapoio técnico no uso de softwares, no acesso a internet e na manutenção de equipamentos,inclusive os pessoais.

Ao DI (Departamento de Informática) e à UM (Universidade do Minho), pela estruturafornecida, pelo apoio material e pelo auxílio para participação em eventos nacionais einternacionais.

À FCT, pelo suporte financeiro imprescindível para a realização deste trabalho.

v

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objectives and Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Industrial Robots Programming 92.1 What is a robot? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Some Robot Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Industrial Robot Programming . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Industrial Robots Programming X Computer Programming . . . . . . . . . 162.5 Limitations of Industrial Robots Programming . . . . . . . . . . . . . . . . 17

2.5.1 Industrial Robots Programming Languages Drawbacks . . . . . . . . 192.5.2 Off-Line Programming Environments Drawbacks . . . . . . . . . . . 192.5.3 Some Principles and Criteria . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Chapter’s Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Industrial Robots Programming Languages 213.1 Industrial Robot Language Classification . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Joint-Control Languages . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Primitive Motion Languages . . . . . . . . . . . . . . . . . . . . . . . 223.1.3 Structured Programming Languages . . . . . . . . . . . . . . . . . . 223.1.4 Task-Oriented Languages . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Standardization of Robot Programming Languages . . . . . . . . . . . . . . 233.3 Industrial Robot Programming Languages: Examples . . . . . . . . . . . . . 24

3.3.1 VAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Melfa Basic III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 VAL II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.4 NACHI SC15F Robot Programming Language . . . . . . . . . . . . 303.3.5 Rapid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii

viii Contents


4 Programming Environments and Some Existing Solutions 354.1 Modelling Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Declarative Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 General Purpose Programming Languages . . . . . . . . . . . . . . . . . . . 40

4.3.1 Similar Computer Strategies . . . . . . . . . . . . . . . . . . . . . . . 424.4 Off-Line Programming Environments . . . . . . . . . . . . . . . . . . . . . . 45

4.4.1 Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.2 RobotStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.3 COSIMIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.4 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Robot Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.5.1 MRROC++ Framework . . . . . . . . . . . . . . . . . . . . . . . . . 504.5.2 Universal Robot Controller . . . . . . . . . . . . . . . . . . . . . . . 50


5 Front-End 535.1 RS Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.1 Structure and operation . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.2 Simple example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1.3 Output from the RS Compiler . . . . . . . . . . . . . . . . . . . . . . 56

5.2 Programming Robots Using RS Language . . . . . . . . . . . . . . . . . . . 575.3 RS Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3.1 RS Program Example that Controls an Industrial Robot . . . . . . . 585.4 Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.5 Standard Grafcet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5.1 Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.5.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5.3 Alternative and Simultaneous Sequences . . . . . . . . . . . . . . . . 615.5.4 Evolution Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6 Why to Use Grafcet instead of RS Language? . . . . . . . . . . . . . . . . . 635.7 Chapter’s Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Intermediate Representation 656.1 Some Existing Intermediate Representations . . . . . . . . . . . . . . . . . . 65

6.1.1 Three Address Code (TAC) . . . . . . . . . . . . . . . . . . . . . . . 656.1.2 Register Transfer Language (RTL) . . . . . . . . . . . . . . . . . . . 666.1.3 GNU Compiler Collection (GCC) . . . . . . . . . . . . . . . . . . . . 666.1.4 RTL System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Contents ix

6.1.5 DIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.1.6 Java Bytecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.1.7 .NET CIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.8 ANSI C Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 Why to Create Another Intermediate Representation? . . . . . . . . . . . . 726.3 InteRGIRo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3.1 Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.3.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3.3 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3.4 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3.5 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.3.6 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.3.7 InteRGIRo Program Examples . . . . . . . . . . . . . . . . . . . . . 806.3.8 InteRGIRo X Three Address Code Representation . . . . . . . . . . 816.3.9 InteRGIRo X Gimple and Simple . . . . . . . . . . . . . . . . . . . . 826.3.10 Why "High-Level" Intermediate Representation? . . . . . . . . . . . 82


7 Automatization of the Code Generation 857.1 Code Generation Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2 Automatic Generation of Code Generators . . . . . . . . . . . . . . . . . . . 867.3 Generic Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.1 General Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3.2 Robot Language Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 897.3.3 Some Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.3.4 Basic Algorithm for Treating Each Instruction . . . . . . . . . . . . . 1017.3.5 Generic Compiler: InteRGIRo -> any Industrial Robot Language . . 1017.3.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105


8 Our Solution: GIRO’s Approach 1158.1 PaintGraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8.1.1 Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188.1.2 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.1.3 Alternatives and Simultaneous Sequences . . . . . . . . . . . . . . . 120

8.2 GIRo Translators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.2.1 PaintGraf -> RS Language . . . . . . . . . . . . . . . . . . . . . . . 1218.2.2 PaintGraf -> InteRGIRo . . . . . . . . . . . . . . . . . . . . . . . . . 1238.2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.3 Optimization: "Variable" allocation . . . . . . . . . . . . . . . . . . . . . . . 126

x Contents


9 Case Studies 1299.1 Robot Language Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 1309.2 A Simple Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

9.2.1 InteRGIRo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.2.2 Robot Language Inputs for VAL Programming Language . . . . . . 1329.2.3 VAL Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389.2.4 Robot Language Inputs for Rapid Programming Language . . . . . . 1399.2.5 Rapid Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

9.3 Boxing Apples Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489.3.1 InteRGIRo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1519.3.2 Robot Language Inputs for VAL II Programming Language . . . . . 1529.3.3 VAL II Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559.3.4 Rapid Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

9.4 Bottles Palletization Case Study . . . . . . . . . . . . . . . . . . . . . . . . 1589.4.1 InteRGIRo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619.4.2 Robot Language Inputs for Melfa Basic III Programming Language . 1639.4.3 Melfa Basic III Final Code . . . . . . . . . . . . . . . . . . . . . . . 1679.4.4 Rapid Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

9.5 A Level Rail Crossing Case Study . . . . . . . . . . . . . . . . . . . . . . . . 1769.5.1 InteRGIRo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779.5.2 Robot Language Inputs for Luna Programming Language . . . . . . 1799.5.3 Luna Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1829.5.4 Rapid Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9.6 A Factorial Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.6.1 InteRGIRo Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.6.2 Robot Language Inputs for Pascal Programming Language . . . . . 1879.6.3 Pascal Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1919.6.4 Robot Language Inputs for C Programming Language . . . . . . . . 1929.6.5 C Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

9.7 Analysis of the Generated Code . . . . . . . . . . . . . . . . . . . . . . . . . 1979.8 Chapter’s Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

10 Conclusions 19910.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20110.2 GIRo’s Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20210.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20210.4 Other Future Ideas... Or Dreams... . . . . . . . . . . . . . . . . . . . . . . . 204

Contents xi

Bibliography 205

A A Simple Case Study 211A.1 VAL II Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211A.2 Melfa Basic III Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212A.3 Luna Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213A.4 Pascal Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214A.5 C Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

B Boxing Apples Case Study 219B.1 VAL Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219B.2 Melfa Basic III Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221B.3 Luna Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223B.4 Pascal Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224B.5 C Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

C Bottles Palletization Case Study 231C.1 VAL Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231C.2 VAL II Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233C.3 Luna Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235C.4 Pascal Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238C.5 C Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

D A Level Rail Crossing Case Study 245D.1 VAL Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245D.2 VAL II Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247D.3 Melfa Basic III Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248D.4 Pascal Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250D.5 C Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

E A Factorial Case Study 255E.1 VAL Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255E.2 VAL II Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256E.3 Rapid Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257E.4 Melfa Basic III Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258E.5 Luna Final Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

xii Contents

List of Figures

1.1 Thesis proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 GIRo’s approach to industrial robots programming. . . . . . . . . . . . . . . 5

2.1 Human and industrial robot workspace. . . . . . . . . . . . . . . . . . . . . 112.2 Industrial robot example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Tool center point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Robot with welding tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Industrial robots X Computer programming tools . . . . . . . . . . . . . . . 182.6 Principles of software engineering and programming languages that must be

supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 NACHI SC15F robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Code generation directly to the machine. . . . . . . . . . . . . . . . . . . . . 404.2 Code generation for the industrial robot programming language. . . . . . . . 414.3 Standard C code generation strategy. . . . . . . . . . . . . . . . . . . . . . . 434.4 Using virtual machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5 Using an automatic generator of code generators. . . . . . . . . . . . . . . . 44

5.1 RS Grammar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 RS reaction rule example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 Example of a single RS program. . . . . . . . . . . . . . . . . . . . . . . . . 565.4 RS automaton generated by the RS compiler. . . . . . . . . . . . . . . . . . 575.5 RS rules generated by the RS compiler. . . . . . . . . . . . . . . . . . . . . 575.6 RS program to control the Nachi SC15F robot. . . . . . . . . . . . . . . . . 585.7 Generated program to be executed at Nachi SC15F robot. . . . . . . . . . . 595.8 Example of Grafcet’s step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.9 Example of Grafcet’s step with action. . . . . . . . . . . . . . . . . . . . . . 615.10 Example of Grafcet’s step with action and conditions. . . . . . . . . . . . . 615.11 Example of Grafcet’s transition. . . . . . . . . . . . . . . . . . . . . . . . . . 615.12 Example of Grafcet’s transition that changes the state of variables. . . . . . 62

xiii

xiv List of Figures

5.13 Example of Grafcet’s simultaneous sequence. . . . . . . . . . . . . . . . . . 625.14 Example of Grafcet’s alternative sequence. . . . . . . . . . . . . . . . . . . . 63

7.1 Schema of the translation between InteRGIRo and the target language. . . . 907.2 First stage of translation from InteRGIRo into industrial robot language. . . 1097.3 Second stage of translation from InteRGIRo into industrial robot language. 1107.4 Third stage of translation from InteRGIRo into industrial robot language. . 1117.5 Fourth stage of translation from InteRGIRo into industrial robot language. 1127.6 Fith stage of translation from InteRGIRo into industrial robot language. . . 113

8.1 GIRo’s approach to industrial robots programming. . . . . . . . . . . . . . . 1168.2 Program example made on the PaintGraf graphical interface, responsible

for making the robot move 10 times between two points. . . . . . . . . . . . 1178.3 Another program example made on the PaintGraf graphical interface, re-

sponsible for calculating the factorial of a given number. . . . . . . . . . . . 1188.4 Step graphic representation (left) and step and actions graphic representa-

tion (right). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.5 Transition graphic representation. . . . . . . . . . . . . . . . . . . . . . . . . 1198.6 Schema of the translation from Paintgraf into InteRGIRo. . . . . . . . . . . 125

9.1 Grafcet diagram for simple case study drawn in PaintGraf editor . . . . . . 1319.2 Grafcet representation of the boxing apples case study. . . . . . . . . . . . . 1499.3 Grafcet diagram for boxing apples case study drawn in PaintGraf editor . . 1509.4 Grafcet representation of the bottles paletization case study. . . . . . . . . . 1599.5 Grafcet diagram for bottles paletization case study drawn in PaintGraf editor1609.6 "Passagem de Nível" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769.7 Grafcet representation of the level rail crossing case study. . . . . . . . . . . 1779.8 Grafcet diagram for level rail crossing case study drawn in PaintGraf editor 1789.9 Grafcet representation of the factorial case study. . . . . . . . . . . . . . . . 1869.10 Grafcet diagram for factorial case study drawn in PaintGraf editor . . . . . 186

Chapter 1

Introduction

Today, the programming task of non-robotic systems is done in very high level languages;each of these languages try to facilitate the specification of the program, that solves theproblem, allowing the programmer to concentrate on the problem, instead of the equipmentwhere this program will be executed.

To do this, the developer should not think about the equipment that will run theprogram. He must be concerned about the problem, to find the correct solution for it.To make this task easy, it is used some modelling technique, appropriate for the kind ofproblem. The modelling technique will decompose the problem into smaller components,that will be implemented using the adequate programming language. This language shouldfacilitate not only the programming task, but the readability, maintenance, reusability,composability and other important features for the development according to softwareengineering principles.

Another advantage of this approach is the existence of compilers to translate the high--level (machine independent) languages into the code of different computer platforms. Withthese, it is possible to run the same source code in different machines. So, the equipmentcan be upgraded, or changed, without the necessity of rewriting the programs.

However, the development of industrial robotic systems is still a difficult, costly, andtime consuming operation. Today’s industrial robots generally require a tremendousamount of programming to make them useful. The commercial robot programming en-vironments are typically closed systems. The manipulator level is still the most widelyused programming method employed in industry for manufacturing tasks. The forerunnerlanguages, such as AML [TSM82] or AL [MGB82], have now been superseded by elabo-rated robot languages like ABB Rapid [ABB94]. Despite their common use, they havethree important drawbacks.

1. They require detailed description of the motion of every joint in the mechanism inorder to execute a desired movement.

2. They require specialized knowledge of the language.3. The robot programs have limited portability. As a result, significant investment must

be made when changing or acquiring a new robot type or simply when upgrading a

1

2 1. Introduction

new controller from the same vendor.

One simple approach to solve some limitations is the Off-line programming environ-ments. These environments are based in graphical simulation platforms, in which theprogramming and execution process is shown using models of the real objects. Conse-quently, the robot programmer has to learn only the simulation language and not any ofthe robot programming languages. Other benefits of off-line programming environmentsinclude libraries of pre-defined high-level commands for certain types of applications, suchas painting or welding, and the possibility to assess the kinematics feasibility of a move,thus enabling the user to plan collision-free paths. The simulation may also be used todetermine the cycle time for a sequence of movements. These environments usually pro-vide a set of primitives commonly used by various robot manufacturers, and produce a se-quence of robot manipulator language primitives such as "move" or "open gripper" that arethen downloaded in the respective robot controllers. However, the current state-of-the-artoff-line systems suffer from two main drawbacks. Firstly, they do not address the issue ofsensor-guided robot actions. Secondly, they are limited to a robot motion simulator, whichprovides no advanced reasoning functionality, nor flexibility in the tasks.

1.1 Motivation

Considerable effort has been concentrated on developing new robot programming lan-guages, and basically, there are two solutions for the creation of a general purpose robotprogramming language:

1. The compiler should generate code directly to the machine, where it should be nec-essary to know the hardware architecture of the robot, before the creation of suchcompiler;

2. the compiler should generate code for the industrial robot programming language,as Workspace1 does.

This problem is also treated on the computers domain. There are some interestingsolutions that are normally used and that are accepted by the society, while some othersare under development and research.

Basically, there are three solutions for computer programming languages, that grantsportability for the source code:

1. The compiler should generate standard C code, because standard C language is a veryused and known programming language, that has translators for almost all computerplatforms;

2. The compiler should generate an intermediate code, and the platforms where theprogram would run must have a virtual machine, responsible for interpreting thisintermediate code, as JVM (Java Virtual Machine - used to interpret java programs)and CLR (Common Language Runtime - used to interpret Microsoft .Net applica-tions) do;

1Workspace is a well-known robot simulation system, that allows the off-line programming of industrialrobots. Workspace is a product of Flow Software Technologies.

1.2. Objectives and Proposal 3

3. The compiler should generate an intermediate code, and an specific final codegenerator translates it into the machine code. However, this final code generatoris generated automatically by an automatic generator of code generators. To do this,it is necessary to specify the hardware architecture for this automatized tool;

Despite the existence of these five solutions, none of them could be really applied forthe existing industrial robots, as it will be explained in chapter 4.

1.2 Objectives and Proposal

The aim of this PhD. work is to automatize the code generation for different industrialrobots. This automatization intends to facilitate the industrial robots programming task,which means that it must be created a programming environment, with the definition ofa programming language (as a front-end), that generates final code to different industrialrobots (the back-ends).

The programming language (front-end) must attend the basic requisites of the industrialrobots programming. It should be easy to use and to learn. It is also important that theuser should actualize the environment to allow the generation of code for new industrialrobots. At last, should solve the problems presented on the previous subsection.

To achieve this goals, it is necessary:

1. to specify a programming language;2. to create a friendly programming environment;3. to automatize the code generation process;4. to simplify the process of obtaining the industrial robot details needed by the code

generator;5. to have a friendly interface for the user to enter the robot details that are needed by

the code generator;6. to grant efficiency and efficacy for the generated final code.

So, after some research and developments, the product of this thesis was created, thatis called GIRo – Grafcet - Industrial Robots: A Generic Environment for ProgrammingIndustrial Robots Off-Line.

GIRo is inspired on a mix of two solutions that was presented on the previous section:the solution that is used by the Workspace, that generates code in the used industrial robotlanguage (figure 4.2); and the one that generates automatically the code generator (figure4.5). Instead of having an automatic generator of code generator, it has a generic compiler,responsible for translating code into many industrial robot programming languages (figure1.1).

GIRo’s approach can be seen on figure 1.2. It is supported by the following languagesand tools that compose the architecture we want to defend:

– a truly high level and declarative language (Grafcet)– an easy-to-use front-end (Paintgraf)

4 1. Introduction

Figure 1.1: Thesis proposal.

1.3. Contribution 5

– an intermediate representation (InteRGIRo)– the translators to InteRGIRo– the generic compiler– the robot language inputs editor

Figure 1.2: GIRo’s approach to industrial robots programming.

At the top, there is the problem to be solved. It would be used an adequate modellingtechnique that describes formally the overall problem. As the modelling language adoptedwas Grafcet, it was included in the FE a Graphical interface to aid editing the Grafcetvisual description, the Paintgraf, an easy-to-use compiler front-end, based on Grafcet, thatis a truly high level language, close to the specification instead of the robot, that interpretsthe specification language and generates an internal data structure, that can be translatedinto InteRGIRo, an intermediate description for the program specified. To generate finalcode it is also necessary to get some description of the target machine, the robot languageinputs. With all of this inputs (InteRGIRo and robot language inputs), the final codegeneration is possible. To generate both the InteRGIRo and the final code, it is necessarysome translators, like the generic compiler, that is responsible for the final code generation.

1.3 Contribution

With GIRo, the contribution of this PhD. work, the programming and maintenance tasksare facilitated, allowing the reuse of source code. The existing problems on the industrialrobot programming languages, (presented in the beginning of this chapter), that motivatedthis thesis, are solved. Besides that, GIRo also attends other users desires like:

– it is user-friendly - because Paintgraf enables the user to describe completely the pro-gram by the use of Grafcet, that is an well known specification diagram for industrialautomation aplications;

– it is easy to use and to learn - because Grafcet is a well knows specification diagram;

6 1. Introduction

– it allows a programming close to the problem specification, instead to the robotdetails - because it is uses a programming language that is based on the Grafcet;

– it is extensible - because it is possible for the user to create high level instructionsand data types;

– it is expressive - because it is possible to create programs in a truly high-level lan-guage, or even directly in the target robot language (loosing the source-code porta-bility);

– it grants the source-code portability - because all the source programs do not dependon the robot language features. They are firstly translated into InteRGIRo, that is,then, translated into the target robot language, by the generic compiler;

– it allows the reusability of source-code - as the source-code portability is granted, itmakes possible to reuse source-code.

– it facilitates the programming and maintenance tasks;– it is platform independent - because GIRo was done by Java language;– it allows the environment interaction - because it is possible to create programs that

could interact with the environment, by the use of digital input/output signals;– it is easy to obtain the target descriptions needed by the code generator - because it

is used the target language description, instead of machine one;– it is easier to describe programs in a high level way, instead of creating them inside

simulators, that can difficult / limit the robot programming;

1.4 Thesis Organization

All of the necessary concepts of this thesis and the components of GIRo are better describedin the chapters that follow this introduction. This thesis is structured in the following way:

– The basic concepts of industrial robotics with the state of the art in industrial robotsprogramming languages, are presented in chapters:

• 2 - Industrial Robots Programming - presents the background of industrial ro-botics and the ways of industrial robots programming, making a comparison oftheir current programming tools with the computer programming tools, showingthe limitations that exist on the first ones;

• 3 - Industrial Robots Programming Languages - classifies the industrial robotprogramming languages, presenting some examples of them;

• 4 - Programming Environments and Some Existing Solutions - presents someother programming tools for the programming of industrial robots;

– The components of our initial approach, that has given the research directions, withits definitions and explanations, are presented in chapters:

• 5 - Front-end, that presents the initial and the actual front-end used in theproduct of this thesis: the declarative and reactive RS language, that gavethe initial idea of this research, that is to facilitate the programming task forindustrial robots; and the Grafcet, one well-known description language forindustrial automation applications, that is suitable to be the visual interface forthe front-end;

1.4. Thesis Organization 7

• 6 - Intermediate Representation - presents the importance of using an intermedi-ate representation on the product of this thesis, with examples of some existingones;

• 7 - Generator of Code Generators - presents the concepts and some examplesof this kind of translator, that is the principal element of this thesis: a compilerthat makes possible the generation of code for different industrial robots;

– The description of the product of this thesis, that is called GIRo, with some casestudies, conclusions and future works, are presented on these last chapters:

• 8 - Our Solution: GIRo’s Approach - presents the product of this thesis, withits components, some implementation details, algorithms, and examples of thetranslation processes;

• 9 - Case Studies - presents some case studies that were done to validate GIRo;• 10 - Conclusions - presents the conclusions of this thesis, with some future works.

8 1. Introduction

Chapter 2

Industrial Robots Programming

In this chapter, it will be presented the background of industrial robotics. An industrialrobot will be defined, with its main features and with its ways of programming. It is alsomade a comparison between the industrial robots programming tools and the computersprogramming tools, showing the drawbacks of the first ones.

2.1 What is a robot?

A robot is an electro-mechanical device, with mechanical actuator(s), controlled by a com-puter. It can be programmed to perform automatically a large amount of tasks. TheRobotic Industries Association [Reh97] defines an industrial robot as follows:

"An industrial robot system includes the robot(s) (hardware and software) consisting ofthe manipulator, power supply, and controller; the end-effector(s); any equipment, devicesand sensors with which the robot is directly interfacing, any equipment, devices and sensorsrequired for the robot to perfom its task; and any communications interface that is operatingand monitoring the robot, equipment and sensors."

2.2 Some Robot Terms

To better understand robot programming, it is necessary to take care about some robotterms. These terms are described following.

End-of-Arm Tooling

Tools and grippers are the two general categories of end effectors used in robotics. In eachcase the robot must not only control the relative position of the tool with respect to thework as a function of time, it must also control the operation of the tool. For this purpose,the robot must be able to transmit control signals to the tool for starting, stopping, and

9

10 2. Industrial Robots Programming

otherwise regulating its actions.

Sensors

The most sophisticated robot available today cannot perform routine tasks, like detectingthat a part has fallen to the floor or when a finished part is not ejected from a machine,without the use of sensors.

Sensors used in industrial robotics can be classified into two categories, sensors thatare internal to the robot and sensors that are external to the robot [Gro87]. Although, thesame types of sensors might be used in both categories.

Sensors internals to the robot are those used for controlling position and velocity ofthe several joints. These sensors form a feedback control loop with the robot controller.Typical sensors used to control the position of the robot arm include potentiometers andoptical encoders. To control the speed of the robot arm, tachometers of several types areused.

Sensors external to the robot are used to coordinate the operation of the robot in itsenvironment. In some cases, these external sensors are relatively simple devices such aslimit switches that determine whether a part has been positioned properly in a fixture, orto indicate that a part is ready to be picked up at a conveyor. Other situations requiremore advanced sensor technologies, like:

– Tactile sensors - these sensors are used to determine whether contact is made betweenthe sensor and another object. Tactile sensors can be divided into two types inrobotics applications: touch sensors and force sensors. Touch sensors are those thatindicate simply that contact has been made with the object. Force sensors are usedto indicate the magnitude of the force with the object.

– Proximity sensors - these indicate when an object is close to the sensor. When thistype of sensor is used to indicate the actual distance of the object, it is called a rangesensor.

– Machine vision and optical sensors - Vision and other optical sensors can be used forvarious purposes. Optical sensors such as photocells and other photometric devicescan be used to detect the presence or absence of objects, and are often used forproximity detection. Machine vision is used in robotics for inspection, parts identifi-cation, guidance, and other uses.

– Miscellaneous sensors - This category includes other types of sensors that might beused in robotics, including devices for measuring temperature, fluid pressure, fluidflow, electrical voltage, current, and several other physical properties.

Some authors, like [Reh97], also classifies the external sensors in another two cate-gories: Contact and noncontact sensors. Contact sensors include the tactile ones, whilethe noncontact sensors include the proximity, miscellaneous and optical sensors, and ma-chine vision.

2.2. Some Robot Terms 11

Teach Stations

Teach stations on robots may consist of teach pendants, teach terminals, or controllerfront panels. Some robots permit a combination of programming devices to be used inprogramming the robot systems, whereas others provide only one system programmingunit. In addition, some robots use IBM PC or compatible microcomputers as programmingstations. Teach stations support three activities: (1) robot power-up and preparation forthe programming; (2) entry and editing of programs; and (3) execution of programs in thework cell. The development of a program includes keying in or selecting menu commandsin the controller language, moving the robot arm to the desired position, and recordingthe position in memory.

Robot Workspace

The space in which the robot gripper can move with no limitations in travel other thanthose imposed by the joints. Figure 2.1 shows a workspace for a spherical geometry robotin contrast to that of a human worker.

Figure 2.1: Human and industrial robot workspace.

Axis Numbering

The following axis numbering convention is used to describe the axes of motion of a robot.See figure 2.2

1. Start at the robot mounting plate (base).2. Label the first axis of motion encountered as axis 1.3. Progress from the base to the end-effector numbering each axis encountered succes-

sively.


Figure 2.2: Industrial robot example.

Degree of Freedom

Every joint or movable axis on the arm is a degree of freedom. A machine with six movablejoints is a robot with 6 degrees of freedom or axes.

Coordinate Systems

All points programmed in the work cell are identified by a base coordinate system thatconsists of three translation coordinates - X, Y and Z - that position spatially the robot;and three rotational coordinates - A, B, and C - that position the tool plate at the end ofthe arm. The number of work-cell coordinates required to define a programmed point isdetermined by the number of degrees of freedom present on the robot.

Offset (Tool Center Point - TCP)

When a tool is mounted to the robot tool plate, the points where the actions must happencan be different from the ones defined for the coordinate system of the previous subsection.The coordinate system corresponds to the location of the tool plate (figure 2.2), while theoffset, or the tool center point (TCP) corresponds to the position where the tool, that ismounted at the tool plate, must act (figure 2.4). With an offset of 0, 0, 0 for the coordinatesof the TCP (L, A and B respectively), the TCP is located at point TCP1 in figure 2.3.With L=10, A=5 and B=4 , the TCP is located at TCP2. When a tool is mounted to the

2.2. Some Robot Terms 13

tool plate, the distance from the TCP1 to the action point on the tool is included in therobot program. For example, the welding torch in figure 2.4 has a TCP of L = 14 inches, A= -4 inches, and B = 0 inches. The robot will control the motion at the welding electrodeas the arm moves through the programmed points.

Figure 2.3: Tool center point.

Figure 2.4: Robot with welding tool.

Control Techniques

The type of control used to position the tool separates robots into two categories: servo(closed-loop) and nonservo (open-loop) systems. An understanding of these two controltechniques is fundamental to understanding the operation and programming or robots[Reh97].

1. Open-Loop Systems: The open-loop system provides no information to the controllerconcerning arm position or rate of change during the robot’s motion throughout the


workspace. The arm receives only the drive signal, and the controller relies on thereliable operation of the actuators to move the arm to the programmed location.There are several advantages of an open-loop system:

– Lower initial investment in robot hardware.– Well-established controller technology in the form of programmable logic con-

trollers.– Less sophisticated mechanical and electronic systems with fewer maintenance

and service requirements.– A larger pool of engineers and technicians familiar with the requirements of this

type of system.2. Closed-Loop Systems: A closed loop control system measures and controls the po-

sition and velocity of the robot tool center point (TCP) at every point during therobot’s motion. The closed-loop uses information provided by the internal sensorsattached to the robot’s movable axes to calculate the current position and velocityof the TCP. These systems are much more complex and have a statistically higherchance to malfunction than open-loop systems; however, the advantages gained inthe application of servo-controlled robots outweigh the problems created by theadditional complexity inherent in the system. The advantages include these:

– They provide highly repeatable positioning anywhere inside the workspace. Thisflexible, multiple-positioning characteristic is necessary for the implementationof robots in many production jobs.

– The servo type of controller with computer capability can provide system controlfor devices and machines that are external to the robot system.

– Powerful programming commands are available to perform complex manufac-turing tasks with very simple program steps.

– Interfacing robots to other computer-controlled systems, such as vision systemsand host computers, is easier to accomplish with this controller.

Program Points

One of the main differences between computer programming languages and robotic pro-gramming languages is the necessity of storing program points, that represents the positionpoints in the workspace, where the robot must pass in.

Normally, this points are defined by the use of the teach box, where the robot is moveduntil the desired location. At this moment, this position point can be stored. This pointsstorage can be done at any time during the development of the program.

On-Line and Off-Line Programming

The terms On-line and off-line programming define the location where the robot programis developed.

For on-line programming, the production operation is stopped and the robot program-mer puts the production machine into the programming mode, loosing production time.So, the programmer teaches the robot the required position, motion, and control sequences.

2.3. Industrial Robot Programming 15

Some robot languages use variable names for the translation points and permit the con-trol structure, moves, and program logic to be developed outside the production machine.The completed program is downloaded to the robot controller and production is stoppedonly to teach translation points for all the location variables named in the program. Asignificant reduction in lost production is achieved.

The term off-line programming means that all of the programming is performed awayfrom the robot and the production area. Some systems use an workcell simulation softwareto define the program points and to test the program.

2.3 Industrial Robot Programming

A robot program can be defined as a path in space to be followed by the manipulator,combined with peripheral actions that support the work cycle, like opening and closing thegripper, for example. The program has two basic parts.

The first part is a set of points in space, to which the robot will move when the programis executed. To do this, it is used the teach box, where the user should move the robot throwits workspace, setting and storing points that will be necessary for the correct execution ofthe program. The second part consists of program statements that set the order of motion,the logic and conditions for decision, gather information on the operation of the cell, andanalyze and prepare data for communication with other machines.

A robot is programmed by entering the commands into its controller memory. Thereare four ways to program a robot[Gro87]:

– Manual setup - the programming is done by setting limit switches and mechanicalstops to control the end points of its motion. However, this does not correspond toa programming method, but to a mechanical control;

– Leadthrough programming - also called "teach by showing", programming task isdone by moving the manipulator through the desired motion path during a teachprocedure, entering the program into the controller memory. It is a simple wayfor the programming task, however, it has some disadvantages: it is necessary tointerrupt the production process during the leadthrough programming; it is limitedin terms of the decision-making logic that can be incorporated into the program; andsince this method was developed before computer control became common for robots,these methods are not readily compatible with modern computer-based technologies,such as CAD/CAM, manufacturing data bases, and local communications networks;

– Computer like robot programming languages - Like a computer programming lan-guage, but with some specific commands to control the robot. They can solve somelimitations of leadthrough programming with some functions, like: Enhanced sensorcapabilities; Improved output capabilities for controlling external equipment; increaseof the program logic control; Computations and data processing similar to computerprogramming languages; Communications with other computer systems;

– Off-line programming - It also uses its own computer like programming language,with the advantages explained above. But all the steps of de programs development,


like programming and testing, is done under a simulator environment. So, only whenthe development is done, and the system is corrected and tested, the program will besent to the robot controller, with no interruption of the production process duringthe program development.

As it can be seen, the use of a computer like programming languages has someadvantages. However, the actual programming languages, like the ones used do controlthe Mitsubishi, Nachi and Puma robots [Cor94], for example, do not allow a correct sys-tems development, following the software engineering principles. It can be seen above:

– These programming languages are imperative, and some of then looks like assemblylanguages. It means that these languages are in a level more close to the machinethan the user. So, the programmer must be care about some hardware featuresinstead of think only about the logic of the system;

– It is used unconditional jumps (like goto) as execution flow control. Even in condi-tional jumps, the execution flow goes to any point of the program, defined by a label.It is against the principles of structured programming;

– There is no source code portability, because each programming language belongs toan specific robot;

– As a consequence, source code reutilization is only possible when using the samerobots;

– Without source code portability, the programmers must be trained to use and pro-gram the machine, each time that the robot is changed;

There are some high level programming languages that are visual, friendly. Although,they are specific for a such robot. So, they do not solve the problem of source codeportability.

Few standards currently exist for robot control languages. There is nointerchangeability of programs among manufacturers, and in some cases, only limited in-terchangeability of programs between models from the same manufacturer [Reh97].

2.4 Industrial Robots Programming X Computer Program-ming

Today, the programming task of computer systems is done in very high level languages;each of these languages try to facilitate the specification of the program that solves theproblem, allowing the programmer to concentrate on the problem, instead of the equipmentwhere this program will be executed.

To do this, the developer should, first, do not think about the equipment that will runthe program. He must be concerned about the problem, to find the correct solution for it.To make this task easy, it is used some modelling technique, appropriate for the kind ofproblem. The modelling technique will decompose the problem into smaller components,that will be implemented using the adequate programming language. This language shouldfacilitate not only the programming task, but the readability, maintenance, reusability,

2.5. Limitations of Industrial Robots Programming 17

composability and other important features for the development according to softwareengineering principles.

Another advantage of this approach is the existence of compilers that translate thehigh-level (machine independent) languages for different computer platforms. With these,it is possible to use the same source code in different machines. So, the equipment can beupgraded, or changed, without the necessity of rewriting the programs.

However, the industrial robot programming languages did not evolved in the samemanner as the computer languages. The development of industrial robotic systems isstill a difficult, costly, and time consuming operation. Today’s industrial robots generallyrequire a tremendous amount of programming to make them useful. Their controllers arenot very sophisticated and the commercial robot programming environments are typicallyclosed systems. The manipulator level is still the most widely used programming methodemployed in industry for manufacturing tasks.

One simple approach that solves some limitations is the Off-line programming envi-ronments. These environments are based in graphical simulation platforms, in which theprogramming and execution process are shown using models of the real objects. Conse-quently, the robot programmer has to learn only the simulation language and not any ofthe robot programming languages. Other benefits of off-line programming environmentsinclude libraries of pre-defined high-level commands for certain types of applications, suchas painting or welding, and the possibility to assess the kinematics feasibility of a move,thus enabling the user to plan collision-free paths. The simulation may also be used todetermine the cycle time for a sequence of movements. These environments usually providea set of primitives commonly used by several robot vendors, and produce a sequence ofrobot manipulator language primitives such as "move" or "open gripper" that are thendownloaded in the respective robot controllers. However, these current state-of-the-artoff-line systems do not solve the problems that we want to treat.

Figure 2.5 shows a schema where can be compared the industrial robots programmingtools with the computer programming tools.

2.5 Limitations of Industrial Robots Programming

It can be said that there are basically two ways for programming industrial robots:

1. by the use of the industrial robots programming languages, where the user can pro-gram directly the robot, with a language that allow him to use all the potentialitiesof the robot;

2. by the use of off-line programming environments, where the programmer can usesome graphical development environment, where it is possible to test the programbefore using it in the robot. It is also possible to develop programs for differentrobots, but it is necessary to have a library for each robot.

However, both of them have their own drawbacks.


Figure 2.5: Industrial robots X Computer programming tools

2.5. Limitations of Industrial Robots Programming 19

2.5.1 Industrial Robots Programming Languages Drawbacks

The industrial robots programming languages did not evolved in the same manner as thecomputer languages. Those languages have some drawbacks:

1. The typical languages are imperative, low-level or structured;2. Each industrial robot has its own programming language, which make difficult or

even impossible, to reuse the source code;3. although the forerunner languages, such as AML [TSM82] or AL [MGB82], have

now been superseded by elaborated robot languages, like ABB Rapid [ABB94], theyrequire detailed description of the motion of every joint in the mechanism in orderto execute a desired movement;

4. the programmer in charged of the task, instead of thinking only about the problem, hehas to think about the robot that will run the program, and about its programminglanguage. Both the robot and the language limitate the specification of the problem;

5. They are more closed to the robot specification than to the problem, difficultingthe problem modelling task and all other good practices that a correct softwareengineering should require;

6. they require specialized knowledge of the language;7. the robot programs have limited portability, and significant investment must be made

when changing or acquiring a new robot type or simply when upgrading a newcontroller from the same vendor.

2.5.2 Off-Line Programming Environments Drawbacks

The off-line programming environments also have some drawbacks, like:

1. They are, also, more closed to the robot specification than to the problem, difficultingthe problem modelling task and all other good practices that a correct softwareengineering should require;

2. These tools do not solve the problem of programming the robot to interact with itsenvironment;

3. the most recent off-line programming environments (for instance, Workspace) do notaddress the issue of sensor-guided robot actions;

4. they are limited to a robot motion simulator, which provides no advanced reasoningfunctionality, nor flexibility in the tasks;

5. Probably, it is necessary to construct a new translator always that a new robot iscreated, or some robot language is increased.

2.5.3 Some Principles and Criteria

According to some principles of software engineering and programming languagesevaluating criteria [Seb99], it is possible to see that these development environments donot attend the user needs, as can be seen on figure 2.6.


Principles Off-Line Industrial RobotsProgramming ProgrammingEnvironments Languages

User-friendly YES NOSource Code Portability YES NOExpressiveness NO YESEnvironment interaction NO YESSpecification close to the problem NO NOReusability NO NO

Figure 2.6: Principles of software engineering and programming languages that must besupported

The programs created today to control industrial robots make them act as program-mable logic controllers that can move; but there are much more things to explore. Maybethe problem arises from the limitations that both the industrial robots programming lan-guages and the off-line programming environments presents, and from the low level of theprogramming languages available, because they do not make easy to program robots as itis with computers, and there is no reuse of source code.

2.6 Chapter’s Considerations

In this chapter it was presented some robot concepts and ways of programming, withsome considerations about each kind of programming. It was made a comparison betweenindustrial robots programming tools and computer programming tools, being clear that,concerning on users facilities and their expectations, the first programming area is far wayfrom the last one.

It is also important to say that:

– each robot model has its own programming language;– the industries do not shows the robot architecture of their produced robots, which

difficult the development of other compilers and softwares.

Chapter 3

Industrial Robots ProgrammingLanguages

In this chapter, some fundamentals about industrial robots programming will be presented,including the classification of industrial robots programming languages, showing the effortthat was done for the standardization of robot programming. At the end, some examplesof such languages are presented, aiming to illustrate that they must be improved.

It is important to say that there are other solutions for the programming of industrialrobots, but they that are more than a language: they are programming environments, oreven robot controllers. These other solutions will be presented in the next chapter.

3.1 Industrial Robot Language Classification

One way to classify the many languages used by industrial robot manufacturers is accordingto the level at which the user must interact with the system during the programmingprocess. The current languages can be grouped into the four loosely formulated levels thatfollows [Reh97]:

3.1.1 Joint-Control Languages

Languages at this level concentrate on the physical control of robot motion in terms of jointsor axes. The program commands must include the required angular change of rotationaljoints or the extension lengths of linear actuators. These languages usually do not supportsystem or work-cell commands, which can be incorporated into the programs of higher-levelrobot languages for control of external devices.

21

22 3. Industrial Robots Programming Languages

3.1.2 Primitive Motion Languages

Point-to-point primitive motion languages are now usually confined to older robot program-ming languages, or they may be an optional programming mode for a more sophisticatedrobot language. These languages have the following characteristics:

– A program point is generated by moving the robot to a desired point and depressinga program switch;

– Program editing capability is provided;– Teaching motion of the robot is controlled by either a teach pendant, terminal, or

joystick;– The programmed and teaching motion can occur in the cartesian, cylindrical, or hand

coordinate modes;– Interfacing to work-cell equipment is possible;– The language permits simple subroutines and branching;– Some languages allow parallel execution using two or more arms in the same word

space.

The advantage of languages at this level is the performance on the manufacturing floor.But as disadvantages, the programming emphasis is still on robot motion rather than onthe production problem, and there is no support for off-line programming. An example ofthis kind of languages is the VAL language.

3.1.3 Structured Programming Languages

These languages offer a major improvement over the last levels, and have become thestandard for the major vendors of robots. There are several examples of this kind oflanguages, like VAL II, Rapid, and others. They have the following characteristics:

– A structured control format is presented;– Extensive use of coordinate transformations and reference frames is permitted;– Complex data structures are supported;– Improved sensor commands and parallel processing;– System variables (called state variables), whose value is a function of the state of

position of the system, are permitted;– The format encourages extensive use of branching and subroutines defined by the

user;– Communication capability with local area networks is improved;– Off-line programming is supported.

3.1.4 Task-Oriented Languages

The primary function of this kind of languages is to hide from the user the commands andprogram structure that normally must be written by the programmer. The user need onlybe concerned with solving the manufacturing problem. These languages have the followingcharacteristics:

3.2. Standardization of Robot Programming Languages 23

– Programming in natural language is permitted;– A plan generation feature allows replanning of robot motion to avoid undesirable

situations;– A world modelling system permits the robot to keep track of objects;– The inclusion of collision avoidance permits accident-free motion;– Teaching can be accomplished by showing the robot an example of a solution.

Currently, no languages at this level are operational, but significant efforts are underwayat university and industrial research laboratories. Several experimental languages haveexhibited the characteristics of this level: AUTOPASS (Automatic Programming Systemfor Mechanical Assembly) from IBM, RAPT (Robot Automatically Programmed Tools),and LAMA (Language for Automatic Mechanical Assembly) [Reh97].

3.2 Standardization of Robot Programming Languages

As it was said before, most of the problems in the successful implementation of indus-trial robots are related to the difficulties in programming and the lack of integrationwith other factory automation equipment. Several experts have suggested the need for astandardized robot programming language, that will enable robots of different manufac-tures to seamlessly converse and reduce high training costs. Researchers worldwide havetried to develop a standardized robot programming language, but have been only partiallysuccessful. Most of the standardization of robot programming is done for industrial pur-poses (for example, IRDATA, MMS, SLIM/STROLIC), and they are directly aimed forprogramming the motions of the robot. [Zie01].

The standardization of robot languages has not matured yet, especially wheninteraction between robot and sensors is involved. Today, there are many standard ro-bot programming languages, but they are not really used by the industrial robots. Theusers and researchers want this kind of language, but the industrial robot manufactures donot. All the references for those languages has, at least, 10 years, but none of them is reallycurrently adopted by the commercial industrial robots. Maybe because of the difficulty foridentifying the needed instructions, or because the industrial robot manufactures are notinterested in adopting any standardization.

However, some of these standardization tries are presented above.

IRL - Industrial Robot Language

Close cooperation between robot manufacturers, robot users, and research institutes gavebirth to a new high level programming language for robots. The national German stan-dardization organization (DIN) published this language in 1993 as a national standardDIN 66312 part 1. The language is independent of any particular robot controller or robotkinematics. [Sal00]

IRL is a high-level language, designed with reference to the Pascal family of languages.It covers facilities for the modularization of programs. It enables the programming of


simple tasks with easy to learn language elements.

RobotScript

Robotic Workspace Technologies (RWT) claims that the RobotScript is the first universalindustrial robot programming language. It is based on the Microsoft interpreted computerlanguage Visual Basic Scripting Edition, or VBScript. The commands are English-like.However, this language can be used only with RWTs Robot Control Solution (RCS inter-prets the RobotScript language to the robot controller). It is necessary to acquire an RWTUniversal Robot Controller (URC), that substitutes the original robot controller. So, tocontrol the robot, it is necessary to develop the industrial robot drivers for the URC. AsURC has an open-architecture, anyone can create these drivers [Tec07b].

This solution transfers the standardization problem from the programming languageto the robot drivers. RoboScript works well, there are some important users like NASA,but to use this language it is necessary to acquire the URC. And to control some industrialrobot, someone has to develop the driver between this robot and URC (which is not asimple task), or an standard driver solution must be created and adopted by the industrialrobots manufactures (that may not be interesting for them).

Other

Many organizations around the world made efforts to standardize programming languagesfor industrial robots, like the German IRDATA, French LME, Japonese SLIM (StandardLanguage for Industrial Manipulators) and ICR (Intermediate Code for Robotics). Theselanguages are aimed for programming robot motions with the correct parametrization (e.g.velocity, acceleration, smoothing), program flow instructions, arithmetic and geometriccalculations, and sensor data processing. They can be seen as a standardization of therobot control. An "assembler-like" intermediate code, that belongs to a lower level thanother industrial robot programming languages [EFK01].

3.3 Industrial Robot Programming Languages: Examples

Some examples of industrial robot programming languages are presented following:

3.3.1 VAL

VAL [Com80] is a computer-based language designed specifically for use with UnimationInc. industrial robots (well known as PUMA robots).

The VAL language consists of monitor commands and program instructions. Themonitor commands are used to prepare the system for execution of user-written programs.

3.3. Industrial Robot Programming Languages: Examples 25

Program instructions provide everything that is necessary to create VAL programs forcontrolling robot actions.

The features of VAL language that influences the programming task are [Com80][Wik07]:

– Control programs are written on the same computer that controls the robot. Itmeans that it is not possible do develop programs in another computer. So, it doesnot allow off-line programming;

– To specify the control flow instructions, numbers are used as labels. So, it is necessaryto assign numbers for the lines that are destines of jumps. Each line must containonly one instruction;

– The existing constants are: integer, real and point;– To indicate a specific location for the robot, it is used point constants. Its syntax is

(X, Y, Z, R, P, Ya), where X, Y and Z matches to the robot translational coordinators;and R, P and Ya matches to the robot rotational coordinators, where R correspondsto the Roll degree, P to the Pitch degree, and Ya to the Yaw degree;

– All the variables are global and it is not necessary to declare them previously, becausedespite using integer and real constants, these are stored on a numeric data type.So, there are only 2 data types:

• numeric data types - that accepts integer and real values;• point data type - that accepts point values.

– There are no distinction between the numeric and point variables identifiers. Asthere is no variable declaration, the user must take care when using each variable;

– To modify the instructions control flow during execution, it is necessary to use jumpinstructions, indicating the label of the target instruction. As it was said before,the label corresponds to a number located in the beginning of the target instruction.The GOTO and IF commands use numbers that act as labels to indicate the nextinstruction to be executed;

– There are two conditional sentences, depending on the condition used:• For conditions that uses channels, like sensors for example, an IFSIG instruction

is necessary, with the following syntax:IFSIG [ch1], [ch2], [ch3], [ch4] THEN line_numberThis instruction only test if a channel is active (bigger than 0) or inactive(equal or smaller than 0). A channel is represented by a positive or negativenumber. When it is positive, the resulting evaluation is true if this channel isactive. When the channel number is negative, the resulting evaluation is trueif it is inactive. It is possible to verify from one to four channels at the sameinstruction, but the three commas are always obligatory. The commas betweenthe described channels works as the logic operator AND;There are 32 input channels, numbered 1001 to 1032, and there are 32 outputchannels, numbered 1 to 32;A SIGNAL command is used to modify an output channel;

• For conditions that uses variables or numbers, a common IF sentence is used.This IF sentence only allows one relational operator (EQ, NE, LT, GT, LE orGE) per IF, and does not allow the use of logic operators.


– The STOP command stops the execution of the program, while the END commandends the execution of the program.

An example of a program can be seen above:

10 ifsig PP1, D2,, then 8020 ifsig PP1, D3,, then 8030 ifsig PP2, D1,, then 17040 ifsig PP2, D3,, then 17050 ifsig PP3, D1,, then 27060 ifsig PP3, D2,, then 27070 goto 1080 closei90 ifsig GC,,, then 110100 goto 90110 move esquerda120 ifsig AP1,,, then 140130 goto 120140 openi150 ifsig GA,,, then 10160 goto 150170 closei180 ifsig D3, GC,, then 210190 ifsig D1, GC,, then 240200 goto 180210 move esquerda220 ifsig AP2,,, then 140230 goto 220240 move direita250 ifsig AP2,,, then 140260 goto 250270 closei280 ifsig GC,,, then 300290 goto 280300 move direita310 ifsig AP3,,, then 140320 goto 310

3.3.2 Melfa Basic III

Melfa Basic III [Com] is the Mitsubishi Movemaster RV-M2 industrial robot programminglanguage. Despite its name indicates that this language could looks like the computer Basiclanguage, it really looks like an assembly language, which makes their programs difficultto read or write. So, to make programs easily, it could be necessary to use the COSIMIRsoftware (a software for off-line programming of Mitsubishi robot systems that allows a


3-D modelling, programming and simulation of production cells), instead of programmingdirectly the robot.

The features of this language that influences the programming task are:

– It is not possible to do programs off-line. There are two ways for programming robotMovemaster RV-M2: by the teach pendant; or by the COSIROP, a software thatmakes a connection between the robot and a computer, allowing its programming;

– All instructions are described with only two letters, which make difficult to read/writeprograms;

– To specify the control flow instructions, it is necessary to number the lines. Eachline must contain only one instruction;

– The numeric constants are: integer, real and point;– To indicate a specific location for the robot, it is used point constants;– It is not used variables. On this language, the program access directly the registers

and counters of the machine;– To modify the instructions control flow during execution, it is necessary to use uncon-

ditional or conditional jumps, indicating the line number of the target instruction;– The GT instruction is used as unconditional jump;– There are conditional jumps, however, there are no IF like sentences. To treat a

condition, the known relational and logical operators are used as commands:• EQ (equal) - causes a jump to occur if the internal register value is equal to the

specified value;• NE (not equal) - causes a jump to occur if the internal register value is not

equal to the specified value;• LG (larger than) - causes a jump to occur if the internal register value is greater

than the specified value;• SM (smaller than) - causes a jump to occur if the internal register value is

smaller than the specified value;• AN (and) - ANDs the internal register value and the specified value;• OR (or) - ORs the internal register value and the specified value;• XO (xor) - Exclusive ORs the internal register value and the specified value;• There are no >= and


3.3.3 VAL II

VAL II [Inc86] evolved from VAL (that was also presented previously). VAL was developedin 1975. In 1978 VAL had been rewritten as VAL II, and was offered commercially withPUMA robots. VAL II is a BASIC like interpreted language. It is also composed of a mixof instructions necessary for robot control and monitor commands.

The features of VAL II language that influence the programming task are:

– Control programs, today, are probably written on the same computer that controlsthe robot. It means that, today, probably it is not possible do develop programsin another computer. It has one possibility for programming it off-line, but is itnecessary to use an very old 8" floppy-disk to transfer the program to this Pumacontroller. So, today, probably is not possible to develop programs off-line;

– To specify the control flow instructions, numbers are used as labels. So, it is necessaryto assign numbers for the lines that are destines of jumps. Each line must containonly one instruction;

– The existing constants are: integer, real and point;– To indicate a specific location for the robot, it is used point constants. Its syntax is

(X, Y, Z, R, P, Ya), where X, Y and Z matches to the robot translational coordinators;and R, P and Ya matches to the robot rotational coordinators, where R correspondsto the Roll degree, P to the Pitch degree, and Ya to the Yaw degree;

– All the variables are global and it is not necessary to declare them previously, becausedespite using integer and real constants, these are stored on a numeric data type.So, there are only 2 data types:

• numeric data types - that accepts integer and real values;• point data type - that accepts point values.

– There are no distinction between the numeric and point variables identifiers. Asthere is no variable declaration, the user must take care when using each variable;

– To modify the instructions control flow during execution, it is necessary to use jumpinstructions, indicating the label of the target instruction. As it was said before,the label corresponds to a number located in the beginning of the target instruction.The GOTO and IF commands use numbers that act as labels to indicate the nextinstruction to be executed;

– There is one conditional sentence that, differently from the first version of VAL,accepts more than one relational operator (==, , , =), separatedby the logic operators. When the condition uses channels, like sensors for example,an SIG command is used to verify if the channel is active (bigger than 0) or inactive(equal or smaller than 0). A channel is represented by a positive or negative number.When it is positive, the resulting evaluation is true if this channel is active. When thechannel number is negative, the resulting evaluation is true if it is inactive. Above,an example of a conditional sentence with the SIG function:

if sig(-1002, 1004) goto 10

– There are 32 input channels, numbered 1001 to 1032, and there are 32 output chan-nels, numbered 1 to 32;


– A SIGNAL command used to modify an output channel, and this command can bewritten as SIG, that is the same name used to evaluate the input signals. To identifythe goal of a SIG command, it is necessary to see the number of the channels (1001to 1032 for input channels, while 1 a 32 for output ones);


– VAL II can run an application command (that controls the robot moving) and calcu-late the I/O values in parallel. It means that it is not necessary to wait the end of amoving command to analyze the I/O channels or to do mathematical calculus. Thismultitasking execution can generate errors, that are not perceived when reading thesource code. For example, in the following fragment of a programMOVE A0IF SIG 1003 GOTO 20the channel 1003 will be analyzed before the end of the moving instruction. But, ifthe 1003 channel is activated only when the robot arrives at the point A0? In thatsituation, the IF sentence will always be false, which is not visible when reading theprogram, because it is not usual to analyze, in an sequential program, a instructionwhile the previous one is not ended. To correct this situation, it is necessary to usethe BREAK command. This command makes the controller wait the end of the lastanalyzed instruction to continue the execution of the program. An example of thiscommand can be seen above:MOVE A0BREAKIF SIG 1003 GOTO 20


10 if sig( PP1) goto 3020 goto 4030 if sig( 1002) goto 20040 if sig( PP1) goto 6050 goto 10060 if sig( 1003) goto 20070 if sig( PP2) goto 9080 goto 10090 if sig( 1001) goto 290100 if sig( PP2) goto 120110 goto 160120 if sig( 1003) goto 290130 if sig( PP3) goto 150140 goto 160150 if sig( 1001) goto 430160 if sig( PP3) goto 180170 goto 190180 if sig( 1002) goto 430190 goto 10


200 closei210 if sig( GC) goto 230220 goto 210230 move esquerda240 if sig( AP1) goto 260250 goto 240260 openi270 if sig( GA) goto 10280 goto 270290 closei300 if sig( 1003) goto 320310 goto 360320 if sig( GC) goto 370330 if sig( 1001) goto 350340 goto 360350 if sig( GC) goto 400360 goto 300370 move esquerda380 if sig( AP2) goto 260390 goto 380400 move direita410 if sig( AP2) goto 260420 goto 410430 closei440 if sig( GC) goto 460450 goto 440460 move direita470 if sig( AP3) goto 260480 goto 470

3.3.4 NACHI SC15F Robot Programming Language

NACHI SC15F robot is general purpose manipulator, made by Nachi-Fujikoshi company.It can be seen on figure 3.1.

It is necessary to store the points where the robot should pass in a file before executingthe program. This action is done by the use of the robot teach box, as described before.

Its programming language is similar to Basic language and its main features are [Cor94]:

– To specify the control flow instructions, it is necessary to number the lines (1 to9999). Each line must contain only one instruction;

– The numeric constants are: integer, real, hexadecimal, binary, and one that expressangles in degrees;

– To indicate a specific location for the robot, it is used point constants. Its syntax is(X, Y, Z, R, P, Ya), where X, Y and Z matches to the robot translational coordinators;


Figure 3.1: NACHI SC15F robot

and R, P and Ya matches to the robot rotational coordinators, where R correspondsto the Roll degree, P to the Pitch degree, and Ya to the Yaw degree;

– Variables have pre-defined names, that depends from the variables data types:• Integer variables format - Vn% or V%[n], where n must be between 1 and 200

(Ex: V1% = 10, V%[2] = 20).• Real variables format - Vn! or V![n] where n must be between 1 and 100 (Ex:

V1! = 10,5, V![2] = 20 * V1!).• Character and string variables format - Vn$ or V$[n], where n must be between

1 and 20 (Ex: V1$ = "ABC", V$[2] = "Z" + V1$).• Point variables format - Pn or P[n], where n must be between 1 and 999 (Ex:

P1 = (100, 0, 100, 0, 0, 90));– To modify the instructions control flow during execution, it is necessary to use labels.

The name of each label must start with the character (*) followed by any othercharacter. The GOTO and IF commands use labels to indicate the next instructionto be executed;



10 USE 120 ACC 030 TOOL 040 V1% = 050 *S151 JMPI 4, I160 IF V1% = 10 THEN *L2X1 ELSE *L2X270 *L2X180 V1% = 090 END100 GOTO *S1110 *L2X2120 V1% = V1% + 1


130 MOVE P, P1, T = 3140 MOVE P, P2, T = 3150 SHIFTA 0, 0, 0, 100160 MOVE P, P3, T = 3170 SHIFTA 0, 0, 0, 0180 GOTO *S1190 MOVE P, P4, T = 3200 MOVE P, P5, T = 3210 MOVE P, P6, T = 3220 GOTO *S1

3.3.5 Rapid

RAPID [Aut] is a powerful programming language used for ABB industrial robots. It isa procedural interpreting language, and syntactically it looks like Basic, C and Pascal.The RAPID interpreter admits multitasking, which means that several RAPID programs,called tasks, can be executed in parallel. Every task consists of one or more modules, whichin turn consist of RAPID instructions. It also handles errors (exceptions) and user traps.

The RAPID language itself is a fairly general purpose programming language. There arepredefined and installed routines, handling the robotic-specific actions (like spot welding,for example), but these are not part of the core language itself.

Its main features for writing programs are:

– It is possible to do programs off-line, which means that, it can be used anothercomputer to develop the programs. If the RobotStudio system is used, it is alsopossible to simulate the robot behavior before executing it on the real robot;

– The numeric constants are integer and real. There are also logical and string ones;– There are 41 data types: the basic ones for computer programming languages, like

numeric, string and boolean; and many other specially created for ABB robot pur-poses, that are records composed by the basic data types. The user can also defineits own records;

– To indicate a specific location for the robot, it is used point constants. As the robotis able to achieve the same position in severa

Documents

Automatization of the Code Generation for Different Industrial … · 2017. 9. 15. · minhas empreitadas e continuam sendo em mais uma, que está começando agora: o início de uma