Linear cluster tool mockup: completing of the ï¬rst link

Where innovation starts

/ Department ofMechanical Engineering

Linear cluster tool mockup:completing of the first link

S.A.M. van der Burgh, H.G.M. Donkers,J. Scholten

Systems Engineering

TU/e Mechanical Engineering

Minor project

Quartile 2 – 2012-2013

Case 4M230

Linear cluster tool mock-up

Completing of the first link

Students:

S.A.M. van der Burgh 0740573 Mechanical engineerH.G.M. Donkers 0674550 Mechanical engineerJ. Scholten 0756173 Electrical engineer

February 8, 2013

Project supervisors:

Dr. ir. J.M. van de Mortel - FronczakIng. H.W.A.M. van RooyF.G.J. Soers

Student assistant:

J. Selen

Summary

The goal of the project 4M230 is to design and realize a mock-up of a linear cluster tool. Acluster tool is used in the semiconductor industry for the production of microchips. Thesemicrochips are processed in batches on a silicon wafer. The production of a wafer consists ofseveral processing steps. Therefore a cluster tool consists of several different modules that eachhave there own specific function. For the mock-up this is simplified to four different modules.The first module is the in/output module, where wafers enter the cluster tool and can exitthe cluster tool after processing. The second type of module is the transport module, whichis located in the middle of the cluster tool so that all surrounding modules can be reached.The third type of module is the process module, this module simulates waiting time thatmatches the processing time that is needed to process a wafer in a real processing machine.The last type of module is the buffer module, here wafers can be stored temporarily, thismodule also acts as a link between two transport modules, this allows a chain of cluster toollinks to be attached to each other. This will create one big cluster tool. The last years linearcluster tools have been designed, where links can be be connected modular. This was notpossible with traditional circular cluster tools. The linear layout exceeds the circular layoutin respect to flexibility and throughput [20] [26] [23]. The advantage of the higher throughputcan be exploited with an intelligent control system, for this reason the mock-up will be usedto test and analyze different control strategies. Apart from control strategies, modules can beswitched mutually, which will impact the efficiency of a control strategy. It should thereforebe possible to switch, remove or add modules to the cluster tool. This is a design criteria forthe mock-up. This report is the second report in a series of two reports [22]. Both reports arebased upon two previous projects of the linear cluster tool mock-up [19] [18] [24] [25]. Thisreport continues where the previous report ended. All modules have been designed and thetransport module and in/output module has been realized and are operational, but have notyet been tested with the last improvements. In this report improved designs on the transportmodule are realized and tested, these designs cover a transmission of the rotation with nobacklash. Also the buffer and process modules are constructed and installed on the clustertool. To control the hardware, software is programmed to support basic maneuvers. Dueto the fact that the biggest components have already been designed, the hardware design ofsmall components will not be discussed in detail. The software design will be discussed indetail. The software is designed and programmed step wise. First a list of criteria is created,which must be met. The next step is to draw the internal processing in more detail, if this isconsistent with the criteria, the programming can begin in TwinCAT. For the testing of themock-up a test set up will be used that measures the important quantities with the help of alaser that measures the distance. These measurements will then be statistically analyzed andthe results will be compared to the criteria that have been stated before. This will eventually

I

allow a proper validation of the mock-up. On the basis of the end product, which is a completelink of the linear cluster tool mock-up with software support for basic maneuvers, a reviewis made to check if the goal is met. At the end of this report a complete link of a clustertool mock-up is realized in hardware along with software that support basic maneuvers. Thisallows the mock-up to pick up a wafer and place it in another module. The axes that aretested satisfied the criteria, only the rotational axis of the transport module has not yet beentested. Further results were very promising.

II

Samenvatting

Het doel van het project 4M230 is het ontwerpen en realiseren van een demonstratie modelvan een lineaire cluster machine. Een cluster machine wordt gebruikt in de halfgeleiderindustrie voor de productie van microchips. Deze microchips worden per batch geproduceerdop een silicium wafer. De productie van deze wafer bestaat uit meerdere stappen. Eencluster machine bestaat daarvoor ook uit meerdere modules met elk een eigen taak. Voorhet demonstratie model is dit versimpeld naar vier verschillende modules. Aller eerst eenin/uitvoer machine, waar de wafers de cluster machine worden ingegeven en na het verwerkenook weer worden uitgenomen. De tweede soort machine is de transport module, die in hetmidden van de cluster machine is geplaatst zodat deze alle modules kan bereiken. De derdesoort machine is een proces module, deze machine simuleert wachttijd die overeenkomt metde echte tijd die nodig is om een wafer the bewerken. De laatste soort machine is een buffermachine, hierin kunnen wafers tijdelijk in worden opgeslagen, ook dienen deze buffers alsdoorgeefluik naar een andere transport module, zodat er een keten van schakels aan elkaarkan worden gezet tot een grote cluster machine. Pas sinds kort zijn lineaire cluster machinesontworpen, waarbij schakels modulair aan elkaar kunnen worden gekoppeld, ten opzichte vande traditionele circulaire cluster machine. De lineaire layout overtreft de circulaire layout alshet gaat om flexibiliteit en doorvoersnelheid [20] [26] [23]. De voordelen van deze groteredoorvoersnelheid kunnen nog meer worden benut met een intelligent besturingssysteem. Omdeze reden zal het demonstratie model ook uiteindelijk gebruikt worden voor het testen enanalyseren van verschillende besturingsstrategieen. Naast de besturingsstrategieen, kunnende modules ook onderling worden verwisseld, wat uiteindelijk ook een impact kan hebben opefficientie. Het moet dus mogelijk zijn modules onderling te verwisselen, te verwijderen oftoe te voegen. Dit is daarom ook een ontwerp eis. Dit verslag is het tweede verslag in eenreeks van twee verslagen [22]. Beide verslagen zijn het gevolg van twee vorige projecten vande lineaire cluster machine [19] [18] [24] [25]. Dit verslag haakt in op waar het vorige verslagis geeindigd. Alle modules zijn namelijk al ontworpen en de transport module en in/uitvoermodule zijn al gebouwd en operationeel, maar nog niet getest naar de laatste aanpassingen.In dit verslag worden de eerder ontworpen aanpassingen aan de transport module gerealiseerden getest, het gaat hierbij om een speling vrije aandrijflijn van de rotatie beweging. Daarnaastworden de buffer en proces module gebouwd en geınstalleerd op de cluster machine. Om debestaande hardware aan te sturen zal er software worden geprogrammeerd dat elementairebewegingen van de hardware kan ondersteunen. Omdat de grootste componenten al zijnontworpen wordt er niet diep ingegaan op het ontwerp proces van de kleine onderdelen.De software daarin tegen wordt met meer diepgang besproken. De software wordt volgenseen bepaalde structuur ontworpen en geprogrammeerd. Eerst wordt er een lijst van eisenopgesteld, waar de software aan moet voldoen. Vervolgens worden er tekeningen gemaakt

III

die de interne werking in meer detail bespreken. Als dit een kloppend geheel is wordt hetuiteindelijk met een standaard norm in TwinCAT geprogrammeerd. Voor het testen zullentest opstellingen worden gebruikt die belangrijke grootheden meten met behulp van lasersensor die de afstand meet. Deze metingen worden dan statistisch geanalyseerd en vergelekenmet de criteria van het ontwerp, om zo uiteindelijk de opstelling te valideren. Aan de hand vanhet eindproduct, een volledige schakel van de cluster machine met software ondersteuning voorelementaire bewegingen, wordt terug gekeken of de gestelde doelen gehaald zijn. Uiteindelijkis een volledige schakel van de cluster machine gerealiseerd in hardware en zijn elementairebewegingen geprogrammeerd. Het is daarmee mogelijk om een wafer op te pakken en teplaatsen in een andere module. De assen die getest zijn voldeden allemaal aan de specificatie,alleen de rotatie van de transport module is niet getest. Verder zijn alle resultaten veelbelovend.

IV

Contents

1 Introduction 11.1 Project objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Design criteria and wishes 52.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Wishes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 The LCT mock-up at start of phase 2 93.1 Mechanical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Electrical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 The transport module 154.1 Construction of previous designs . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 New designs for the transport module . . . . . . . . . . . . . . . . . . . . . . 17

5 The buffer and process module 215.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 The user interface 256.1 Hardware or software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 General layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.4 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.5 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.6 Signal Lights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.7 Panel layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.8 Feedback panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Hardware safety measures 337.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8 Software 378.1 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.2 Programming environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

V

9 Testing 499.1 I/O module - Lift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499.2 Transport module - Manipulator . . . . . . . . . . . . . . . . . . . . . . . . . 519.3 Transport module - Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . 529.4 Transport module - Elevator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

10 Budget 53

11 Conclusion 55

12 Recommendation 57

A Error analysis 63A.1 Mean value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.2 Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.3 Student t parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.4 Error propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.5 Maximum error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

B Patent study of the anti-backlash spring 65B.1 Competitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.2 Number of patents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.3 Patent comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

C Software: Function Blocks and State machines 67C.1 FB I/OModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68C.2 FB TransportModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

D Software extra 119D.1 GetErrorCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119D.2 Initialize all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120D.3 Connecting a variable using TwinCAT IO . . . . . . . . . . . . . . . . . . . . 123

E Tuning the system 125

F OR gate circuit 131

G Wiring codes 133

H Contact information 137

0

Chapter 1

Introduction

This report covers the second phase of the project of the linear cluster tool mock-up. It isa continuation on the previous 4M230 reports [22], [19], [18], [24], [25]. The project of themock-up covers the construction of a demonstration model to the eventual controlling of theend product. The final goal of the project is to have a working link of a linear cluster tool,which has the capability to be attached to other identical links of a linear cluster tool. Thissystem will be used to analyze different control strategies that can be applied on cluster tools.Although this analysis is not part of the project, it does influence certain design choices.

A cluster tool is used to process semiconductor wafers for the fabrication of microelectroniccomponents [13]. The cluster tool is an assembly of several modules with different functions.A typical cluster tool consists of a number of wafer processing modules that are controlledvia a central control system. The layout of the modules is such that a transport module ispresent at the center of the tool, which allows this module to transport the wafers betweenthe surrounding modules for processing. In this case, there are only 4 modules surroundingthe transport module, see Figure 1.1.

Figure 1.1: A schematic layout of the linear cluster tool [1].

The layout of linear cluster tool allows a modular connection of the individual links. This isa feature that separates the linear cluster tool from other cluster tools. In this project onlyone link will be build of this cluster tool.

1

The cluster tool allows the wafer to move in any way through the system, which gives muchflexibility to the process. The wafers enter the cluster tool via an input module and exit thecluster tool via an output module. Once in the system, the wafers are transported by thetransport module to different processing modules and if necessary, placed in a buffer moduleto allow the wafer to be transferred to the next link of the cluster tool.

1.1 Project objective

The objective of this project is to achieve a working link of the linear cluster tool that meetsall its requirements and is capable of preforming basic tasks. This cannot be done in a singlephase, because this assignment is too big. This means that the objective for this phase isdetermined by the status of the project at the beginning of the phase.

At the beginning of this phase, the mock-up tool only had two modules that are presentin hardware. The transport module, and the input/output module, which will be referredto as the I/O module. These modules have been constructed in previous phases of thiscourse [19], [18], [24], [25]. Other parts are designed [22], but not yet constructed, this meansthe hardware design of the mock-up tool is complete, see Figure 1.2.

Figure 1.2: The design of the linear cluster tool.

A cluster tool consists of more than hardware. It consists of four major layers in total, whichare stated below.

• A user interface.

• Software.

• A link of the cluster tool.

2

• Individual modules.

The software consists of several extra internal layers, such as the low level and high levelcontrol. Low level control is the control and process of single inputs and outputs, thatsupport a high level control that defines a function. Apart from these two control levels, thesoftware can consist of a database and a control strategy. The database and control strategiesis beyond the goal of this phase.

The goal of this phase is therefore to assemble the link of the cluster tool and achieve basicsoftware control. This report will discuss each step that is taken to the eventual end product.Starting with identifying the work that is left on the mock-up tool in Chapter 3.

After that the report will discuss the mechanical achievements. This is done for the transportmodule in Chapter 4 and the buffer and process modules in Chapter 5, which are alreadydesigned in previous phases of this project. Followed by a new mechanical design of the userinterface in Chapter 6. These chapters will cover the entire hardware achievements on themock-up tool.

Apart from the hardware achievements, the software needs to be programmed to support therequired basic maneuvers, which is discussed in Chapter 8. When the basic maneuvers areproperly functioning, the hardware and software can be tested, this is discussed in Chapter 9.These tests will provide the data to allow a proper conclusion and recommendation is Chapter11. Of course, this conclusion reflects on the state of the mock-up tool at the beginning ofthis phase which will be discussed in the following chapter.

3

4

Chapter 2

Design criteria and wishes

This project is a continuation of the work done in two previous projects. This project iscurrently in the second phase of the third year, as stated in the introduction. Some globaldesign criteria have already been determined in previous phases of the project. In this projectthese same criteria are used and supplemented with new criteria. The original criteria canbe found in [19, p.9], [24, p.6] and [22, p.5]. Where [19] contains the most important criteria,since this is the first phase of this course and shaped the determination of the rest of theproject.

2.1 Criteria

Given criteria hardware

• One linear cluster has a maximum width of 75 cm, the length should be chosen so thatit will fit in an elevator. A single module has a maximum footprint size of 25 cm x 25cm.

• The mock-up consists of several different modules: an input, an output, several processmodules and a transport module.

• The electrical part of the mock-up should work on a single voltage power supply (witha maximum) of 24VDC (control voltage and power voltage supply should be separated,if possible).

• The modules have to be linkable (mechanically and electrically) and the layout of thesystem should be alterable by adding, interchanging or removing modules.

• The system has to be capable to detect if a wafer is present in a certain module. Thetype of wafer does not have to be recognized in hardware.

• The transport module should be capable of transporting wafers from one module toanother.

• Process modules have to be designed without actually performing the process, so thewafer just waits in the module for the entire process time.

5

• Wafers should never collide.

• Wafers should not be damaged during transport.

• A process or buffer module can hold one wafer at a time.

• A transport module has to be able to serve stations at four discrete positions at 0, 90,180 and 270 degrees.

• The maximum time needed for the transport module to pick and place a wafer over180o is 8 seconds (pick, transport 180o, place).

• The wafer dimensions are 60 ± 0.5 mm.

• Wafers have a thickness of 1 mm.

• The desired general positioning accuracy of wafers inside the mock-up is set to be ± 1mm.

• The buffer module and the process module should be of equal size. As stated before,altering the layout of the mock-up should be possible. For instance, it should be possibleto change any process module shown in 1.1 into a buffer module, which in turn isconnected to a new transport module. That is only possible if both buffer and processmodule have the same dimensions.

• Status updates and error messages should be visible during operation. These updatesand messages are shown by both hardware (LEDs for instance) and software.

Given criteria software

• The software will have to be programmed either in TwinCAT or in CodeSys.

• It should be possible to test the functionality of the system.

• It should be possible to program different process flows for different wafer types. Thesystem should chose the proper flow based on the type of wafer it is transporting.

• The mock-up has to be capable of simulating faults.

New criteria

• Programming the software is done according to the IEC 61131-3 standard as describedby the PLCopen association [12].

2.2 Wishes

Wishes can be used, next to these constraints, to guide the design process further in a certaindirection. In previous phases some wishes were formulated.

6

Wishes determined in previous project phases

• Building costs should be minimized.

• Compressed air should not be used in the mock-up.

• In the mock-up, an aluminum disc should be treated as an actual wafer and thereforethe modules in the mock-up are not allowed to grab or touch the discs at the top.

• The user interface for different modules should be implemented in one general layout.

Now that all the design criteria and wishes have been stated, a global view of the mock-uptool will be given. This will give an overview of all the work that still needs to be done.

7

8

Chapter 3

The LCT mock-up at start of phase2

This chapter covers the state of the system at the beginning of the second phase and enumer-ates the challenges that are still left to complete a link of the linear cluster mock-up tool. Asdescribed in the introduction, previous project phases have already lead to the constructionof the transport and the I/O module. The state of the system in the beginning is importantto determine what still needs to be done, a picture of the design of the mock-up tool can beseen in Figure 1.2.

The mock-up tool has two hardware modules that are present, the transport module and theI/O module. These modules can be seen in Figures 3.1a and 3.1b.

(a) The transport module. (b) The I/O module.

Figure 3.1: The modules at the beginning of phase two.

The other surrounding modules, the buffer module and the process module, only exist inCAD. First the hardware section will be discussed, followed by the software section.

9

3.1 Mechanical

The hardware of the mock-up tool, is the base on which the rest of the software and controlis based on. Therefore it is essential that this part of the mock-up tool is finished first. Moreinformation on the details of the designs can be found in the report of phase 1 [22].

Transport module

The transport module is at the center of the mock-up tool, it transports the wafers frommodule to module. Because the transport module is at the center of the mock-up tool,other modules will be aligned with respect to the transport module, to ensure that eachmodule can interact with its neighbor. The transport module is not fully assembled as canbe seen in Figure 3.1a. The transport module consists of a frame with actuators that allowsthe movement of the module in three degrees of freedom. A tangential movement, a radialmovement and an up and down movement. This allows the transport module to pick up wafersand transport them between other modules. The transport module is nearing its completionand almost all hardware parts are designed in CAD, but not yet constructed or implemented.Only the hardware for the initialization of the actuators needs to be designed from the start.This includes new brackets for the initialization of the rotary movement and a modificationto the brackets of the height sensor and the linear movement. The design and constructionof the parts can be found in chapter 4.

Finishing the hardware

In [22] the design for the improvement of the transport module is discussed. The designimprovements that only need to be constructed are listed below.

• A new motor with encoder for the rotary movement is selected.

• A new constant force spring is selected.

• A new mount for a pulley is designed.

These improvements are not sufficient for the completion of the hardware, therefore someextra designs are made and constructed in this report.

• Bracket for the initialization sensors of the rotary movement.

• Bracket for the sensors of the linear movement.

• Brackets for the height sensors of the up and down movement.

The design and construction of these parts will be discussed in Section 4.2.

Input/output module

The I/O module is positioned at one end of the mock-up tool. In this module, the wafers enterand exit the system. Unlike the transport module, the I/O module only has one movement,an up and down movement. The state of the I/O module at the beginning of phase 2, can

10

be seen in Figure 3.1b. The I/O module is completely finished in hardware. Only the controland the validation of the hardware still need to be done.

Buffer and process modules

The buffer and process modules are basically temporarily storage modules. However, a buffermodule, unlike a pocess module, serves as a connection between two adjecent transport mod-ules. Both type of modules only exist in CAD. The CAD models of the modules can be seenin Figure 3.2a and Figure 3.2b.

(a) The buffer module. (b) The process module.

Figure 3.2: CAD assemblies of the buffer and process modules.

In order to complete these modules, the modules will need to be constructed and aligned withthe transport module. Furthermore, the wafer sensor and the interaction with the transportmodule will need to be tested. Since these modules have no moving parts, any further testsare not necessary.

User interface

The user interface is not part of a module of the mock-up tool. It is a separate set of panelsthat allow the user to interact with the mock-up tool. The design of the user interface is notstarted at the beginning of this phase. However since a user interface is a vital link for a userfriendly system it should be finished by the end this phase. To do so, the user interface mustunder go the stages of concept, design, build, programming and testing.

3.2 Electrical

A large part of the electrical components are already present, in this report the new electricalcomponents will be discussed. These new components will support the actuators and sensorsin their function. The eventual electrical system will consist of a number of components thatare listed below.

11

• Wires that transfer signals and power.

• Safety measures that include an emergency stop and end sensors.

• Soldered circuits that process signals to control the system.

Wiring

The wiring of the LCT is already present for a major part of the system. However, this wiringis very chaotic, which will make it difficult for others to understand. Therefore the wiringneeds to be organized and finished for the new parts. The labels of each individual set ofwires can be found in Appendix G.

Safety measures

In order to prevent the system from breaking down a number of safety measures is needed.These safety measures are present in different parts of the system. There are two types ofsafety measures in this system. The first type of safety measure is placing end sensors forevery moving part. This will prevent the moving parts from moving too far and causing afailure in the system. The idea is that if the sensor state is changed the movement in thatdirection is blocked. The design and implementation of this type of safety measures can beseen in Chapter 7. The second type of safety measure is an emergency kill switch that canbe activated by the operator. This kill switch immediately stops all movement in the system.Further details on the emergency kill switch can be found in 7.

Interfaces

The mock-up tool requires a number of soldered circuits, for two reasons. The first reasonis to process encoder signals for the I/O module and transport module. The design of thisinterface can be found in [22]. There is already one circuit available for the I/O module, butnot yet for the transport module. The second reason is that the system needs an OR-gate toinitialize properly. This OR-gate will overrule the enable signals at the initialization. Moredetails can be found in F.

3.3 Software

Hardware by itself does not do anything. In order for the hardware to preform its function,software is needed. At the beginning of this phase there was almost no software, so this had tobe written completely. The mock-up tool should be able to preform basic actions, like pickingup a wafer and placing it in a different module. To do so, the software has to be constructedinto several layers. In order to write proper software a number of steps are required. Thesesteps are listed below.

• Making a global design of the software, describing the desired behavior.

• Constructing state machines of individual parts, so called function blocks.

12

• Communication between function blocks allowing basic joint maneuvers.

These steps above will all be discussed in more detail in Chapter 8. However, before thesoftware can be made first the hardware parts must be finished. This means that the nextchapters will be about the hardware, starting with the transport module, which is at thecenter of the mock-up tool.

13

14

Chapter 4

The transport module

This chapter covers the work that is done on the transport module. The transport module isfirst designed by a project group in 2009 [19]. This means that a lot of work is already finishedon this module. This chapter will start with assembling and the construction of parts thathave already been designed. After that the design and construction of new parts is discussed.

4.1 Construction of previous designs

In previous reports a number of designs have been made to improve the transport module.More background information on these improvements can be found in [22]. The previousimprovements that are discussed in this section are stated below.

• The new motor with encoder.

• The new pulley mount.

• The new anti-backlash spring.

The new motor with encoder

The first improvement is the rotary motor that is equipped with an encoder. The selection ofthe motor and the encoder can be found in report 4M230, 2012 phase 1 [22]. This improve-ment was needed to increase the performance of the rotary movement to achieve the desiredaccuracy and speed of operation. The motor combination can be seen in Figure 4.1a.

The figure above shows a motor combination consisting of three parts. The first part is therotary encoder with 256 counts per turn, at the back end of the combination. The second partis the 20 W DC motor between the encoder and the gearbox. The final part is the gearboxwith a transmission ratio of 86:1. This entire combination is then slided in the axis seen inFigure 4.1b.

In Figure 4.1b it is clearly shown that the axis has a slot in it, which can be filled with a key.This key is then clamped against the flat surface on the axis of the gearbox, creating a stiffconnection as shown in Figure 4.2.

15

(a) The motor combination. (b) The axis that is attached to the motor.

Figure 4.1: The motor combination and its corresponding axis.

Figure 4.2: The connection between the motor combination and the axis.

The new pulley mount

At the other end of the axis that is attached to the motor combination, a pulley is mounted.This pulley transfers the power of the axis onto a timing belt that powers the main axis. Inthe previous design the attachment of the pulley to the axis was improper and had to beredesigned. Eventually an axial clamping is designed for the pulley. This subsection coversthe assembly of this connection. The axial clamping connection consists of a number ofcomponents that can be seen in Figure 4.3a.

(a) Exploded view of the connection betweenthe pulley and the axis.

(b) The connection between the pulley and theaxis.

Figure 4.3: The process of attaching the pulley to the axis.

The figure above shows a number of components. On the left there are three M3 inbus bolts.These bolts fit through a plate that distributes the force and then through the pulley. Thebolts end up at the axis where the bolts can be tightened. The fully assembled mount of the

16

pulley is shown in Figure 4.3b.

The new anti-backlash spring

The first two constructions have created a stiff and manageable drivetrain for the rotarymotion. However to ensure that the measured position is the same as the actual position, ananti-backlash spring is needed. This spring pulls the backlash into one direction that ensuresthe measured location is reliable.

The realized design consists of a spring that delivers a constant force, which is applied tothe main axis that pulls the system in one direction through the backlash. The finishedconstruction can be seen in Figure 4.4.

Figure 4.4: The eventual hardware implementation of the anti backlash spring.

4.2 New designs for the transport module

With the improvements, the hardware of the transport module is still not compatible withits function. This section covers the final designs that are made to finish the hardware of thetransport module.

The new designs that are needed, have to ensure an initialization procedure. This includesthe parts that are listed below.

• A bracket for the initialization and definition of the safety region for the rotary move-ment.

• A bracket for the initialization and definition of the safety region for the linear move-ment.

These brackets have already had previous versions on the mock-up tool. However the previousversions were found improper. For the linear movement only a minor adjustment was neededin the design, but for the rotary movement the whole concept has changed. Therefore onlythe rotary movement sensor will be discussed.

17

Bracket for the rotary movement

The bracket for the rotary movement must allow the system to initialize and define an areaof safe operation. To do so, first the area of safe operation needs to be defined.

Area of safe operation

The area of safe operation is 360 degrees otherwise the wiring can break. To ensure therotation does not exceed 360 degrees a part of the rotation should not be permitted, that waythe maximum rotation will always stay under 360 degrees. This restriction can be achievedwith the use of a sensor. The rotating disk is not a full circle, one part of the circle is cut undera straight line. This geometrical property can be used to define the area of safe operation.

If a sensor is placed at the outer radius of the disc it can detect where the disc has beencut of. This allows the transport module to prevent it from turning more than 360 degrees.However one sensor can not determine the direction of the rotating disc, this means that asecond sensor is needed to allow the system to know at which end of the area of safe operationit is. See Figure 4.5.

Figure 4.5: The sensor that detects the rotating disc above.

Initialization

To ensure a proper initialization, the sensors must have a repeating accuracy that is withina cycle of the encoder on the motor. This will allow the index signal of the encoder to be atthe same spot every time the system is initialized.

Design

The design of the bracket is determined by the desired position of the sensors and the rest ofthe system. The design consists on a number of aspects listed below.

• Determine the type of sensor.

• Determine the ideal location in the system of the sensor.

• Attachment of the bracket to the frame of the transport module.

18

There were two types of sensors that were immediately favorites, the inductive and capacitivesensors. In this case some left over inductive sensors were already present. This sensor hadto be checked to ensure that the sensor is compatible. The repeating accuracy of the sensoris 0.15 mm [17]. The distance the rotary disc travels at the outer radius between two indexsignals is 0.17 mm. This means that the sensor is compatible for the initialization. Thesesensors are then ideally placed in the middle between two position of the manipulator. Thiswill ensure that both locations are accessible and the margin of error is the same at bothsides. This defines the location of the sensors in respect to the disc. The sensor bracketneeds to be mounted to the frame. These requirements lead to the design that can be seen inFigure 4.6. Figure 4.6 shows the two holes in the top that hold the sensor and the two holes in

Figure 4.6: A CAD design of the bracket for the rotational end sensors.

the bottom where the bracket is fixed onto the frame. In the complete assembly, the bracketlooks as seen in Figure 4.7. The location of the initialization sensor also determines how eachof the four Module positions is labeled. Figure 4.8 shows how each module is labeled. Thislayout is also used within the software. More information about software can be found inChapter 8 and Appendix C. This bracket is the final part that is needed to complete thehardware on the transport module. The hardware of the I/O module was already completedat the start of this phase. Therefore, the buffer and process module are next on the list to becompleted.

19

Figure 4.7: The bracket for the rotational end sensors placed in the transport module.

Figure 4.8: Position labels within the Transport Module.

20

Chapter 5

The buffer and process module

This chapter covers the buffer and process modules. In [22], the design of the buffer andprocess modules is discussed. The state of the buffer and process modules is that the designis completely finished, but the hardware is not yet constructed or validated. The design ofthe buffer module can be seen in Figure 5.1a and the design of the process module can beseen in Figure 5.1b.


Figure 5.1: CAD assemblies of the buffer and process modules.

The design of the buffer and process modules are very much alike. Both modules are meant tostore a wafer, this storage is either meant to simulate waiting in the process module or meantto pass through a wafer between transport modules in the buffer module. This differencein function also explains the difference in the design. The process module only needs to beaccessible from one side and the buffer module needs to be accessible from 2 sides.

21

5.1 Construction

The first step to achieving an operating buffer and process module is the construction. Inorder to construct the buffer and process modules correctly a number of steps have to becarried out that are listed below.

• Assembling the frame.

• Aligning the frame.

• Assembling the wafer container and sensor.

• Attaching the frame to the transport module.

The assembly of the frame is very straightforward. The parts of the frame are already theright size, so aligning of the parts with respect to each other is the biggest challenge. Thealigning of the parts is important so that the transport module can place the wafer withoutproblems.

The aligning is done by carefully placing the parts in the right position with respect to anotherand then force the parts to stay in place with the use of bolts, nuts and clamps. This willensure that the frame is stiff enough to be placed without any parts moving separately.

The assembly of the wafer container is relatively easy. It consists of four parts, a bottomplate, two side plates and an inductive sensor that can be seen in Figure 5.2

Figure 5.2: The wafer container of a buffer module.

22

The frame and the wafer container together form the process or buffer module. The construc-tion of the buffer and process modules can be seen in Figures 5.3a and 5.3b.


Figure 5.3: The buffer and process modules.

These modules still need to be connected to the frame of the transport module. The attach-ment to the transport module is done with brackets that are designed for the profiles thatmake up the frame. In Figure 5.4 these modules are attached to the transport module. Thered circle indicates the location of a process module.

Figure 5.4: The mock-up tool with two process modules, a transport module and I/O module.

With all the modules of the mock-up tool installed, a start can be made with the user interface.This is the final hardware part that is needed in the system.

23

24

Chapter 6

The user interface

This chapter covers the design of the user interface. A user interface is the link between thesystem and the operator. This link consists of two parts, the first part is the informationflow from the system to the operator and the second part is the information flow from theoperator to the system.

A user interface is subject to a number of requirements. These requirements are stated below.

• The user interface must give an accurate display of the global state of the mock-up tooland its modules.

• The user interface must allow the user to enter commands into the system that arerelevant for the operation.

These requirements will allow the user to control the system without having to use TwinCATat every entered command. In order to design a user interface first the general layout will bediscussed, after that a more detailed view of the separate components will be given.

6.1 Hardware or software

A user interface can be made in hardware, but also in software, or a combination of both.However, the user interface of the mock-up tool must be visible and understandable formultiple people at once, since it is a demonstration tool. Therefore a computer screen is notcompatible, since this only allows approximately five people to watch at the same time. Thismeans that the user interface will be visualized in hardware.

6.2 General layout

A user interface can have a number of configurations. This configuration has impact on theuser friendly character of the mock-up tool.

There are two sorts of concepts for the general layout of the user interface. If the entire userinterface is in one location, the system can be controlled from one point. However the clustertool will not always have the same number of links. Therefore it is useful to separate the

25

feedback from every link of the tool. This automatically means that the global control willalso have to be separated. This means that the user interface will consist of a global controlpanel and feedback points on every link of the system.

6.3 Controller

To control the machine it is necessary to have a number of switches and signal lights. Thissection describes which switches and signal light are mandatory for the machine to be ableto operate. This is done by first describing the different states of the complete machine thatare required. After that is described which switches are required to switch between thesedifferent states and finally the signal lights that are required to show the operator in whichstate the machine is.

6.4 Modes

The different Modes are divided in different categories. The categories that are used are op-eration mode, initialization,run mode and error. The categories are described in the differentparagraphs.

Operation mode

The first requirement for the states of the machines is that it should be able to have a manualoperation and an automatic operation. The manual operation is required to test the singleaxes in the machine. The automatic mode is the mode in which the motion is controlled bya prescribed set of motions set by the control theory.

Initialization mode

The system requires an initialization procedure to setup all the axis and sensors. The endsensors of all the axis disable the power to the motors. When the system is in its off stateit is possible that the different axis enable the end sensors. When the switches are enabledit becomes impossible for the system to move out of this position. Therefore it is necessaryto overrule the end sensors with an extra manually operated switch. From this requirementcome all the machine states that have to do with initialization. The first state is the statein which the system is uninitialized. The second state is the state in which the machine isperforming an initialization. In this state it is mandatory that the extra manual switch isenabled, to override the limit switches. The third state is the state in which the machine isinitialized.

• Uninitialized.

• Initializing.

• Initialized.

26

Run mode

The third category is for the run mode of the system. The run mode describes the operationstate of automatic control by the software. The first state is the off state. In this state theautomatic mode is off. The second state is the on state. In this state the automatic modeis operational. The third state is the pause state. This state is used to make small changesduring operation, for example to move a wafer if it is not correctly aligned. The advantageis that the data collected during operation is maintained. The fourth state is the state inwhich the system is shutting down. The system will no longer introduces new wafers into thesystem, it will only place wafers into a I/O module. After all the wafers are placed in I/Omodules the system will proceed to the off state.

• Off.

• On.

• Pause.

• Stopping.

Error

During running the system could get in an error state. In the category error there are twostates. An error state and a not error state.

• No error.

• Error.

6.5 Switches

It is necessary to have a switch to switch between the manual state and the automatic state.It is necessary to have a pushbutton for the initialization. The pushbutton would overrulethe end sensors.There should be three pushbuttons to control the run mode of the system. The first buttonwill start the system, the second button places the system in the pause mode and the thirdbutton will let the system stop.The initialization needs one pushbutton to overrule the end switches during initialization.There is also a pushbutton needed to make the transition possible from the error state to thenon-error state.

6.6 Signal Lights

In principle it is necessary to have a signal light for all the categories to show in which statethe system is. A single signal light has to show four states for the run mode. This is possiblebecause the signal light can also be in four different states. These states are on, off, slowflashing and fast flashing. All the other categories have less state so for these categories it is

27

also possible to show in which state the system is with a single signal light.

6.7 Panel layout

The figure below shows a first layout of the control panel.

Figure 6.1: Layout of the designed panel. Pb refers to a pushbutton, L refers to a light andS refers to a switch.

6.8 Feedback panel

In this section the concepts and design of the feedback panel will be discussed. The feedbackpanel must give a quick and accurate overview of the state of the link. This means that theuser will have to be able to see where what happens at any time. For example, if a error occursin a sensor of the transport module, an error should be visible which will tell the user thatthe error is in the transport module. This quick definition of the state of each module can betricky. It is done via continuous indicator lights which are discussed in the next subsection,which are then be followed by several concepts. Then the final design is discussed.

Type of indicators

The feedback panel consists of a number of indicators that show the global state of the module.There are only three global states that are relevant for the feedback.

• Idle.

• Busy.

• Error.

These three states cover the most important states of a module. If the module is finished andno longer working, the state idle will show that the module is ready to begin another process.If the module is currently busy, the busy state will show that the module is currently notcapable of a new process. The third state will indicate that an error has occurred during theprocessing of the wafer.

28

In order to show correctly which state the module is currently in, three types of signals needto be present. These signals can be distinguished in two ways.

• A difference in the color of the signal.

• A difference in the interval of the signal.

If different colors are selected, a continuous signal can be observed. which means that ateach moment the state of the module can be determined. If an interval is used it becomesdiscontinuous, this is because a flashing signal is a combination of the on signal and the offsignal. This means that an observation of several seconds is needed to accurately determinethe state of a module. It also makes the feedback panel less clear than with different colorsignals. Therefore a continuous color signal is selected for the feedback panel.

Possible concepts

A user interface can be designed in various ways. To come up with a proper design a phase ofconcepts is necessary, to better look into the possibilities. The concepts for the user interfaceare listed below.

• Linking the individual feedback panels to the control panel.

• Attaching the feedback panels to the individual links.

These 2 concepts are very similar to each other. However the concepts are different in thevisual aspect.

Linking the panels into one cluster

It is possible to connect the feedback panels of each link to the control panel to create onecluster that holds all the information of the system. This is shown in Figure 6.2.

Figure 6.2: The complete user interface, by use of connecting several separate panels.

This concept ensures that every signal is in the same place of the system. A downside to thisconcept is that all the buttons in the same place make it harder to distinguish the signalsfrom one another. This is clearly shown in Figure 6.2.

29

Attaching feedback panels to individual links

If each link of the cluster tool is equipped with a feedback panel to the side, it becomes easierto distinguish which signal belongs to which module. However this will lead to a feedbackthat is not in one place. An assembly of the feedback panel that is attached to the processmodule can be seen in Figure 6.3.

Figure 6.3: The complete user interface, with several panels spread for the cluster tool.

The figure above clearly shows that it is easy to distinguish the signals from each other. Thereare now less signals in the same spot, which makes it easier to observe the state the moduleis in.

Selection of concept

The two concepts above both have a drawback in the feedback, as is discussed earlier. There-fore the concept is selected where the drawback can be handled the best. This leads to theselection of having feedback panel at each link of the cluster tool. The division of the feedbackin this way allows the separate overviews to be clear.

Design

The design of the feedback panel starts with selecting the indicators. After that the layoutof the indicators on the panel is determined. This choice is based on aesthetic arguments.

Selection of indicator

The selection of the type of indicator has been discussed earlier in Subsection 6.8. Theindicator is selected on several criteria.

• Number input signals required.

• Realizable in the software.

30

The number of indicator input signals determines the number of digital output channelsneeded. This in turn determines which and how many Beckhoff EtherCAT digitial outputmodules are needed. An indicator has been selected that can be seen in Figure 6.4.

Figure 6.4: The technical drawing of the indicator [7].

This indicator has two LEDs, one with the color green and one with the color red. If boththe green and red LED is active, the color is yellow. This means that one less output signalis needed for each indicator. The control of this indicator can be achieved via two separatesignals.

Panel geometry

The panel geometry is restricted by the dimensions of the process module. This means thatall the indicators have to be within a rectangle of 100 mm by 210 mm.

To ensure good viewing capabilities, the panel is placed under a small incline. This gives agood visibility from both a standing, and a sitting position, see Figure 6.5a.

(a) The CAD design of the feedback panel. (b) The CAD assembly of the feedback panel.

Figure 6.5: The feedback panel

The placing of the indicators is also important for a good visibility and a clear overview.The indicators are mapped as if it is the cluster tool seen from above. This makes it easyto determine which module gives the signal. In case there is still any doubt, labels areadded. The extra space the label requires gives a slightly different offset between vertical andhorizontal distance.

A final thing is to determine how the feedback panel is attached to the frame. To achievea nice finish it is chosen to mount the feedback panel on the inside of the frame. The CADassembly of the feedback panel is shown in Figure 6.5b.

31

32

Chapter 7

Hardware safety measures

The mock-up will be used as a demonstration and testing model, this makes it necessaryto implement a number of safety measures. Chapter 6 already introduced the kill-switch.This kill-switch switches the 24 Volt source to the DC motor controllers. When this buttonis pushed, this will result in a full stop for all DC motors, except the lift in the transportmodule, which is connected to another 24 Volt source. Both software and hardware failurescan cause a system malfunction. To prevent software failures causing damage, hardware safetymeasures are needed, next to this manually operated emergency button. The malfunction thatis considered in this report is a scenario in which a DC motor will run into the end of its track.As an example the lift of the I/O module is used, but the same measures can be applied to therotational and linear movement of the the transport module. Without any safety measuresthe lift in the I/O module could damage some of its parts, for instance its gearbox, if notstopped when it reaches one of its end points. Consequences of movements outside the normalregion of operation are more serious for the rotating movement of the transport module. Thiscan result in damage to the wires connected to the manipulator on the transport module.

7.1 Requirements

The solution should meet the following requirements:

• The solution must block destructive hardware operation, without the help of any soft-ware.

• The solution must preserve the passive breaking provided by the magnetic field in the DCmotor. Therefore, the motor terminals should be short circuited at the right moment.This prevents the lift from falling down when reaching the top sensor.

The following wishes are defined:

• It is useful if the end sensors can be used in an initialization procedure. Therefore themotor should be allowed to move away from an endpoint-sensor, even if this sensor isactivated.

• Initialization also requires that the activation of end sensors is visible in software.

33

7.2 Design

The first question to be answered is the following: should the end sensors switch the motorvoltage directly, or should they just generate a signal, which in turns blocks destructivemovement? There are two reasons suggesting the second alternative is the best of the two.First of all, not all types of sensors are suitable to handle motor currents. For instance, thetransport module uses inductive sensors, which most certainly are not up to this task. In thatcase, extra relays are therefore needed to implement direct switching of motor current. Thesecond reason is that the software cannot see what the switching state is of an end sensorif the motor currents are switched directly. Given these results, it is chosen to let the endsensors switch a signal in stead of motor current.

However, the main goal of the end switches is blocking destructive motor movements. Duringthis project two wiring alternatives that block destructive movement were investigated. Thefirst option is to connect the end switch signals to the enable input of the DC motor controller.Since all motor controllers used in the mock-up have an enable input, this alternative isfeasible. During a previous project [25] this technique was used in the wiring of the endswitches of the manipulator of the transport module.The second solution is shown in Figure 7.1. This solution is based on an assumption that hasto be verified. It assumes that both motor outputs A1 and A2 are kept at 0 Volts, and onlythe voltage of one of them is positive at any instance. A simple test was performed and theassumption was verified, since the voltage between A1 or A2 and the ground turns out to beonly several milli Volts. This wiring scheme ensures that the lift motor is short circuited whenan end sensor is activated. This can be seen when considering the situation in which the liftis moving upwards and activates the top end sensor. Moving upwards means that the voltageat terminal A1 is zero and terminal A2 is positive. Figure 7.1 shows that terminal A2 is cutoff by the top microswitch and the corresponding motor terminal is connected to the 0 Voltterminal of the voltage source. If A2 stays positive, A1 must stay 0 Volt and the DC motor isbreaking on its own internal magnetic field, since both the DC motor terminals see the samevoltage. Furthermore, if the software decides to send the lift downwards, away from the topmicroswitch, it makes A1 high and as a consequence A2 is kept at 0 Volt. In this situationthe DC motor will actively move, since A1 is still connected to the DC motor, and the otherDC motor terminal is kept at 0 Volt independent of the state of the top microswitch. Thewiring of the bottom microswitch is based on the same design, but is connected to the otherDC motor terminal.

To be sure the Beckhoff EL7342 DC motor controller, used to control the lift in the I/O mod-ule, is not damaged using this wiring, the manufacturer was contacted [3]. They replied thatthis wiring schematic could damage the controller, since at the switching moments the currentthrough the DC motor, which is an inductor, is interrupted instantaneously. Equation (7.1)shows the general formula relating voltage and current for an inductor [21, p.468]. L repre-sents the inductance of an inductor in Henry, Vind represents the voltage across the inductorterminals and Iind stands for the current through the indoctor. In general an instantaneouschange results in an infinite derivative. This formula clearly shows that an instantaneouschange in current through an inductor results in an infinitely large voltage across its termi-nals. In reality the voltage across the DC motor will not be infinite, but it could very wellbe large enough to damage the solid state based controller connected to it. An employee of

34

Figure 7.1: Wiring concept that meets the requirements using two relays to switch the motorcurrent.

Beckhoff suggested to use input channel I1 on the controller in Figure 7.1 as an hardwareenable input, which is one of the predefined functions of this input. This function can bechanged by editing the COE-online register of the EL7342 DC motor controller EtherCATterminal.

Vind =dIinddt

· L (7.1)

There exist several possibilities, sometimes called snubbers, to counter act inductive voltagepeaks. Two possible solutions are shown in Figure 7.2. However, Beckhoff insisted on usinga hardware enable input, instead of snubbers. Given these arguments it seems that the bestsolution is to use the hardware enable input of the controllers.

Figure 7.2: Two types of protective circuits as described by Omron [10, p.7].

Implementation

It is common practice to use end switches in the initialization procedure of an incrementalencoder. This is only possible if the end switches are overruled during an initialization pro-cedure. This can be implemented by an extra manual initialization switch. The final wiringschematic is shown in Figure 7.3. The signal labeled Initialization active signal is either 0Volt or 24 Volt and is controlled by the software. This ensures that the end sensors are onlydeactivated during an initialization procedure. After initialization, the software sets the Ini-tialization active signal to 0 Volt and thereby disables the ability of the manually operatedinitialization switch to overrule the end sensor signals. Furthermore, the individual states of

35

the end sensors is also send to the software by two separate signals, labeled Rot Sensor 1 andRot Sensor 2 for the Transport module in Figure 7.3Using OR gates is just one feasible solution. An equally functional circuit might incorporateextra relays. However, OR gates are in general a factor 10 cheaper then relays. ThereforeOR gates are used in this circuit. A design for the implemented OR gate circuit is availablein AppendixThis implementation requires some extra measures. The first measure is that standard ORgates work at a supply voltage of 5 Volt. On the other hand, most input modules bought bythe previous group work with 24 Volt signals. Since damping a signal can be done withoutactive electronics, it is better to let the end switching signals be 24 Volt. The inputs to theOR gates are then scaled down by using simple voltage divider circuits. Fortunately, thehardware enable input of the Beckhoff EL7342 DC motor amplifier accepts signals of 5 Volt,so no amplifiers are needed for the OR gate outputs. The second measure involves the encoderindex signals. Since the inputs on the EL7342 module are now in use as hardware enableinputs, the encoder index signal needs to be connected to a seperate module. The encoderindex signal, however, has an amplitude of 5 Volt and is therefore not suited as input for anEL1104 module, as stated earlier. Fortunately, the Beckhoff EL1124 digital input module canwork with 5 Volt input signals.

Figure 7.3: Wiring concept based on hardware enable, incorporating initialization switch andOR gates.

36

Chapter 8

Software

This chapter covers the design of software applications for the LCT mock-up. First the designconsiderations are discussed. Next, the two feasible Integrated Design Environments (IDE)are compared and a selection is made. The next section covers the actual design. This phaseuses a top down view. To create a subdivision in functionality this section starts with adescription of the desired behavior of the different modules in the mock-up. This is followedby defining outputs for the different module function blocks. Next, the inner workings of eachmodule function block is covered. This way, design and programming are divided into severalsmaller parts and thereby reducing complexity of the total code.

8.1 Design considerations

In [22] four global design criteria were mentioned regarding software. In addition some newcriteria are described.

Previously determined design criteria:

• The software is programmed either in TwinCAT [15] or in CodeSys [4].

• It is possible to test the functionality of the system.

• It is possible to program different process flows for different wafer types. Thesystem should chose the proper flow based on the type of wafer it is transporting.

• The mock-up is capable of simulating faults.

New design criteria:

• Programming is done according to the IEC 61131-3 standard as described by thePLCopen association [12].

The last design criterion, mentioning the IEC 61131-3, requires an introduction. Accordingto the PLCopen website, IEC 61131 is the only global standard for industrial control program-ming. It harmonizes the way people design and operate industrial controls by standardizingthe programming interface. A standard programming interface allows people with differentbackgrounds and skills to create different elements of a program during different stages ofthe software lifecycle: specification, design, implementation, testing, installation and main-

37

tenance [12]. Respecting the rules and programming conventions used in this standard willprobably improve readability of the code and reduce the chance of programming errors.

8.2 Programming environment

As mentioned in the design criteria, software will be written in either the TwinCAT 3 [15]or CoDeSys 3 [4] environment. Both environments implement the IEC 61131-3 standard. Anargument favoring CodeSys 3 is that during a previous project some basic testing scripts werewritten using CoDeSys 3 [25]. On the other hand, since TwinCAT 3 and CoDeSys 3 supportthe same programming languages, scripts that work in one environment are expected to becompatible with the other environment too.However, TwinCAT 3 has two advantages over CoDeSys 3. Firstly, TwinCAT 3 is designedto be accessible for MATLAB, and can make use scripts written in C++. Future users ofthis LCT mock-up might benefit from these extensions, which for instance enables them toanalyze the results of their supervisor design directly in MATLAB. The second advantage isthat all controller hardware is from Beckhoff, which also developed TwinCAT. Put differently,TwinCAT 3 is designed in the first place to be used with EtherCAT modules from Beckhoff. Ingeneral it is favorable to use, if possible, hardware and software from the same manufacturer.Another advantage of TwinCAT 3 over CoDeSys 3 is its license system. Engineering licenses,which are used in this project, are free of charge and are valid for seven days. When expired,they can be renewed by a simple and straightforward procedure. The demo version of CoDeSys3 can only run for an hour, after which it has to be reset. This reset sometimes requires thatthe PC is restarted, which is inconvenient.A possible downside of TwinCAT 3 is that is quite new and therefore might contain bugs.Furthermore, none of the project supervisors have experience using TwinCAT 3, so learninghow to use it might be more challenging.

Based on these arguments TwinCAT 3 is chosen to be the first choice. It has some clearadvantages over CoDeSys 3. In the first week of the second fase, placing breakpoints inTwinCAT 3 code resulted in a fatal error, but after installing an update this issues wereresolved.

8.3 Design

PLC projects in TwinCAT3 are written using one or more of the five interchangeable program-ming languages as described in the IEC 61131-3 standard. Of these five, ST, or StructuredText, will be the main language used throughout this project. Furthermore, the naming ofobjects, variables and instances is done by using the programming conventions as describedin the TwinCAT 3 documentation [15]. In addition to these conventions, every function blockinput variable ends with an I and every function block output variable ends with an O.The behaviour of a PLC project is described by one or more Program Organization Units, orPOU. A POU can be of type Program, Function or Function block. Explanation of differentPOUs can also be found in the TwinCAT 3 documentation.It is useful in ST to describe the different types of modules as function blocks. Since the mock-up is a composition of four different modules (process, buffer, I/O and transport module),

38

it makes sense to define four different function blocks, one for each type. Module functionblocks in the software are individual instances, without any knowledge of other modules inthe mock-up. This is done to minimize the complexity of the function block scripts. However,on a higher level a controller will have to make sure no destructive behavior can occur. Tothis end, the module function blocks should provide the the controller with the necessarysignals to detect potentially damaging movements.

Desired behaviour of the module function blocks

Defining the desired behaviour of the module function blocks is the first step in designingthe software. In this context, users operate on these function blocks, by providing inputsand reading outputs. A user, in this context, is a higher level software based controller. Thefunction block object names, as used throughout the software, are introduced here.

FB IOModule When initialized, the I/O module function block accepts tasks from the user,which consist of a location identifier. Internally, the location identifier is translated intoan absolute position and the cassette lift is moved to this position. The function blockuser receives a signal when the cassette lift has stopped at the commanded position.Furthermore, the function block returns a location identifier to the user, which tellswhich storage location is now reachable for a transport module. It is possible to assigna new task to the function block, while it is already moving. This new task is executedimmediately.

FB TransportModule When initialized, the transport module function block accepts tasksfrom the user. A task consists of two location identifiers. The first identifier tells thetransport module where to pick up a wafer. The second identifier tells where this wafermust be transported to. In contrast with the I/O module, this function cannot receivenew tasks while performing one. Otherwise the transport module might pick up awafer, and suddenly try to pick up a second wafer, which is unwanted behavior. Whileperforming a task, the function block tells the user which task it is performing by meansof two location identifiers. The user receives a signal when the task is finished.During normal operation, the user might want to block movement of the manipulator.This might be the case when the I/O module cassette lift is moving, while the transportmodule wants to pick up a wafer at the I/O module. Therefore, outward movement of themanipulator is only allowed when the user supplies an enable signal for the manipulator.Furthermore, the function block tells the user at all times if its manipulator is retractedand not moving or is moving.

FB ProcessModule A process module can be of a specific type (e.g. deposition, removalprocess, patterning, etc. [14]). When initialized, the process module function blockaccepts tasks from the user, only when a wafer is present in the process module. A taskconsists of a process identifier, which tells which process should be performed on a wafer.The process module should check whether the commanded process can be performed onthis module. If not, it should report an error. While processing, new tasks are ignoredand at meanwhile the function block tells the user which process task it is performing.When the task is finished the user receives a signal. It is not possible to process a wafertwo times, so a new task only starts when the processed wafer is removed and a newwafer is delivered. The function block informs the user at all times if it holds a wafer

39

or not. Its task process output is only valid when a wafer is in the process module.

FB BufferModule The buffer module continuously informs the user of the presence of awafer. When using this function block, extra attention must be paid to the fact thata buffer module is accessible for two different transport modules. Since a buffermoduleis not aware of any other modules, the user must ensure the two manipulators can notcollide.

Module function block inputs and outputs and global behavior

The IEEC 61131-3 standard supports object oriented programming. Therefore, functionblocks can inherit properties from other function blocks. Since module function blocks havesome in and outputs in common, object oriented programming is applicable to these functionblocks. Figure 8.1 shows the UML class diagram of all module function blocks and theirinheritance. The diagram only contains in and outputs to reduce the information density ofthis drawing. More detailed information about each function block, like specific methods orinternal variables, is introduced further on in this chapter.

FB Module This function block consists of in and outputs that are found in every modulefunction block.Every module has an bEnableI input, which acts as a power on switch. Every modulechecks if all its parameters (pointers and specific values) are initialized. All modules areinitialized using a public method called M Init. This method sets the internal variablebInitialized to TRUE. If any module is enabled while its parameters are not initialized(e.g. bInitized == FALSE), it generates an error. Furthermore, in the event of anerror, a reset can be performed on a module by making bResetI TRUE and bEnableIand bExecuteI FALSE.Furthermore, all modules have the following outputs. bStatusO tells if the module isactive and can receive tasks. This output is the normal end result of bEnableI. bErrorOand nErrorIDO report if and which error has occurred in a module.

FB BufferModule This function block is derived from the FB Module.This module has one output, bWaferPresentO, which tells the user that the wafersensor of the buffer module senses a wafer.

FB ActiveModule This function block is derived from FB Module, and forms thebasis for the process, I/O and transport module function block.It has one additional input, bExecuteI, by which the user can tell the functionblock to start a new task. Only rising edges on this input initiate a new task.Two outputs are added in this function block. The first, bBusyO, tells the userthat the function block is performing a task. A module cannot take a new taskwhile it is busy. Rising edges on bInputI are therefore ignored when bBusyO istrue. The other, bDoneO, is true when the function block has finished its last task.

FB TransportModule This function block is derived from FB ActiveModule.It has two addition inputs. The first is stTransportTaskI, which is a struct,consisting of a pick up location identifier and a delivery location identifier.The second is bEnableManipI, which enables the transport module to initiatean outward movement of its manipulator. This enables the user to block de-

40

structive movement.Furthermore, it has three additional outputs. The first is stTransportTaskO,which shows to the user which task the function block is performing whenbBusyO is true. When bDoneO is true, this output represents the last per-formed task. nLocationO is only nonzero if the rotating actuator is standingstill at one of four the predefined positions and in that case it represents whichmodule the manipulator can reach. The last output is bManipRetractedO,which is only true if the manipulator is standing still in its retracted position.These last two outputs enable the user to detect destructive movements.

FB IOModule This function block is derived from FB ActiveModule.it has one additional input, nLocationI, by which the user can tell the functionblock which storage location should be made accessible.nLocationO is the counterpart of nLocationI, and tells the user which stor-age location is made accessible while bBusyO is true. if bDoneO is true itrepresents which storage location is currently accessible. bWaferPresentO isalready described by FB BufferModule.

FB ProcessModule This function block is derived from FB ActiveModule.It has one additional input, stProcessTaskI. This is a struct that describeswhich process type should be perfomed and how long it should be executed.If the demanded process type does not match the process module type, thenthe task is rejected by en error.Two outputs are added, of which stProcessTaskO is the first. It is the coun-terpart of stProcessTaskI. If bBusyO is true it represents which task is beingperformed. If bDoneO is true it represents the last perfomed task. The otheroutput is bWaferPresentO, which is already described.

Figure 8.1: UML class diagram representing the module function blocks and their inheritance.

41

Actuator function block inputs and outputs

Both the transport and I/O module have one or more actuators. A normal user will notsee these actuator function blocks, since they are to be used inside module function blocks.It is of course possible to make one big monolithic state machine for every module, butsubdividing a module into different actuator function blocks results in more compact statemachines, that are easier to design, test and understand. Figure 8.2 shows the differentactuator function blocks and their inheritance. This chapter only treats the statemachine ofthe FB IOModLiftAct function block. A summary of the other function blocks, both modulesand actuators can be found in Appendix C.The functionality of most in and outputs is already discussed when treating the modulefunction blocks. In compliance with the module function blocks, all actuator function blocksneed to be initialized before they can be used. Every actuator function block generates an errorif it is enabled before its parameters are initialized. Furthermore, all outputs that start withbSen represent sensor signals. For consistency, these signals are true if this sensor is activated(senses an object), so all sensors outputs on a function block behave as an NO (normalyopen) sensor. Note that this does not have to correspond to the actual voltage output ofa sensor. For instance, the signal of a normally closed switch will be negated before it isshown on the actuator function block output. The FB TransModLiftAct, which correspondsto the lifting motion of the transport module, has the output bMovingUpO. This output istrue if the transport module lift is moving up, or standing still in upward position. TheFB TransModManipAct, which corresponds to the manipulator of the transport module, hasthe output bMovingOutO. This output is true if the manipulator is moving out, or standingstill in outward position. More detailed information about these different actuators, such asbehavior, internal variables and specific methods is treated further on in this chapter and inAppendix C.

Initialization of parameters and pointers

All function blocks, actuators and modules, use parameters and pointers to specific EtherCATin and outputs. The internal parameters are in general private members of the function blocks,which means that they are invisible outside the function block. Therefor, a public method isneeded to facilitate initialization of the parameters and pointers. This method is M Init andevery function block that has been designed for this project has this method. The method hasone input, which is always a struct. The type of struct differs from function block to functionblock. This struct contains all parameters and pointers, needed to initialize that specificfunction block. Once this method has been run successfully, it sets the internal functionblock variable bInitialized to TRUE.

Error coding

Every module and actuator function block has an error code output called nErrorIDO. Thisoutput is of type UDINT and gives information about the specific condition that caused the er-ror. An error code generating function is implemented to ensure that every function block usesthe same number for the same error type. This function is called GetErrorCode and returns anerror code. The error code is determined by its input, which is an ENUM DUT of error types,

42

Figure 8.2: UML class diagram representing the actuator function blocks and their inheri-tance.

called E ErrorCodes. For instance, enabling an uninitialized function block corresponds toan E ErrorCodes value called Error NotInitialized and GetErrorCode(Error NotInitialized)generates a 1. More information on specific error codes can be found in Appendix D.1.

I/O Module function block

The I/O Module consists of a lift and a wafer sensor, as shown in 8.3. The bWaferPresentOoutput is connected directly to the wafer sensor and the I/O module operates on the liftfunction block.

FB IOModLiftAct

The I/O module function block contains one actuator, which is a lift with ten discrete posi-tions. Its function block representation is shown in Figure 8.3. The corresponding hardwareis an DC motor with an incremental encoder. This DC motor is controlled by an BeckhoffEtherCAT EL7342 DC motor output stage. In TwinCAT 3 such an actuator is implementedas an NC axis which can be controlled using MC function blocks as defined in the IEC 61131-3standard . The behavior of these MC function blocks falls outside the scope of this report,but more information can be found on the PLCOpen website [11] and the TwinCAT 3 in-fosys helpfiles [15]. The following internal variables are located inside the FB IOModLiftActfunction block:

bInitialized BOOL, this variable is TRUE once the public method M Init has been executedand ensures that all pointers and variables are initialized.

43

Figure 8.3: Overview of the function blocks related to the I/O module.

bTaskError BOOL, this variable is TRUE if a user tries to execute an invalid task.

nLocation BYTE, contains the last valid location. The lift is either moving towards thislocation or stopped at this location.

bCalibrated BOOL, is true once the private method M Calibrate has been executed.

afLiftPositions ARRAY[1..10] OF LREAL, contains the positions of the 10 storage positionsof the wafer cassette in millimeter. Needs to be initialized using public method M Init.

fSpeedCalibFast LREAL, fast calibration speed in millimeters per second. Needs to beinitialized using public method M Init.

fSpeedCalibSlow LREAL, slow calibration speed in millimeters per second. Needs to beinitialized using public method M Init.

pbEncoderIndex POINTER TO BOOL, this pointer contains the address of the EtherCATinput to which the physical encoder signal is connected. Needs to be initialized usingpublic method M Init.

pbSenLiftBottom POINTER TO BOOL, this pointer contains the address of the Ether-CAT input to which the physical signal of the bottom end sensor is connected. Needsto be initialized using public method M Init.

pbSenLiftTop POINTER TO BOOL, this pointer contains the address of the EtherCATinput to which the physical signal of the top end sensor is connected. Needs to beinitialized using public method M Init.

44

FB IOModLiftAct behavior and state machine When the PLC program is started,the function block is disabled and all internal pointers are invalid and all MC function blocksare reset. If the bEnableI input is true while bInitialized is false the function block generatesan error, for error codes see D.1. First a higher level program, that uses this function block,has to run the public method M Init to initialize all parameters. After initialization thefunction block is ready to be activated by means of the bEnableI input. When the PLCprogram is started, bCalibrated is FALSE, which means that the NC axis is not calibratedand its exact position is unknown. A private calibration method, called M Calibrate is run ifbEnableI is TRUE and bCalibrated is false. This corresponds to the state Calibrate in Figure8.4 This method calibrates the NC axis and sets bCalibrated to TRUE. Once calibrated theNC axis is activated after which the function block is ready to take tasks. From now on, thisfunction block starts a new task when it detects a rising edge on its bExecuteI input. If thenLocationI input is not an integer between 1 and 10, the function block generates an error.The NC axis and MC function blocks used in the FB IOModLiftAct function block can alsogenerate errors. In that case the function block also generates an error and passes on theerror code of the NC axis or MC function block. Once the bResetI input is true, the functionblock and all its MC function blocks are reset. After successful reset and when bResetI isfalse, the function block gets back in its disabled state, after which it can be enabled using thebEnableI input. This behavior is captured inside the state machine of the FB IOModLiftActfunction block, which is shown in Figure 8.4.

FB IOModLiftAct.M Calibrate behavior and statemachine To reduce the complex-ity of the previously described statemachine, calibration of the FB IOModLiftAct functionblock is specified in a separate private method, called M Calibrate. The calibration proce-dure is as follows: first, if the lift is not at the bottom end sensor, the lift moves down. Oncethe bottom end sensor is activated, the lift moves up again. When the bottom end sensoris deactivated again the lift reduces its speed, but keeps moving until it the encoder indexsignal is true. At that point the NC axis position is set to 0.0 millimeter. Finally the liftmoves to the first storage position. Figure 8.5 shows the state machine corresponding to thisdescription.

45

FB_IOModLiftAct 17-12-2012

when: bExecuteI=TRUE &

0 < nLocationI <= 10 THEN

nLocation := nLocationI;

END_IF

nLocationO:=nLocation

fbMcMoveAbsolute1.position:=afLiftPositions[nLocation]

fbMcMoveAbsolute1.Execute:=TRUE

bBusyO:=fbMcMoveAbsolute1.Busy

bDoneO:=fbMcMoveAbsolute1.Done

fbMcMoveAbsolute2.Execute:=FALSE

Move1

bTaskError:=TRUE

InvalidLocation




ReadyForTask2

when: bExecuteI=FALSE




END_IF


(nLocationI >10 OR nLocationI < 1)




bTaskError:=FALSE

fbMcReset.Execute:=FALSE

bStatusO:=FALSE

bBusyO:=FALSE

bErrorO:=FALSE

bDoneO:=FALSE

fbMcPower.Enable:=FALSE

eCalibrateState:=Begin



fbMcHalt.Execute:=FALSE

Disabled

when: bCalibrated=TRUE AND

bEnableI=TRUE

when: bCalibrated=FALSE AND

bEnableI=TRUE

nErrorIDO:=...

bErrorO:=TRUE



bStatusO:=FALSE


bDoneO:=FALSE

bBusyO:=FALSE

Error

fbMcReset.Execute:=TRUE

bTaskError:=FALSE

Reset

when: bResetI=TRUE

when: McReset.Done=TRUE AND

bResetI=FALSE AND bInitialized=TRUE

bStatusO:=TRUE

Enabled

fbMcPower.Override:=100.0

fbMcPower.Enable_Positive = TRUE

fbMcPower.Enable = TRUE

fbMcPower.Enable_Negative = TRUE

nLocationO:=0

PowerOn

when: fbAxis.Status.Disabled = FALSE

when: McHalt.Done=TRUE

From any state, excluding

Stop, Disabled,InvalidLocation,

Error and Reset, if

bEnableI:=FALSE


Error and Reset, if

fbAxis.Status.Error:=TRUE







Move2




ReadyForTask1

M_Calibrate

Calibrate

McHalt.execute:=TRUE

Stop

when: bInitialized:=FALSE

Figure 8.4: FB IOModLiftAct UML state machine design.

46

Figure 8.5: FB IOModLiftAct.M Calibrate UML state machine design.

47

48

Chapter 9

Testing

Testing of the chosen hardware is the final step in the project. The results of the test definea part of the conclusion if the chosen hardware meets the requirements. In this chapter aredifferent experiments described to check whether the multiple axis meets the requirements.There are three axis that need to be tested for there accuracy. The first axis is the movementof the lift within the I/O module. The second axis is the rotation axis of the transport module.The third axis is the linear axis of the transport module. The tests for these axis discussedin this chapter are in the same order as described as above.

9.1 I/O module - Lift

To completely map out the accuracy of the lift in the I/O module it is necessary to do twotypes of experiments. The first test is to determine the accuracy of the movement and thesecond test is to determine the accuracy of the initialization. These two parts of the movementdetermines the overall accuracy of the lift axis.

Experiment description

The test plan is to let the I/O module move between the height of 10 mm and 100 mm. Theheight is specified as the distance between the base of the lift and the bottom of the lift. Thesequence below describes the loop how it is programmed into the used software.

1. initialize the system.

2. move to the measure position. (100 mm)

3. wait for 2 seconds.

4. move to a lower position. (10 mm)

5. wait for 2 seconds.

6. move back to the measurable position.

7. loop from point 3.

49

During one experiment the lift makes the loop 10 times. After these 10 loops the lift is againcalibrated. The experiment is run 10 times. This type of sequence is chosen to be able tomeasure the accuracy of the position and the accuracy of the calibration during the sameexperiment. The position of the I/O module is measured using a laser distance sensor. [9]The sensor measures the distance between the top of the I/O module and the top of the lift.This is not the same as the height previous described, due to the fact that the laser distancesensor is not placed at the reference height.

Analysis

Every time the lift reaches its position, the laser distance sensor takes 1000 samples to measurethe position. This is done to determine the position accurate. The real position is determinantby averaging these 1000 points. The measured position during each loop is shown in Figure9.1A. The distribution of these 1000 data points is shown in Figure 9.1B. The distributionof the points is of the same magnitude as the accuracy of the used laser distance sensor. [9]Therefor can be concluded that the lift stays stable at its position.

Figure 9.1: Data obtained from the experiments with the lift in the I/O module. (A) Av-erage measured distance during one loop. Calculated over 1000 data points. (B) Calculateddistribution of one position during one loop. More details in Appendix A. Calculated over1000 data points.

The accuracy of the lift can be determined by looking at the distribution of the averagedpositions. The distribution (σ) of these averaged positions is 0.03 mm. So with an certaintyof 99 % the accuracy is 0.09 mm.

Conclusion

The measured position has a accuracy of 0.09 mm. This accuracy is significant lower than theoverall accuracy required by the system,described in Chapter 2, and therefor can be concludedthat the hardware meets the requirement.

50

9.2 Transport module - Manipulator

The experiment done for the manipulator is similar to the experiment done with the lift.The setup stays the same and only the configuration changes so that the movement of themanipulator can be tested.

Experiment description

Analysis

The measured position during each loop is shown in Figure 9.1A. The distribution of these1000 data points is shown in Figure 9.1B.

Figure 9.2: Data obtained from the experiments with the manipulator on the transportmodule. (A) Average measured distance during one loop. Calculated over 1000 data points.(B) Calculated distribution of one position during one loop. More details in Appendix A.Calculated over 1000 data points.

In Figure 9.2A it looks like their are three levels in the measuring data. This phenomenacan be described by the fact that the system is turned off between these levels. Turning offthe system can change the reference voltage for the speed of the manipulator and therebychange the speed of the manipulator. The speed of the manipulator influences how fast themanipulator comes to a stop after the sensor has detected it.

When taken into account these different levels in the measuring data the overall distributionσ is 0.07 mm. So the accuracy with a certainty of 99% is 0.21 mm.

Conclusion

The movement of the manipulator has a accuracy of 0.21 mm. This accuracy is a magnitudelower than the overall accuracy required by the system,described in Chapter 2, and thereforcan be concluded that the hardware meets the requirement.

51

9.3 Transport module - Rotation

One of the choices made during the project was om not to test the accuracy of the rotationaxis. The test could not be done due to a number of delayed parts. The construction in therotation axis is similar to the construction of the lift in the I/O module. Therefor is mostlikely that the accuracy of the rotation axis is of the same magnitude as the one from the lift.This conclusion is not solid and therefor needs to be tested before the mock-up is finalizedcompletely.

9.4 Transport module - Elevator

The movement of the elevator does not require a certain precision. One of the requirementsthat is applied is that the stroke of the elevator should be large enough. This requirement isalready tested. [25]

52

Chapter 10

Budget

Every design and realization project needs to be financed in order to be realized. Therefore,this chapter covers a global indication of the costs of the last two phases. More informationon the suppliers can be found in Appendix H. The product numbers of each part can be foundin the corresponding section that discussed its design. Most of these parts are designed inphase one of this project [22]. At the end all the components and workhours add up to atotal that is shown in Table 10.1.

Table 10.1: The cost of per supplier, with indication of the type of parts that are supplied.

Supplier Components Price

Maxon Motor + Gear + Encoder e505.05 incl.Hepco profiles, brackets and miscellaneous e 275.20 incl.Turck 4x inductive sensors e 154.40 incl.Amatec constant force springs e 28.50 incl.Farnell electrical components and indicators e116.25 incl.Brammer bearings e 107.46 incl.Koppe clamp, drive belt, pulley e 20.83 incl.Baco Buttons and lamps e 93.09 incl.Beckhoff New ethercat termincals e 93.17 incl.EPC work hours and material e 918.00 incl.

total e 2.311.95

53

54

Chapter 11

Conclusion

The final Goal of the project is to design and create a working link of a linear cluster toolmock-up, which can be used by others to conduct analysis on different control strategies.However the goal of this phase was to assemble a link of the mock- up and achieve basicsoftware control. To do so, first the work that needed to be done was defined, which is basedupon the unfinished work on the mock-up. The achievements for this phase can best besummarized for each separate module.

• Transport module:

– Installing the designs that are discussed in the previous phase of this course [22].Including a DC motor, a pulley mount and a backlash spring.

– Sensor brackets for the rotation, linear motion, lifting motion and controlling com-ponents are either designed or improved and constructed.

– Software scripts to support all basic maneuvers needed to transport the wafer.

• I/O module:

– Software scripts to support the lifting motion that allows the module to presenteach wafer to the transport module.

• Process and buffer modules:

– Realized three process modules and one buffer module in hardware.

• User interface:

– Designed with CAD and components ordered.

The complete link of the realized linear cluster tool mock-up can be seen in Figure 11.1. Thefigure only shows hardware, in a movie enclosed in a cd that is enclosed with the report canbe seen that the software is functional.

Furthermore, tests on many components have been conducted. These tests cover the liftingmotion of the I/O module and the linear motion of the transport motion. The componentsthat have not been tested were subject to elementary checks. The result of these tests wereanalyzed and compared to the required accuracy of 1 mm. The lift of the I/O module has anaccuracy of 0.09 mm and the manipulator of the transport module has an accuracy of 0.21

55

Figure 11.1: The linear cluster tool mock-up.

mm. These values are small compared to the required value, but the error can propagatethrough the work cycle since every wafer gets transported several times. The values found inthe tests confirm that the system meets its criteria.

56

Chapter 12

Recommendation

The mock-up tool is not entirely finished, some improvements and further steps are neededto complete a mock-up tool that can be used for control strategy analysis.

This includes assembling the user interface. All the components are present and the CADassemblies are available to indicate the way it needs to be assembled. The user interface alsoneeds to be incorporated in the software. For the feedback panel there are software variablesalready present that can function as the input for the indicators, for the operator panel a lotmore programming needs to be done to make the system smooth.

However the mock-up tool needs to keep track of each wafer and their progress in the simulatedproduction. This requires a database that is updated for each wafer and process step. Thisdatabase needs complete state machines of every module, which are not yet present for thebuffer module or process modules. On base of the database information, higher level controlcan be used to create an autonomous processing of a wafer with the help of interacting functionblocks that decide on information from the database.

The rotational motion of the transport module still needs to be tested to validate the modulecompletely. After this validation the controls of each actuator can be fine tuned to increasethe speed of operation. During the software test of the transport module, it became clearthat the initialization of the rotational movement is not accurate. During the initializationThe index signal is very close to the position where the end sensors are located. The bracketthat supports the sensors is not sufficient and can move by a few millimeter, if work is doneon the LCT. Therefore it is important to redesign this bracket in a way that the sensors andthe bracket cannot move with respect to the rotational disc and the frame.

57

58

Evaluation

In this section the evaluation of the two phases is discussed by the members of the group.The first thing that was noticed by the group is that the project already had two previousgroups, which each realized a single module. This was very hard in the beginning, sincethe loose ends of the previous two groups had to be finished. This was time consuming andsomewhat annoying, but very useful. The immediate evaluation of an existing design, provedto be useful in the coming design process. This was the first learning moment, which thewhole project was full of.

The project of the linear cluster tool mock-up is the most versatile project, which helps thestudents to gain a very complete view of how the process of designing works in practice.Therefore this project educates the members of the group to be engineers better then in otherprojects of the same minor.

The formation of a group that lasted for two phases was well received within the group.Especially the presentation and report, that needed to be handed in right in the middle ofthe project, helped the group to keep the performance high. This is due to the fact that itfelt like a new beginning.

However due to the versatility of this project. The review in the presentation was hard. Wheremost groups only have one component to discuss, the mock-up group had several componentsto discuss. It was hard to get a good presentation, which in turn led to an unfair criticism.This is the biggest downside that was experienced by the group. To conclude the evaluation,the group advises other students to participate in the same project, because of its versatility.

59

60

Bibliography

[1] 4m230 minorproject se, design and realization of a linear cluster tool mock-up. https:

//ai5.wtb.tue.nl/doccontent/semesterinfoW/default.php?id=525.

[2] Beckhoff el7342 dc motor controller documentation. http://www.beckhoff.com/

english.asp?ethercat/el7342.htm.

[3] beckhoff website. http://www.beckhof.com/.

[4] Codesys 3 website. http://www.codesys.com/the-system.html.

[5] Error analsis. http://teacher.nsrl.rochester.edu/phy_labs/AppendixB/

AppendixB.html.

[6] espacenet, site for patents. http://www.espacenet.com.

[7] Farnell. http://nl.farnell.com/.

[8] The good gain method for pi(d) controller tuning, finn haugen, techteach, 19july 2010. http://techteach.no/publications/articles/good_gain_method/good_

gain_method.pdf.

[9] Manual laser distance sensor baumer oadm12. http://www.baumer.com.

[10] Omron microswitch technical data. http://downloads.components.omron.eu/OCB/

Products/Switches/Microswitches/Technical/Micro.pdf.

[11] Plcopen tc2 motion control website. http://www.plcopen.org/pages/tc2_motion_

control/.

[12] Plcopen website. http://www.plcopen.org/.

[13] Semiconductor cluster tools information. http://beta.globalspec.com/learnmore/

manufacturing_process_equipment/vacuum_equipment/thin_film_equipment/

semiconductor_process_systems_cluster_tools.

[14] Semiconductor device fabrication. http://en.wikipedia.org/wiki/Semiconductor_

device_fabrication.

[15] Twincat 3 documentation website. http://xcat3.infosys.beckhoff.com/.

[16] Student t parameter table. http://statstutorstl.blogspot.nl/2010/07/t-table.

html, 2010.

[17] contrinex. Data sheet inductive proximity switch DW-A.-50.-M8.

[18] T. Derksen, F. Elich, J. Selen, and M. Wijnhoven. Minor design for mechanical systems

61

4m230 - design and realization of a linear cluster tool mock-up, phase 2. Bachelor projectreport, TU/e, Department of Mechanical Engineering, The Systems Engineering group,2009/2010.

[19] T. Derksen, F. Elich, J. Selen, and M. Wijnhoven. Minor design for mechanical systems:Design and realiazation of a linear cluster tool mock-up, phase 1. Bachelor projectreport, TU/e, Department of Mechanical Engineering, The Systems Engineering group,2009/2010.

[20] K. Park and J. R. Morrison. Cluster tool design comparisons via simulation. 2011.

[21] R. D. Russel L. Meade. Foundation of electronic circuits and devices. 2003.

[22] S. van der Burgh, H. Donkers, and J. Scholten. Minor project 4m230, linear cluster toolmock-up, phase 1. Bachelor project report, TU/e, Department of Mechanical Engineer-ing, The Systems Engineering group, 2012/2013.

[23] P. van der Meulen. Linear semiconductor manufacturing logistics and the impact oncycle time. In Proc. 18th Ann. IEEE/SEMI Adv. Semiconduct. Manuf. Conf., 2007.

[24] B. van Hedel, K. Meeusen, J. van Pinxteren, and T. Zwijgers. Minor project 4m230,linear cluster tool mock-up, phase 1. Bachelor project report, TU/e, Department ofMechanical Engineering, The Systems Engineering group, 2011/2012.

[25] B. van Hedel, K. Meeusen, J. van Pinxteren, and T. Zwijgers. Minor project 4m230,linear cluster tool mock-up, phase 2. Bachelor project report, TU/e, Department ofMechanical Engineering, The Systems Engineering group, 2011/2012.

[26] S. D. M. Z. Yi, J. and P. van der Meulen. Throughput analysis of linear cluster tools. InProceeding of the 3rd IEEE Conference on Austomation Science and Engineering, 2007.

62

Appendix A

Error analysis

This appendix covers the error analysis that is used to determine the accuracy of the ex-periments. The error analysis uses mathematical function to determine the mean value, thestandard deviation and the maximum error [5].

A.1 Mean value

The mean value of a set of data is the average value of all the data points. It is calculated byadding all the data points and then dividing it by the number of data points as can be seenin Equation (A.1).

x =1

N

N∑i=1

xi (A.1)

Where x is the mean value over all the data points and N is the number of data points andxi is the value of an individual data point.

A.2 Deviation

The deviation is the a value for the difference between the mean value and the measure points.The deviation is therefore an indication for the accuracy of a mean value. The formula forcalculating the deviation can be seen in Equation (A.2).

σ =

√√√√ 1

N

N∑i=1

(x1 − x)2 (A.2)

Where σ is the standard deviation of the data points in respect to the mean value.

63

A.3 Student t parameter

The standard deviation always has to be corrected via a student t parameter, because thenumber of measurements is always finite. This parameter is needed to correct the mistake thatis made with a finite number of measurement points. This student t parameter is multipliedwith the measured deviation to form an adjusted usable deviation. See Equation (A.3)

∆x = σ tv (A.3)

Where ∆x is the adjusted deviation and tv is the student t parameter [16]. The student tparameter varies with the number of datapoints and the accuracy that is desired.

A.4 Error propagation

If the measured value is only part of the system. The error can propagate via a partialdifferential formula of the total system. This means that the relation between measured valueand the error in the value that is depended on the measured value does not have to be linear.The calculation of such an error propagation can be seen in Equation (A.4).

∆z =

√(δz

δx)2∆x2 + (

δz

δy)2∆y2 (A.4)

Where ( δzδx) represents the partial differentiation of the total value z over x.

A.5 Maximum error

The maximum error of an error analysis is a value that is checked to ensure that the er-ror analysis is valid. It is a check that the maximum measured error does not exceed thespecifications, see Equation (A.5).

∆xmax =xmax− xmin

2(A.5)

64

Appendix B

Patent study of the anti-backlashspring

The transport module is equipped with a spring that counters the backlash. This springpulls the system into one end of the backlash, effectively negating the negative effect of thebacklash. However this concept has already been used in practice many times over. Thereforea patent study is required to see if the concept is valid for use.

B.1 Competitors

The competitors for the patents are the manufacturers who either hold the patent or wantto make use of the capability of the patent. In the case of backlash, a lot of competitors arepresent. Every industry branch that requires high precision will need a minimum amountof backlash. Patents on this subject are widely spread through the machine tool industry.Although there is no pattern to see who is the biggest steak holder in this patent branch, themajority of the patents of this type originate from Chinese industry.

B.2 Number of patents

The number of patents in this particular case are high. This is because the same baseprinciples can be achieved in many various ways. Many patents therefore seem alike, butare different on a small aspect. Either in an extra extension of the patent or in a differentinterpretation. In most cases the patents are valid for 20 years after the enforcement of thepatent. In the case of anti-backlash concepts, the patents are often not more than six yearsold. This is because the precision branch is expanding rapidly the last few years.

B.3 Patent comparison

Due to the sheer amount of patents, two patents were selected for the comparison. Thesepatents were the JP 2006112528 and the JP2 005076691 [6]. The first patent is about the

65

countering of backlash in a gear system, as can be seen schematically in Figure B.1a. Thesecond patent is about countering the backlash in a door hinge. as seen in Figure B.1b.

(a) The gear patent (b) the door patent

Figure B.1: The schematic figures concerning both patents that are compared.

Both patents make use of a spring to exert the force on the system that is to be free ofbacklash, this is also the case in the transport module. However the design of the spring inpatents and in the transport module is very different, the design of the spring in the transportmodule can be seen in Figure B.2.

Figure B.2: A view of the actual used spring in the transport module

Even though the patents are international and still valid. The patents are not in conflict withthe design in the transport module, since the designs are very different and the project ispurely meant for demonstration and education purposes. Which will not be a disadvantageto any of the patent holders. Therefore the patents cannot cause any problem for the project.

66

Appendix C

Software: Function Blocks andState machines

This appendix contains all designs and ST (structured text) PLC (programmable logic con-troller) scripts used to control the movements of the Transport and I/O module. The Twin-CAT 3 project LCT mockup 4M230.sln contains all these scripts, located under the PLC tabas shown in figure C.1. Furthermore, during this project some test scripts have been written.These test scripts have been omitted in this report to reduce the number of pages in thisreport. The following test scripts are available in this TwinCAT 3 project:

• Transport module basic task test.

• Transport module bEnableI functioning test.

• Transport module lift actuator functioning test.

• Transport module manipulator actuator functioning test.

• Transport module manipulator actuator bEnableI functioning test.

• Transport module rotation accuracy test.

• I/O module lift actuator accuracy test.

• I/O module lift actuator initialization accuracy test.

• I/O module lift actuator variable initialization error test.

• I/O module lift actuator bEnableI functioning test.

• I/O module lift actuator task error test.

For every function block its layout is shown, then its internal statemachine design is shownand finally the ST scripts for associated with the function block is shown. The states in everystatemachine drawing are colored red, blue or green. Red states and transitions are relatedto error handling, blue states and arrows are related to normal enabling, calibration anddisabling events. Finally, green states and arrows are related to normal operation. The firstsection of this appendix covers the I/O module, while the second section covers the Transportmodule.

67

Figure C.1: The PLC part in the TwinCAT 3 project for the LCT 1 link mock-up

C.1 FB I/OModule

(a) FB for the I/O module. (b) FB for the I/O module Lift.

Figure C.2

68

POU: FB_IOModule

LCT_mockup_4M230.projectPage 1 of 1

5-2-2013 19:13

1 //name: FB_IOModule2 //Version: 1.43 //Date: 09-01-2013, Joni Scholten4 //This Function block is not yet drawn in 5 FUNCTION_BLOCK FB_IOModule EXTENDS FB_ActiveModule6 VAR_INPUT7 nLocationI : BYTE ;

//The commanded discrete position. Internally this integer is translated into a precise movement. Initialization must be completed upfront8 END_VAR9 VAR_OUTPUT10 nLocationO : BYTE ;

//discrete position to which the actuator is moving if bBusyO = TRUE, and has reached if bDoneO=TRUE;11 bWaferPresentO : BOOL ;

//indicates that a wafer is present in the buffer module12 END_VAR13 VAR14 //local variables1516 //pointers17 pbWaferSensor : POINTER TO BOOL ;1819 //actuator function blocks20 fbIOModLiftAct : FB_IOModLiftAct ;21 END_VAR22

1 //update function block nputs2 fbIOModLiftAct . bEnableI := bEnableI ;3 fbIOModLiftAct . bExecuteI := bExecuteI ;4 fbIOModLiftAct . bResetI := bResetI ;5 fbIOModLiftAct . nLocationI := nLocationI ;67 //Run actuator function blocks8 A_RunActuatorFB ( ) ;910 //update outputs11 bStatusO := fbIOModLiftAct . bStatusO ;12 bBusyO := fbIOModLiftAct . bBusyO ;13 bDoneO := fbIOModLiftAct . bDoneO ;14 bErrorO := fbIOModLiftAct . bErrorO ;15 nErrorIDO := fbIOModLiftAct . nErrorIDO ;16 nLocationO := fbIOModLiftAct . nLocationO ;1718 bWaferPresentO := pbWaferSensor ^ ;19

FB_IOModLiftAct 17-12-2012




END_IF







Move1

bTaskError:=TRUE

InvalidLocation




ReadyForTask2





END_IF






bTaskError:=FALSE


bStatusO:=FALSE

bBusyO:=FALSE

bErrorO:=FALSE

bDoneO:=FALSE






Disabled


bEnableI=TRUE


bEnableI=TRUE

nErrorIDO:=...

bErrorO:=TRUE



bStatusO:=FALSE


bDoneO:=FALSE

bBusyO:=FALSE

Error


bTaskError:=FALSE

Reset

when: bResetI=TRUE



bStatusO:=TRUE

Enabled





nLocationO:=0

PowerOn





Error and Reset, if

bEnableI:=FALSE


Error and Reset, if








Move2




ReadyForTask1

M_Calibrate

Calibrate


Stop


Figure C.3: State machine of the I/O module Lift.

70

Figure C.4: State machine of the I/O module Lift calibration procedure.

71

POU: FB_IOModLiftAct


5-2-2013 12:41

1 //name: FB_IOModLiftAct2 //Version: 1.43 //Date: 15-01-2013, Joni Scholten45 FUNCTION_BLOCK FB_IOModLiftAct EXTENDS FB_EncoderAct6 VAR_INPUT7 END_VAR8 VAR_OUTPUT9 bSenLiftTopO : BOOL ;10 bSenLiftBottomO : BOOL ;11 END_VAR12 VAR13 //MC function blocks14 fbMcMoveAbsolute2 : MC_MoveAbsolute ;

//Extra function block, needed to change task while moving1516 //Statemachine States17 eState : E_FB_IOModLiftActStates ;18 emCalibrateState : E_M_FB_EncActCalibrateStates ;1920 //Internal variables21 afLiftPositions : ARRAY [ 1 .. 10 ] OF LREAL ;

//contains the relative position of the 10 storage positions of the wafer cassette2223 //POINTERS24 pbSenLiftBottom : POINTER TO BOOL ;25 pbSenLiftTop : POINTER TO BOOL ;26 END_VAR27

1 fbAxis . ReadStatus ( ) ; //Read the current status of the IO lift axis23 CASE eState OF4 eIOLiftState_Reset :

//Start state, reset all MC function blocks, to cancel errors from previous runs5 //outputs6 bStatusO := FALSE ;7 bBusyO := FALSE ;8 bDoneO := FALSE ;9 bErrorO := FALSE ;10 nErrorIDO := 0 ;11 //Internal variables12 bTaskError := FALSE ;13 //MC function block settings14 fbMcPower . Enable := FALSE ;15 fbMcReset . Execute := TRUE ;16 fbMcMoveAbsolute1 . Execute := FALSE ;17 fbMcMoveAbsolute2 . Execute := FALSE ;18 IF NOT bInitialized THEN19 eState := eIOLiftState_Error ;20 ELSIF fbMcReset . Done AND NOT bResetI AND bInitialized THEN21 eState := eIOLiftState_Disabled ;22 END_IF2324 eIOLiftState_Stop :

//Stop all MC function blocks using MC halt, otherwise an error might occur.



5-2-2013 12:41

25 //MC function block settings26 fbMcHalt . Execute := TRUE ;27 //determine next state28 IF fbMcHalt . Done THEN29 eState := eIOLiftState_Disabled ;30 END_IF3132 eIOLiftState_Disabled :

//Marker state, nothing moves, nothing is enabled33 //Outputs34 bStatusO := FALSE ;35 bBusyO := FALSE ;36 bDoneO := FALSE ;37 bErrorO := FALSE ;38 //Internal variables39 bTaskError := FALSE ;40 emCalibrateState := eEncActCalibState_Begin ;

//Reset M_Calibrate statemachine41 //MC function block settings42 fbMcReset . Execute := FALSE ;43 fbMcPower . Enable := FALSE ;44 fbMcMoveAbsolute1 . Execute := FALSE ;45 fbMcMoveAbsolute2 . Execute := FALSE ;46 fbMcHalt . Execute := FALSE ;47 //Determine next state48 IF NOT bCalibrated AND bEnableI THEN49 eState := eIOLiftState_Calibrate ;50 ELSIF bCalibrated AND bEnableI THEN51 eState := eIOLiftState_PowerOn ;52 END_IF5354 eIOLiftState_Calibrate :

//call M_Calibrate method to perform calibration55 //Outputs56 bStatusO := FALSE ;57 bBusyO := FALSE ;58 bDoneO := FALSE ;59 bErrorO := FALSE ;60 //Internal variables61 //Run calibration method M_Calibrate62 M_Calibrate ( ) ;63 //Determine next state64 IF bCalibrated AND bEnableI THEN65 eState := eIOLiftState_PowerOn ;66 END_IF6768 eIOLiftState_PowerOn :69 //Outputs70 bStatusO := FALSE ;71 bBusyO := FALSE ;72 bDoneO := FALSE ;73 bErrorO := FALSE ;74 //Internal variables75 //MC function block settings76 fbMcPower . Enable := TRUE ;77 fbMcPower . Override := 100.0 ;



5-2-2013 12:41

78 fbMcPower . Enable_Negative := TRUE ;79 fbMcPower . Enable_Positive := TRUE ;80 fbMcMoveAbsolute1 . Execute := FALSE ;81 fbMcMoveAbsolute2 . Execute := FALSE ;82 //nLocation:=0;83 nLocationO := 0 ;84 //Determine next state85 IF NOT fbAxis . Status . Disabled THEN86 eState := eIOLiftState_Enabled ;87 END_IF8889 eIOLiftState_Enabled :90 //outputs91 bStatusO := TRUE ;92 bBusyO := FALSE ;93 bDoneO := FALSE ;94 bErrorO := FALSE ;95 //Internal variables96 //MC function block settings97 fbMcMoveAbsolute1 . Execute := FALSE ;98 fbMcMoveAbsolute2 . Execute := FALSE ;99 //determine next state100 IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN101 nLocation := nLocationI ;102 eState := eIOLiftState_Move1 ;103 ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN104 eState := eIOLiftState_InvalidLocation ;105 END_IF106107 eIOLiftState_Move1 :108 //Outputs109 bStatusO := TRUE ;110 bBusyO := fbMcMoveAbsolute1 . Busy ;111 bDoneO := fbMcMoveAbsolute1 . Done ;112 bErrorO := FALSE ;113 //Internal variables114 nLocationO := nLocation ;115 //MC function block settings116 fbMcMoveAbsolute1 . Execute := TRUE ;117 fbMcMoveAbsolute1 . Position := afLiftPositions [ nLocation ] ;118 fbMcMoveAbsolute2 . Execute := FALSE ;119 //Determine next state120 IF NOT bExecuteI THEN121 eState := eIOLiftState_ReadyForTask2 ;122 END_IF123124 eIOLiftState_ReadyForTask2 :125 //Outputs126 bStatusO := TRUE ;127 bBusyO := fbMcMoveAbsolute1 . Busy ;128 bDoneO := fbMcMoveAbsolute1 . Done ;129 bErrorO := FALSE ;130 //Internal variables131 //MC function block settings132 fbMcMoveAbsolute1 . Execute := TRUE ;133 fbMcMoveAbsolute2 . Execute := FALSE ;



5-2-2013 12:41

134 //Determine next state135 IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN136 nLocation := nLocationI ;137 eState := eIOLiftState_Move2 ;138 ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN139 eState := eIOLiftState_InvalidLocation ;140 END_IF141142 eIOLiftState_Move2 :143 //Outputs144 bStatusO := TRUE ;145 bBusyO := fbMcMoveAbsolute2 . Busy ;146 bDoneO := fbMcMoveAbsolute2 . Done ;147 bErrorO := FALSE ;148 //Internal variables149 nLocationO := nLocation ;150 //MC function block settings151 fbMcMoveAbsolute1 . Execute := FALSE ;152 fbMcMoveAbsolute2 . Execute := TRUE ;153 fbMcMoveAbsolute2 . Position := afLiftPositions [ nLocation ] ;154 //Determine next state155 IF NOT bExecuteI THEN156 eState := eIOLiftState_ReadyForTask1 ;157 END_IF158159 eIOLiftState_ReadyForTask1 :160 //Outputs161 bStatusO := TRUE ;162 bBusyO := fbMcMoveAbsolute2 . Busy ;163 bDoneO := fbMcMoveAbsolute2 . Done ;164 bErrorO := FALSE ;165 //Internal variables166 //MC function block settings167 fbMcMoveAbsolute1 . Execute := FALSE ;168 fbMcMoveAbsolute2 . Execute := TRUE ;169 //determine next state170 IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN171 nLocation := nLocationI ;172 eState := eIOLiftState_Move1 ;173 ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN174 eState := eIOLiftState_InvalidLocation ;175 END_IF176177 eIOLiftState_InvalidLocation :178 //internal variables179 bTaskError := TRUE ;180 //MC function block settings181 fbMcMoveAbsolute1 . Execute := FALSE ;182 fbMcMoveAbsolute2 . Execute := FALSE ;183 //next state184 eState := eIOLiftState_Error ;185186 eIOLiftState_Error :187 //outputs188 bStatusO := FALSE ;189 bBusyO := FALSE ;



5-2-2013 12:42

190 bDoneO := FALSE ;191 bErrorO := TRUE ;192 //Internal variables193 //MC function block settings194 fbMcPower . Enable := FALSE ;195 fbMcMoveAbsolute1 . Execute := FALSE ;196 fbMcMoveAbsolute2 . Execute := FALSE ;197 //Determine errorcode198 IF fbAxis . Status . Error THEN199 nErrorIDO := fbAxis . Status . ErrorID ;200 ELSIF fbMcPower . Error THEN201 nErrorIDO := fbMcPower . ErrorID ;202 ELSIF fbMcReset . Error THEN203 nErrorIDO := fbMcReset . ErrorID ;204 ELSIF fbMcSetPosition . Error THEN205 nErrorIDO := fbMcSetPosition . ErrorID ;206 ELSIF fbMcMoveAbsolute1 . Error THEN207 nErrorIDO := fbMcMoveAbsolute1 . ErrorID ;208 ELSIF fbMcMoveAbsolute2 . Error THEN209 nErrorIDO := fbMcMoveAbsolute2 . ErrorID ;210 ELSIF fbMcMoveVelocity . Error THEN211 nErrorIDO := fbMcMoveVelocity . ErrorID ;212 ELSIF fbMcHalt . Error THEN213 nErrorIDO := fbMcHalt . ErrorID ;214 ELSIF bTaskError THEN215 nErrorIDO := GetErrorCode ( Error_InvalidTask ) ;216 ELSIF NOT bInitialized THEN217 nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;218 END_IF219 //Determine next state220 IF bResetI THEN221 eState := eIOLiftState_Reset ;222 END_IF223 END_CASE224225 //State changes which are the same for almost all states226 //check for errors227 IF ( fbMcMoveAbsolute1 . Error OR fbMcMoveAbsolute2 . Error OR

fbMcMoveVelocity . Error OR fbMcReset . Error OR fbMcPower . Error ORfbMcSetPosition . Error OR fbAxis . Status . Error OR fbMcHalt . Error ) ANDeState <> eIOLiftState_Reset AND eState <> eIOLiftState_Error THEN

228 eState := eIOLiftState_Error ;229 // check if lift should be disabled230 ELSIF NOT bEnableI AND eState <> eIOLiftState_Reset AND eState <>

eIOLiftState_Error AND eState <> eIOLiftState_InvalidLocation AND eState<> eIOLiftState_Stop AND eState <> eIOLiftState_Disabled THEN

231 eState := eIOLiftState_Stop ;232 END_IF233234 //avoid pointer errors235 IF bInitialized THEN236 A_RunMcFunctionBlocks ( ) ;237 bSenLiftBottomO := pbSenLiftBottom ^ ;238 bSenLiftTopO := pbSenLiftTop ^ ;239 END_IF240

Method: M_Calibrate


5-2-2013 12:44

1 //name: M_Calibrate2 //Version: 1.23 //Date: 10-01-2013, Joni Scholten4 //Calibration procedure for the FB_IOModLiftAct.5 METHOD PRIVATE M_Calibrate6 VAR_INPUT7 END_VAR8

1 CASE emCalibrateState OF2 eEncActCalibState_Begin :

//startsequence of calibration3 bCalibrated := FALSE ;4 //Determine next state5 IF bEnableI := TRUE THEN6 emCalibrateState := eEncActCalibState_StartCalibration ;7 END_IF89 eEncActCalibState_StartCalibration : //enable MC_Power of axis10 //Set Mc Function blocks11 fbMcPower . Enable := TRUE ;12 fbMcPower . Enable_Positive := TRUE ;13 fbMcPower . Enable_Negative := TRUE ;14 fbMcPower . Override := 100.0 ;15 IF fbMcPower . Status THEN16 emCalibrateState := eEncActCalibState_Active ;17 END_IF1819 eEncActCalibState_Active :20 ////Set Mc Function blocks21 fbMcMoveVelocity . Velocity := fSpeedCalibFast ;22 //Determine next state23 IF pbSenLiftBottom ^ THEN24 emCalibrateState := eEncActCalibState_BottomEndSensorActive ;25 ELSIF NOT pbSenLiftBottom ^ THEN26 emCalibrateState := eEncActCalibState_NotAtBottom ;27 END_IF2829 eEncActCalibState_NotAtBottom :30 ////Set Mc Function blocks31 fbMcMoveVelocity . Execute := TRUE ;32 fbMcMoveVelocity . Direction := MC_Negative_Direction ;33 //Determine next state34 IF pbSenLiftBottom ^ THEN35 emCalibrateState := eEncActCalibState_BottomEndSensorActive ;36 fbMcMoveVelocity . Execute := FALSE ;37 END_IF3839 eEncActCalibState_BottomEndSensorActive :40 ////Set Mc Function blocks41 fbMcMoveVelocity . Execute := TRUE ;42 fbMcMoveVelocity . Direction := MC_Positive_Direction ;43 //Determine Next state44 IF NOT pbSenLiftBottom ^ THEN45 emCalibrateState := eEncActCalibState_FindIndex ;46 fbMcMoveVelocity . Execute := FALSE ;

Method: M_Calibrate


5-2-2013 12:44

47 END_IF4849 eEncActCalibState_FindIndex :50 ////Set Mc Function blocks51 fbMcMoveVelocity . Execute := TRUE ;52 fbMcMoveVelocity . Velocity := fSpeedCalibSlow ;

//THIS VALUE IS CRITICAL FOR DETECTION OF ENCODER INDEX signal53 //determine next state54 IF pbEncoderIndex ^ THEN55 emCalibrateState := eEncActCalibState_SetPosition ;56 END_IF5758 eEncActCalibState_SetPosition :59 fbMcSetPosition . Position := 0.0 ;60 fbMcSetPosition . Execute := TRUE ;61 fbMcSetPosition . Mode := FALSE ;62 //Determine next state63 IF fbMcSetPosition . Done THEN64 emCalibrateState := eEncActCalibState_MoveToStart ;65 END_IF6667 eEncActCalibState_MoveToStart :68 //Set Mc Function blocks69 fbMcMoveVelocity . Execute := FALSE ;70 fbMcPower . Override := 100 ;71 fbMcSetPosition . Execute := FALSE ;72 fbMcMoveAbsolute1 . Execute := TRUE ;73 fbMcMoveAbsolute1 . Position := afLiftPositions [ 1 ] ;74 //Determine next state75 IF fbMcMoveAbsolute1 . Done THEN76 emCalibrateState := eEncActCalibState_Calibrated ;77 END_IF7879 eEncActCalibState_Calibrated :80 bCalibrated := TRUE ;81 END_CASE82

Method: M_Init


8-2-2013 9:48

1 //name: M_Init2 //Version: 1.23 //Date: 08-02-2013, Joni Scholten4 //This method initializes the Lift actuator in the I/O module 5 METHOD PUBLIC M_Init : BOOL6 VAR_INPUT7 stInit : ST_M_FB_IOModLiftAct_Init ;8 END_VAR9 VAR10 counter : BYTE ;11 END_VAR12

1 //Check if positions are well sorted, otherwise initialisation failed2 FOR counter := 2 TO 10 DO3 IF stInit . afLiftPositionsI [ counter ] < stInit . afLiftPositionsI [

counter - 1 ] THEN4 M_Init := FALSE ;5 RETURN ;6 END_IF7 END_FOR89 FOR counter := 1 TO 10 DO10 afLiftPositions [ counter ] := stInit . afLiftPositionsI [ counter ] +

stInit . fOffsetI ;11 END_FOR12 pbSenLiftBottom := stInit . pbSenLiftBottom ;13 pbSenLiftTop := stInit . pbSenLiftTop ;14 pbEncoderIndex := stInit . pbEncoderIndex ;1516 bCalibrated := FALSE ;1718

//check if fast calibration speed is slower than slow calibration speed. Otherwise initialisation failed19 IF stInit . fSpeedCalibFast < stInit . fSpeedCalibSlow THEN20 M_Init := FALSE ;21 RETURN ;22 ELSE23 fSpeedCalibFast := stInit . fSpeedCalibFast ;24 fSpeedCalibSlow := stInit . fSpeedCalibSlow ;25 END_IF2627 fbMcMoveAbsolute1 . Velocity := stInit . fSpeedNormal ;28 fbMcMoveAbsolute2 . Velocity := stInit . fSpeedNormal ;2930 bInitialized := TRUE ;3132 M_Init := TRUE ;33

C.2 FB TransportModule

Figure C.5: FB for the Transport module.

80

bStatusO:=FALSE

bDoneO:=FALSE

bBusyO:=FALSE

eActivateState:=Lift

Disabled

M_ActivateActuators()

ActivateActuators

nErrorIDO:=......

fbRotAct.bEnableI:=FALSE

bStatusO:=FALSE

fbManAct.bEnableI:=FALSE

fbLiftAct.bEnableI:=FALSE

bErrorO:=TRUE

bBusyO:=FALSE

Error

when: bEnableI=TRUE AND

bInitialized=TRUE AND

fbLiftAct.bStatusO=FALSE AND

fbRotAct.bStatusO=FALSE AND

fbManipAct.bStatusO=FALSE

fbLiftAct.bEnableI:=TRUE

fbRotAct.bEnableI:=TRUE

fbManipAct.bEnableI:=FALSE

bStatusO:=TRUE

bBusyO:=FALSE

bDoneO:=TRUE

ReadyForNewTask

when: M_CalibrateActuators()=TRUE

fbRotAct.nLocationI:=stTransportTask.nLocationFromI

fbRotAct.bExecuteI: NOT fbManipAct.bMovingOutO

bBusyO:=TRUE

bDoneO:=FALSE

MoveRotPickUp

fbManipAct.bExecuteI:=NOT fbRotAct.bBusyO AND fbLiftAct.bSenLiftDownO


MoveManOutPickUp

fbLiftAct.ExecuteI:=TRUE

fbManipAct.ExecuteI:=FALSE

MoveLiftUpPickUp

fbManipAct.bExecuteI:=TRUE

fbLiftAct.bExecuteI:=FALSE

MoveManInPickUp

fbManipAct.bEnableI:=FALSE

fbLiftAct.bExecute:=TRUE

fbRotAct.bEnableI:=TRUE

MoveLiftDownPickUp

fbRotAct.nLocationI:=stTransportTask.nLocationToI

fbRotAct.bExecuteI:= NOT fbManipAct.bMovingOutO


MoveRotDeliver

fbLiftAct.bExecuteI:=TRUE

fbRotAct.bExecuteI:=FALSE

MoveLiftUpDeliver

fbManipAct.bExecuteI:=NOT fbRotAct.bBusyO AND fbLiftAct.bSenLiftUpO

MoveManOutDeliver

fbLiftAct.bExecuteI:=TRUE

fbManipAct.bExecuteI:=FALSE

MoveLiftDownDeliver

fbManipAct.bExecuteI:=TRUE


MoveManInDeliver

when: bExecuteI=TRUE AND

fbManipAct.bSenManipInO=TRUEAND

fbManipAct.bStatusO=FALSE AND

fbLiftAct.bSenLiftDownO=TRUE AND

fbLiftAct.bDone=TRUE THEN

stTransportTask:=stTransportTaskI;

when: fbRotAct.bDoneO=TRUE AND

fbRotAct.nLocationO=stTransportTask.nLocationFromI AND

fbLiftAct.bSenLiftDownO=TRUE

when: fbManipAct.DoneO=TRUE AND

fbManipAct.bSenManipOutO=TRUE

when: fbLiftAct.bDoneO=TRUE AND

fbLiftAct.bSenLiftUpO=TRUE


fbManipAct.bSenManipInO=TRUE



fbManipAct.bSenManipInO=TRUE

when: fbRotAct.bDoneO=TRUE AND

fbRotAct.nLocationO=stTransportTask.nLocationToI

fbLiftAct.bSenLiftDownO=TRUE


fbLiftAct.bSenLiftUpO=TRUE

fbManipAct.bEnableI:= bEnableManipI


fbRotAct.bExecuteI:=FALSE

MoveManEnablePickUp

when: fbManipAct.bStatusO=TRUE AND

fbManipAct.bSenManipIn.O=TRUE

fbManipAct.bEnableI:=TRUE AND bEnableManipI




MoveManEnableDeliver

when: fbManipAct.bStatusO=TRUE AND

fbManipAct.bSenManipIn.O=TRUE


fbManipAct.bSenManipOutO=TRUE




fbManipAct.bSenManipInO=TRUE AND

bExecuteI=FALSE

fbManipAct.bResetI:=TRUE

fbLiftAct.bResetI:=TRUE

fbRotAct.bResetI:=TRUE

Resetwhen: bResetI=FALSE AND

fbRotAct.bErrorO=FALSE AND

fbLiftAct.bErrorO=FALSE AND

fbManipAct.bErrorO=FALSEwhen: bResetI=TRUE

FB_TransportModule statemachine 30-01-2013

From any state

excluding Error

and Reset if

bEnableI=FALSE

Error

when: bEnableManipI=FALSE



For global error

conditions see Code in

TwinCAT

Figure C.6: State machine for the Transport module.

81

POU: FB_TransportModule


5-2-2013 19:14

1 //name: FB_TransportModule2 //Version: 1.4 3 //Date: 30-01-2013, Joni Scholten4

//This Function block is defined in the document UML_software_1link_mock-up_V2_25-11-2012 AND 4M230_software_UML_StateDiagram5 FUNCTION_BLOCK FB_TransportModule EXTENDS FB_ActiveModule6 VAR_INPUT7 stTransportTaskI : ST_TransportTask ;

//struct that defines a transport module task 8 bEnableManipI : BOOL ;

//TRUE the manipulator is allowed to move to its outward position. 9

//Only needed when transport module is connected to an IO module to prevent a collision between manipulator and cassette lift,10

//or to prevent collision with another entering the same buffer module. These situations will have to be handled on a higher level 11 END_VAR12 VAR_OUTPUT13 stTransportTaskO : ST_TransportTask ;

//struct that defines a transport module task14 nLocationO : BYTE ;

//Location at which the transport module is standing still. only nonzero when transporter is not rotating and at one of the four predefined positions.15 bManipRetractedO : BOOL ;

//Only true if the manipulator is retracted and not moving. 16 END_VAR17 VAR18 //states19 eState : E_FB_TransportModuleStates ;20 eActivateState : E_M_FB_TransModActivateActuators ;2122

//bHoldsWafer : BOOL:=FALSE; //TRUE -> There lies a wafer on the manipulator23 stTransportTask : ST_TransportTask ;

//struct that defines a transport module task24 eErrorCode : E_ErrorCodes ; //enumerate with error names2526 //actuator function blocks27 fbTransModLiftAct : FB_TransModLiftAct ;28 fbTransModManipAct : FB_TransModManipAct ;29 fbTransModRotAct : FB_TransModRotAct ;3031 END_VAR32

1 CASE eState OF2 eTransModState_Disabled :3 //outputs4 bStatusO := FALSE ;5 bBusyO := FALSE ;6 bDoneO := FALSE ;7 bErrorO := FALSE ;8 nErrorIDO := 0 ;9 //internal variables10 eActivateState := eTransModCaliActState_Lift ;11 //set actuator FB inputs12 //lift actuator13 fbTransModLiftAct . bEnableI := FALSE ;



5-2-2013 19:14

14 fbTransModLiftAct . bExecuteI := FALSE ;15 fbTransModLiftAct . bResetI := FALSE ;16 //manip actuator17 fbTransModManipAct . bEnableI := FALSE ;18 fbTransModManipAct . bExecuteI := FALSE ;19 fbTransModManipAct . bResetI := FALSE ;20 //rotational actuator21 fbTransModRotAct . bEnableI := FALSE ;22 fbTransModRotAct . bExecuteI := FALSE ;23 fbTransModRotAct . bResetI := FALSE ;24 IF bEnableI AND bInitialized AND NOT fbTransModLiftAct . bStatusO

AND NOT fbTransModManipAct . bStatusO AND NOT fbTransModRotAct . bStatusOTHEN

25 eState := eTransModState_ActivateActuators ;26 ELSIF bEnableI AND NOT bInitialized THEN27 eState := eTransModState_Error ;28 END_IF2930 eTransModState_ActivateActuators :31 //outputs32 bStatusO := FALSE ;33 bBusyO := FALSE ;34 bDoneO := FALSE ;35 bErrorO := FALSE ;36 nErrorIDO := 0 ;37 //determine next state38 IF M_ActivateActuators ( ) THEN39 eState := eTransModState_ReadyForNewTask ;40 END_IF4142 eTransModState_ReadyForNewTask :43 //outputs44 bStatusO := TRUE ;45 bBusyO := FALSE ;46 bDoneO := TRUE ;47 bErrorO := FALSE ;48 nErrorIDO := 0 ;49 //set actuator FB inputs50 //lift actuator51 fbTransModLiftAct . bEnableI := TRUE ;52 fbTransModLiftAct . bExecuteI := FALSE ;53 fbTransModLiftAct . bResetI := FALSE ;54 //manip actuator55 fbTransModManipAct . bEnableI := FALSE ;56 fbTransModManipAct . bExecuteI := FALSE ;57 fbTransModManipAct . bResetI := FALSE ;58 //rotational actuator59 fbTransModRotAct . bEnableI := TRUE ;60 fbTransModRotAct . bExecuteI := FALSE ;61 fbTransModRotAct . bResetI := FALSE ;62 //determine next state63 IF bExecuteI AND fbTransModManipAct . bSenManipInO AND NOT

fbTransModManipAct . bStatusO AND fbTransModLiftAct . bSenLiftDownO ANDfbTransModLiftAct . bDoneO THEN

64 stTransportTask := stTransportTaskI ;65 eState := eTransModState_MoveRotPickUp ;



5-2-2013 19:14

66 END_IF6768 eTransModState_MoveRotPickUp :69 //outputs70 bStatusO := TRUE ;71 bBusyO := TRUE ;72 bDoneO := FALSE ;73 bErrorO := FALSE ;74 nErrorIDO := 0 ;75 //set actuator FB inputs76 //lift actuator77 fbTransModLiftAct . bEnableI := TRUE ;78 fbTransModLiftAct . bExecuteI := FALSE ;79 fbTransModLiftAct . bResetI := FALSE ;80 //manip actuator81 fbTransModManipAct . bEnableI := FALSE ;82 fbTransModManipAct . bExecuteI := FALSE ;83 fbTransModManipAct . bResetI := FALSE ;84 //rotational actuator85 fbTransModRotAct . bEnableI := TRUE ;86 fbTransModRotAct . bExecuteI := NOT fbTransModManipAct . bMovingOutO ;87 fbTransModRotAct . bResetI := FALSE ;88 fbTransModRotAct . nLocationI := stTransportTask . nLocationFromI ;89 //determine next state90 IF fbTransModRotAct . bDoneO AND fbTransModRotAct . nLocationO =

stTransPortTask . nLocationFromI AND fbTransModLiftAct . bSenLiftDownO THEN91 eState := eTransModState_MoveManEnablePickUp ;92 END_IF9394 eTransModState_MoveManEnablePickUp :95 //outputs96 bStatusO := TRUE ;97 bBusyO := TRUE ;98 bDoneO := FALSE ;99 bErrorO := FALSE ;100 nErrorIDO := 0 ;101 //set actuator FB inputs102 //lift actuator103 fbTransModLiftAct . bEnableI := TRUE ;104 fbTransModLiftAct . bExecuteI := FALSE ;105 fbTransModLiftAct . bResetI := FALSE ;106 //manip actuator107 fbTransModManipAct . bEnableI := bEnableManipI ;108 fbTransModManipAct . bExecuteI := FALSE ;109 fbTransModManipAct . bResetI := FALSE ;110 //rotational actuator111 fbTransModRotAct . bEnableI := TRUE ;112 fbTransModRotAct . bExecuteI := FALSE ;113 fbTransModRotAct . bResetI := FALSE ;114 //determine next state115 IF fbTransModManipAct . bStatusO AND fbTransModManipAct .

bSenManipInO THEN116 eState := eTransModState_MoveManOutPickUp ;117 END_IF118119 eTransModState_MoveManOutPickUp :



5-2-2013 19:14

120 //outputs121 bStatusO := TRUE ;122 bBusyO := TRUE ;123 bDoneO := FALSE ;124 bErrorO := FALSE ;125 nErrorIDO := 0 ;126 //set actuator FB inputs127 //lift actuator128 fbTransModLiftAct . bEnableI := TRUE ;129 fbTransModLiftAct . bExecuteI := FALSE ;130 fbTransModLiftAct . bResetI := FALSE ;131 //manip actuator132 fbTransModManipAct . bEnableI := bEnableManipI ;133 fbTransModManipAct . bExecuteI := ( NOT fbTransModRotAct . bBusyO )

AND fbTransModLiftAct . bSenLiftDownO ;134 fbTransModManipAct . bResetI := FALSE ;135 //rotational actuator136 fbTransModRotAct . bEnableI := FALSE ;137 fbTransModRotAct . bExecuteI := FALSE ;138 fbTransModRotAct . bResetI := FALSE ;139 //determine next state140 IF NOT bEnableManipI THEN

//in this state the manipulator should be enabled141 eErrorCode := Error_ManipDisabled ;142 eState := eTransModState_Error ;143 ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .

bSenManipOutO THEN144 eState := eTransModState_MoveLiftUpPickUp ;145 END_IF146147 eTransModState_MoveLiftUpPickUp :148 //outputs149 bStatusO := TRUE ;150 bBusyO := TRUE ;151 bDoneO := FALSE ;152 bErrorO := FALSE ;153 nErrorIDO := 0 ;154 //set actuator FB inputs155 //lift actuator156 fbTransModLiftAct . bEnableI := TRUE ;157 fbTransModLiftAct . bExecuteI := TRUE ;158 fbTransModLiftAct . bResetI := FALSE ;159 //manip actuator160 fbTransModManipAct . bEnableI := bEnableManipI ;161 fbTransModManipAct . bExecuteI := FALSE ;162 fbTransModManipAct . bResetI := FALSE ;163 //rotational actuator164 fbTransModRotAct . bEnableI := FALSE ;165 fbTransModRotAct . bExecuteI := FALSE ;166 fbTransModRotAct . bResetI := FALSE ;167 //determine next state168 IF NOT bEnableManipI THEN

//in this state the manipulator should be enabled169 eErrorCode := Error_ManipDisabled ;170 eState := eTransModState_Error ;171 ELSIF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftUpO



5-2-2013 19:14

THEN172 eState := eTransModState_MoveManInPickUp ;173 END_IF174175 eTransModState_MoveManInPickUp :176 //outputs177 bStatusO := TRUE ;178 bBusyO := TRUE ;179 bDoneO := FALSE ;180 bErrorO := FALSE ;181 nErrorIDO := 0 ;182 //set actuator FB inputs183 //lift actuator184 fbTransModLiftAct . bEnableI := TRUE ;185 fbTransModLiftAct . bExecuteI := FALSE ;186 fbTransModLiftAct . bResetI := FALSE ;187 //manip actuator188 fbTransModManipAct . bEnableI := bEnableManipI ;189 fbTransModManipAct . bExecuteI := TRUE ;190 fbTransModManipAct . bResetI := FALSE ;191 //rotational actuator192 fbTransModRotAct . bEnableI := FALSE ;193 fbTransModRotAct . bExecuteI := FALSE ;194 fbTransModRotAct . bResetI := FALSE ;195 //determine next state196 IF NOT bEnableManipI THEN


bSenManipInO THEN200 eState := eTransModState_MoveLiftDownPickUp ;201 END_IF202203 eTransModState_MoveLiftDownPickUp :204 //outputs205 bStatusO := TRUE ;206 bBusyO := TRUE ;207 bDoneO := FALSE ;208 bErrorO := FALSE ;209 nErrorIDO := 0 ;210 //set actuator FB inputs211 //lift actuator212 fbTransModLiftAct . bEnableI := TRUE ;213 fbTransModLiftAct . bExecuteI := TRUE ;214 fbTransModLiftAct . bResetI := FALSE ;215 //manip actuator216 fbTransModManipAct . bEnableI := FALSE ;217 fbTransModManipAct . bExecuteI := FALSE ;218 fbTransModManipAct . bResetI := FALSE ;219 //rotational actuator220 fbTransModRotAct . bEnableI := TRUE ;221 fbTransModRotAct . bExecuteI := FALSE ;222 fbTransModRotAct . bResetI := FALSE ;223 //determine next state224 IF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftDownO

AND fbTransModManipAct . bSenManipInO THEN



5-2-2013 19:14

225 eState := eTransModState_MoveRotDeliver ;226 END_IF227228 eTransModState_MoveRotDeliver :229 //outputs230 bStatusO := TRUE ;231 bBusyO := TRUE ;232 bDoneO := FALSE ;233 bErrorO := FALSE ;234 nErrorIDO := 0 ;235 //set actuator FB inputs236 //lift actuator237 fbTransModLiftAct . bEnableI := TRUE ;238 fbTransModLiftAct . bExecuteI := FALSE ;239 fbTransModLiftAct . bResetI := FALSE ;240 //manip actuator241 fbTransModManipAct . bEnableI := FALSE ;242 fbTransModManipAct . bExecuteI := FALSE ;243 fbTransModManipAct . bResetI := FALSE ;244 //rotational actuator245 fbTransModRotAct . bEnableI := TRUE ;246 fbTransModRotAct . bExecuteI := NOT fbTransModManipAct . bMovingOutO ;247 fbTransModRotAct . bResetI := FALSE ;248 fbTransModRotAct . nLocationI := stTransportTask . nLocationToI ;249 //determine next state250 IF fbTransModRotAct . bDoneO AND fbTransModRotAct . nLocationO =

stTransportTask . nLocationToI AND fbTransModLiftAct . bSenLiftDownO THEN251 eState := eTransModState_MoveLiftUpDeliver ;252 END_IF253254 eTransModState_MoveLiftUpDeliver :255 //outputs256 bStatusO := TRUE ;257 bBusyO := TRUE ;258 bDoneO := FALSE ;259 bErrorO := FALSE ;260 nErrorIDO := 0 ;261 //set actuator FB inputs262 //lift actuator263 fbTransModLiftAct . bEnableI := TRUE ;264 fbTransModLiftAct . bExecuteI := TRUE ;265 fbTransModLiftAct . bResetI := FALSE ;266 //manip actuator267 fbTransModManipAct . bEnableI := FALSE ;268 fbTransModManipAct . bExecuteI := FALSE ;269 fbTransModManipAct . bResetI := FALSE ;270 //rotational actuator271 fbTransModRotAct . bEnableI := TRUE ;272 fbTransModRotAct . bExecuteI := FALSE ;273 fbTransModRotAct . bResetI := FALSE ;274 //determine next state275 IF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftUpO

THEN276 eState := eTransModState_MoveManEnableDeliver ;277 END_IF278



5-2-2013 19:14

279 eTransModState_MoveManEnableDeliver :280 //outputs281 bStatusO := TRUE ;282 bBusyO := TRUE ;283 bDoneO := FALSE ;284 bErrorO := FALSE ;285 nErrorIDO := 0 ;286 //set actuator FB inputs287 //lift actuator288 fbTransModLiftAct . bEnableI := TRUE ;289 fbTransModLiftAct . bExecuteI := FALSE ;290 fbTransModLiftAct . bResetI := FALSE ;291 //manip actuator292 fbTransModManipAct . bEnableI := bEnableManipI ;293 fbTransModManipAct . bExecuteI := FALSE ;294 fbTransModManipAct . bResetI := FALSE ;295 //rotational actuator296 fbTransModRotAct . bEnableI := FALSE ;297 fbTransModRotAct . bExecuteI := FALSE ;298 fbTransModRotAct . bResetI := FALSE ;299 //determine next state300 IF fbTransModManipAct . bStatusO AND fbTransModManipAct .

bSenManipInO THEN301 eState := eTransModState_MoveManOutDeliver ;302 END_IF303304 eTransModState_MoveManOutDeliver :305 //outputs306 bStatusO := TRUE ;307 bBusyO := TRUE ;308 bDoneO := FALSE ;309 bErrorO := FALSE ;310 nErrorIDO := 0 ;311 //set actuator FB inputs312 //lift actuator313 fbTransModLiftAct . bEnableI := TRUE ;314 fbTransModLiftAct . bExecuteI := FALSE ;315 fbTransModLiftAct . bResetI := FALSE ;316 //manip actuator317 fbTransModManipAct . bEnableI := bEnableManipI ;318 fbTransModManipAct . bExecuteI := ( NOT fbTransModRotAct . bBusyO )

AND fbTransModLiftAct . bSenLiftUpO ;319 fbTransModManipAct . bResetI := FALSE ;320 //rotational actuator321 fbTransModRotAct . bEnableI := FALSE ;322 fbTransModRotAct . bExecuteI := FALSE ;323 fbTransModRotAct . bResetI := FALSE ;324 //determine next state325 IF NOT bEnableManipI THEN


bSenManipOutO THEN329 eState := eTransModState_MoveLiftDownDeliver ;330 END_IF



5-2-2013 19:14

331332 eTransModState_MoveLiftDownDeliver :333 //outputs334 bStatusO := TRUE ;335 bBusyO := TRUE ;336 bDoneO := FALSE ;337 bErrorO := FALSE ;338 nErrorIDO := 0 ;339 //set actuator FB inputs340 //lift actuator341 fbTransModLiftAct . bEnableI := TRUE ;342 fbTransModLiftAct . bExecuteI := TRUE ;343 fbTransModLiftAct . bResetI := FALSE ;344 //manip actuator345 fbTransModManipAct . bEnableI := bEnableManipI ;346 fbTransModManipAct . bExecuteI := FALSE ;347 fbTransModManipAct . bResetI := FALSE ;348 //rotational actuator349 fbTransModRotAct . bEnableI := FALSE ;350 fbTransModRotAct . bExecuteI := FALSE ;351 fbTransModRotAct . bResetI := FALSE ;352 //determine next state353 IF NOT bEnableManipI THEN

//in this state the manipulator should be enabled354 eErrorCode := Error_ManipDisabled ;355 eState := eTransModState_Error ;356 ELSIF fbTransModLiftAct . bDoneO AND fbTransModLiftAct .

bSenLiftDownO THEN357 eState := eTransModState_MoveManInDeliver ;358 END_IF359360 eTransModState_MoveManInDeliver :361 //outputs362 bStatusO := TRUE ;363 bBusyO := TRUE ;364 bDoneO := FALSE ;365 bErrorO := FALSE ;366 nErrorIDO := 0 ;367 //set actuator FB inputs368 //lift actuator369 fbTransModLiftAct . bEnableI := TRUE ;370 fbTransModLiftAct . bExecuteI := FALSE ;371 fbTransModLiftAct . bResetI := FALSE ;372 //manip actuator373 fbTransModManipAct . bEnableI := bEnableManipI ;374 fbTransModManipAct . bExecuteI := TRUE ;375 fbTransModManipAct . bResetI := FALSE ;376 //rotational actuator377 fbTransModRotAct . bEnableI := TRUE ;378 fbTransModRotAct . bExecuteI := FALSE ;379 fbTransModRotAct . bResetI := FALSE ;380 //determine next state381 IF NOT bEnableManipI THEN

//in this state the manipulator should be enabled382 eErrorCode := Error_ManipDisabled ;383 eState := eTransModState_Error ;



5-2-2013 19:14

384 ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .bSenManipInO AND NOT bExecuteI THEN

385 eState := eTransModState_ReadyForNewTask ;386 END_IF387388 eTransModState_Error :389 //outputs390 bStatusO := FALSE ;391 bBusyO := FALSE ;392 bDoneO := FALSE ;393 bErrorO := TRUE ;394 //set actuator FB inputs395 //lift actuator396 fbTransModLiftAct . bEnableI := FALSE ;397 fbTransModLiftAct . bExecuteI := FALSE ;398 fbTransModLiftAct . bResetI := FALSE ;399 //manip actuator400 fbTransModManipAct . bEnableI := FALSE ;401 fbTransModManipAct . bExecuteI := FALSE ;402 fbTransModManipAct . bResetI := FALSE ;403 //rotational actuator404 fbTransModRotAct . bEnableI := FALSE ;405 fbTransModRotAct . bExecuteI := FALSE ;406 fbTransModRotAct . bResetI := FALSE ;407 //determine nErrorIDO output408 IF fbTransModLiftAct . bErrorO THEN409 nErrorIDO := fbTransModliftAct . nErrorIDO ;410 ELSIF fbTransModManipAct . bErrorO THEN411 nErrorIDO := fbTransModManipAct . nErrorIDO ;412 ELSIF fbTransModRotAct . bErrorO THEN413 nErrorIDO := fbTransModRotAct . nErrorIDO ;414 ELSE415 nErrorIDO := GetErrorCode ( eErrorCode ) ;416 END_IF417 //determine next state418 IF bResetI THEN419 eState := eTransModState_Reset ;420 END_IF421422 eTransModState_Reset :423 //outputs424 bStatusO := FALSE ;425 bBusyO := FALSE ;426 bDoneO := FALSE ;427 bErrorO := FALSE ;428 nErrorIDO := 0 ;429 //set actuator FB inputs430 //lift actuator431 fbTransModLiftAct . bEnableI := FALSE ;432 fbTransModLiftAct . bExecuteI := FALSE ;433 fbTransModLiftAct . bResetI := TRUE ;434 //manip actuator435 fbTransModManipAct . bEnableI := FALSE ;436 fbTransModManipAct . bExecuteI := FALSE ;437 fbTransModManipAct . bResetI := TRUE ;438 //rotational actuator



5-2-2013 19:14

439 fbTransModRotAct . bEnableI := FALSE ;440 fbTransModRotAct . bExecuteI := FALSE ;441 fbTransModRotAct . bResetI := TRUE ;442 //determine next state443 IF NOT bResetI AND NOT fbTransModRotAct . bErrorO AND NOT

fbTransModLiftAct . bErrorO AND NOT fbTransModManipAct . bErrorO THEN444 eState := eTransModState_Disabled ;445 END_IF446 END_CASE447448 //Error and disable detection449 IF eState <> eTransModState_Error AND eState <> eTransModState_Reset THEN

450 //error occurance451 IF bEnableI AND NOT bInitialized THEN //initialize error452 eErrorCode := Error_NotInitialized ;453 eState := eState := eTransModState_Error ;454 ELSIF fbTransModRotAct . bBusyO AND ( fbTransModManipAct . bMovingOutO OR

NOT fbTransModManipAct . bSenManipInO ) THEN//rotation while manipulator is not retracted

455 eErrorCode := Error_IllegalActuatorAction ;456 eState := eTransModState_Error ;457 ELSIF fbTransModLiftAct . bErrorO OR fbTransModManipAct . bErrorO OR

fbTransModRotAct . bErrorO THEN //error in actuator function blocks458 eState := eTransModState_Error ;459 //bEnableI=FALSE;460 ELSIF eState <> eTransModState_Disabled AND NOT bEnableI THEN461 eState := eTransModState_Disabled ;462 END_IF463 END_IF464465 //set additional outputs466 stTransportTaskO := stTransportTask ;467 nLocationO := fbTransModRotAct . nLocationO ;468 bManipRetractedO := fbTransModManipAct . bSenManipInO AND NOT

fbTransModManipAct . bMovingOutO ;469 //run actuator function blocks470 IF bInitialized THEN471 A_RunActuatorFB ( ) ;472 END_IF473

Figure C.7: State machine for the Transport module actuators activation.

92

Method: M_ActivateActuators


5-2-2013 19:15

1 //16-01-2013 Joni Scholten activate actuators sequence2 METHOD PRIVATE M_ActivateActuators : BOOL3 VAR_INPUT4 END_VAR5

1 CASE eActivateState OF2 eTransModCaliActState_Lift :3 //set actuator FB inputs4 //lift actuator5 fbTransModLiftAct . bEnableI := TRUE ;6 fbTransModLiftAct . bExecuteI := FALSE ;7 fbTransModLiftAct . bResetI := FALSE ;8 //manip actuator9 fbTransModManipAct . bEnableI := FALSE ;10 fbTransModManipAct . bExecuteI := FALSE ;11 fbTransModManipAct . bResetI := FALSE ;12 //rotational actuator13 fbTransModRotAct . bEnableI := FALSE ;14 fbTransModRotAct . bExecuteI := FALSE ;15 fbTransModRotAct . bResetI := FALSE ;16 //determine next state17 IF fbTransModLiftAct . bStatusO AND fbTransModLiftAct . bSenLiftDownO

THEN18 eActivateState := eTransModCaliActState_Manip ;19 END_IF20 //return value21 M_ActivateActuators := FALSE ;2223 eTransModCaliActState_Manip :24 //set actuator FB inputs25 //lift actuator26 fbTransModLiftAct . bEnableI := TRUE ;27 fbTransModLiftAct . bExecuteI := FALSE ;28 fbTransModLiftAct . bResetI := FALSE ;29 //manip actuator30 fbTransModManipAct . bEnableI := TRUE ;31 fbTransModManipAct . bExecuteI := FALSE ;32 fbTransModManipAct . bResetI := FALSE ;33 //rotational actuator34 fbTransModRotAct . bEnableI := FALSE ;35 fbTransModRotAct . bExecuteI := FALSE ;36 fbTransModRotAct . bResetI := FALSE ;37 //determine next state38 IF fbTransModManipAct . bStatusO AND fbTransModManipAct .

bSenManipInO THEN39 eActivateState := eTransModCaliActState_Rot ;40 END_IF41 //return value42 M_ActivateActuators := FALSE ;4344 eTransModCaliActState_Rot :45 //set actuator FB inputs46 //lift actuator47 fbTransModLiftAct . bEnableI := TRUE ;48 fbTransModLiftAct . bExecuteI := FALSE ;

Method: M_ActivateActuators


5-2-2013 19:15

49 fbTransModLiftAct . bResetI := FALSE ;50 //manip actuator51 fbTransModManipAct . bEnableI := TRUE ;52 fbTransModManipAct . bExecuteI := FALSE ;53 fbTransModManipAct . bResetI := FALSE ;54 //rotational actuator55 fbTransModRotAct . bEnableI := TRUE ;56 fbTransModRotAct . bExecuteI := FALSE ;57 fbTransModRotAct . bResetI := FALSE ;58 //determine next state59 IF fbTransModRotAct . bStatusO = TRUE THEN60 //return value61 M_ActivateActuators := TRUE ;62 ELSE63 //return value64 M_ActivateActuators := FALSE ;65 END_IF66 END_CASE67

Method: M_Init


5-2-2013 19:15

1 //name: M_Init2 //Version: 1.13 //Date: 16-12-2012, Joni Scholten4 //This method initializes the TransportModule 5 METHOD M_Init : BOOL6 VAR_INPUT7 stInit : ST_M_FB_TransportModule_Init ;8 END_VAR9

1 bInitialized := fbTransModLiftAct . M_Init ( stInit . stLiftInit ) ANDfbTransModRotAct . M_Init ( stInit . stRotInit ) AND fbTransModManipAct . M_Init( stInit . stManipInit ) ;

2 M_init := bInitialized ;3

C.2.1 Transport Module actuators

(a) FB for the Transport mod-ule rotation.

(b) FB for the Transport mod-ule lift.

(c) FB for the Transport mod-ule manipulator.

Figure C.8

96

FB_TransModRotAct 19-12-2012




END_IF






Move1

bTaskError:=TRUE

InvalidLocation






bTaskError:=FALSE

bBusyO:=FALSE

bStatusO:=FALSE



bDoneO:=FALSE

bErrorO:=FALSE

Disabled


bEnableI=TRUE


bEnableI=TRUE


bStatusO:=FALSE


nErrorIDO:=...

bErrorO:=TRUE

bBusyO:=FALSE

bDoneO:=FALSE

Error


bTaskError:=FALSE

Reset

when: bResetI=TRUE



bStatusO:=TRUE

Enabled




END_IF







nLocationO:=0

PowerOn





Error and Reset, if

bEnableI:=FALSE


Error and Reset, if





ReadyForTask

M_Calibrate

Calibrate


Stop


when: bExecuteI=FALSEwhen: McMoveAbsolute1.Done=TRUE



Move2

Figure C.9: State machine for the Transport module rotation.

97

POU: FB_TransModRotAct


5-2-2013 19:09

1 //name: FB_TransModRotAct2 //Version: 1.13 //Date: 15-01-2013, Joni Scholten4

//This Function block is defined in the document UML_class_diagram_software_1link_mock-up5 FUNCTION_BLOCK FB_TransModRotAct EXTENDS FB_EncoderAct6 VAR_INPUT7 END_VAR8 VAR_OUTPUT9 bSenRotEnd1O : BOOL ;

//TRUE -> Rotating disc clockwise end sensor is activated. This sensor is used for calibration!10 bSenRotEnd2O : BOOL ;

//TRUE -> Rotating disc counterclockwise end sensor is activated.11 END_VAR12 VAR13 //state machine states14 eState : E_FB_TransModRotActStates ;15 emCalibrateState : E_M_FB_EncActCalibrateStates ;16 //internal variables17 afRotPositions : ARRAY [ 1 .. 4 ] OF LREAL ;18 //pointers19 pbSenRotEnd1 : POINTER TO BOOL ;

//This sensor is used for calibration!20 pbSenRotEnd2 : POINTER TO BOOL ;21 END_VAR22

1 //TODO2 //Make end sensors turn positive if they detect the lift.34 fbAxis . ReadStatus ( ) ; //Read the current status of the IO lift axis56 CASE eState OF7 eTransRotState_Reset :

//Reset all MC function blocks. Initial state (to cancel possible errors from previous runs)8 //outputs9 bStatusO := FALSE ;10 bBusyO := FALSE ;11 bDoneO := FALSE ;12 bErrorO := FALSE ;13 nErrorIDO := 0 ;14 //Internal variables15 bTaskError := FALSE ;16 //MC function block settings17 fbMcPower . Enable := FALSE ;18 fbMcReset . Execute := TRUE ;19 fbMcMoveAbsolute1 . Execute := FALSE ;20 //determine next state21 IF NOT bInitialized THEN22 eState := eTransRotState_Error ;23 ELSIF fbMcReset . Done AND NOT bResetI AND bInitialized THEN24 eState := eTransRotState_Disabled ;25 END_IF2627 eTransRotState_Stop :

//Stop all MC function blocks using MC halt, otherwise an error might occur.



5-2-2013 19:09

28 //MC function block settings29 fbMcHalt . Execute := TRUE ;30 //determine next state31 IF fbMcHalt . Done THEN32 eState := eTransRotState_Disabled ;33 END_IF3435 eTransRotState_Disabled : //nothing moves, nothing is enabled36 //Outputs37 bStatusO := FALSE ;38 bBusyO := FALSE ;39 bDoneO := FALSE ;40 bErrorO := FALSE ;41 //Internal variables42 bTaskError := FALSE ;43 emCalibrateState := eEncActCalibState_Begin ;

//Reset M_Calibrate statemachine44 //MC function block settings45 fbMcReset . Execute := FALSE ;46 fbMcPower . Enable := FALSE ;47 fbMcMoveAbsolute1 . Execute := FALSE ;48 fbMcHalt . Execute := FALSE ;49 //Determine next state50 IF NOT bCalibrated AND bEnableI THEN51 eState := eTransRotState_Calibrate ;52 ELSIF bCalibrated AND bEnableI THEN53 eState := eTransRotState_PowerOn ;54 END_IF5556 eTransRotState_Calibrate :

//call M_Calibrate method to perform calibration57 //Outputs58 bStatusO := FALSE ;59 bBusyO := FALSE ;60 bDoneO := FALSE ;61 bErrorO := FALSE ;62 //Internal variables63 //Run calibration method M_Calibrate64 M_Calibrate ( ) ;65 //Determine next state66 IF bCalibrated AND bEnableI THEN67 eState := eTransRotState_PowerOn ;68 END_IF6970 eTransRotState_PowerOn :71 //Outputs72 bStatusO := FALSE ;73 bBusyO := FALSE ;74 bDoneO := FALSE ;75 bErrorO := FALSE ;76 //Internal variables77 //MC function block settings78 fbMcPower . Enable := TRUE ;79 fbMcPower . Override := 100.0 ;80 fbMcPower . Enable_Negative := TRUE ;81 fbMcPower . Enable_Positive := TRUE ;



5-2-2013 19:09

82 fbMcMoveAbsolute1 . Execute := FALSE ;83 nLocationO := 0 ;84 //Determine next state85 IF NOT fbAxis . Status . Disabled THEN86 eState := eTransRotState_Enabled ;87 END_IF8889 eTransRotState_Enabled :90 //outputs91 bStatusO := TRUE ;92 bBusyO := FALSE ;93 bDoneO := FALSE ;94 bErrorO := FALSE ;95 //Internal variables96 //MC function block settings97 fbMcMoveAbsolute1 . Execute := FALSE ;98 //determine next state99 IF bExecuteI AND nLocationI > 0 AND nLocationI <= 4 THEN100 nLocation := nLocationI ;101 eState := eTransRotState_Move1 ;102 ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 4 THEN103 eState := eTransRotState_InvalidLocation ;104 END_IF105106 eTransRotState_Move1 :107 //Outputs108 bStatusO := TRUE ;109 bBusyO := fbMcMoveAbsolute1 . Busy ;110 bDoneO := fbMcMoveAbsolute1 . Done ;111 bErrorO := FALSE ;112 //Internal variables113 nLocationO := nLocation ;114 //MC function block settings115 fbMcMoveAbsolute1 . Execute := TRUE ;116 fbMcMoveAbsolute1 . Position := afRotPositions [ nLocation ] ;117 //Determine next state118 IF NOT bExecuteI THEN119 eState := eTransRotState_Move2 ;120 END_IF121122 eTransRotState_Move2 :123 //Outputs124 bStatusO := TRUE ;125 bBusyO := fbMcMoveAbsolute1 . Busy ;126 bDoneO := fbMcMoveAbsolute1 . Done ;127 bErrorO := FALSE ;128 //Internal variables129 //MC function block settings130 //Determine next state131 IF fbMcMoveAbsolute1 . Done THEN132 eState := eTransRotState_ReadyForTask ;133 END_IF134135 eTransRotState_ReadyForTask :136 //Outputs137 bStatusO := TRUE ;



5-2-2013 19:09

138 bBusyO := fbMcMoveAbsolute1 . Busy ;139 bDoneO := fbMcMoveAbsolute1 . Done ;140 bErrorO := FALSE ;141 //Internal variables142 //MC function block settings143 fbMcMoveAbsolute1 . Execute := FALSE ;144 //determine next state145 IF bExecuteI AND nLocationI > 0 AND nLocationI <= 4 THEN146 nLocation := nLocationI ;147 eState := eTransRotState_Move1 ;148 ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 4 THEN149 eState := eTransRotState_InvalidLocation ;150 END_IF151152 eTransRotState_InvalidLocation :153 //internal variables154 bTaskError := TRUE ;155 //MC function block settings156 fbMcMoveAbsolute1 . Execute := FALSE ;157 //next state158 eState := eTransRotState_Error ;159160 eTransRotState_Error :161 //outputs162 bStatusO := FALSE ;163 bBusyO := FALSE ;164 bDoneO := FALSE ;165 bErrorO := TRUE ;166 //Internal variables167 //MC function block settings168 fbMcPower . Enable := FALSE ;169 fbMcMoveAbsolute1 . Execute := FALSE ;170 //Determine errorcode171 IF fbAxis . Status . Error THEN172 nErrorIDO := fbAxis . Status . ErrorID ;173 ELSIF fbMcPower . Error THEN174 nErrorIDO := fbMcPower . ErrorID ;175 ELSIF fbMcReset . Error THEN176 nErrorIDO := fbMcReset . ErrorID ;177 ELSIF fbMcSetPosition . Error THEN178 nErrorIDO := fbMcSetPosition . ErrorID ;179 ELSIF fbMcMoveAbsolute1 . Error THEN180 nErrorIDO := fbMcMoveAbsolute1 . ErrorID ;181 ELSIF fbMcMoveVelocity . Error THEN182 nErrorIDO := fbMcMoveVelocity . ErrorID ;183 ELSIF fbMcHalt . Error THEN184 nErrorIDO := fbMcHalt . ErrorID ;185 ELSIF bTaskError THEN186 nErrorIDO := GetErrorCode ( Error_InvalidTask ) ;187 ELSIF NOT bInitialized THEN188 nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;189 END_IF190 //Determine next state191 IF bResetI THEN192 eState := eIOLiftState_Reset ;193 END_IF



5-2-2013 19:09

194195 END_CASE196197 //State changes which are the same for almost all states198 //check for errors199 IF ( fbMcMoveAbsolute1 . Error OR fbMcMoveVelocity . Error OR fbMcReset .

Error OR fbMcPower . Error OR fbMcSetPosition . Error OR fbAxis . Status .Error OR fbMcHalt . Error ) AND eState <> eTransRotState_Reset AND eState<> eTransRotState_Error THEN

200 eState := eTransRotState_Error ;201 // check if lift should be disabled202 ELSIF NOT bEnableI AND eState <> eTransRotState_Reset AND eState <>

eTransRotState_Error AND eState <> eTransRotState_InvalidLocation ANDeState <> eTransRotState_Stop AND eState <> eTransRotState_Disabled THEN

203 eState := eTransRotState_Stop ;204 END_IF205206 //avoid pointer errors207 IF bInitialized THEN208 A_RunMcFunctionBlocks ( ) ;209 END_IF210

Method: M_Calibrate


5-2-2013 19:10

1 //Version: 1.12 //Date: 15-01-2013, Joni Scholten3 //Calibration procedure for the FB_TransModRotAct.4 METHOD PRIVATE M_Calibrate : BOOL5 VAR_INPUT6 END_VAR7

1 CASE emCalibrateState OF2 eEncActCalibState_Begin :

//startsequence of calibration3 bCalibrated := FALSE ;4 //Determine next state5 IF bEnableI := TRUE THEN6 emCalibrateState := eEncActCalibState_StartCalibration ;7 END_IF89 eEncActCalibState_StartCalibration : //enable MC_Power of axis10 //Set Mc Function blocks11 fbMcPower . Enable := TRUE ;12 fbMcPower . Enable_Positive := TRUE ;13 fbMcPower . Enable_Negative := TRUE ;14 fbMcPower . Override := 100.0 ;15 IF fbMcPower . Status THEN16 emCalibrateState := eEncActCalibState_Active ;17 END_IF1819 eEncActCalibState_Active :20 ////Set Mc Function blocks21 fbMcMoveVelocity . Velocity := fSpeedCalibFast ;22 //Determine next state23 IF NOT pbSenRotEnd2 ^ THEN24 emCalibrateState := eEncActCalibState_BottomEndSensorActive ;25 ELSIF pbSenRotEnd2 ^ THEN26 emCalibrateState := eEncActCalibState_NotAtBottom ;27 END_IF2829 eEncActCalibState_NotAtBottom :30 ////Set Mc Function blocks31 fbMcMoveVelocity . Execute := TRUE ;32 fbMcMoveVelocity . Direction := MC_Negative_Direction ;33 //Determine next state34 IF NOT pbSenRotEnd2 ^ THEN35 emCalibrateState := eEncActCalibState_BottomEndSensorActive ;36 fbMcMoveVelocity . Execute := FALSE ;37 END_IF3839 eEncActCalibState_BottomEndSensorActive :40 ////Set Mc Function blocks41 fbMcMoveVelocity . Execute := TRUE ;42 fbMcMoveVelocity . Direction := MC_Positive_Direction ;43 //Determine Next state44 IF pbSenRotEnd2 ^ THEN45 emCalibrateState := eEncActCalibState_FindIndex ;46 fbMcMoveVelocity . Execute := FALSE ;47 END_IF

Method: M_Calibrate


5-2-2013 19:10

4849 eEncActCalibState_FindIndex :50 ////Set Mc Function blocks51 fbMcMoveVelocity . Execute := TRUE ;52 fbMcMoveVelocity . Velocity := fSpeedCalibSlow ;

//THIS VALUE IS CRITICAL FOR DETECTION OF ENCODER INDEX signal53 //determine next state54 IF pbEncoderIndex ^ THEN55 emCalibrateState := eEncActCalibState_SetPosition ;56 END_IF5758 eEncActCalibState_SetPosition :59 fbMcSetPosition . Position := 0.0 ;60 fbMcSetPosition . Execute := TRUE ;61 fbMcSetPosition . Mode := FALSE ;62 //Determine next state63 IF fbMcSetPosition . Done THEN64 emCalibrateState := eEncActCalibState_MoveToStart ;65 END_IF6667 eEncActCalibState_MoveToStart :68 //Set Mc Function blocks69 fbMcMoveVelocity . Execute := FALSE ;70 fbMcPower . Override := 100 ;71 fbMcSetPosition . Execute := FALSE ;72 fbMcMoveAbsolute1 . Execute := TRUE ;73 fbMcMoveAbsolute1 . Position := afRotPositions [ 1 ] ;74 //Determine next state75 IF fbMcMoveAbsolute1 . Done THEN76 emCalibrateState := eEncActCalibState_Calibrated ;77 END_IF7879 eEncActCalibState_Calibrated :80 bCalibrated := TRUE ;81 END_CASE82

Method: M_Init


8-2-2013 9:52

1 //name: M_Init2 //Version: 1.23 //Date: 08-02-2013, Joni Scholten4 //This method initializes the rotating actuator in the transport module 5 METHOD PUBLIC M_Init : BOOL6 VAR_INPUT7 stInit : ST_M_FB_TransModRotAct_Init ;8 END_VAR9 VAR10 counter : BYTE ;11 END_VAR12

1 //Check if positions are well sorted, otherwise initialisation failed2 FOR counter := 2 TO 4 DO3 IF stInit . afRotPositionsI [ counter ] < stInit . afRotPositionsI [

counter - 1 ] THEN4 M_Init := FALSE ;5 RETURN ;6 END_IF7 END_FOR89 FOR counter := 1 TO 4 DO10 afRotPositions [ counter ] := stInit . afRotPositionsI [ counter ] + stInit .

fOffsetI ;11 END_FOR12 pbSenRotEnd1 := stInit . pbSenRotEnd1 ;13 pbSenRotEnd2 := stInit . pbSenRotEnd2 ;14 pbEncoderIndex := stInit . pbEncoderIndex ;1516 bCalibrated := FALSE ;1718

//check if fast calibration speed is slower than slow calibration speed. Otherwise initialisation failed19 IF stInit . fSpeedCalibFast < stInit . fSpeedCalibSlow THEN20 M_Init := FALSE ;21 RETURN ;22 ELSE23 fSpeedCalibFast := stInit . fSpeedCalibFast ;24 fSpeedCalibSlow := stInit . fSpeedCalibSlow ;25 END_IF2627 fbMcMoveAbsolute1 . Velocity := stInit . fSpeedNormal ;2829 bInitialized := TRUE ;3031 M_Init := TRUE ;32

Figure C.10: State machine for the Transport module lift.

106

POU: FB_TransModLiftAct


5-2-2013 12:46

1 //name: FB_TransModLiftAct2 //Version: 1.43 //Date: 15-01-2012, Joni Scholten4

//This Function block is defined in the document UML_class_diagram_software_1link_mock-up5

//This Function block is described in the document software_UML_Statediagrams6 //Function block represents the lifting actuator in the transport module7 FUNCTION_BLOCK FB_TransModLiftAct EXTENDS FB_Act8 VAR_INPUT9 END_VAR10 VAR_OUTPUT11 bSenLiftDownO : BOOL ; //TRUE -> Bottom lift sensor is activated12 bSenLiftUpO : BOOL ; //TRUE -> Top lift sensor is activated13 bMovingUpO : BOOL ;

//TRUE: lift moves up, FALSE: lift moves down14 END_VAR15 VAR16 eState : E_FB_TransModLiftActStates ;17 pbMoveLiftAct : POINTER TO BOOL ;

//TRUE--> lift actuator moves, FALSE-->lift is stopped18 pbDirLiftAct : POINTER TO BOOL ;

//determines direction of lift actuator19 pbSenLiftUp : POINTER TO BOOL ;20 pbSenLiftDown : POINTER TO BOOL ;21 END_VAR22

1 CASE eState OF2 eTransLiftState_Disabled :3 //Outputs4 bStatusO := FALSE ;5 bBusyO := FALSE ;6 bDoneO := FALSE ;7 bMovingUpO := FALSE ;8 //internal variables9 pbMoveLiftAct ^ := FALSE ;10 //Determine next state11 IF bEnableI AND bInitialized THEN12 eState := eTransLiftState_MovingDown ;13 ELSIF bEnableI AND NOT bInitialized THEN14 eState := eTransLiftState_Error ;15 END_IF1617 eTransLiftState_MovingDown :18 //Outputs19 bBusyO := TRUE ;20 bDoneO := FALSE ;21 bMovingUpO := FALSE ;22 //internal variables23 pbMoveLiftAct ^ := TRUE ;24 pbDirLiftAct ^ := FALSE ;25 //Determine next state26 IF NOT pbSenLiftDown ^ THEN27 eState := eTransLiftState_LiftDown ;28 END_IF



5-2-2013 12:46

2930 eTransLiftState_LiftDown :31 //Outputs32 bBusyO := FALSE ;33 bDoneO := TRUE ;34 bMovingUpO := FALSE ;35 //internal variables36 pbMoveLiftAct ^ := FALSE ;37 //Determine next state38 IF NOT bExecuteI THEN39 eState := eTransLiftState_ReadyForNewTaskDown ;40 END_IF4142 eTransLiftState_ReadyForNewTaskDown :43 //Outputs44 bStatusO := TRUE ;45 bBusyO := FALSE ;46 bDoneO := TRUE ;47 bMovingUpO := FALSE ;48 //internal variables49 pbMoveLiftAct ^ := FALSE ;50 //Determine next state51 IF bExecuteI THEN52 eState := eTransLiftState_MovingUp ;53 END_IF5455 eTransLiftState_MovingUp :56 //Outputs57 bStatusO := TRUE ;58 bBusyO := TRUE ;59 bDoneO := FALSE ;60 bMovingUpO := TRUE ;61 //internal variables62 pbMoveLiftAct ^ := TRUE ;63 pbDirLiftAct ^ := TRUE ;64 //Determine next state65 IF NOT pbSenLiftUp ^ THEN66 eState := eTransLiftState_LiftUp ;67 END_IF6869 eTransLiftState_LiftUp :70 //Outputs71 bStatusO := TRUE ;72 bBusyO := FALSE ;73 bDoneO := TRUE ;74 bMovingUpO := TRUE ;75 //internal variables76 pbMoveLiftAct ^ := FALSE ;77 //Determine next state78 IF NOT bExecuteI THEN79 eState := eTransLiftState_ReadyForNewTaskUp ;80 END_IF8182 eTransLiftState_ReadyForNewTaskUp :83 //Outputs84 bStatusO := TRUE ;



5-2-2013 12:46

85 bBusyO := FALSE ;86 bDoneO := TRUE ;87 bMovingUpO := TRUE ;88 //internal variables89 pbMoveLiftAct ^ := FALSE ;90 //Determine next state91 IF bExecuteI THEN92 eState := eTransLiftState_MovingDown ;93 END_IF9495 eTransLiftState_Error :96 bErrorO := TRUE ;97 IF NOT bInitialized THEN98 nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;99 END_IF100 //Determine next state101 IF bResetI := TRUE THEN102 eState := eTransLiftState_Reset ;103 END_IF104105 eTransLiftState_Reset :106 bErrorO := FALSE ;107 nErrorIDO := 0 ;108 IF bResetI := FALSE THEN109 eState := eTransLiftState_Disabled ;110 END_IF111 END_CASE112113 IF NOT bEnableI THEN114 eState := eTransLiftState_Disabled ;115 END_IF116117 bSenLiftDownO := NOT pbSenliftDown ^ ;118 bSenLiftUpO := NOT pbSenLiftUp ^ ;119

Method: M_Init


5-2-2013 12:47

1 //name: M_Init2 //Version: 1.03 //Date: 14-12-2012, Joni Scholten4 //This method initializes the Lift actuator in the Transport module 5 METHOD PUBLIC M_Init : BOOL6 VAR_INPUT7 stInit : ST_M_FB_TransModLiftAct_Init ;8 END_VAR9

1 pbMoveLiftAct := stInit . pbMoveLiftAct ;2 pbDirLiftAct := stInit . pbDirLiftAct ;3 pbSenLiftUp := stInit . pbSenLiftUp ;4 pbSenLiftDown := stInit . pbSenLiftDown ;5 bInitialized := TRUE ;6 M_Init := TRUE ;7

Figure C.11: State machine for the Transport module manipulator.

111

POU: FB_TransModManipAct


5-2-2013 19:07

1 //name: FB_TransModManAct2 //Version: 1.23 //Date: 15-01-2013, Joni Scholten4

//This Function block is defined in the document UML_class_diagram_software_1link_mock-up5 //Function block represents the manipulator actuator in the transport module6 FUNCTION_BLOCK FB_TransModManipAct EXTENDS FB_Act7 VAR_INPUT8 END_VAR9 VAR_OUTPUT10 bSenManipInEndO : BOOL ;

//TRUE -> Manipulator inward end sensor is activated.11 bSenManipOutEndO : BOOL ;

//TRUE -> Manipulator outward end sensor is activated.12 bSenManipInO : BOOL ;

//TRUE -> Manipulator inward sensor is activated13 bSenManipOutO : BOOL ;

//TRUE -> Manipulator outward sensor is activated.14 bMovingOutO : BOOL ;

//TRUE -> Manipulator is moving out, or standing still at outward position15 END_VAR16 VAR17 eState : E_FB_TransModManipActStates ;

//states for transport manipulator18 //function blocks19 fbTimer : TON ; //timer functionblock20 //normal variables21 nSpeedFast : INT ;22 nSpeedSlow : INT ;23 timeFastMovement : TIME ;2425 //pointers26 pbActLinEnable : POINTER TO BOOL ;27 pnSetPlus : POINTER TO INT ;28 pnSetMin : POINTER TO INT ;29 pbSenManipInEnd : POINTER TO BOOL ;30 pbSenManipOutEnd : POINTER TO BOOL ;31 pbSenManipIn : POINTER TO BOOL ;32 pbSenManipOut : POINTER TO BOOL ;3334 END_VAR35

1 CASE eState OF2 eTransManipState_Disabled :3 //Outputs4 bStatusO := FALSE ;5 bBusyO := FALSE ;6 bDoneO := FALSE ;7 bErrorO := FALSE ;8 nErrorIDO := 0 ;9 bMovingOutO := FALSE ;10 //internal variables11 IF bInitialized THEN12 pbActLinEnable ^ := FALSE ;13 END_IF



5-2-2013 19:07

14 //Determine next state15 IF bEnableI AND bInitialized THEN16 eState := eTransManipState_MoveInSlow ;17 ELSIF NOT bInitialized THEN18 eState := eTransManipState_Error ;19 END_IF2021 eTransManipState_MoveInSlow :22 //Outputs23 bBusyO := TRUE ;24 bDoneO := FALSE ;25 bMovingOutO := FALSE ;26 //internal variables27 pbActLinEnable ^ := TRUE ;28 fbTimer . IN := FALSE ;29 //SET SLOW SPEED////////////////////////////////////////////////////30 pnSetPlus ^ := - 1 * nSpeedSlow ;31 pnSetMin ^ := nSpeedSlow ;32 //Determine next state33 IF NOT pbSenManipIn ^ THEN34 eState := eTransManipState_StoppedIn ;35 END_IF3637 eTransManipState_StoppedIn :38 //Outputs39 bBusyO := FALSE ;40 bDoneO := TRUE ;41 bMovingOutO := FALSE ;42 //internal variables43 pbActLinEnable ^ := FALSE ;44 //determine next state45 IF NOT bExecuteI THEN46 eState := eTransManipState_ReadyForNewTaskIn ;47 END_IF4849 eTransManipState_ReadyForNewTaskIn :50 //Outputs51 bStatusO := TRUE ;52 bBusyO := FALSE ;53 bDoneO := TRUE ;54 bMovingOutO := FALSE ;55 //internal variables56 pbActLinEnable ^ := FALSE ;57 //determine next state58 IF bExecuteI THEN59 eState := eTransManipState_MoveOutFast ;60 END_IF6162 eTransManipState_MoveOutFast :63 //Outputs64 bStatusO := TRUE ;65 bBusyO := TRUE ;66 bDoneO := FALSE ;67 bMovingOutO := TRUE ;68 //internal variables69 pbActLinEnable ^ := TRUE ;



5-2-2013 19:07

70 //SET FAST SPEED/////////////////////////////////////////71 pnSetPlus ^ := nSpeedFast ;72 pnSetMin ^ := - 1 * nSpeedFast ;73 fbTimer . IN := TRUE ;74 fbTimer . PT := timeFastMovement ;75 //determine next state76 IF fbTimer . Q OR NOT pbSenManipOut ^ THEN77 eState := eTransManipState_MoveOutSlow ;78 END_IF7980 eTransManipState_MoveOutSlow :81 //Outputs82 bStatusO := TRUE ;83 bBusyO := TRUE ;84 bDoneO := FALSE ;85 bMovingOutO := TRUE ;86 //internal variables87 pbActLinEnable ^ := TRUE ;88 //SET SLOW SPEED/////////////////////////////////////////89 pnSetPlus ^ := nSpeedSlow ;90 pnSetMin ^ := - 1 * nSpeedSlow ;91 fbTimer . IN := FALSE ;92 //Determine next state93 IF NOT pbSenManipOut ^ THEN94 eState := eTransManipState_StoppedOut ;95 END_IF9697 eTransManipState_StoppedOut :98 //Outputs99 bStatusO := TRUE ;100 bBusyO := FALSE ;101 bDoneO := TRUE ;102 bMovingOutO := TRUE ;103 //internal variables104 pbActLinEnable ^ := FALSE ;105 //Determine next state106 IF NOT bExecuteI THEN107 eState := eTransManipState_ReadyForNewTaskOut ;108 END_IF109110 eTransManipState_ReadyForNewTaskOut :111 //Outputs112 bStatusO := TRUE ;113 bBusyO := FALSE ;114 bDoneO := TRUE ;115 bMovingOutO := TRUE ;116 //internal variables117 pbActLinEnable ^ := FALSE ;118 //determine next state119 IF bExecuteI THEN120 eState := eTransManipState_MoveInFast ;121 END_IF122123 eTransManipState_MoveInFast :124 //Outputs125 bStatusO := TRUE ;



5-2-2013 19:07

126 bBusyO := TRUE ;127 bDoneO := FALSE ;128 bMovingOutO := FALSE ;129 //internal variables130 pbActLinEnable ^ := TRUE ;131 //SET FAST SPEED/////////////////////////////////////////132 pnSetPlus ^ := - 1 * nSpeedFast ;133 pnSetMin ^ := nSpeedFast ;134 fbTimer . IN := TRUE ;135 fbTimer . PT := timeFastMovement ;136 //determine next state137 IF fbTimer . Q OR NOT pbSenManipIn ^ THEN138 eState := eTransManipState_MoveInSlow ;139 END_IF140141 eTransManipState_MoveInSlowDis :142 //Outputs143 bStatusO := FALSE ;144 bBusyO := TRUE ;145 bDoneO := FALSE ;146 //bMovingOutO:=FALSE;147 //internal variables148 pbActLinEnable ^ := TRUE ;149 fbTimer . IN := FALSE ;150 //SET SLOW SPEED////////////////////////////////////////////////////151 pnSetPlus ^ := - 1 * nSpeedSlow ;152 pnSetMin ^ := nSpeedSlow ;153 //Determine next state154 IF NOT pbSenManipIn ^ THEN155 eState := eTransManipState_Disabled ;156 END_IF157158 eTransManipState_Error :159 //Outputs160 bErrorO := TRUE ;161 bDoneO := FALSE ;162 bBusyO := FALSE ;163 //internal variables164 IF bInitialized THEN165 pbActLinEnable ^ := FALSE ;166 END_IF167 //Get error codes168 IF NOT bInitialized THEN169 nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;170 ELSIF pbSenManipInEnd ^ OR NOT pbSenManipOutEnd ^ THEN171 nErrorIDO := GetErrorCode ( Error_EndSensorActivated ) ;172 END_IF173 //Determine next state174 IF bResetI THEN175 eState := eTransManipState_Reset ;176 END_IF177178 eTransManipState_Reset :179 //Outputs180 bErrorO := FALSE ;181 nErrorIDO := 0 ;



5-2-2013 19:07

182 //internal variables183 IF bInitialized THEN184 pbActLinEnable ^ := FALSE ;185 END_IF186 //Determine next state187 IF NOT bResetI THEN188 eState := eTransManipState_Disabled ;189 END_IF190191 END_CASE192193 IF bInitialized THEN194 //END sensors activated --> problem195 IF pbSenManipInEnd ^ OR pbSenManipOutEnd ^ THEN196 eState := eTransManipState_Error ;197 ELSIF NOT bEnableI AND eState <> eTransManipState_Disabled AND

eState <> eTransManipState_Error THEN //disable function block198 eState := eTransManipState_MoveInSlowDis ;199 END_IF200201 //set outputs202 bSenManipInO := NOT pbSenManipIn ^ ;203 bSenManipOutO := NOT pbSenManipOut ^ ;204 bSenManipInEndO := pbSenManipInEnd ^ ;205 bSenManipOutEndO := pbSenManipOutEnd ^ ;206 END_IF207208 fbTimer ( ) ;209

Method: M_Init


8-2-2013 9:57

1 //name: M_Init2 //Version: 1.23 //Date: 08-02-2013, Joni Scholten4 //This method initializes the manipulator actuator in the Transport module 5 METHOD PUBLIC M_Init : BOOL6 VAR_INPUT7 stInit : ST_M_FB_TransModManipAct_Init ;8 END_VAR9

1 timeFastMovement := stInit . timeFastMovement ;23

//check if speeds are well defined between 0.0 and 100.0, otherwise initialisation failed4 IF stInit . fSpeedFast < stInit . fSpeedSlow OR stInit . fSpeedFast < 0.0

OR stInit . fSpeedFast > 100.0 OR stInit . fSpeedSlow < 0.0 OR stInit .fSpeedSlow > 100.0 THEN

5 M_Init := FALSE ;6 RETURN ;7 ELSE8 nSpeedFast := REAL_TO_INT ( stInit . fSpeedFast / 100 * ( EXPT ( 2 ,

15 ) - 1 ) ) ;9 nSpeedSlow := REAL_TO_INT ( stInit . fSpeedSlow / 100 * ( EXPT ( 2 ,

15 ) - 1 ) ) ;10 END_IF1112 pbActLinEnable := stInit . pbActLinEnable ;13 pnSetPlus := stInit . pnSetPlus ;14 pnSetMin := stInit . pnSetMin ;15 pbSenManipInEnd := stInit . pbSenManipInEnd ;16 pbSenManipOutEnd := stInit . pbSenManipOutEnd ;17 pbSenManipIn := stInit . pbSenManipIn ;18 pbSenManipOut := stInit . pbSenManipOut ;1920 bInitialized := TRUE ;2122 M_Init := TRUE ;23

118

Appendix D

Software extra

D.1 GetErrorCode

Providing a user with information about the occurrence of an error is crucial for debuggingpurposes. It is common practice to use a error coding system to provide this information.The error coding of the module and actuator function blocks is an extension of the error codesfound in the MC function blocks of the Tc2 MC library. All error codes starting with 4... inhexadecimal coding are directly related to the TwinCAT tc2 MC library. More informationon these codes can be found in the TwinCAT help file under Beckhoff Information System/ TwinCAT 3 / TwinCAT 3 Motion / TwinCAT NC Error Codes / Overview. Figure D.1shows this page.

Figure D.1: TwinCAT help file NC Error Codes overview

Next to these predefined error codes some specific ”LCT mock-up” error codes are added.These are defined in an enumeration called E ErrorCodes and the function GetErrorCode

119

translates this enumeration into an error code. Figure D.2a shows the ST (structured text)code of E ErrorCodes, and Figure D.2b shows the ST code for the GetErrorCode function.The function GetErrorCode is called inside the error state of an actuator of module FBstatemachine. Future users can introduce new error codes when needed by adding a new line

(a) Structured text code ofE ErrorCodes enumeration. (b) Structured text code of the GetErrorCode function.

Figure D.2

to the enumeration and adding that enumeration type in the GetErrorCode function. FigureD.3 shows how to use the GetErrorCode function, the example is taken from the statemachineof the lift actuator in the Transport module.

Figure D.3: ST code of the error state of the lift actuator in the Transport module.

D.2 Initialize all

The function Initialize all can be used to initialize all modules used in the mock-up. Thisfunction can be called from any test program, instead of initializing all modules inside everynew test program.

120

POU: Initialize_all


4-2-2013 16:00

1 //15-01-2013 Joni Scholten2 //this function is used to initialize all modules of the 1 link mock-up. 3 //NB: calibration of the encoders is not performed with this function4 FUNCTION Initialize_all : bool5 VAR_INPUT6 END_VAR7 VAR8 //IO module9 stInitIOLiftAct : ST_M_FB_IOModLiftAct_Init ;10 stInitIOModule : ST_M_FB_IOModule_Init ;11 afLiftPosistions : ARRAY [ 1 .. 10 ] OF LREAL ;12 nCounter : BYTE ;1314 //Transport module15 stInitTransLiftAct : ST_M_FB_TransModLiftAct_Init ;16 stInitTransRotAct : ST_M_FB_TransModRotAct_Init ;17 stInitTransManipAct : ST_M_FB_TransModManipAct_Init ;18 stInitTransportModule : ST_M_FB_TransportModule_Init ;19 afTransRotPositions : ARRAY [ 1 .. 4 ] OF LREAL ;20 END_VAR21

1 //initialize I/O module2 FOR nCounter := 1 TO 10 DO3 afLiftPosistions [ nCounter ] := ( nCounter - 1 ) * 14.0 ;4 END_FOR5 stInitIOLiftAct . afLiftPositionsI := afLiftPosistions ;6 stInitIOLiftAct . fOffsetI := 10.0 ;7 stInitIOLiftAct . pbSenLiftBottom := ADR ( bIOLiftBottomEndSenI ) ;8 stInitIOLiftAct . pbSenLiftTop := ADR ( bIOLiftTopEndSenI ) ;9 stInitIOLiftAct . pbEncoderIndex := ADR ( bIOLiftEncoderIndexI ) ;10 stInitIOLiftAct . fSpeedCalibSlow := 0.5 ;11 stInitIOLiftAct . fSpeedCalibFast := 2.5 ;12 stInitIOLiftAct . fSpeedNormal := 50.0 ;13 stInitIOModule . stLiftInit := stInitIOLiftAct ;14 stInitIOModule . pbWaferSensor := ADR ( bIOWaferSensorI ) ;15 //disable IO module16 fbIOModule . bEnableI := FALSE ;17 fbIOModule . bExecuteI := FALSE ;18 fbIOModule . bResetI := FALSE ;1920 //initialize Transport module21 //lift actuator22 stInitTransLiftAct . pbMoveLiftAct := ADR ( bTransLiftEnableO ) ;23 stInitTransLiftAct . pbDirLiftAct := ADR ( bTransLiftDirectionO ) ;24 stInitTransLiftAct . pbSenLiftUp := ADR ( bTransLiftSenUpI ) ;25 stInitTransLiftAct . pbSenLiftDown := ADR ( bTransLiftSenDownI ) ;26 //disable lift actuator27 //fbTransModLiftAct.bExecuteI:=FALSE;28 //fbTransModLiftAct.bEnableI:=FALSE;29 //Rotation actuator30 FOR nCounter := 1 TO 4 DO31 afTransRotPositions [ nCounter ] := ( nCounter - 1 ) * 90 ;32 END_FOR33 stInitTransRotAct . afRotPositionsI := afTransRotPositions ;34 stInitTransRotAct . fOffsetI := 9.25 ;

POU: Initialize_all


4-2-2013 16:00

35 stInitTransRotAct . pbSenRotEnd1 := ADR ( bTransRotSenEnd1I ) ;36 stInitTransRotAct . pbSenRotEnd2 := ADR ( bTransRotSenEnd2I ) ;37 stInitTransRotAct . pbEncoderIndex := ADR ( bTransRotEncoderIndexI ) ;38 stInitTransRotAct . fSpeedCalibSlow := 0.2 ;39 stInitTransRotAct . fSpeedCalibFast := 2.5 ;40 stInitTransRotAct . fSpeedNormal := 150 ;41 //manipulator actuator42 stInitTransManipAct . fSpeedFast := 40 ;43 stInitTransManipAct . fSpeedSlow := 5 ;44 stInitTransManipAct . pbActLinEnable := ADR ( bTransManipEnableO ) ;45 stInitTransManipAct . pbSenManipIn := ADR ( bTransManipSenInI ) ;46 stInitTransManipAct . pbSenManipOut := ADR ( bTransManipSenOutI ) ;47 stInitTransManipAct . pbSenManipInEnd := ADR ( bTransManipLimSenInI ) ;48 stInitTransManipAct . pbSenManipOutEnd := ADR ( bTransManipLimSenOutI ) ;49 stInitTransManipAct . pnSetMin := ADR ( nTransManipSetMinO ) ;50 stInitTransManipAct . pnSetPlus := ADR ( nTransManipSetPlusO ) ;51 stInitTransManipAct . timeFastMovement := T#900MS ;52 //transport module53 stInitTransportModule . stLiftInit := stInitTransLiftAct ;54 stInitTransportModule . stManipInit := stInitTransManipAct ;55 stInitTransportModule . stRotInit := stInitTransRotAct ;56 //disable transport module57 fbTransportModule . bEnableI := FALSE ;58 fbTransportModule . bExecuteI := FALSE ;59 fbTransportModule . bResetI := FALSE ;60 fbTransportModule . bEnableManipI := FALSE ;6162 Initialize_all := fbIOModule . M_Init ( stInitIOModule ) AND fbTransportModule

. M_Init ( stInitTransportModule ) ;63

D.3 Connecting a variable using TwinCAT IO

This section explains how to establish a link between a variable in a PLC program and aphysical EtherCAT channel under TwinCAT 3. As an example the variable associated withthe encoder index signal of the I/O module lift is treated. The first step is declaring a variable.It is advised to declare the variable as a global variable. This is shown in Figure D.4: linethree bIOLiftEncoderIndexI. Notice the AT%I* notation. The next step is to link this globalvariable to an EtherCAT channel using the TwinCAT I/O tab. This is shown in FigureD.5, which shows that bIOLiftEncoderIndexI is linked to channel 1 of an EL1124 EtherCATterminal.

Figure D.4: Global variables under the TwinCAT 3 PLC tab

Figure D.5: Linking a variable to a channel on an EtherCAT terminal using the TwinCAT 3I/O tab in TwinCAT 3

123

124

Appendix E

Tuning the system

This chapter covers the tuning of several parts of the system. First, the tuning of the DCmotor controllers with incremental encoder, that are used in the mock-up, is treated. Thisis followed by a description of the tuning of relevant parameters related to the real timeperformance of TwinCAT 3.

Position control: DC motor with incremental encoder

The mock-up consists of two DC motors with incremental encoder. Both these motors arecontrolled by a Beckhoff EL7342 DC motor controller, which is a hardware proportionalintegrator (PI) controller, as shown in the CoE Online registers beginning with index 8021in [2]. Configuring the controller is done using the Motion tab of TwinCAT 3, since this projectuses TwinCAT 3, as stated in Chapter 8. TwinCAT automatically recognizes the EL7342 aspart of an axis, so it creates an axis in the motion tab of TwinCAT 3. An axis in TwinCAT3 always contains, among other tabs, an textitCtrl tab, as shown in Figure E.1a. Ctrl is anabbreviation for controller and this tab contains all options with respect to the controller ofthe axis. TwinCAT 3 offers various controller types. The EL7342 is an PI controller, as statedearlier, but more complicated controllers can be selected, in which case the PC is partly usedto calculate a controller. Both a textitposition controller P (proportional controller) and anposition controller PID (with Ka) (proportional integration and differentiation) were testedon the lift of the IO-module. The transfer function of the PID controller implemented inTwinCAT Motion is shown in (E.1). A plain P controller worked fine, but a steady stateerror remained, as is always the case with this type of controller. The steady state error wasreduced by introducing the integration term in the controller. Simple tests can be run onan NC axis using the online tab of an Axis under the Motion tab in TwinCAT 3, as shownin Figure E.1b. To enable the axis, click the set button and then click ”all” in the pop-upscreen. Now it is possible to move the axis by means of the buttons in the left bottom cornerin Figure E.1b. The functions tab in Figure E.1b provides simple but useful tasks for theaxis, like for instance ”move to 10 mm with a speed of 10 mm/sec”.

G(s) = Kp(1 +1

Tns+

Tvs

1 + Tds) (E.1)

125

(a) The Motion tab in Twin-CAT 3 for the 1 link LCTmock-up.

(b) The online test environment of an Axis under the TwinCAT 3motion tab.

Tuning the PI controller

Many books and articles have been written about the tuning of a PI controller. Some of themethods require a complete model of the system to be available, while others are based onsome basic measurements on the actual system. For this project a method called The GoodGain Method [8] is used, which is a more hands on approach, rather than a theoretical method.The first step is increasing the controller gain until the control loop gets good stability. Thecontrol signal is provided to the system using the online part of the axis tab in motion part ofTwinCAT. As an example the tuning process of the lift of the I/O module will be explained,but the same method was used for tuning the controller for the rotation of the Transportmodule.Using the right settings, a step signal was approximated, and using TwinCAT Scope a stepresponse was obtained, as can be seen in Figure E.1. This step response is used to determineTou, which is the time between the undershoot (marked by blue line) and overshoot (markedby green line), as described in [8]. Next the integral action time Tn in (E.1) is set equalto Tn = 1.5Tou = 25ms. In practice it turns out that the system is less noisy when Tn isincreased to 60ms as can be seen in Figure E.2. An integration term generally slows downthe system’s response. To make the response faster, a differentiating term can be used. Adownside of this term is amplification of noise, as explained in [8]. The settling time of the liftis about 0.2 seconds, as shown in Figure E.2, which is fast enough. Therefore, a differentiatingterm is not used, meaning that both Tv and Td in (E.1) are set to zero. Figure E.3 showsthat the steady state error in the position lift of the I/O module remains within ±0.01mm.Furthermore, the resolution of the encoder is clearly visible by means of the stair case shapeof the plot.

126

Figure E.1: Determining Tou for the lift in the I/O module, as described in [8]. Screen shotof TwinCAT Scope. Tou ≈ 17ms.

(a) Tn = 25ms. (b) Tn = 60ms

Figure E.2: Step responses for the lift in the I/O module Tn = 25ms and Tn = 60ms.

127

Figure E.3: Steady state error of the position of the lift in the I/O module.

Figure E.4: Real-Time settings in TwinCAT 3.

Real-Time parameters in TwinCAT

Figure E.4 shows the Real-Time (RT) settings under the system tab in TwinCAT 3. Theydetermine the timing of all components (NC-tasks, PLC-tasks, etc.) and can result in un-expected behavior when poorly chosen. One of the most critical tasks in any machine is itsinitialization procedure. The standard RT settings of TwinCAT resulted in undefined behav-ior during initialization. The reference position was not always the same, for the completeprocedure see Chapter 8. Sometimes the lift would pass the index signal without resetting itsposition to zero. The following parameters play an important role:

Encoder resolution The DC motor in both lift of the I/O module and the rotation ofthe transport module are equipped with an incremental encoder, for more informationread [22, p.18]. The index signal of these encoders is synchronized with either channelA or B. The general formula for calculating the resolution is shown in (E.2).

resolution =2π · pulleyRadius

inc/rev · gearratio(E.2)

I/O module lift The theoretical resolution is resolution = 2π·22.28512·185193/2197 = 0.0032436246[mm/inc].

It turned out that this value resulted in a small offset. Through measurements amore accurate resolution of 0.0032580407[mm/inc] was obtained.

Transport module rotation

Input filter of encoder index signal The index signal of the encoder is connected to an

128

Beckhoff EL1124 input terminal. Each of its channels has an input filter of 0.05µs [3].

PLC task cycle time This is a TwinCAT parameter that determines how fast the PLCloop is executed. Unlike the previous two, this parameter can be adjusted.

NC task cycle time This is a TwinCAT parameter that determines how fast the numericcontroller (NC) is recalculated.

These parameters together determine how fast the lift can move during initialization. Thefollowing constraint must be met: the index signal should remain true for at least the inputfilter time and cycle time together. The input filter time is irrelevant, since the cycle time is50000 times higher than the input filter time. The index signal of the encoder is synchronizedwith either channel A or B, which are both true during two increments. This means that theindex signal is true for a distance of 2 · resolution = 0.006516mm. A new TwinCAT projectalways has a PLC cycle time of 10ms. With this setting, the lift must not move faster than0.006516

0.01 = 0.65[m/s]. During normal operation however, the lift is not moving at a constantspeed, but its speed varies with a deviation of ±1[m/s], as Figure E.5 shows. Therefore, thelift is not guaranteed to move slower than 0.65[m/s]. To make the initialization proceduremore robust, the cycle time is set to 2.5ms as shown in Figure E.4. This means that the liftmust not move faster than 0.006516

0.0025 = 2.6[m/s], which is easier satisfied and therefore morerobust. Furthermore, Figure E.6 shows that the speed deviation is reduced to ±0.65[m/s].This is probably due to the fact that the NC task cycle time is also reduced from 2ms to0.5ms, which means that the PI controller is updated more frequently.

Figure E.5: Steady state error in the speed of the lift in the I/O module. PLC cycle time =10ms. NC cycle time = 2ms.

129

Figure E.6: Steady state error in the speed of the lift in the I/O module. PLC cycle time =2.5ms. NC cycle time = 0.5ms.

130

Appendix F

OR gate circuit

This appendix briefly explains how the OR gate circuit seen in Figure F.1 works. There afive inputs, located on the right of the circuit. The input connected to the green dotted lineis supposed to be connected to the output of the initialize button of the user interface asintroduced in Chapter 6. This input makes all four outputs, located on the left of the circuit,true. The other four inputs are linked to only one output. Such an input is meant to beconnected to the output of a safety sensor chain, as shown in Figure 7.3. The chip used inthis circuit is the TEXAS 74ACT11032 Quadruple 2-input positive-OR gates chip. The ORinputs are supposed to be either 0 or 24 Volt. R1 and R2 form a voltage divider to reducethe 24 Volt signals to 5 Volt signals, to make the signals fall within the operating range ofthe OR gate chip.

131

Figure F.1: OR gate circuit as used in 1 link LCT Mock-up. Inputs are on the right side,outputs are on the left side.

132

Appendix G

Wiring codes

This appendix covers the information concerning the wiring that is present in the mock-uptool, divided in both input signals and output signals. The system in the coding is straightforward. The first letter in the code represents the module it belongs to, the digit then canbe looked up in the table for the exact signal it resembles. In Table G.1 the inputs are shownand in Table G.2 the outputs are shown.

133

Tab

leG

.1:In

pu

tsign

alsfor

the

ethercat

mod

ules.

I/O

mod

ule

Lab

eld

escriptio

nE

therC

atI1

I/O

mod

ule

enco

der

signals

(yellow=

A,

blu

e=

B,

green=

Ind

ex)

EL

7342.1+

EL

1124.1I2

grey

I/O

mod

ule

wafer

sensor

(black

=sign

al,b

lue

=0V

,b

rown

=24V

)2.1

I2yellow

I/O

mod

ule

topen

dsen

sor2.2

I2b

lue

I/O

mod

ule

bottom

end

sensor

2.3I2

green

I/O

mod

ule

hard

ware

enab

leO

RG

ate1

+E

L7342.1

Tra

nsp

ort

modu

le

T1

Tra

nsp

ort

mod

ule

enco

der

signals

(yellow=

A,

blu

e=

B,

green=

Ind

ex)

EL

7342.2T

2T

ran

sport

mod

ule

liftd

own

(black

=sign

al,b

lue=

0V,

red=

24V)

2.4T

3T

ran

sport

mod

ule

liftu

p(b

lack=

signal,

blu

e=0V

,red

=24V

)3.1

T4

Tra

nsp

ort

mod

ule

man

ipu

latorsen

sorIn

(black

=sign

al,b

lue=

0V,

brow

n=

24V)

3.2T

5T

ran

sport

mod

ule

man

ipu

latorsen

sorO

ut

(black

=sign

al,b

lue=

0V,b

rown

=24V

)3.3

T6

yellow

Tra

nsp

ort

mod

ule

man

ipu

latorlim

itsen

sorIn

3.4T

6b

lue

Tra

nsp

ort

mod

ule

man

ipu

latorlim

itsen

sorO

ut

4.1T

6b

lack

Tra

nsp

ort

mod

ule

man

ipu

latorH

Wen

able

Lin

kedto

T10

blu

eT

8T

ran

sport

mod

ule

rotationen

dsen

sor1

-¿H

Wen

able

4.2(b

lack

=sig

nal,

blu

e=0V

,brow

n=

24V)

OR

Gate

2T

9T

ran

sport

mod

ule

rotationen

dsen

sor2

-¿calib

rationsen

sor4.3

(bla

ck=

sign

al,b

lue=

0V,b

rown=

24V)

Bu

ffer

mod

ule

BB

uff

erm

od

ule

wafer

sensor

(black

=sign

al,b

lue=

0V,b

rown

=24V

)

Pro

cessm

od

ules

P1

Pro

cessm

od

ule

1w

afersen

sor(b

lack=

signal,

blu

e=0V

,brow

n=

24V)

4.4P

2P

rocess

mod

ule

2w

afersen

sor(b

lack=

signal,

blu

e=0V

,brow

n=

24V)

5.1P

3P

rocess

mod

ule

3w

afersen

sor(b

lack=

signal,

blu

e=0V

,brow

n=

24V)

134

Tab

leG

.2:

Ou

tpu

tsi

gnal

sfr

omth

eet

her

cat

mod

ule

s

I/O

mod

ule

IMI/

Om

od

ule

lift

mot

orvo

ltag

e

Tra

nsp

ort

mod

ule

T6

Red

Tra

nsp

ort

mod

ule

man

ipH

Wen

able

2.3

T10

yel

low

Tra

nsp

ort

mod

ule

man

ipse

t+1.1

T10

Gre

enT

ran

spor

tm

od

ule

man

ipse

t-1.2

T10

Blu

eT

ran

spor

tm

od

ule

man

ipto

HW

enab

leof

mot

oram

pli

fier

Lin

ked

toT

6b

lack

T11

yel

low

Tra

nsp

ort

mod

ule

lift

enab

le2.1

T11

blu

eT

ran

spor

tm

od

ule

lift

dir

ecti

on2.2

TM

Tra

nsp

ort

mod

ule

rota

tion

mot

orvo

ltag

e

135

136

Appendix H

Contact information

This appendix contains the information of every supplier that is used in the last two phases ofthis project. Some components are hard to find, for example the LED indicators on the userinterface are not found under ”LED lights 24V”, but found under the term ”24 V indicator”.Be sure to use the correct terms to specify your search as good as possible.

There weren’t always standard contact persons used, but always ask the name of the personthat is reached. This will all an easy trace if the communication is not smooth. If there is nocontact person mentioned, there was no standard contact person.

Maxon

Maxon is the supplier of all the DC motor combinations that are found in the transport andI/O module. Take into account that this supplier has a delivery time of up to six weeks.

Site: http://www.maxonmotorusa.com/maxon/view/content/index Phone: +31 (0)53 4864777

Hepcomotion

Hepcomotion is the supplier of the frame work and the accessories of the frame. Also themanipulator uses a linear guidance that is made by Hepcomotion. The delivery time can varywith each part.

Site: http://www.hepcomotion.com Phone: +31 (0)492 551290

Turck

Turck is the supplier of the inductive sensors that can be found on the process and buffermodules. This is a good supplier of sensors.

Site: http://www.turck.nl Phone: +31 (0)38 4227750 Contact person: Jacob Klaver

137

Amatec

Amatec is the supplier of the spring that applies a constant force on the main rotation axisof the transport module. It is specialized in technical springs.

Site: http://www.amatec.nl Phone: +31 (0)172 439359

Farnell

Farnell is the supplier of miscellaneous electrical components used to manufacture the inter-faces. The indicators of the user interface are also ordered from Farnell.

Site: http://www.farnell.com Phone: +31 (0)30 2417315

Brammer

Brammer is the supplier of the bearings used in the transport module. Various mechanical,hydraulic and pneumatic components are also on sale at Brammer.

Site: http://www.brammer.nl Phone: +31 (0)40 2436258

Koppe

Koppe is the supplier of various specialized mechanical components. However the productsthat are on sale at Koppe can be found on the side of the manufacturer Maedler.

Site Sale: http://koppe.nl Site Products: http://www.maedler.nl Phone: +31 (0)705119322

Baco

Baco is the supplier of buttons and lamps that are used in the control panel of the userinterface. The prices of these products are not always available on the website. The pricescan be asked in an offer from the supplier. These products can also be bought from Laumans.

Site Baco: http://www.bacocontrols.com Site Laumans: http://www.laumans.com Phone:+31 (0)495 521067

Beckhoff

Beckhoff is the supplier of the PLC’s that connect the software to the hardware. The PLC’sare the units that are hidden under the haystack of well organized wiring.

Site: http://www.beckhoff.com Phone: +31 (0)23 5185140 Contact person: Jurjen Verhoeff

138

Equipment and prototyping center

The EPC is the workshop in the TNO building where specialized parts can be manufactured.The contact person in this case is Harrie de Laat, which can help you evaluate the design andestimate the cost before the part is ordered. For smaller parts Henri Vliegen can be asked inthe workshop of mechanical engineering.

Phone Harrie: +31 (0)40 2473496 Location Harrie: TNO 0.097 Phone Henri: +31 (0)402473722 Location Henri: Gemini North 1.50

139

Documents

Linear cluster tool mockup: completing of the ï¬rst link