/ Department of
Mechanical Engineering
Systems Engineering
Linear cluster tool mockup:
completing of the first link
S.A.M. van der Burgh, H.G.M. Donkers,
J. Scholten
Where innovation starts
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 engineer
H.G.M. Donkers
0674550 Mechanical engineer
J. Scholten
0756173 Electrical engineer
February 8, 2013
Project supervisors:
Dr. ir. J.M. van de Mortel - Fronczak
Ing. H.W.A.M. van Rooy
F.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. A
cluster tool is used in the semiconductor industry for the production of microchips. These
microchips are processed in batches on a silicon wafer. The production of a wafer consists of
several processing steps. Therefore a cluster tool consists of several different modules that each
have 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 exit
the cluster tool after processing. The second type of module is the transport module, which
is 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 that
matches 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, this
module also acts as a link between two transport modules, this allows a chain of cluster tool
links to be attached to each other. This will create one big cluster tool. The last years linear
cluster tools have been designed, where links can be be connected modular. This was not
possible with traditional circular cluster tools. The linear layout exceeds the circular layout
in respect to flexibility and throughput [20] [26] [23]. The advantage of the higher throughput
can be exploited with an intelligent control system, for this reason the mock-up will be used
to test and analyze different control strategies. Apart from control strategies, modules can be
switched mutually, which will impact the efficiency of a control strategy. It should therefore
be possible to switch, remove or add modules to the cluster tool. This is a design criteria for
the mock-up. This report is the second report in a series of two reports [22]. Both reports are
based upon two previous projects of the linear cluster tool mock-up [19] [18] [24] [25]. This
report continues where the previous report ended. All modules have been designed and the
transport module and in/output module has been realized and are operational, but have not
yet been tested with the last improvements. In this report improved designs on the transport
module are realized and tested, these designs cover a transmission of the rotation with no
backlash. Also the buffer and process modules are constructed and installed on the cluster
tool. To control the hardware, software is programmed to support basic maneuvers. Due
to the fact that the biggest components have already been designed, the hardware design of
small components will not be discussed in detail. The software design will be discussed in
detail. 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 is
consistent with the criteria, the programming can begin in TwinCAT. For the testing of the
mock-up a test set up will be used that measures the important quantities with the help of a
laser that measures the distance. These measurements will then be statistically analyzed and
the 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 complete
link of the linear cluster tool mock-up with software support for basic maneuvers, a review
is made to check if the goal is met. At the end of this report a complete link of a cluster
tool mock-up is realized in hardware along with software that support basic maneuvers. This
allows the mock-up to pick up a wafer and place it in another module. The axes that are
tested satisfied the criteria, only the rotational axis of the transport module has not yet been
tested. Further results were very promising.
II
Samenvatting
Het doel van het project 4M230 is het ontwerpen en realiseren van een demonstratie model
van een lineaire cluster machine. Een cluster machine wordt gebruikt in de halfgeleider
industrie voor de productie van microchips. Deze microchips worden per batch geproduceerd
op een silicium wafer. De productie van deze wafer bestaat uit meerdere stappen. Een
cluster machine bestaat daarvoor ook uit meerdere modules met elk een eigen taak. Voor
het demonstratie model is dit versimpeld naar vier verschillende modules. Aller eerst een
in/uitvoer machine, waar de wafers de cluster machine worden ingegeven en na het verwerken
ook weer worden uitgenomen. De tweede soort machine is de transport module, die in het
midden van de cluster machine is geplaatst zodat deze alle modules kan bereiken. De derde
soort machine is een proces module, deze machine simuleert wachttijd die overeenkomt met
de echte tijd die nodig is om een wafer the bewerken. De laatste soort machine is een buffer
machine, hierin kunnen wafers tijdelijk in worden opgeslagen, ook dienen deze buffers als
doorgeefluik naar een andere transport module, zodat er een keten van schakels aan elkaar
kan worden gezet tot een grote cluster machine. Pas sinds kort zijn lineaire cluster machines
ontworpen, waarbij schakels modulair aan elkaar kunnen worden gekoppeld, ten opzichte van
de traditionele circulaire cluster machine. De lineaire layout overtreft de circulaire layout als
het gaat om flexibiliteit en doorvoersnelheid [20] [26] [23]. De voordelen van deze grotere
doorvoersnelheid kunnen nog meer worden benut met een intelligent besturingssysteem. Om
deze reden zal het demonstratie model ook uiteindelijk gebruikt worden voor het testen en
analyseren van verschillende besturingsstrategieën. Naast de besturingsstrategieën, kunnen
de modules ook onderling worden verwisseld, wat uiteindelijk ook een impact kan hebben op
efficiëntie. Het moet dus mogelijk zijn modules onderling te verwisselen, te verwijderen of
toe te voegen. Dit is daarom ook een ontwerp eis. Dit verslag is het tweede verslag in een
reeks van twee verslagen [22]. Beide verslagen zijn het gevolg van twee vorige projecten van
de lineaire cluster machine [19] [18] [24] [25]. Dit verslag haakt in op waar het vorige verslag
is geëindigd. Alle modules zijn namelijk al ontworpen en de transport module en in/uitvoer
module 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 gerealiseerd
en getest, het gaat hierbij om een speling vrije aandrijflijn van de rotatie beweging. Daarnaast
worden de buffer en proces module gebouwd en geı̈nstalleerd op de cluster machine. Om de
bestaande hardware aan te sturen zal er software worden geprogrammeerd dat elementaire
bewegingen van de hardware kan ondersteunen. Omdat de grootste componenten al zijn
ontworpen 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 volgens
een bepaalde structuur ontworpen en geprogrammeerd. Eerst wordt er een lijst van eisen
opgesteld, 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 het
uiteindelijk met een standaard norm in TwinCAT geprogrammeerd. Voor het testen zullen
test opstellingen worden gebruikt die belangrijke grootheden meten met behulp van laser
sensor die de afstand meet. Deze metingen worden dan statistisch geanalyseerd en vergeleken
met de criteria van het ontwerp, om zo uiteindelijk de opstelling te valideren. Aan de hand van
het eindproduct, een volledige schakel van de cluster machine met software ondersteuning voor
elementaire bewegingen, wordt terug gekeken of de gestelde doelen gehaald zijn. Uiteindelijk
is een volledige schakel van de cluster machine gerealiseerd in hardware en zijn elementaire
bewegingen geprogrammeerd. Het is daarmee mogelijk om een wafer op te pakken en te
plaatsen 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 veel
belovend.
IV
Contents
1 Introduction
1.1 Project objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2 Design criteria and wishes
2.1 Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Wishes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
3 The
3.1
3.2
3.3
LCT mock-up at
Mechanical . . . .
Electrical . . . . .
Software . . . . . .
start of phase 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
11
12
4 The transport module
4.1 Construction of previous designs . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 New designs for the transport module . . . . . . . . . . . . . . . . . . . . . .
15
15
17
5 The buffer and process module
5.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
22
6 The
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
.
.
.
.
.
.
.
.
25
25
25
26
26
27
27
28
28
7 Hardware safety measures
7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33
34
8 Software
8.1 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Programming environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37
38
38
user interface
Hardware or software .
General layout . . . .
Controller . . . . . . .
Modes . . . . . . . . .
Switches . . . . . . . .
Signal Lights . . . . .
Panel layout . . . . . .
Feedback panel . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9 Testing
9.1 I/O module - Lift .
9.2 Transport module 9.3 Transport module 9.4 Transport module -
. . . . . . . .
Manipulator
Rotation . .
Elevator . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
51
52
52
10 Budget
53
11 Conclusion
55
12 Recommendation
57
A Error analysis
A.1 Mean value . . . . .
A.2 Deviation . . . . . .
A.3 Student t parameter
A.4 Error propagation .
A.5 Maximum error . . .
.
.
.
.
.
63
63
63
64
64
64
B Patent study of the anti-backlash spring
B.1 Competitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Number of patents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Patent comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
65
65
65
C Software: Function Blocks and State machines
C.1 FB I/OModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 FB TransportModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
68
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D Software extra
119
D.1 GetErrorCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
D.2 Initialize all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D.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 is
a continuation on the previous 4M230 reports [22], [19], [18], [24], [25]. The project of the
mock-up covers the construction of a demonstration model to the eventual controlling of the
end 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. This
system 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 microelectronic
components [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 controlled
via a central control system. The layout of the modules is such that a transport module is
present at the center of the tool, which allows this module to transport the wafers between
the surrounding modules for processing. In this case, there are only 4 modules surrounding
the 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 is
a feature that separates the linear cluster tool from other cluster tools. In this project only
one 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 much
flexibility to the process. The wafers enter the cluster tool via an input module and exit the
cluster tool via an output module. Once in the system, the wafers are transported by the
transport module to different processing modules and if necessary, placed in a buffer module
to 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 meets
all its requirements and is capable of preforming basic tasks. This cannot be done in a single
phase, because this assignment is too big. This means that the objective for this phase is
determined 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 present
in hardware. The transport module, and the input/output module, which will be referred
to as the I/O module. These modules have been constructed in previous phases of this
course [19], [18], [24], [25]. Other parts are designed [22], but not yet constructed, this means
the 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, which
are 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 level
control. Low level control is the control and process of single inputs and outputs, that
support a high level control that defines a function. Apart from these two control levels, the
software can consist of a database and a control strategy. The database and control strategies
is beyond the goal of this phase.
The goal of this phase is therefore to assemble the link of the cluster tool and achieve basic
software 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 transport
module in Chapter 4 and the buffer and process modules in Chapter 5, which are already
designed in previous phases of this project. Followed by a new mechanical design of the user
interface in Chapter 6. These chapters will cover the entire hardware achievements on the
mock-up tool.
Apart from the hardware achievements, the software needs to be programmed to support the
required basic maneuvers, which is discussed in Chapter 8. When the basic maneuvers are
properly 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 Chapter
11. Of course, this conclusion reflects on the state of the mock-up tool at the beginning of
this 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 is
currently in the second phase of the third year, as stated in the introduction. Some global
design criteria have already been determined in previous phases of the project. In this project
these same criteria are used and supplemented with new criteria. The original criteria can
be 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 the
project.
2.1
Criteria
Given criteria hardware
• One linear cluster has a maximum width of 75 cm, the length should be chosen so that
it will fit in an elevator. A single module has a maximum footprint size of 25 cm x 25
cm.
• The mock-up consists of several different modules: an input, an output, several process
modules and a transport module.
• The electrical part of the mock-up should work on a single voltage power supply (with
a 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 the
system 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. The
type of wafer does not have to be recognized in hardware.
• The transport module should be capable of transporting wafers from one module to
another.
• Process modules have to be designed without actually performing the process, so the
wafer 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 over
180o 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 ± 1
mm.
• 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 possible
to change any process module shown in 1.1 into a buffer module, which in turn is
connected to a new transport module. That is only possible if both buffer and process
module have the same dimensions.
• Status updates and error messages should be visible during operation. These updates
and 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. The
system 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 described
by the PLCopen association [12].
2.2
Wishes
Wishes can be used, next to these constraints, to guide the design process further in a certain
direction. 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 therefore
the 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-up
tool 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 phase
2
This chapter covers the state of the system at the beginning of the second phase and enumerates the challenges that are still left to complete a link of the linear cluster mock-up tool. As
described in the introduction, previous project phases have already lead to the construction
of the transport and the I/O module. The state of the system in the beginning is important
to determine what still needs to be done, a picture of the design of the mock-up tool can be
seen in Figure 1.2.
The mock-up tool has two hardware modules that are present, the transport module and the
I/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 in
CAD. 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 control
is based on. Therefore it is essential that this part of the mock-up tool is finished first. More
information 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 from
module 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 each
module can interact with its neighbor. The transport module is not fully assembled as can
be seen in Figure 3.1a. The transport module consists of a frame with actuators that allows
the movement of the module in three degrees of freedom. A tangential movement, a radial
movement and an up and down movement. This allows the transport module to pick up wafers
and transport them between other modules. The transport module is nearing its completion
and 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 modification
to the brackets of the height sensor and the linear movement. The design and construction
of 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 design
improvements 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 some
extra 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 enter
and 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 control
and 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 buffer
module, unlike a pocess module, serves as a connection between two adjecent transport modules. Both type of modules only exist in CAD. The CAD models of the modules can be seen
in 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 with
the transport module. Furthermore, the wafer sensor and the interaction with the transport
module will need to be tested. Since these modules have no moving parts, any further tests
are not necessary.
User interface
The user interface is not part of a module of the mock-up tool. It is a separate set of panels
that allow the user to interact with the mock-up tool. The design of the user interface is not
started at the beginning of this phase. However since a user interface is a vital link for a user
friendly system it should be finished by the end this phase. To do so, the user interface must
under 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 electrical
components will be discussed. These new components will support the actuators and sensors
in their function. The eventual electrical system will consist of a number of components that
are 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 wiring
is very chaotic, which will make it difficult for others to understand. Therefore the wiring
needs to be organized and finished for the new parts. The labels of each individual set of
wires 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 of
safety measures in this system. The first type of safety measure is placing end sensors for
every moving part. This will prevent the moving parts from moving too far and causing a
failure in the system. The idea is that if the sensor state is changed the movement in that
direction is blocked. The design and implementation of this type of safety measures can be
seen in Chapter 7. The second type of safety measure is an emergency kill switch that can
be 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 reason
is to process encoder signals for the I/O module and transport module. The design of this
interface can be found in [22]. There is already one circuit available for the I/O module, but
not yet for the transport module. The second reason is that the system needs an OR-gate to
initialize properly. This OR-gate will overrule the enable signals at the initialization. More
details 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 to
be written completely. The mock-up tool should be able to preform basic actions, like picking
up a wafer and placing it in a different module. To do so, the software has to be constructed
into several layers. In order to write proper software a number of steps are required. These
steps 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 the
software can be made first the hardware parts must be finished. This means that the next
chapters will be about the hardware, starting with the transport module, which is at the
center 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 is
first designed by a project group in 2009 [19]. This means that a lot of work is already finished
on this module. This chapter will start with assembling and the construction of parts that
have 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 previous
improvements 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 of
the motor and the encoder can be found in report 4M230, 2012 phase 1 [22]. This improvement was needed to increase the performance of the rotary movement to achieve the desired
accuracy 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 the
rotary encoder with 256 counts per turn, at the back end of the combination. The second part
is the 20 W DC motor between the encoder and the gearbox. The final part is the gearbox
with a transmission ratio of 86:1. This entire combination is then slided in the axis seen in
Figure 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 stiff
connection 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. In
the previous design the attachment of the pulley to the axis was improper and had to be
redesigned. Eventually an axial clamping is designed for the pulley. This subsection covers
the assembly of this connection. The axial clamping connection consists of a number of
components that can be seen in Figure 4.3a.
(a) Exploded view of the connection between
the pulley and the axis.
(b) The connection between the pulley and the
axis.
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. The
bolts 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 rotary
motion. However to ensure that the measured position is the same as the actual position, an
anti-backlash spring is needed. This spring pulls the backlash into one direction that ensures
the measured location is reliable.
The realized design consists of a spring that delivers a constant force, which is applied to
the main axis that pulls the system in one direction through the backlash. The finished
construction 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 with
its function. This section covers the final designs that are made to finish the hardware of the
transport module.
The new designs that are needed, have to ensure an initialization procedure. This includes
the parts that are listed below.
• A bracket for the initialization and definition of the safety region for the rotary movement.
• A bracket for the initialization and definition of the safety region for the linear movement.
These brackets have already had previous versions on the mock-up tool. However the previous
versions were found improper. For the linear movement only a minor adjustment was needed
in the design, but for the rotary movement the whole concept has changed. Therefore only
the 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 area
of 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 the
rotation does not exceed 360 degrees a part of the rotation should not be permitted, that way
the maximum rotation will always stay under 360 degrees. This restriction can be achieved
with the use of a sensor. The rotating disk is not a full circle, one part of the circle is cut under
a 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 been
cut 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 a
second sensor is needed to allow the system to know at which end of the area of safe operation
it 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 within
a cycle of the encoder on the motor. This will allow the index signal of the encoder to be at
the 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 of
the 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 capacitive
sensors. In this case some left over inductive sensors were already present. This sensor had
to be checked to ensure that the sensor is compatible. The repeating accuracy of the sensor
is 0.15 mm [17]. The distance the rotary disc travels at the outer radius between two index
signals is 0.17 mm. This means that the sensor is compatible for the initialization. These
sensors are then ideally placed in the middle between two position of the manipulator. This
will ensure that both locations are accessible and the margin of error is the same at both
sides. This defines the location of the sensors in respect to the disc. The sensor bracket
needs to be mounted to the frame. These requirements lead to the design that can be seen in
Figure 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 bracket
looks as seen in Figure 4.7. The location of the initialization sensor also determines how each
of the four Module positions is labeled. Figure 4.8 shows how each module is labeled. This
layout is also used within the software. More information about software can be found in
Chapter 8 and Appendix C. This bracket is the final part that is needed to complete the
hardware on the transport module. The hardware of the I/O module was already completed
at the start of this phase. Therefore, the buffer and process module are next on the list to be
completed.
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 and
process modules is discussed. The state of the buffer and process modules is that the design
is completely finished, but the hardware is not yet constructed or validated. The design of
the buffer module can be seen in Figure 5.1a and the design of the process module can be
seen in Figure 5.1b.
(a) The buffer module.
(b) The process module.
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 to
store a wafer, this storage is either meant to simulate waiting in the process module or meant
to pass through a wafer between transport modules in the buffer module. This difference
in function also explains the difference in the design. The process module only needs to be
accessible 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. In
order to construct the buffer and process modules correctly a number of steps have to be
carried 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 the
right size, so aligning of the parts with respect to each other is the biggest challenge. The
aligning of the parts is important so that the transport module can place the wafer without
problems.
The aligning is done by carefully placing the parts in the right position with respect to another
and then force the parts to stay in place with the use of bolts, nuts and clamps. This will
ensure 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 bottom
plate, 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 construction of the buffer and process modules can be seen in Figures 5.3a and 5.3b.
(a) The buffer module.
(b) The process module.
Figure 5.3: The buffer and process modules.
These modules still need to be connected to the frame of the transport module. The attachment to the transport module is done with brackets that are designed for the profiles that
make up the frame. In Figure 5.4 these modules are attached to the transport module. The
red 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 the
system and the operator. This link consists of two parts, the first part is the information
flow from the system to the operator and the second part is the information flow from the
operator 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 tool
and its modules.
• The user interface must allow the user to enter commands into the system that are
relevant for the operation.
These requirements will allow the user to control the system without having to use TwinCAT
at every entered command. In order to design a user interface first the general layout will be
discussed, 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 for
multiple people at once, since it is a demonstration tool. Therefore a computer screen is not
compatible, since this only allows approximately five people to watch at the same time. This
means 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 the
user friendly character of the mock-up tool.
There are two sorts of concepts for the general layout of the user interface. If the entire user
interface is in one location, the system can be controlled from one point. However the cluster
tool 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 will
also have to be separated. This means that the user interface will consist of a global control
panel 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. This
section describes which switches and signal light are mandatory for the machine to be able
to operate. This is done by first describing the different states of the complete machine that
are required. After that is described which switches are required to switch between these
different states and finally the signal lights that are required to show the operator in which
state the machine is.
6.4
Modes
The different Modes are divided in different categories. The categories that are used are operation mode, initialization,run mode and error. The categories are described in the different
paragraphs.
Operation mode
The first requirement for the states of the machines is that it should be able to have a manual
operation and an automatic operation. The manual operation is required to test the single
axes in the machine. The automatic mode is the mode in which the motion is controlled by
a 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 end
sensors of all the axis disable the power to the motors. When the system is in its off state
it is possible that the different axis enable the end sensors. When the switches are enabled
it becomes impossible for the system to move out of this position. Therefore it is necessary
to overrule the end sensors with an extra manually operated switch. From this requirement
come all the machine states that have to do with initialization. The first state is the state
in which the system is uninitialized. The second state is the state in which the machine is
performing an initialization. In this state it is mandatory that the extra manual switch is
enabled, to override the limit switches. The third state is the state in which the machine is
initialized.
• Uninitialized.
• Initializing.
• Initialized.
26
Run mode
The third category is for the run mode of the system. The run mode describes the operation
state of automatic control by the software. The first state is the off state. In this state the
automatic mode is off. The second state is the on state. In this state the automatic mode
is operational. The third state is the pause state. This state is used to make small changes
during operation, for example to move a wafer if it is not correctly aligned. The advantage
is that the data collected during operation is maintained. The fourth state is the state in
which the system is shutting down. The system will no longer introduces new wafers into the
system, it will only place wafers into a I/O module. After all the wafers are placed in I/O
modules 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 two
states. 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 overrule
the end sensors.
There should be three pushbuttons to control the run mode of the system. The first button
will start the system, the second button places the system in the pause mode and the third
button 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 the
non-error state.
6.6
Signal Lights
In principle it is necessary to have a signal light for all the categories to show in which state
the system is. A single signal light has to show four states for the run mode. This is possible
because the signal light can also be in four different states. These states are on, off, slow
flashing 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 and
S refers to a switch.
6.8
Feedback panel
In this section the concepts and design of the feedback panel will be discussed. The feedback
panel must give a quick and accurate overview of the state of the link. This means that the
user will have to be able to see where what happens at any time. For example, if a error occurs
in a sensor of the transport module, an error should be visible which will tell the user that
the error is in the transport module. This quick definition of the state of each module can be
tricky. 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 and
no 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 not
capable of a new process. The third state will indicate that an error has occurred during the
processing of the wafer.
28
In order to show correctly which state the module is currently in, three types of signals need
to 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 at
each moment the state of the module can be determined. If an interval is used it becomes
discontinuous, this is because a flashing signal is a combination of the on signal and the off
signal. This means that an observation of several seconds is needed to accurately determine
the state of a module. It also makes the feedback panel less clear than with different color
signals. 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 of
concepts is necessary, to better look into the possibilities. The concepts for the user interface
are 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 the
visual aspect.
Linking the panels into one cluster
It is possible to connect the feedback panels of each link to the control panel to create one
cluster 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 this
concept is that all the buttons in the same place make it harder to distinguish the signals
from 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 easier
to distinguish which signal belongs to which module. However this will lead to a feedback
that is not in one place. An assembly of the feedback panel that is attached to the process
module 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. There
are now less signals in the same spot, which makes it easier to observe the state the module
is in.
Selection of concept
The two concepts above both have a drawback in the feedback, as is discussed earlier. Therefore the concept is selected where the drawback can be handled the best. This leads to the
selection of having feedback panel at each link of the cluster tool. The division of the feedback
in this way allows the separate overviews to be clear.
Design
The design of the feedback panel starts with selecting the indicators. After that the layout
of 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. The
indicator 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 channels
needed. This in turn determines which and how many Beckhoff EtherCAT digitial output
modules 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 both
the green and red LED is active, the color is yellow. This means that one less output signal
is needed for each indicator. The control of this indicator can be achieved via two separate
signals.
Panel geometry
The panel geometry is restricted by the dimensions of the process module. This means that
all 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 a
good 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 easy
to determine which module gives the signal. In case there is still any doubt, labels are
added. The extra space the label requires gives a slightly different offset between vertical and
horizontal distance.
A final thing is to determine how the feedback panel is attached to the frame. To achieve
a nice finish it is chosen to mount the feedback panel on the inside of the frame. The CAD
assembly 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 necessary
to 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 button
is pushed, this will result in a full stop for all DC motors, except the lift in the transport
module, which is connected to another 24 Volt source. Both software and hardware failures
can cause a system malfunction. To prevent software failures causing damage, hardware safety
measures are needed, next to this manually operated emergency button. The malfunction that
is 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 the
rotational and linear movement of the the transport module. Without any safety measures
the lift in the I/O module could damage some of its parts, for instance its gearbox, if not
stopped when it reaches one of its end points. Consequences of movements outside the normal
region of operation are more serious for the rotating movement of the transport module. This
can 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 software.
• The solution must preserve the passive breaking provided by the magnetic field in the DC
motor. 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 the
motor should be allowed to move away from an endpoint-sensor, even if this sensor is
activated.
• 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 motor
voltage directly, or should they just generate a signal, which in turns blocks destructive
movement? 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, the
transport module uses inductive sensors, which most certainly are not up to this task. In that
case, extra relays are therefore needed to implement direct switching of motor current. The
second reason is that the software cannot see what the switching state is of an end sensor
if the motor currents are switched directly. Given these results, it is chosen to let the end
sensors switch a signal in stead of motor current.
However, the main goal of the end switches is blocking destructive motor movements. During
this project two wiring alternatives that block destructive movement were investigated. The
first 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 is
feasible. During a previous project [25] this technique was used in the wiring of the end
switches of the manipulator of the transport module.
The second solution is shown in Figure 7.1. This solution is based on an assumption that has
to be verified. It assumes that both motor outputs A1 and A2 are kept at 0 Volts, and only
the voltage of one of them is positive at any instance. A simple test was performed and the
assumption was verified, since the voltage between A1 or A2 and the ground turns out to be
only several milli Volts. This wiring scheme ensures that the lift motor is short circuited when
an end sensor is activated. This can be seen when considering the situation in which the lift
is moving upwards and activates the top end sensor. Moving upwards means that the voltage
at terminal A1 is zero and terminal A2 is positive. Figure 7.1 shows that terminal A2 is cut
off by the top microswitch and the corresponding motor terminal is connected to the 0 Volt
terminal of the voltage source. If A2 stays positive, A1 must stay 0 Volt and the DC motor is
breaking on its own internal magnetic field, since both the DC motor terminals see the same
voltage. Furthermore, if the software decides to send the lift downwards, away from the top
microswitch, it makes A1 high and as a consequence A2 is kept at 0 Volt. In this situation
the DC motor will actively move, since A1 is still connected to the DC motor, and the other
DC motor terminal is kept at 0 Volt independent of the state of the top microswitch. The
wiring of the bottom microswitch is based on the same design, but is connected to the other
DC motor terminal.
To be sure the Beckhoff EL7342 DC motor controller, used to control the lift in the I/O module, is not damaged using this wiring, the manufacturer was contacted [3]. They replied that
this wiring schematic could damage the controller, since at the switching moments the current
through 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 represents the inductance of an inductor in Henry, Vind represents the voltage across the inductor
terminals and Iind stands for the current through the indoctor. In general an instantaneous
change results in an infinite derivative. This formula clearly shows that an instantaneous
change in current through an inductor results in an infinitely large voltage across its terminals. In reality the voltage across the DC motor will not be infinite, but it could very well
be 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 motor
current.
Beckhoff suggested to use input channel I1 on the controller in Figure 7.1 as an hardware
enable input, which is one of the predefined functions of this input. This function can be
changed by editing the COE-online register of the EL7342 DC motor controller EtherCAT
terminal.
Vind =
dIind
·L
dt
(7.1)
There exist several possibilities, sometimes called snubbers, to counter act inductive voltage
peaks. Two possible solutions are shown in Figure 7.2. However, Beckhoff insisted on using
a hardware enable input, instead of snubbers. Given these arguments it seems that the best
solution 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 incremental
encoder. This is only possible if the end switches are overruled during an initialization procedure. This can be implemented by an extra manual initialization switch. The final wiring
schematic is shown in Figure 7.3. The signal labeled Initialization active signal is either 0
Volt or 24 Volt and is controlled by the software. This ensures that the end sensors are only
deactivated during an initialization procedure. After initialization, the software sets the Initialization active signal to 0 Volt and thereby disables the ability of the manually operated
initialization 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 and
Rot Sensor 2 for the Transport module in Figure 7.3
Using OR gates is just one feasible solution. An equally functional circuit might incorporate
extra relays. However, OR gates are in general a factor 10 cheaper then relays. Therefore
OR gates are used in this circuit. A design for the implemented OR gate circuit is available
in Appendix
This implementation requires some extra measures. The first measure is that standard OR
gates work at a supply voltage of 5 Volt. On the other hand, most input modules bought by
the previous group work with 24 Volt signals. Since damping a signal can be done without
active electronics, it is better to let the end switching signals be 24 Volt. The inputs to the
OR gates are then scaled down by using simple voltage divider circuits. Fortunately, the
hardware 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 encoder
index signals. Since the inputs on the EL7342 module are now in use as hardware enable
inputs, the encoder index signal needs to be connected to a seperate module. The encoder
index signal, however, has an amplitude of 5 Volt and is therefore not suited as input for an
EL1104 module, as stated earlier. Fortunately, the Beckhoff EL1124 digital input module can
work with 5 Volt input signals.
Figure 7.3: Wiring concept based on hardware enable, incorporating initialization switch and
OR gates.
36
Chapter 8
Software
This chapter covers the design of software applications for the LCT mock-up. First the design
considerations 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 phase
uses a top down view. To create a subdivision in functionality this section starts with a
description of the desired behavior of the different modules in the mock-up. This is followed
by defining outputs for the different module function blocks. Next, the inner workings of each
module function block is covered. This way, design and programming are divided into several
smaller 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 new
criteria 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. The
system 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 the
PLCopen association [12].
The last design criterion, mentioning the IEC 61131-3, requires an introduction. According
to the PLCopen website, IEC 61131 is the only global standard for industrial control programming. It harmonizes the way people design and operate industrial controls by standardizing
the programming interface. A standard programming interface allows people with different
backgrounds and skills to create different elements of a program during different stages of
the software lifecycle: specification, design, implementation, testing, installation and main37
tenance [12]. Respecting the rules and programming conventions used in this standard will
probably 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. An
argument favoring CodeSys 3 is that during a previous project some basic testing scripts were
written using CoDeSys 3 [25]. On the other hand, since TwinCAT 3 and CoDeSys 3 support
the same programming languages, scripts that work in one environment are expected to be
compatible with the other environment too.
However, TwinCAT 3 has two advantages over CoDeSys 3. Firstly, TwinCAT 3 is designed
to be accessible for MATLAB, and can make use scripts written in C++. Future users of
this LCT mock-up might benefit from these extensions, which for instance enables them to
analyze the results of their supervisor design directly in MATLAB. The second advantage is
that 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. In
general 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 CoDeSys
3 can only run for an hour, after which it has to be reset. This reset sometimes requires that
the 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 learning
how to use it might be more challenging.
Based on these arguments TwinCAT 3 is chosen to be the first choice. It has some clear
advantages over CoDeSys 3. In the first week of the second fase, placing breakpoints in
TwinCAT 3 code resulted in a fatal error, but after installing an update this issues were
resolved.
8.3
Design
PLC projects in TwinCAT3 are written using one or more of the five interchangeable programming languages as described in the IEC 61131-3 standard. Of these five, ST, or Structured
Text, will be the main language used throughout this project. Furthermore, the naming of
objects, variables and instances is done by using the programming conventions as described
in the TwinCAT 3 documentation [15]. In addition to these conventions, every function block
input 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, or
POU. A POU can be of type Program, Function or Function block. Explanation of different
POUs 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 mockup 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 function
blocks in the software are individual instances, without any knowledge of other modules in
the 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. To
this end, the module function blocks should provide the the controller with the necessary
signals 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 designing
the software. In this context, users operate on these function blocks, by providing inputs
and reading outputs. A user, in this context, is a higher level software based controller. The
function 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 into
an absolute position and the cassette lift is moved to this position. The function block
user 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 tells
which storage location is now reachable for a transport module. It is possible to assign
a new task to the function block, while it is already moving. This new task is executed
immediately.
FB TransportModule When initialized, the transport module function block accepts tasks
from the user. A task consists of two location identifiers. The first identifier tells the
transport module where to pick up a wafer. The second identifier tells where this wafer
must be transported to. In contrast with the I/O module, this function cannot receive
new tasks while performing one. Otherwise the transport module might pick up a
wafer, and suddenly try to pick up a second wafer, which is unwanted behavior. While
performing a task, the function block tells the user which task it is performing by means
of 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 transport
module wants to pick up a wafer at the I/O module. Therefore, outward movement of the
manipulator 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 retracted
and not moving or is moving.
FB ProcessModule A process module can be of a specific type (e.g. deposition, removal
process, patterning, etc. [14]). When initialized, the process module function block
accepts tasks from the user, only when a wafer is present in the process module. A task
consists 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 on
this module. If not, it should report an error. While processing, new tasks are ignored
and 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 wafer
two times, so a new task only starts when the processed wafer is removed and a new
wafer 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 a
wafer. When using this function block, extra attention must be paid to the fact that
a buffer module is accessible for two different transport modules. Since a buffermodule
is not aware of any other modules, the user must ensure the two manipulators can not
collide.
Module function block inputs and outputs and global behavior
The IEEC 61131-3 standard supports object oriented programming. Therefore, function
blocks can inherit properties from other function blocks. Since module function blocks have
some in and outputs in common, object oriented programming is applicable to these function
blocks. Figure 8.1 shows the UML class diagram of all module function blocks and their
inheritance. The diagram only contains in and outputs to reduce the information density of
this drawing. More detailed information about each function block, like specific methods or
internal variables, is introduced further on in this chapter.
FB Module This function block consists of in and outputs that are found in every module
function block.
Every module has an bEnableI input, which acts as a power on switch. Every module
checks if all its parameters (pointers and specific values) are initialized. All modules are
initialized using a public method called M Init. This method sets the internal variable
bInitialized 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 an
error, a reset can be performed on a module by making bResetI TRUE and bEnableI
and bExecuteI FALSE.
Furthermore, all modules have the following outputs. bStatusO tells if the module is
active and can receive tasks. This output is the normal end result of bEnableI. bErrorO
and 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 wafer
sensor of the buffer module senses a wafer.
FB ActiveModule This function block is derived from FB Module, and forms the
basis for the process, I/O and transport module function block.
It has one additional input, bExecuteI, by which the user can tell the function
block 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 user
that the function block is performing a task. A module cannot take a new task
while it is busy. Rising edges on bInputI are therefore ignored when bBusyO is
true. 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 initiate
an outward movement of its manipulator. This enables the user to block de40
structive movement.
Furthermore, it has three additional outputs. The first is stTransportTaskO,
which shows to the user which task the function block is performing when
bBusyO is true. When bDoneO is true, this output represents the last performed task. nLocationO is only nonzero if the rotating actuator is standing
still at one of four the predefined positions and in that case it represents which
module 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 function
block which storage location should be made accessible.
nLocationO is the counterpart of nLocationI, and tells the user which storage location is made accessible while bBusyO is true. if bDoneO is true it
represents which storage location is currently accessible. bWaferPresentO is
already 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 describes
which process type should be perfomed and how long it should be executed.
If the demanded process type does not match the process module type, then
the task is rejected by en error.
Two outputs are added, of which stProcessTaskO is the first. It is the counterpart of stProcessTaskI. If bBusyO is true it represents which task is being
performed. If bDoneO is true it represents the last perfomed task. The other
output 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 not
see 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, but
subdividing a module into different actuator function blocks results in more compact state
machines, that are easier to design, test and understand. Figure 8.2 shows the different
actuator function blocks and their inheritance. This chapter only treats the statemachine of
the FB IOModLiftAct function block. A summary of the other function blocks, both modules
and actuators can be found in Appendix C.
The functionality of most in and outputs is already discussed when treating the module
function blocks. In compliance with the module function blocks, all actuator function blocks
need to be initialized before they can be used. Every actuator function block generates an error
if it is enabled before its parameters are initialized. Furthermore, all outputs that start with
bSen 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 (normaly
open) sensor. Note that this does not have to correspond to the actual voltage output of
a sensor. For instance, the signal of a normally closed switch will be negated before it is
shown on the actuator function block output. The FB TransModLiftAct, which corresponds
to the lifting motion of the transport module, has the output bMovingUpO. This output is
true if the transport module lift is moving up, or standing still in upward position. The
FB TransModManipAct, which corresponds to the manipulator of the transport module, has
the output bMovingOutO. This output is true if the manipulator is moving out, or standing
still in outward position. More detailed information about these different actuators, such as
behavior, internal variables and specific methods is treated further on in this chapter and in
Appendix C.
Initialization of parameters and pointers
All function blocks, actuators and modules, use parameters and pointers to specific EtherCAT
in 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 is
needed to facilitate initialization of the parameters and pointers. This method is M Init and
every function block that has been designed for this project has this method. The method has
one input, which is always a struct. The type of struct differs from function block to function
block. This struct contains all parameters and pointers, needed to initialize that specific
function block. Once this method has been run successfully, it sets the internal function
block variable bInitialized to TRUE.
Error coding
Every module and actuator function block has an error code output called nErrorIDO. This
output is of type UDINT and gives information about the specific condition that caused the error. An error code generating function is implemented to ensure that every function block uses
the same number for the same error type. This function is called GetErrorCode and returns an
error 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 inheritance.
called E ErrorCodes. For instance, enabling an uninitialized function block corresponds to
an 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 bWaferPresentO
output is connected directly to the wafer sensor and the I/O module operates on the lift
function block.
FB IOModLiftAct
The I/O module function block contains one actuator, which is a lift with ten discrete positions. Its function block representation is shown in Figure 8.3. The corresponding hardware
is an DC motor with an incremental encoder. This DC motor is controlled by an Beckhoff
EtherCAT EL7342 DC motor output stage. In TwinCAT 3 such an actuator is implemented
as an NC axis which can be controlled using MC function blocks as defined in the IEC 61131-3
standard . 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 infosys helpfiles [15]. The following internal variables are located inside the FB IOModLiftAct
function block:
bInitialized BOOL, this variable is TRUE once the public method M Init has been executed
and 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 this
location 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 positions
of 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 be
initialized using public method M Init.
fSpeedCalibSlow LREAL, slow calibration speed in millimeters per second. Needs to be
initialized using public method M Init.
pbEncoderIndex POINTER TO BOOL, this pointer contains the address of the EtherCAT
input to which the physical encoder signal is connected. Needs to be initialized using
public method M Init.
pbSenLiftBottom POINTER TO BOOL, this pointer contains the address of the EtherCAT input to which the physical signal of the bottom end sensor is connected. Needs
to be initialized using public method M Init.
pbSenLiftTop POINTER TO BOOL, this pointer contains the address of the EtherCAT
input to which the physical signal of the top end sensor is connected. Needs to be
initialized 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 blocks
are reset. If the bEnableI input is true while bInitialized is false the function block generates
an 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 the
function block is ready to be activated by means of the bEnableI input. When the PLC
program is started, bCalibrated is FALSE, which means that the NC axis is not calibrated
and its exact position is unknown. A private calibration method, called M Calibrate is run if
bEnableI is TRUE and bCalibrated is false. This corresponds to the state Calibrate in Figure
8.4 This method calibrates the NC axis and sets bCalibrated to TRUE. Once calibrated the
NC axis is activated after which the function block is ready to take tasks. From now on, this
function block starts a new task when it detects a rising edge on its bExecuteI input. If the
nLocationI 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 also
generate errors. In that case the function block also generates an error and passes on the
error code of the NC axis or MC function block. Once the bResetI input is true, the function
block and all its MC function blocks are reset. After successful reset and when bResetI is
false, the function block gets back in its disabled state, after which it can be enabled using the
bEnableI input. This behavior is captured inside the state machine of the FB IOModLiftAct
function block, which is shown in Figure 8.4.
FB IOModLiftAct.M Calibrate behavior and statemachine To reduce the complexity of the previously described statemachine, calibration of the FB IOModLiftAct function
block is specified in a separate private method, called M Calibrate. The calibration procedure is as follows: first, if the lift is not at the bottom end sensor, the lift moves down. Once
the bottom end sensor is activated, the lift moves up again. When the bottom end sensor
is deactivated again the lift reduces its speed, but keeps moving until it the encoder index
signal is true. At that point the NC axis position is set to 0.0 millimeter. Finally the lift
moves to the first storage position. Figure 8.5 shows the state machine corresponding to this
description.
45
FB_IOModLiftAct 17-12-2012
Stop
From any state, excluding
Stop, Disabled,InvalidLocation,
Error and Reset, if
bEnableI:=FALSE
McHalt.execute:=TRUE
when: McHalt.Done=TRUE
Disabled
when: McReset.Done=TRUE AND
bResetI=FALSE AND bInitialized=TRUE
bTaskError:=FALSE
fbMcReset.Execute:=FALSE
bStatusO:=FALSE
bBusyO:=FALSE
bErrorO:=FALSE
bDoneO:=FALSE
fbMcPower.Enable:=FALSE
eCalibrateState:=Begin
fbMcMoveAbsolute2.Execute:=FALSE
fbMcMoveAbsolute1.Execute:=FALSE
fbMcHalt.Execute:=FALSE
Reset
fbMcReset.Execute:=TRUE
bTaskError:=FALSE
when: bResetI=TRUE
when: bCalibrated=FALSE AND
bEnableI=TRUE
Calibrate
M_Calibrate
when: bCalibrated=TRUE AND
bEnableI=TRUE
when: bInitialized:=FALSE
Error
nErrorIDO:=...
bErrorO:=TRUE
fbMcMoveAbsolute1.Execute:=FALSE
fbMcMoveAbsolute2.Execute:=FALSE
bStatusO:=FALSE
fbMcPower.Enable:=FALSE
bDoneO:=FALSE
bBusyO:=FALSE
PowerOn
From any state, excluding
Error and Reset, if
fbAxis.Status.Error:=TRUE
fbMcPower.Override:=100.0
fbMcPower.Enable_Positive = TRUE
fbMcPower.Enable = TRUE
fbMcPower.Enable_Negative = TRUE
nLocationO:=0
when: fbAxis.Status.Disabled = FALSE
InvalidLocation
when: bExecuteI=TRUE &
(nLocationI >10 OR nLocationI < 1)
bTaskError:=TRUE
Enabled
bStatusO:=TRUE
Move2
fbMcMoveAbsolute1.Execute:=FALSE
bDoneO:=fbMcMoveAbsolute2.Done
fbMcMoveAbsolute2.position:=afLiftPositions[nLocation]
nLocationO:=nLocation
bBusyO:=fbMcMoveAbsolute2.Busy
fbMcMoveAbsolute2.Execute:=TRUE
when: bExecuteI=TRUE &
(nLocationI >10 OR nLocationI < 1)
ReadyForTask1
when: bExecuteI=FALSE
fbMcMoveAbsolute2.Execute:=FALSE
bBusyO:=fbMcMoveAbsolute2.Busy
bDoneO:=fbMcMoveAbsolute2.Done
when: bExecuteI=TRUE &
0 < nLocationI <= 10 THEN
nLocation := nLocationI;
END_IF
when: bExecuteI=TRUE &
0 < nLocationI <= 10 THEN
nLocation := nLocationI;
END_IF
Move1
ReadyForTask2
when: bExecuteI=FALSE
bDoneO:=fbMcMoveAbsolute1.Done
bBusyO:=fbMcMoveAbsolute1.Busy
fbMcMoveAbsolute1.Execute:=FALSE
nLocationO:=nLocation
fbMcMoveAbsolute1.position:=afLiftPositions[nLocation]
fbMcMoveAbsolute1.Execute:=TRUE
bBusyO:=fbMcMoveAbsolute1.Busy
bDoneO:=fbMcMoveAbsolute1.Done
fbMcMoveAbsolute2.Execute:=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 define
a part of the conclusion if the chosen hardware meets the requirements. In this chapter are
different 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 movement
of 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 discussed
in 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 two
types of experiments. The first test is to determine the accuracy of the movement and the
second test is to determine the accuracy of the initialization. These two parts of the movement
determines 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. The
height is specified as the distance between the base of the lift and the bottom of the lift. The
sequence 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 again
calibrated. The experiment is run 10 times. This type of sequence is chosen to be able to
measure the accuracy of the position and the accuracy of the calibration during the same
experiment. 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 distance
sensor is not placed at the reference height.
Analysis
Every time the lift reaches its position, the laser distance sensor takes 1000 samples to measure
the position. This is done to determine the position accurate. The real position is determinant
by averaging these 1000 points. The measured position during each loop is shown in Figure
9.1A. The distribution of these 1000 data points is shown in Figure 9.1B. The distribution
of 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) 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.
The accuracy of the lift can be determined by looking at the distribution of the averaged
positions. The distribution (σ) of these averaged positions is 0.03 mm. So with an certainty
of 99 % the accuracy is 0.09 mm.
Conclusion
The measured position has a accuracy of 0.09 mm. This accuracy is significant lower than the
overall accuracy required by the system,described in Chapter 2, and therefor can be concluded
that 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 the
manipulator can be tested.
Experiment description
Analysis
The measured position during each loop is shown in Figure 9.1A. The distribution of these
1000 data points is shown in Figure 9.1B.
Figure 9.2: Data obtained from the experiments with the manipulator on the transport
module. (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 phenomena
can be described by the fact that the system is turned off between these levels. Turning off
the system can change the reference voltage for the speed of the manipulator and thereby
change the speed of the manipulator. The speed of the manipulator influences how fast the
manipulator 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 magnitude
lower than the overall accuracy required by the system,described in Chapter 2, and therefor
can 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 rotation
axis. The test could not be done due to a number of delayed parts. The construction in the
rotation axis is similar to the construction of the lift in the I/O module. Therefor is most
likely 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 finalized
completely.
9.4
Transport module - Elevator
The movement of the elevator does not require a certain precision. One of the requirements
that is applied is that the stroke of the elevator should be large enough. This requirement is
already 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 information
on the suppliers can be found in Appendix H. The product numbers of each part can be found
in the corresponding section that discussed its design. Most of these parts are designed in
phase one of this project [22]. At the end all the components and workhours add up to a
total 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
Maxon
Hepco
Turck
Amatec
Farnell
Brammer
Koppe
Baco
Beckhoff
EPC
Components
Motor + Gear + Encoder
profiles, brackets and miscellaneous
4x inductive sensors
constant force springs
electrical components and indicators
bearings
clamp, drive belt, pulley
Buttons and lamps
New ethercat termincals
work hours and material
Price
e505.05
e 275.20
e 154.40
e 28.50
e116.25
e 107.46
e 20.83
e 93.09
e 93.17
e 918.00
e 2.311.95
total
53
incl.
incl.
incl.
incl.
incl.
incl.
incl.
incl.
incl.
incl.
54
Chapter 11
Conclusion
The final Goal of the project is to design and create a working link of a linear cluster tool
mock-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 basic
software control. To do so, first the work that needed to be done was defined, which is based
upon the unfinished work on the mock-up. The achievements for this phase can best be
summarized 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 components 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 present
each 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. The
figure only shows hardware, in a movie enclosed in a cd that is enclosed with the report can
be seen that the software is functional.
Furthermore, tests on many components have been conducted. These tests cover the lifting
motion of the I/O module and the linear motion of the transport motion. The components
that have not been tested were subject to elementary checks. The result of these tests were
analyzed and compared to the required accuracy of 1 mm. The lift of the I/O module has an
accuracy 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 propagate
through the work cycle since every wafer gets transported several times. The values found in
the 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 needed
to 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 CAD
assemblies are available to indicate the way it needs to be assembled. The user interface also
needs to be incorporated in the software. For the feedback panel there are software variables
already present that can function as the input for the indicators, for the operator panel a lot
more 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 simulated
production. This requires a database that is updated for each wafer and process step. This
database needs complete state machines of every module, which are not yet present for the
buffer module or process modules. On base of the database information, higher level control
can be used to create an autonomous processing of a wafer with the help of interacting function
blocks that decide on information from the database.
The rotational motion of the transport module still needs to be tested to validate the module
completely. After this validation the controls of each actuator can be fine tuned to increase
the speed of operation. During the software test of the transport module, it became clear
that the initialization of the rotational movement is not accurate. During the initialization
The index signal is very close to the position where the end sensors are located. The bracket
that supports the sensors is not sufficient and can move by a few millimeter, if work is done
on the LCT. Therefore it is important to redesign this bracket in a way that the sensors and
the 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 previous
groups, which each realized a single module. This was very hard in the beginning, since
the loose ends of the previous two groups had to be finished. This was time consuming and
somewhat annoying, but very useful. The immediate evaluation of an existing design, proved
to be useful in the coming design process. This was the first learning moment, which the
whole project was full of.
The project of the linear cluster tool mock-up is the most versatile project, which helps the
students 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 other
projects 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 of
the project, helped the group to keep the performance high. This is due to the fact that it
felt like a new beginning.
However due to the versatility of this project. The review in the presentation was hard. Where
most groups only have one component to discuss, the mock-up group had several components
to 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.
english.asp?ethercat/el7342.htm.
http://www.beckhoff.com/
[3] beckhoff website. http://www.beckhof.com/.
[4] Codesys 3 website. http://www.codesys.com/the-system.html.
[5] Error analsis.
AppendixB.html.
http://teacher.nsrl.rochester.edu/phy_labs/AppendixB/
[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, 19
july 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 project
report, 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 project
report, 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 tool
mock-up, phase 1. Bachelor project report, TU/e, Department of Mechanical Engineering, The Systems Engineering group, 2012/2013.
[23] P. van der Meulen. Linear semiconductor manufacturing logistics and the impact on
cycle 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 of
Mechanical 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 of
Mechanical 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. In
Proceeding 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 experiments. The error analysis uses mathematical function to determine the mean value, the
standard 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 by
adding all the data points and then dividing it by the number of data points as can be seen
in Equation (A.1).
N
1 X
x̄ =
xi
N
(A.1)
i=1
Where x̄ is the mean value over all the data points and N is the number of data points and
xi 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 for
calculating the deviation can be seen in Equation (A.2).
v
u
N
u1 X
t
(x1 − x̄)2
σ=
N
(A.2)
i=1
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 the
number of measurements is always finite. This parameter is needed to correct the mistake that
is made with a finite number of measurement points. This student t parameter is multiplied
with 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 t
parameter 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 partial
differential formula of the total system. This means that the relation between measured value
and 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).
s
∆z =
(
δz 2 2
δz
) ∆x + ( )2 ∆y 2
δx
δy
(A.4)
δz
Where ( δ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 error analysis is valid. It is a check that the maximum measured error does not exceed the
specifications, see Equation (A.5).
∆xm ax =
xm ax − xm in
2
(A.5)
64
Appendix B
Patent study of the anti-backlash
spring
The transport module is equipped with a spring that counters the backlash. This spring
pulls the system into one end of the backlash, effectively negating the negative effect of the
backlash. However this concept has already been used in practice many times over. Therefore
a 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 want
to make use of the capability of the patent. In the case of backlash, a lot of competitors are
present. Every industry branch that requires high precision will need a minimum amount
of 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, the
majority 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 base
principles can be achieved in many various ways. Many patents therefore seem alike, but
are different on a small aspect. Either in an extra extension of the patent or in a different
interpretation. In most cases the patents are valid for 20 years after the enforcement of the
patent. In the case of anti-backlash concepts, the patents are often not more than six years
old. 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. These
patents 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. The
second 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 of
backlash, this is also the case in the transport module. However the design of the spring in
patents and in the transport module is very different, the design of the spring in the transport
module 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 with
the design in the transport module, since the designs are very different and the project is
purely meant for demonstration and education purposes. Which will not be a disadvantage
to any of the patent holders. Therefore the patents cannot cause any problem for the project.
66
Appendix C
Software: Function Blocks and
State machines
This appendix contains all designs and ST (structured text) PLC (programmable logic controller) scripts used to control the movements of the Transport and I/O module. The TwinCAT 3 project LCT mockup 4M230.sln contains all these scripts, located under the PLC tab
as 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 this
report. 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 shown
and finally the ST scripts for associated with the function block is shown. The states in every
statemachine drawing are colored red, blue or green. Red states and transitions are related
to error handling, blue states and arrows are related to normal enabling, calibration and
disabling events. Finally, green states and arrows are related to normal operation. The first
section of this appendix covers the I/O module, while the second section covers the Transport
module.
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//name: FB_IOModule
//Version: 1.4
//Date: 09-01-2013, Joni Scholten
//This Function block is not yet drawn in
FUNCTION_BLOCK FB_IOModule EXTENDS FB_ActiveModule
VAR_INPUT
nLocationI
:
BYTE ;
//The commanded discrete position. Internally this integer is translated into a precise movement.
END_VAR
VAR_OUTPUT
nLocationO
:
BYTE ;
//discrete position to which the actuator is moving if bBusyO = TRUE, and has reached if bDoneO=TR
bWaferPresentO
:
BOOL ;
//indicates that a wafer is present in the buffer module
END_VAR
VAR
//local variables
//pointers
pbWaferSensor
:
POINTER TO BOOL ;
//actuator function blocks
fbIOModLiftAct
:
FB_IOModLiftAct ;
END_VAR
//update function block nputs
fbIOModLiftAct . bEnableI := bEnableI ;
fbIOModLiftAct . bExecuteI := bExecuteI ;
fbIOModLiftAct . bResetI := bResetI ;
fbIOModLiftAct . nLocationI := nLocationI ;
//Run actuator function blocks
A_RunActuatorFB ( ) ;
//update outputs
bStatusO := fbIOModLiftAct . bStatusO ;
bBusyO := fbIOModLiftAct . bBusyO ;
bDoneO := fbIOModLiftAct . bDoneO ;
bErrorO := fbIOModLiftAct . bErrorO ;
nErrorIDO := fbIOModLiftAct . nErrorIDO ;
nLocationO := fbIOModLiftAct . nLocationO ;
bWaferPresentO := pbWaferSensor ^ ;
LCT_mockup_4M230.project
5-2-2013 19:13
Page 1 of 1
FB_IOModLiftAct 17-12-2012
Stop
From any state, excluding
Stop, Disabled,InvalidLocation,
Error and Reset, if
bEnableI:=FALSE
McHalt.execute:=TRUE
when: McHalt.Done=TRUE
Disabled
when: McReset.Done=TRUE AND
bResetI=FALSE AND bInitialized=TRUE
bTaskError:=FALSE
fbMcReset.Execute:=FALSE
bStatusO:=FALSE
bBusyO:=FALSE
bErrorO:=FALSE
bDoneO:=FALSE
fbMcPower.Enable:=FALSE
eCalibrateState:=Begin
fbMcMoveAbsolute2.Execute:=FALSE
fbMcMoveAbsolute1.Execute:=FALSE
fbMcHalt.Execute:=FALSE
Reset
fbMcReset.Execute:=TRUE
bTaskError:=FALSE
when: bResetI=TRUE
when: bCalibrated=FALSE AND
bEnableI=TRUE
Calibrate
M_Calibrate
when: bCalibrated=TRUE AND
bEnableI=TRUE
when: bInitialized:=FALSE
Error
nErrorIDO:=...
bErrorO:=TRUE
fbMcMoveAbsolute1.Execute:=FALSE
fbMcMoveAbsolute2.Execute:=FALSE
bStatusO:=FALSE
fbMcPower.Enable:=FALSE
bDoneO:=FALSE
bBusyO:=FALSE
PowerOn
From any state, excluding
Error and Reset, if
fbAxis.Status.Error:=TRUE
fbMcPower.Override:=100.0
fbMcPower.Enable_Positive = TRUE
fbMcPower.Enable = TRUE
fbMcPower.Enable_Negative = TRUE
nLocationO:=0
when: fbAxis.Status.Disabled = FALSE
InvalidLocation
when: bExecuteI=TRUE &
(nLocationI >10 OR nLocationI < 1)
bTaskError:=TRUE
Enabled
bStatusO:=TRUE
Move2
fbMcMoveAbsolute1.Execute:=FALSE
bDoneO:=fbMcMoveAbsolute2.Done
fbMcMoveAbsolute2.position:=afLiftPositions[nLocation]
nLocationO:=nLocation
bBusyO:=fbMcMoveAbsolute2.Busy
fbMcMoveAbsolute2.Execute:=TRUE
when: bExecuteI=TRUE &
(nLocationI >10 OR nLocationI < 1)
ReadyForTask1
when: bExecuteI=FALSE
fbMcMoveAbsolute2.Execute:=FALSE
bBusyO:=fbMcMoveAbsolute2.Busy
bDoneO:=fbMcMoveAbsolute2.Done
when: bExecuteI=TRUE &
0 < nLocationI <= 10 THEN
nLocation := nLocationI;
END_IF
when: bExecuteI=TRUE &
0 < nLocationI <= 10 THEN
nLocation := nLocationI;
END_IF
Move1
ReadyForTask2
when: bExecuteI=FALSE
bDoneO:=fbMcMoveAbsolute1.Done
bBusyO:=fbMcMoveAbsolute1.Busy
fbMcMoveAbsolute1.Execute:=FALSE
nLocationO:=nLocation
fbMcMoveAbsolute1.position:=afLiftPositions[nLocation]
fbMcMoveAbsolute1.Execute:=TRUE
bBusyO:=fbMcMoveAbsolute1.Busy
bDoneO:=fbMcMoveAbsolute1.Done
fbMcMoveAbsolute2.Execute:=FALSE
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
//name: FB_IOModLiftAct
//Version: 1.4
//Date: 15-01-2013, Joni Scholten
FUNCTION_BLOCK FB_IOModLiftAct EXTENDS FB_EncoderAct
VAR_INPUT
END_VAR
VAR_OUTPUT
bSenLiftTopO
:
BOOL ;
bSenLiftBottomO
:
BOOL ;
END_VAR
VAR
//MC function blocks
fbMcMoveAbsolute2
:
MC_MoveAbsolute ;
//Extra function block, needed to change task while moving
//Statemachine States
eState
:
emCalibrateState
:
E_FB_IOModLiftActStates ;
E_M_FB_EncActCalibrateStates ;
//Internal variables
afLiftPositions
:
ARRAY [ 1 .. 10 ] OF LREAL ;
//contains the relative position of the 10 storage positions of the wafer cassette
//POINTERS
pbSenLiftBottom
pbSenLiftTop
END_VAR
:
:
POINTER TO BOOL ;
POINTER TO BOOL ;
fbAxis . ReadStatus ( ) ; //Read the current status of the IO lift axis
CASE eState OF
eIOLiftState_Reset
:
//Start state, reset all MC function blocks, to cancel errors from previous runs
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//Internal variables
bTaskError := FALSE ;
//MC function block settings
fbMcPower . Enable := FALSE ;
fbMcReset . Execute := TRUE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
IF NOT bInitialized THEN
eState := eIOLiftState_Error ;
ELSIF fbMcReset . Done AND NOT bResetI AND bInitialized THEN
eState := eIOLiftState_Disabled ;
END_IF
eIOLiftState_Stop
:
//Stop all MC function blocks using MC halt, otherwise an error might occur.
LCT_mockup_4M230.project
5-2-2013 12:41
Page 1 of 5
POU: FB_IOModLiftAct
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
//MC function block settings
fbMcHalt . Execute := TRUE ;
//determine next state
IF fbMcHalt . Done THEN
eState := eIOLiftState_Disabled ;
END_IF
eIOLiftState_Disabled
:
//Marker state, nothing moves, nothing is enabled
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
bTaskError := FALSE ;
emCalibrateState := eEncActCalibState_Begin ;
//Reset M_Calibrate statemachine
//MC function block settings
fbMcReset . Execute := FALSE ;
fbMcPower . Enable := FALSE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
fbMcHalt . Execute := FALSE ;
//Determine next state
IF NOT bCalibrated AND bEnableI THEN
eState := eIOLiftState_Calibrate ;
ELSIF bCalibrated AND bEnableI THEN
eState := eIOLiftState_PowerOn ;
END_IF
eIOLiftState_Calibrate
:
//call M_Calibrate method to perform calibration
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//Run calibration method M_Calibrate
M_Calibrate ( ) ;
//Determine next state
IF bCalibrated AND bEnableI THEN
eState := eIOLiftState_PowerOn ;
END_IF
eIOLiftState_PowerOn
:
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcPower . Enable := TRUE ;
fbMcPower . Override := 100.0 ;
LCT_mockup_4M230.project
5-2-2013 12:41
Page 2 of 5
POU: FB_IOModLiftAct
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
fbMcPower . Enable_Negative := TRUE ;
fbMcPower . Enable_Positive := TRUE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
//nLocation:=0;
nLocationO := 0 ;
//Determine next state
IF NOT fbAxis . Status . Disabled THEN
eState := eIOLiftState_Enabled ;
END_IF
eIOLiftState_Enabled
:
//outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
//determine next state
IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN
nLocation := nLocationI ;
eState := eIOLiftState_Move1 ;
ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN
eState := eIOLiftState_InvalidLocation ;
END_IF
eIOLiftState_Move1
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute1 . Busy ;
bDoneO := fbMcMoveAbsolute1 . Done ;
bErrorO := FALSE ;
//Internal variables
nLocationO := nLocation ;
//MC function block settings
fbMcMoveAbsolute1 . Execute := TRUE ;
fbMcMoveAbsolute1 . Position := afLiftPositions [ nLocation ] ;
fbMcMoveAbsolute2 . Execute := FALSE ;
//Determine next state
IF NOT bExecuteI THEN
eState := eIOLiftState_ReadyForTask2 ;
END_IF
eIOLiftState_ReadyForTask2
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute1 . Busy ;
bDoneO := fbMcMoveAbsolute1 . Done ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcMoveAbsolute1 . Execute := TRUE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
LCT_mockup_4M230.project
5-2-2013 12:41
Page 3 of 5
POU: FB_IOModLiftAct
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
//Determine next state
IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN
nLocation := nLocationI ;
eState := eIOLiftState_Move2 ;
ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN
eState := eIOLiftState_InvalidLocation ;
END_IF
eIOLiftState_Move2
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute2 . Busy ;
bDoneO := fbMcMoveAbsolute2 . Done ;
bErrorO := FALSE ;
//Internal variables
nLocationO := nLocation ;
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := TRUE ;
fbMcMoveAbsolute2 . Position := afLiftPositions [ nLocation ] ;
//Determine next state
IF NOT bExecuteI THEN
eState := eIOLiftState_ReadyForTask1 ;
END_IF
eIOLiftState_ReadyForTask1
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute2 . Busy ;
bDoneO := fbMcMoveAbsolute2 . Done ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := TRUE ;
//determine next state
IF bExecuteI AND nLocationI > 0 AND nLocationI <= 10 THEN
nLocation := nLocationI ;
eState := eIOLiftState_Move1 ;
ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 10 THEN
eState := eIOLiftState_InvalidLocation ;
END_IF
eIOLiftState_InvalidLocation
:
//internal variables
bTaskError := TRUE ;
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
//next state
eState := eIOLiftState_Error ;
eIOLiftState_Error
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
LCT_mockup_4M230.project
5-2-2013 12:41
:
Page 4 of 5
POU: FB_IOModLiftAct
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
bDoneO := FALSE ;
bErrorO := TRUE ;
//Internal variables
//MC function block settings
fbMcPower . Enable := FALSE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcMoveAbsolute2 . Execute := FALSE ;
//Determine errorcode
IF fbAxis . Status . Error THEN
nErrorIDO := fbAxis . Status . ErrorID ;
ELSIF fbMcPower . Error THEN
nErrorIDO := fbMcPower . ErrorID ;
ELSIF fbMcReset . Error THEN
nErrorIDO := fbMcReset . ErrorID ;
ELSIF fbMcSetPosition . Error THEN
nErrorIDO := fbMcSetPosition . ErrorID ;
ELSIF fbMcMoveAbsolute1 . Error THEN
nErrorIDO := fbMcMoveAbsolute1 . ErrorID ;
ELSIF fbMcMoveAbsolute2 . Error THEN
nErrorIDO := fbMcMoveAbsolute2 . ErrorID ;
ELSIF fbMcMoveVelocity . Error THEN
nErrorIDO := fbMcMoveVelocity . ErrorID ;
ELSIF fbMcHalt . Error THEN
nErrorIDO := fbMcHalt . ErrorID ;
ELSIF bTaskError THEN
nErrorIDO := GetErrorCode ( Error_InvalidTask ) ;
ELSIF NOT bInitialized THEN
nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;
END_IF
//Determine next state
IF bResetI THEN
eState := eIOLiftState_Reset ;
END_IF
END_CASE
//State changes which are the same for almost all states
//check for errors
IF ( fbMcMoveAbsolute1 . Error OR fbMcMoveAbsolute2 . Error OR
fbMcMoveVelocity . Error OR fbMcReset . Error OR fbMcPower . Error OR
fbMcSetPosition . Error OR fbAxis . Status . Error OR fbMcHalt . Error ) AND
eState <> eIOLiftState_Reset AND eState <> eIOLiftState_Error THEN
eState := eIOLiftState_Error ;
// check if lift should be disabled
ELSIF NOT bEnableI AND eState <> eIOLiftState_Reset AND eState <>
eIOLiftState_Error AND eState <> eIOLiftState_InvalidLocation AND eState
<> eIOLiftState_Stop AND eState <> eIOLiftState_Disabled THEN
eState := eIOLiftState_Stop ;
END_IF
//avoid pointer errors
IF bInitialized THEN
A_RunMcFunctionBlocks ( ) ;
bSenLiftBottomO := pbSenLiftBottom ^ ;
bSenLiftTopO := pbSenLiftTop ^ ;
END_IF
LCT_mockup_4M230.project
5-2-2013 12:42
Page 5 of 5
Method: M_Calibrate
1
2
3
4
5
6
7
8
//name: M_Calibrate
//Version: 1.2
//Date: 10-01-2013, Joni Scholten
//Calibration procedure for the FB_IOModLiftAct.
METHOD PRIVATE M_Calibrate
VAR_INPUT
END_VAR
1
2
CASE emCalibrateState OF
eEncActCalibState_Begin
:
//startsequence of calibration
bCalibrated := FALSE ;
//Determine next state
IF bEnableI := TRUE THEN
emCalibrateState := eEncActCalibState_StartCalibration ;
END_IF
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
eEncActCalibState_StartCalibration
: //enable MC_Power of axis
//Set Mc Function blocks
fbMcPower . Enable := TRUE ;
fbMcPower . Enable_Positive := TRUE ;
fbMcPower . Enable_Negative := TRUE ;
fbMcPower . Override := 100.0 ;
IF fbMcPower . Status THEN
emCalibrateState := eEncActCalibState_Active ;
END_IF
eEncActCalibState_Active
:
////Set Mc Function blocks
fbMcMoveVelocity . Velocity := fSpeedCalibFast ;
//Determine next state
IF pbSenLiftBottom ^ THEN
emCalibrateState := eEncActCalibState_BottomEndSensorActive ;
ELSIF NOT pbSenLiftBottom ^ THEN
emCalibrateState := eEncActCalibState_NotAtBottom ;
END_IF
eEncActCalibState_NotAtBottom
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Direction := MC_Negative_Direction ;
//Determine next state
IF pbSenLiftBottom ^ THEN
emCalibrateState := eEncActCalibState_BottomEndSensorActive ;
fbMcMoveVelocity . Execute := FALSE ;
END_IF
eEncActCalibState_BottomEndSensorActive
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Direction := MC_Positive_Direction ;
//Determine Next state
IF NOT pbSenLiftBottom ^ THEN
emCalibrateState := eEncActCalibState_FindIndex ;
fbMcMoveVelocity . Execute := FALSE ;
LCT_mockup_4M230.project
5-2-2013 12:44
Page 1 of 2
Method: M_Calibrate
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
END_IF
eEncActCalibState_FindIndex
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Velocity := fSpeedCalibSlow ;
//THIS VALUE IS CRITICAL FOR DETECTION OF ENCODER INDEX signal
//determine next state
IF pbEncoderIndex ^ THEN
emCalibrateState := eEncActCalibState_SetPosition ;
END_IF
eEncActCalibState_SetPosition
:
fbMcSetPosition . Position := 0.0 ;
fbMcSetPosition . Execute := TRUE ;
fbMcSetPosition . Mode := FALSE ;
//Determine next state
IF fbMcSetPosition . Done THEN
emCalibrateState := eEncActCalibState_MoveToStart ;
END_IF
eEncActCalibState_MoveToStart
:
//Set Mc Function blocks
fbMcMoveVelocity . Execute := FALSE ;
fbMcPower . Override := 100 ;
fbMcSetPosition . Execute := FALSE ;
fbMcMoveAbsolute1 . Execute := TRUE ;
fbMcMoveAbsolute1 . Position := afLiftPositions [ 1 ] ;
//Determine next state
IF fbMcMoveAbsolute1 . Done THEN
emCalibrateState := eEncActCalibState_Calibrated ;
END_IF
eEncActCalibState_Calibrated
bCalibrated := TRUE ;
END_CASE
LCT_mockup_4M230.project
5-2-2013 12:44
:
Page 2 of 2
Method: M_Init
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
//name: M_Init
//Version: 1.2
//Date: 08-02-2013, Joni Scholten
//This method initializes the Lift actuator in the I/O module
METHOD PUBLIC M_Init : BOOL
VAR_INPUT
stInit
: ST_M_FB_IOModLiftAct_Init ;
END_VAR
VAR
counter
: BYTE ;
END_VAR
//Check if positions are well sorted, otherwise initialisation failed
FOR counter := 2 TO 10 DO
IF stInit . afLiftPositionsI [ counter ] < stInit . afLiftPositionsI [
counter - 1 ] THEN
M_Init := FALSE ;
RETURN ;
END_IF
END_FOR
FOR counter := 1 TO 10 DO
afLiftPositions [ counter ] := stInit . afLiftPositionsI [ counter ] +
stInit . fOffsetI ;
END_FOR
pbSenLiftBottom := stInit . pbSenLiftBottom ;
pbSenLiftTop := stInit . pbSenLiftTop ;
pbEncoderIndex := stInit . pbEncoderIndex ;
bCalibrated := FALSE ;
//check if fast calibration speed is slower than slow calibration speed. Otherwise initialisation
IF stInit . fSpeedCalibFast < stInit . fSpeedCalibSlow THEN
M_Init := FALSE ;
RETURN ;
ELSE
fSpeedCalibFast := stInit . fSpeedCalibFast ;
fSpeedCalibSlow := stInit . fSpeedCalibSlow ;
END_IF
fbMcMoveAbsolute1 . Velocity := stInit . fSpeedNormal ;
fbMcMoveAbsolute2 . Velocity := stInit . fSpeedNormal ;
bInitialized := TRUE ;
M_Init := TRUE ;
LCT_mockup_4M230.project
8-2-2013 9:48
Page 1 of 1
C.2
FB TransportModule
Figure C.5: FB for the Transport module.
80
For global error
conditions see Code in
TwinCAT
FB_TransportModule statemachine 30-01-2013
Error
Reset
nErrorIDO:=......
fbRotAct.bEnableI:=FALSE
bStatusO:=FALSE
fbManAct.bEnableI:=FALSE
fbLiftAct.bEnableI:=FALSE
bErrorO:=TRUE
bBusyO:=FALSE
when: bResetI=TRUE
fbManipAct.bResetI:=TRUE
fbLiftAct.bResetI:=TRUE
fbRotAct.bResetI:=TRUE
when: bEnableI=TRUE AND
bInitialized=TRUE AND
fbLiftAct.bStatusO=FALSE AND
fbRotAct.bStatusO=FALSE AND
fbManipAct.bStatusO=FALSE
ActivateActuators
when: M_CalibrateActuators()=TRUE
fbLiftAct.bEnableI:=TRUE
fbRotAct.bEnableI:=TRUE
fbManipAct.bEnableI:=FALSE
bStatusO:=TRUE
bBusyO:=FALSE
bDoneO:=TRUE
From any state
excluding Error
and Reset if
bEnableI=FALSE
Disabled
bStatusO:=FALSE
bDoneO:=FALSE
bBusyO:=FALSE
eActivateState:=Lift
M_ActivateActuators()
when: bExecuteI=TRUE AND
fbManipAct.bSenManipInO=TRUEAND
fbManipAct.bStatusO=FALSE AND
fbLiftAct.bSenLiftDownO=TRUE AND
fbLiftAct.bDone=TRUE THEN
stTransportTask:=stTransportTaskI;
ReadyForNewTask
when: bResetI=FALSE AND
fbRotAct.bErrorO=FALSE AND
fbLiftAct.bErrorO=FALSE AND
fbManipAct.bErrorO=FALSE
MoveRotPickUp
fbRotAct.nLocationI:=stTransportTask.nLocationFromI
fbRotAct.bExecuteI: NOT fbManipAct.bMovingOutO
bBusyO:=TRUE
bDoneO:=FALSE
when: fbManipAct.DoneO=TRUE AND
fbManipAct.bSenManipInO=TRUE AND
bExecuteI=FALSE
when: fbRotAct.bDoneO=TRUE AND
fbRotAct.nLocationO=stTransportTask.nLocationFromI AND
fbLiftAct.bSenLiftDownO=TRUE
MoveManInDeliver
MoveManEnablePickUp
when: fbLiftAct.bDoneO=TRUE AND
fbLiftAct.bSenLiftDownO=TRUE AND
fbManipAct.bExecuteI:=TRUE
fbLiftAct.bExecuteI:=FALSE
fbManipAct.bEnableI:= bEnableManipI
fbManipAct.bExecuteI:=FALSE
fbRotAct.bExecuteI:=FALSE
when: fbManipAct.bStatusO=TRUE AND
fbManipAct.bSenManipIn.O=TRUE
MoveLiftDownDeliver
fbLiftAct.bExecuteI:=TRUE
fbManipAct.bExecuteI:=FALSE
MoveManOutPickUp
when: fbManipAct.DoneO=TRUE AND
fbManipAct.bSenManipOutO=TRUE
fbManipAct.bExecuteI:=NOT fbRotAct.bBusyO AND fbLiftAct.bSenLiftDownO
fbRotAct.bEnableI:=FALSE
when: bEnableManipI=FALSE
when: fbManipAct.DoneO=TRUE AND
fbManipAct.bSenManipOutO=TRUE
MoveManOutDeliver
fbManipAct.bExecuteI:=NOT fbRotAct.bBusyO AND fbLiftAct.bSenLiftUpO
MoveLiftUpPickUp
when: bEnableManipI=FALSE
fbLiftAct.ExecuteI:=TRUE
fbManipAct.ExecuteI:=FALSE
when: fbManipAct.bStatusO=TRUE AND
fbManipAct.bSenManipIn.O=TRUE
Error
MoveManEnableDeliver
fbManipAct.bEnableI:=TRUE AND bEnableManipI
fbManipAct.bExecuteI:=FALSE
fbLiftAct.bExecuteI:=FALSE
fbRotAct.bEnableI:=FALSE
when: bEnableManipI=FALSE
when: fbLiftAct.bDoneO=TRUE AND
fbLiftAct.bSenLiftUpO=TRUE
MoveLiftUpDeliver
fbLiftAct.bExecuteI:=TRUE
fbRotAct.bExecuteI:=FALSE
when: fbLiftAct.bDoneO=TRUE AND
fbLiftAct.bSenLiftUpO=TRUE
when: fbRotAct.bDoneO=TRUE AND
fbRotAct.nLocationO=stTransportTask.nLocationToI
fbLiftAct.bSenLiftDownO=TRUE
MoveRotDeliver
when: fbLiftAct.bDoneO=TRUE AND
fbLiftAct.bSenLiftDownO=TRUE AND
fbManipAct.bSenManipInO=TRUE
fbRotAct.nLocationI:=stTransportTask.nLocationToI
fbRotAct.bExecuteI:= NOT fbManipAct.bMovingOutO
fbLiftAct.bExecuteI:=FALSE
MoveManInPickUp
fbManipAct.bExecuteI:=TRUE
fbLiftAct.bExecuteI:=FALSE
when: fbManipAct.DoneO=TRUE AND
fbManipAct.bSenManipInO=TRUE
MoveLiftDownPickUp
fbManipAct.bEnableI:=FALSE
fbLiftAct.bExecute:=TRUE
fbRotAct.bEnableI:=TRUE
Figure C.6: State machine for the Transport module.
81
POU: FB_TransportModule
1
2
3
4
5
6
7
8
//name: FB_TransportModule
//Version: 1.4
//Date: 30-01-2013, Joni Scholten
//This Function block is defined in the document UML_software_1link_mock-up_V2_25-11-2012 AND 4M23
FUNCTION_BLOCK FB_TransportModule EXTENDS FB_ActiveModule
VAR_INPUT
stTransportTaskI
:
ST_TransportTask ;
//struct that defines a transport module task
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 ma
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
1
2
3
4
5
6
7
8
9
10
11
12
13
//or to prevent collision with another entering the same buffer module. These situations will have
END_VAR
VAR_OUTPUT
stTransportTaskO
:
ST_TransportTask ;
//struct that defines a transport module task
nLocationO
:
BYTE ;
//Location at which the transport module is standing still. only nonzero when transporter is not r
bManipRetractedO
:
BOOL ;
//Only true if the manipulator is retracted and not moving.
END_VAR
VAR
//states
eState
:
E_FB_TransportModuleStates ;
eActivateState
:
E_M_FB_TransModActivateActuators ;
//bHoldsWafer
:
BOOL:=FALSE; //TRUE -> There lies a wafer on the manipulato
stTransportTask
:
ST_TransportTask ;
//struct that defines a transport module task
eErrorCode
:
E_ErrorCodes ; //enumerate with error names
//actuator function blocks
fbTransModLiftAct
:
fbTransModManipAct
:
fbTransModRotAct
:
FB_TransModLiftAct ;
FB_TransModManipAct ;
FB_TransModRotAct ;
END_VAR
CASE eState OF
eTransModState_Disabled
:
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//internal variables
eActivateState := eTransModCaliActState_Lift ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := FALSE ;
LCT_mockup_4M230.project
5-2-2013 19:14
Page 1 of 10
POU: FB_TransportModule
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
IF bEnableI AND bInitialized AND NOT fbTransModLiftAct . bStatusO
AND NOT fbTransModManipAct . bStatusO AND NOT fbTransModRotAct . bStatusO
THEN
eState := eTransModState_ActivateActuators ;
ELSIF bEnableI AND NOT bInitialized THEN
eState := eTransModState_Error ;
END_IF
eTransModState_ActivateActuators
:
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//determine next state
IF M_ActivateActuators ( ) THEN
eState := eTransModState_ReadyForNewTask ;
END_IF
eTransModState_ReadyForNewTask
:
//outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF bExecuteI AND fbTransModManipAct . bSenManipInO AND NOT
fbTransModManipAct . bStatusO AND fbTransModLiftAct . bSenLiftDownO AND
fbTransModLiftAct . bDoneO THEN
stTransportTask := stTransportTaskI ;
eState := eTransModState_MoveRotPickUp ;
LCT_mockup_4M230.project
5-2-2013 19:14
Page 2 of 10
POU: FB_TransportModule
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
END_IF
eTransModState_MoveRotPickUp
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := NOT fbTransModManipAct . bMovingOutO ;
fbTransModRotAct . bResetI := FALSE ;
fbTransModRotAct . nLocationI := stTransportTask . nLocationFromI ;
//determine next state
IF fbTransModRotAct . bDoneO AND fbTransModRotAct . nLocationO =
stTransPortTask . nLocationFromI AND fbTransModLiftAct . bSenLiftDownO THEN
eState := eTransModState_MoveManEnablePickUp ;
END_IF
eTransModState_MoveManEnablePickUp
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModManipAct . bStatusO AND fbTransModManipAct .
bSenManipInO THEN
eState := eTransModState_MoveManOutPickUp ;
END_IF
eTransModState_MoveManOutPickUp
LCT_mockup_4M230.project
5-2-2013 19:14
:
Page 3 of 10
POU: FB_TransportModule
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := ( NOT fbTransModRotAct . bBusyO )
AND fbTransModLiftAct . bSenLiftDownO ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .
bSenManipOutO THEN
eState := eTransModState_MoveLiftUpPickUp ;
END_IF
eTransModState_MoveLiftUpPickUp
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := TRUE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
ELSIF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftUpO
LCT_mockup_4M230.project
5-2-2013 19:14
Page 4 of 10
POU: FB_TransportModule
THEN
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
eState := eTransModState_MoveManInPickUp ;
END_IF
eTransModState_MoveManInPickUp
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := TRUE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .
bSenManipInO THEN
eState := eTransModState_MoveLiftDownPickUp ;
END_IF
eTransModState_MoveLiftDownPickUp
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := TRUE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftDownO
AND fbTransModManipAct . bSenManipInO THEN
LCT_mockup_4M230.project
5-2-2013 19:14
Page 5 of 10
POU: FB_TransportModule
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
eState := eTransModState_MoveRotDeliver ;
END_IF
eTransModState_MoveRotDeliver
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := NOT fbTransModManipAct . bMovingOutO ;
fbTransModRotAct . bResetI := FALSE ;
fbTransModRotAct . nLocationI := stTransportTask . nLocationToI ;
//determine next state
IF fbTransModRotAct . bDoneO AND fbTransModRotAct . nLocationO =
stTransportTask . nLocationToI AND fbTransModLiftAct . bSenLiftDownO THEN
eState := eTransModState_MoveLiftUpDeliver ;
END_IF
eTransModState_MoveLiftUpDeliver
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := TRUE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModLiftAct . bDoneO AND fbTransModLiftAct . bSenLiftUpO
THEN
276
277
278
eState := eTransModState_MoveManEnableDeliver ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:14
Page 6 of 10
POU: FB_TransportModule
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
eTransModState_MoveManEnableDeliver :
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModManipAct . bStatusO AND fbTransModManipAct .
bSenManipInO THEN
eState := eTransModState_MoveManOutDeliver ;
END_IF
eTransModState_MoveManOutDeliver
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := ( NOT fbTransModRotAct . bBusyO )
AND fbTransModLiftAct . bSenLiftUpO ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .
bSenManipOutO THEN
eState := eTransModState_MoveLiftDownDeliver ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:14
Page 7 of 10
POU: FB_TransportModule
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
eTransModState_MoveLiftDownDeliver
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := TRUE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
ELSIF fbTransModLiftAct . bDoneO AND fbTransModLiftAct .
bSenLiftDownO THEN
eState := eTransModState_MoveManInDeliver ;
END_IF
eTransModState_MoveManInDeliver
:
//outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := bEnableManipI ;
fbTransModManipAct . bExecuteI := TRUE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF NOT bEnableManipI THEN
//in this state the manipulator should be enabled
eErrorCode := Error_ManipDisabled ;
eState := eTransModState_Error ;
LCT_mockup_4M230.project
5-2-2013 19:14
Page 8 of 10
POU: FB_TransportModule
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
ELSIF fbTransModManipAct . bDoneO AND fbTransModManipAct .
bSenManipInO AND NOT bExecuteI THEN
eState := eTransModState_ReadyForNewTask ;
END_IF
eTransModState_Error
:
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := TRUE ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := FALSE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine nErrorIDO output
IF fbTransModLiftAct . bErrorO THEN
nErrorIDO := fbTransModliftAct . nErrorIDO ;
ELSIF fbTransModManipAct . bErrorO THEN
nErrorIDO := fbTransModManipAct . nErrorIDO ;
ELSIF fbTransModRotAct . bErrorO THEN
nErrorIDO := fbTransModRotAct . nErrorIDO ;
ELSE
nErrorIDO := GetErrorCode ( eErrorCode ) ;
END_IF
//determine next state
IF bResetI THEN
eState := eTransModState_Reset ;
END_IF
eTransModState_Reset
:
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := FALSE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := TRUE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := TRUE ;
//rotational actuator
LCT_mockup_4M230.project
5-2-2013 19:14
Page 9 of 10
POU: FB_TransportModule
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := TRUE ;
//determine next state
IF NOT bResetI AND NOT fbTransModRotAct . bErrorO AND NOT
fbTransModLiftAct . bErrorO AND NOT fbTransModManipAct . bErrorO THEN
eState := eTransModState_Disabled ;
END_IF
END_CASE
//Error and disable detection
IF eState <> eTransModState_Error
AND eState <> eTransModState_Reset
THEN
//error occurance
IF bEnableI AND NOT bInitialized THEN //initialize error
eErrorCode := Error_NotInitialized ;
eState := eState := eTransModState_Error ;
ELSIF fbTransModRotAct . bBusyO AND ( fbTransModManipAct . bMovingOutO
NOT fbTransModManipAct . bSenManipInO ) THEN
//rotation while manipulator is not retracted
eErrorCode := Error_IllegalActuatorAction ;
eState := eTransModState_Error ;
ELSIF fbTransModLiftAct . bErrorO OR fbTransModManipAct . bErrorO OR
fbTransModRotAct . bErrorO THEN //error in actuator function blocks
eState := eTransModState_Error ;
//bEnableI=FALSE;
ELSIF eState <> eTransModState_Disabled AND NOT bEnableI THEN
eState := eTransModState_Disabled ;
END_IF
END_IF
//set additional outputs
stTransportTaskO := stTransportTask ;
nLocationO := fbTransModRotAct . nLocationO ;
bManipRetractedO := fbTransModManipAct . bSenManipInO
fbTransModManipAct . bMovingOutO ;
//run actuator function blocks
IF bInitialized THEN
A_RunActuatorFB ( ) ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:14
OR
AND NOT
Page 10 of 10
Figure C.7: State machine for the Transport module actuators activation.
92
Method: M_ActivateActuators
1
2
3
4
5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
//16-01-2013 Joni Scholten activate actuators sequence
METHOD PRIVATE M_ActivateActuators : BOOL
VAR_INPUT
END_VAR
CASE eActivateState OF
eTransModCaliActState_Lift
:
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := FALSE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModLiftAct . bStatusO AND fbTransModLiftAct . bSenLiftDownO
THEN
eActivateState := eTransModCaliActState_Manip ;
END_IF
//return value
M_ActivateActuators := FALSE ;
eTransModCaliActState_Manip
:
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := TRUE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := FALSE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModManipAct . bStatusO AND fbTransModManipAct .
bSenManipInO THEN
eActivateState := eTransModCaliActState_Rot ;
END_IF
//return value
M_ActivateActuators := FALSE ;
eTransModCaliActState_Rot
:
//set actuator FB inputs
//lift actuator
fbTransModLiftAct . bEnableI := TRUE ;
fbTransModLiftAct . bExecuteI := FALSE ;
LCT_mockup_4M230.project
5-2-2013 19:15
Page 1 of 2
Method: M_ActivateActuators
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
fbTransModLiftAct . bResetI := FALSE ;
//manip actuator
fbTransModManipAct . bEnableI := TRUE ;
fbTransModManipAct . bExecuteI := FALSE ;
fbTransModManipAct . bResetI := FALSE ;
//rotational actuator
fbTransModRotAct . bEnableI := TRUE ;
fbTransModRotAct . bExecuteI := FALSE ;
fbTransModRotAct . bResetI := FALSE ;
//determine next state
IF fbTransModRotAct . bStatusO = TRUE THEN
//return value
M_ActivateActuators := TRUE ;
ELSE
//return value
M_ActivateActuators := FALSE ;
END_IF
END_CASE
LCT_mockup_4M230.project
5-2-2013 19:15
Page 2 of 2
Method: M_Init
1
2
3
4
5
6
7
8
9
//name: M_Init
//Version: 1.1
//Date: 16-12-2012, Joni Scholten
//This method initializes the TransportModule
METHOD M_Init : BOOL
VAR_INPUT
stInit
:
ST_M_FB_TransportModule_Init ;
END_VAR
1
bInitialized := fbTransModLiftAct . M_Init ( stInit . stLiftInit ) AND
fbTransModRotAct . M_Init ( stInit . stRotInit ) AND fbTransModManipAct . M_Init
( stInit . stManipInit ) ;
M_init := bInitialized ;
2
3
LCT_mockup_4M230.project
5-2-2013 19:15
Page 1 of 1
C.2.1
Transport Module actuators
(a) FB for the Transport mod- (b) FB for the Transport mod- (c) FB for the Transport module rotation.
ule lift.
ule manipulator.
Figure C.8
96
FB_TransModRotAct 19-12-2012
Stop
McHalt.execute:=TRUE
From any state, excluding
Stop, Disabled,InvalidLocation,
Error and Reset, if
bEnableI:=FALSE
when: McHalt.Done=TRUE
when: McReset.Done=TRUE AND
bResetI=FALSE AND bInitialized=TRUE
Disabled
fbMcReset.Execute:=FALSE
fbMcMoveAbsolute1.Execute:=FALSE
fbMcHalt.Execute:=FALSE
bTaskError:=FALSE
bBusyO:=FALSE
bStatusO:=FALSE
eCalibrateState:=Begin
fbMcPower.Enable:=FALSE
bDoneO:=FALSE
bErrorO:=FALSE
Reset
fbMcReset.Execute:=TRUE
bTaskError:=FALSE
when: bCalibrated=FALSE AND
bEnableI=TRUE
Calibrate
M_Calibrate
when: bResetI=TRUE
when: bCalibrated=TRUE AND
bEnableI=TRUE
when: bInitialized:=FALSE
Error
fbMcMoveAbsolute1.Execute:=FALSE
bStatusO:=FALSE
fbMcPower.Enable:=FALSE
nErrorIDO:=...
bErrorO:=TRUE
bBusyO:=FALSE
bDoneO:=FALSE
PowerOn
From any state, excluding
Error and Reset, if
fbAxis.Status.Error:=TRUE
fbMcPower.Enable_Negative = TRUE
fbMcPower.Enable = TRUE
fbMcPower.Enable_Positive = TRUE
fbMcPower.Override:=100.0
nLocationO:=0
when: fbAxis.Status.Disabled = FALSE
InvalidLocation
when: bExecuteI=TRUE &
(nLocationI >10 OR nLocationI < 1)
Enabled
bStatusO:=TRUE
bTaskError:=TRUE
when: bExecuteI=TRUE &
0 < nLocationI <= 4 THEN
nLocation := nLocationI;
END_IF
when: bExecuteI=TRUE &
(nLocationI >4 OR nLocationI < 1)
when: bExecuteI=TRUE &
0 < nLocationI <= 4 THEN
nLocation := nLocationI;
END_IF
Move1
ReadyForTask
nLocationO:=nLocation
fbMcMoveAbsolute1.position:=afLiftPositions[nLocation]
bBusyO:=fbMcMoveAbsolute1.Busy
fbMcMoveAbsolute1.Execute:=TRUE
bDoneO:=fbMcMoveAbsolute1.Done
fbMcMoveAbsolute1.Execute:=FALSE
bBusyO:=fbMcMoveAbsolute1.Busy
bDoneO:=fbMcMoveAbsolute1.Done
when: McMoveAbsolute1.Done=TRUE
Move2
when: bExecuteI=FALSE
bDoneO:=fbMcMoveAbsolute1.Done
bBusyO:=fbMcMoveAbsolute1.Busy
Figure C.9: State machine for the Transport module rotation.
97
POU: FB_TransModRotAct
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
//name: FB_TransModRotAct
//Version: 1.1
//Date: 15-01-2013, Joni Scholten
//This Function block is defined in the document UML_class_diagram_software_1link_mock-up
FUNCTION_BLOCK FB_TransModRotAct EXTENDS FB_EncoderAct
VAR_INPUT
END_VAR
VAR_OUTPUT
bSenRotEnd1O
:
BOOL ;
//TRUE -> Rotating disc clockwise end sensor is activated. This sensor is used for calibration!
bSenRotEnd2O
:
BOOL ;
//TRUE -> Rotating disc counterclockwise end sensor is activated.
END_VAR
VAR
//state machine states
eState
:
E_FB_TransModRotActStates ;
emCalibrateState
:
E_M_FB_EncActCalibrateStates ;
//internal variables
afRotPositions
:
ARRAY [ 1 .. 4 ] OF LREAL ;
//pointers
pbSenRotEnd1
:
POINTER TO BOOL ;
//This sensor is used for calibration!
pbSenRotEnd2
:
POINTER TO BOOL ;
END_VAR
//TODO
//Make end sensors turn positive if they detect the lift.
fbAxis . ReadStatus ( ) ; //Read the current status of the IO lift axis
CASE eState OF
eTransRotState_Reset
:
//Reset all MC function blocks. Initial state (to cancel possible errors from previous runs)
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
//Internal variables
bTaskError := FALSE ;
//MC function block settings
fbMcPower . Enable := FALSE ;
fbMcReset . Execute := TRUE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
//determine next state
IF NOT bInitialized THEN
eState := eTransRotState_Error ;
ELSIF fbMcReset . Done AND NOT bResetI AND bInitialized THEN
eState := eTransRotState_Disabled ;
END_IF
eTransRotState_Stop
:
//Stop all MC function blocks using MC halt, otherwise an error might occur.
LCT_mockup_4M230.project
5-2-2013 19:09
Page 1 of 5
POU: FB_TransModRotAct
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
//MC function block settings
fbMcHalt . Execute := TRUE ;
//determine next state
IF fbMcHalt . Done THEN
eState := eTransRotState_Disabled ;
END_IF
eTransRotState_Disabled
: //nothing moves, nothing is enabled
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
bTaskError := FALSE ;
emCalibrateState := eEncActCalibState_Begin ;
//Reset M_Calibrate statemachine
//MC function block settings
fbMcReset . Execute := FALSE ;
fbMcPower . Enable := FALSE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
fbMcHalt . Execute := FALSE ;
//Determine next state
IF NOT bCalibrated AND bEnableI THEN
eState := eTransRotState_Calibrate ;
ELSIF bCalibrated AND bEnableI THEN
eState := eTransRotState_PowerOn ;
END_IF
eTransRotState_Calibrate
:
//call M_Calibrate method to perform calibration
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//Run calibration method M_Calibrate
M_Calibrate ( ) ;
//Determine next state
IF bCalibrated AND bEnableI THEN
eState := eTransRotState_PowerOn ;
END_IF
eTransRotState_PowerOn
:
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcPower . Enable := TRUE ;
fbMcPower . Override := 100.0 ;
fbMcPower . Enable_Negative := TRUE ;
fbMcPower . Enable_Positive := TRUE ;
LCT_mockup_4M230.project
5-2-2013 19:09
Page 2 of 5
POU: FB_TransModRotAct
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
fbMcMoveAbsolute1 . Execute := FALSE ;
nLocationO := 0 ;
//Determine next state
IF NOT fbAxis . Status . Disabled THEN
eState := eTransRotState_Enabled ;
END_IF
eTransRotState_Enabled
:
//outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
//determine next state
IF bExecuteI AND nLocationI > 0 AND nLocationI <= 4 THEN
nLocation := nLocationI ;
eState := eTransRotState_Move1 ;
ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 4 THEN
eState := eTransRotState_InvalidLocation ;
END_IF
eTransRotState_Move1
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute1 . Busy ;
bDoneO := fbMcMoveAbsolute1 . Done ;
bErrorO := FALSE ;
//Internal variables
nLocationO := nLocation ;
//MC function block settings
fbMcMoveAbsolute1 . Execute := TRUE ;
fbMcMoveAbsolute1 . Position := afRotPositions [ nLocation ] ;
//Determine next state
IF NOT bExecuteI THEN
eState := eTransRotState_Move2 ;
END_IF
eTransRotState_Move2
:
//Outputs
bStatusO := TRUE ;
bBusyO := fbMcMoveAbsolute1 . Busy ;
bDoneO := fbMcMoveAbsolute1 . Done ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
//Determine next state
IF fbMcMoveAbsolute1 . Done THEN
eState := eTransRotState_ReadyForTask ;
END_IF
eTransRotState_ReadyForTask
//Outputs
bStatusO := TRUE ;
LCT_mockup_4M230.project
5-2-2013 19:09
:
Page 3 of 5
POU: FB_TransModRotAct
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
bBusyO := fbMcMoveAbsolute1 . Busy ;
bDoneO := fbMcMoveAbsolute1 . Done ;
bErrorO := FALSE ;
//Internal variables
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
//determine next state
IF bExecuteI AND nLocationI > 0 AND nLocationI <= 4 THEN
nLocation := nLocationI ;
eState := eTransRotState_Move1 ;
ELSIF bExecuteI AND nLocationI < 0 OR nLocationI > 4 THEN
eState := eTransRotState_InvalidLocation ;
END_IF
eTransRotState_InvalidLocation :
//internal variables
bTaskError := TRUE ;
//MC function block settings
fbMcMoveAbsolute1 . Execute := FALSE ;
//next state
eState := eTransRotState_Error ;
eTransRotState_Error
:
//outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := TRUE ;
//Internal variables
//MC function block settings
fbMcPower . Enable := FALSE ;
fbMcMoveAbsolute1 . Execute := FALSE ;
//Determine errorcode
IF fbAxis . Status . Error THEN
nErrorIDO := fbAxis . Status . ErrorID ;
ELSIF fbMcPower . Error THEN
nErrorIDO := fbMcPower . ErrorID ;
ELSIF fbMcReset . Error THEN
nErrorIDO := fbMcReset . ErrorID ;
ELSIF fbMcSetPosition . Error THEN
nErrorIDO := fbMcSetPosition . ErrorID ;
ELSIF fbMcMoveAbsolute1 . Error THEN
nErrorIDO := fbMcMoveAbsolute1 . ErrorID ;
ELSIF fbMcMoveVelocity . Error THEN
nErrorIDO := fbMcMoveVelocity . ErrorID ;
ELSIF fbMcHalt . Error THEN
nErrorIDO := fbMcHalt . ErrorID ;
ELSIF bTaskError THEN
nErrorIDO := GetErrorCode ( Error_InvalidTask ) ;
ELSIF NOT bInitialized THEN
nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;
END_IF
//Determine next state
IF bResetI THEN
eState := eIOLiftState_Reset ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:09
Page 4 of 5
POU: FB_TransModRotAct
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
END_CASE
//State changes which are the same for almost all states
//check for errors
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
eState := eTransRotState_Error ;
// check if lift should be disabled
ELSIF NOT bEnableI AND eState <> eTransRotState_Reset AND eState <>
eTransRotState_Error AND eState <> eTransRotState_InvalidLocation AND
eState <> eTransRotState_Stop AND eState <> eTransRotState_Disabled THEN
eState := eTransRotState_Stop ;
END_IF
//avoid pointer errors
IF bInitialized THEN
A_RunMcFunctionBlocks ( ) ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:09
Page 5 of 5
Method: M_Calibrate
1
2
3
4
5
6
7
//Version: 1.1
//Date: 15-01-2013, Joni Scholten
//Calibration procedure for the FB_TransModRotAct.
METHOD PRIVATE M_Calibrate : BOOL
VAR_INPUT
END_VAR
1
2
CASE emCalibrateState OF
eEncActCalibState_Begin
:
//startsequence of calibration
bCalibrated := FALSE ;
//Determine next state
IF bEnableI := TRUE THEN
emCalibrateState := eEncActCalibState_StartCalibration ;
END_IF
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
eEncActCalibState_StartCalibration
: //enable MC_Power of axis
//Set Mc Function blocks
fbMcPower . Enable := TRUE ;
fbMcPower . Enable_Positive := TRUE ;
fbMcPower . Enable_Negative := TRUE ;
fbMcPower . Override := 100.0 ;
IF fbMcPower . Status THEN
emCalibrateState := eEncActCalibState_Active ;
END_IF
eEncActCalibState_Active
:
////Set Mc Function blocks
fbMcMoveVelocity . Velocity := fSpeedCalibFast ;
//Determine next state
IF NOT pbSenRotEnd2 ^ THEN
emCalibrateState := eEncActCalibState_BottomEndSensorActive ;
ELSIF pbSenRotEnd2 ^ THEN
emCalibrateState := eEncActCalibState_NotAtBottom ;
END_IF
eEncActCalibState_NotAtBottom
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Direction := MC_Negative_Direction ;
//Determine next state
IF NOT pbSenRotEnd2 ^ THEN
emCalibrateState := eEncActCalibState_BottomEndSensorActive ;
fbMcMoveVelocity . Execute := FALSE ;
END_IF
eEncActCalibState_BottomEndSensorActive
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Direction := MC_Positive_Direction ;
//Determine Next state
IF pbSenRotEnd2 ^ THEN
emCalibrateState := eEncActCalibState_FindIndex ;
fbMcMoveVelocity . Execute := FALSE ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:10
Page 1 of 2
Method: M_Calibrate
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
eEncActCalibState_FindIndex
:
////Set Mc Function blocks
fbMcMoveVelocity . Execute := TRUE ;
fbMcMoveVelocity . Velocity := fSpeedCalibSlow ;
//THIS VALUE IS CRITICAL FOR DETECTION OF ENCODER INDEX signal
//determine next state
IF pbEncoderIndex ^ THEN
emCalibrateState := eEncActCalibState_SetPosition ;
END_IF
eEncActCalibState_SetPosition
:
fbMcSetPosition . Position := 0.0 ;
fbMcSetPosition . Execute := TRUE ;
fbMcSetPosition . Mode := FALSE ;
//Determine next state
IF fbMcSetPosition . Done THEN
emCalibrateState := eEncActCalibState_MoveToStart ;
END_IF
eEncActCalibState_MoveToStart
:
//Set Mc Function blocks
fbMcMoveVelocity . Execute := FALSE ;
fbMcPower . Override := 100 ;
fbMcSetPosition . Execute := FALSE ;
fbMcMoveAbsolute1 . Execute := TRUE ;
fbMcMoveAbsolute1 . Position := afRotPositions [ 1 ] ;
//Determine next state
IF fbMcMoveAbsolute1 . Done THEN
emCalibrateState := eEncActCalibState_Calibrated ;
END_IF
eEncActCalibState_Calibrated
bCalibrated := TRUE ;
END_CASE
LCT_mockup_4M230.project
5-2-2013 19:10
:
Page 2 of 2
Method: M_Init
1
2
3
4
5
6
7
8
9
10
11
12
//name: M_Init
//Version: 1.2
//Date: 08-02-2013, Joni Scholten
//This method initializes the rotating actuator in the transport module
METHOD PUBLIC M_Init : BOOL
VAR_INPUT
stInit
:
ST_M_FB_TransModRotAct_Init ;
END_VAR
VAR
counter
: BYTE ;
END_VAR
1
2
3
//Check if positions are well sorted, otherwise initialisation failed
FOR counter := 2 TO 4 DO
IF stInit . afRotPositionsI [ counter ] < stInit . afRotPositionsI [
counter - 1 ] THEN
M_Init := FALSE ;
RETURN ;
END_IF
END_FOR
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
FOR counter := 1 TO 4 DO
afRotPositions [ counter ] := stInit . afRotPositionsI [ counter ] + stInit .
fOffsetI ;
END_FOR
pbSenRotEnd1 := stInit . pbSenRotEnd1 ;
pbSenRotEnd2 := stInit . pbSenRotEnd2 ;
pbEncoderIndex := stInit . pbEncoderIndex ;
bCalibrated := FALSE ;
//check if fast calibration speed is slower than slow calibration speed. Otherwise initialisation
IF stInit . fSpeedCalibFast < stInit . fSpeedCalibSlow THEN
M_Init := FALSE ;
RETURN ;
ELSE
fSpeedCalibFast := stInit . fSpeedCalibFast ;
fSpeedCalibSlow := stInit . fSpeedCalibSlow ;
END_IF
fbMcMoveAbsolute1 . Velocity := stInit . fSpeedNormal ;
bInitialized := TRUE ;
M_Init := TRUE ;
LCT_mockup_4M230.project
8-2-2013 9:52
Page 1 of 1
Figure C.10: State machine for the Transport module lift.
106
POU: FB_TransModLiftAct
1
2
3
4
//name: FB_TransModLiftAct
//Version: 1.4
//Date: 15-01-2012, Joni Scholten
//This Function block is defined in the document UML_class_diagram_software_1link_mock-up
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
//This Function block is described in the document software_UML_Statediagrams
//Function block represents the lifting actuator in the transport module
FUNCTION_BLOCK FB_TransModLiftAct EXTENDS FB_Act
VAR_INPUT
END_VAR
VAR_OUTPUT
bSenLiftDownO
:
BOOL ; //TRUE -> Bottom lift sensor is activated
bSenLiftUpO
:
BOOL ; //TRUE -> Top lift sensor is activated
bMovingUpO
:
BOOL ;
//TRUE: lift moves up, FALSE: lift moves down
END_VAR
VAR
eState
:
E_FB_TransModLiftActStates ;
pbMoveLiftAct
:
POINTER TO BOOL ;
//TRUE--> lift actuator moves, FALSE-->lift is stopped
pbDirLiftAct
:
POINTER TO BOOL ;
//determines direction of lift actuator
pbSenLiftUp
:
POINTER TO BOOL ;
pbSenLiftDown
:
POINTER TO BOOL ;
END_VAR
CASE eState OF
eTransLiftState_Disabled
:
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bMovingUpO := FALSE ;
//internal variables
pbMoveLiftAct ^ := FALSE ;
//Determine next state
IF bEnableI AND bInitialized THEN
eState := eTransLiftState_MovingDown ;
ELSIF bEnableI AND NOT bInitialized THEN
eState := eTransLiftState_Error ;
END_IF
eTransLiftState_MovingDown
:
//Outputs
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingUpO := FALSE ;
//internal variables
pbMoveLiftAct ^ := TRUE ;
pbDirLiftAct ^ := FALSE ;
//Determine next state
IF NOT pbSenLiftDown ^ THEN
eState := eTransLiftState_LiftDown ;
END_IF
LCT_mockup_4M230.project
5-2-2013 12:46
Page 1 of 3
POU: FB_TransModLiftAct
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
eTransLiftState_LiftDown
:
//Outputs
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingUpO := FALSE ;
//internal variables
pbMoveLiftAct ^ := FALSE ;
//Determine next state
IF NOT bExecuteI THEN
eState := eTransLiftState_ReadyForNewTaskDown ;
END_IF
eTransLiftState_ReadyForNewTaskDown :
//Outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingUpO := FALSE ;
//internal variables
pbMoveLiftAct ^ := FALSE ;
//Determine next state
IF bExecuteI THEN
eState := eTransLiftState_MovingUp ;
END_IF
eTransLiftState_MovingUp
:
//Outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingUpO := TRUE ;
//internal variables
pbMoveLiftAct ^ := TRUE ;
pbDirLiftAct ^ := TRUE ;
//Determine next state
IF NOT pbSenLiftUp ^ THEN
eState := eTransLiftState_LiftUp ;
END_IF
eTransLiftState_LiftUp
:
//Outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingUpO := TRUE ;
//internal variables
pbMoveLiftAct ^ := FALSE ;
//Determine next state
IF NOT bExecuteI THEN
eState := eTransLiftState_ReadyForNewTaskUp ;
END_IF
eTransLiftState_ReadyForNewTaskUp
//Outputs
bStatusO := TRUE ;
LCT_mockup_4M230.project
5-2-2013 12:46
:
Page 2 of 3
POU: FB_TransModLiftAct
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingUpO := TRUE ;
//internal variables
pbMoveLiftAct ^ := FALSE ;
//Determine next state
IF bExecuteI THEN
eState := eTransLiftState_MovingDown ;
END_IF
eTransLiftState_Error
:
bErrorO := TRUE ;
IF NOT bInitialized THEN
nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;
END_IF
//Determine next state
IF bResetI := TRUE THEN
eState := eTransLiftState_Reset ;
END_IF
eTransLiftState_Reset
:
bErrorO := FALSE ;
nErrorIDO := 0 ;
IF bResetI := FALSE THEN
eState := eTransLiftState_Disabled ;
END_IF
END_CASE
IF NOT bEnableI THEN
eState := eTransLiftState_Disabled ;
END_IF
bSenLiftDownO := NOT pbSenliftDown ^ ;
bSenLiftUpO := NOT pbSenLiftUp ^ ;
LCT_mockup_4M230.project
5-2-2013 12:46
Page 3 of 3
Method: M_Init
1
2
3
4
5
6
7
8
9
//name: M_Init
//Version: 1.0
//Date: 14-12-2012, Joni Scholten
//This method initializes the Lift actuator in the Transport module
METHOD PUBLIC M_Init : BOOL
VAR_INPUT
stInit
: ST_M_FB_TransModLiftAct_Init ;
END_VAR
1
2
3
4
5
6
7
pbMoveLiftAct
pbDirLiftAct
pbSenLiftUp
pbSenLiftDown
bInitialized
M_Init
LCT_mockup_4M230.project
5-2-2013 12:47
:=
:=
:=
:=
:=
:=
stInit . pbMoveLiftAct ;
stInit . pbDirLiftAct ;
stInit . pbSenLiftUp ;
stInit . pbSenLiftDown ;
TRUE ;
TRUE ;
Page 1 of 1
Figure C.11: State machine for the Transport module manipulator.
111
POU: FB_TransModManipAct
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
1
2
3
4
5
6
7
8
9
10
11
12
13
//name: FB_TransModManAct
//Version: 1.2
//Date: 15-01-2013, Joni Scholten
//This Function block is defined in the document UML_class_diagram_software_1link_mock-up
//Function block represents the manipulator actuator in the transport module
FUNCTION_BLOCK FB_TransModManipAct EXTENDS FB_Act
VAR_INPUT
END_VAR
VAR_OUTPUT
bSenManipInEndO
:
BOOL ;
//TRUE -> Manipulator inward end sensor is activated.
bSenManipOutEndO
:
BOOL ;
//TRUE -> Manipulator outward end sensor is activated.
bSenManipInO
:
BOOL ;
//TRUE -> Manipulator inward sensor is activated
bSenManipOutO
:
BOOL ;
//TRUE -> Manipulator outward sensor is activated.
bMovingOutO
:
BOOL ;
//TRUE -> Manipulator is moving out, or standing still at outward position
END_VAR
VAR
eState
:
E_FB_TransModManipActStates ;
//states for transport manipulator
//function blocks
fbTimer
:
TON ; //timer functionblock
//normal variables
nSpeedFast
:
INT ;
nSpeedSlow
:
INT ;
timeFastMovement
:
TIME ;
//pointers
pbActLinEnable
pnSetPlus
pnSetMin
pbSenManipInEnd
pbSenManipOutEnd
pbSenManipIn
pbSenManipOut
:
:
:
:
:
:
:
POINTER
POINTER
POINTER
POINTER
POINTER
POINTER
POINTER
TO
TO
TO
TO
TO
TO
TO
BOOL ;
INT ;
INT ;
BOOL ;
BOOL ;
BOOL ;
BOOL ;
END_VAR
CASE eState OF
eTransManipState_Disabled
//Outputs
bStatusO := FALSE ;
bBusyO := FALSE ;
bDoneO := FALSE ;
bErrorO := FALSE ;
nErrorIDO := 0 ;
bMovingOutO := FALSE ;
//internal variables
IF bInitialized THEN
pbActLinEnable ^ := FALSE ;
END_IF
LCT_mockup_4M230.project
5-2-2013 19:07
:
Page 1 of 5
POU: FB_TransModManipAct
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
//Determine next state
IF bEnableI AND bInitialized THEN
eState := eTransManipState_MoveInSlow ;
ELSIF NOT bInitialized THEN
eState := eTransManipState_Error ;
END_IF
eTransManipState_MoveInSlow
:
//Outputs
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingOutO := FALSE ;
//internal variables
pbActLinEnable ^ := TRUE ;
fbTimer . IN := FALSE ;
//SET SLOW SPEED////////////////////////////////////////////////////
pnSetPlus ^ := - 1 * nSpeedSlow ;
pnSetMin ^ := nSpeedSlow ;
//Determine next state
IF NOT pbSenManipIn ^ THEN
eState := eTransManipState_StoppedIn ;
END_IF
eTransManipState_StoppedIn
:
//Outputs
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingOutO := FALSE ;
//internal variables
pbActLinEnable ^ := FALSE ;
//determine next state
IF NOT bExecuteI THEN
eState := eTransManipState_ReadyForNewTaskIn ;
END_IF
eTransManipState_ReadyForNewTaskIn
:
//Outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingOutO := FALSE ;
//internal variables
pbActLinEnable ^ := FALSE ;
//determine next state
IF bExecuteI THEN
eState := eTransManipState_MoveOutFast ;
END_IF
eTransManipState_MoveOutFast
//Outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingOutO := TRUE ;
//internal variables
pbActLinEnable ^ := TRUE ;
LCT_mockup_4M230.project
5-2-2013 19:07
:
Page 2 of 5
POU: FB_TransModManipAct
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
//SET FAST SPEED/////////////////////////////////////////
pnSetPlus ^ := nSpeedFast ;
pnSetMin ^ := - 1 * nSpeedFast ;
fbTimer . IN := TRUE ;
fbTimer . PT := timeFastMovement ;
//determine next state
IF fbTimer . Q OR NOT pbSenManipOut ^ THEN
eState := eTransManipState_MoveOutSlow ;
END_IF
eTransManipState_MoveOutSlow
:
//Outputs
bStatusO := TRUE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingOutO := TRUE ;
//internal variables
pbActLinEnable ^ := TRUE ;
//SET SLOW SPEED/////////////////////////////////////////
pnSetPlus ^ := nSpeedSlow ;
pnSetMin ^ := - 1 * nSpeedSlow ;
fbTimer . IN := FALSE ;
//Determine next state
IF NOT pbSenManipOut ^ THEN
eState := eTransManipState_StoppedOut ;
END_IF
eTransManipState_StoppedOut
:
//Outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingOutO := TRUE ;
//internal variables
pbActLinEnable ^ := FALSE ;
//Determine next state
IF NOT bExecuteI THEN
eState := eTransManipState_ReadyForNewTaskOut ;
END_IF
eTransManipState_ReadyForNewTaskOut
:
//Outputs
bStatusO := TRUE ;
bBusyO := FALSE ;
bDoneO := TRUE ;
bMovingOutO := TRUE ;
//internal variables
pbActLinEnable ^ := FALSE ;
//determine next state
IF bExecuteI THEN
eState := eTransManipState_MoveInFast ;
END_IF
eTransManipState_MoveInFast
//Outputs
bStatusO := TRUE ;
LCT_mockup_4M230.project
5-2-2013 19:07
:
Page 3 of 5
POU: FB_TransModManipAct
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
bBusyO := TRUE ;
bDoneO := FALSE ;
bMovingOutO := FALSE ;
//internal variables
pbActLinEnable ^ := TRUE ;
//SET FAST SPEED/////////////////////////////////////////
pnSetPlus ^ := - 1 * nSpeedFast ;
pnSetMin ^ := nSpeedFast ;
fbTimer . IN := TRUE ;
fbTimer . PT := timeFastMovement ;
//determine next state
IF fbTimer . Q OR NOT pbSenManipIn ^ THEN
eState := eTransManipState_MoveInSlow ;
END_IF
eTransManipState_MoveInSlowDis
:
//Outputs
bStatusO := FALSE ;
bBusyO := TRUE ;
bDoneO := FALSE ;
//bMovingOutO:=FALSE;
//internal variables
pbActLinEnable ^ := TRUE ;
fbTimer . IN := FALSE ;
//SET SLOW SPEED////////////////////////////////////////////////////
pnSetPlus ^ := - 1 * nSpeedSlow ;
pnSetMin ^ := nSpeedSlow ;
//Determine next state
IF NOT pbSenManipIn ^ THEN
eState := eTransManipState_Disabled ;
END_IF
eTransManipState_Error
:
//Outputs
bErrorO := TRUE ;
bDoneO := FALSE ;
bBusyO := FALSE ;
//internal variables
IF bInitialized THEN
pbActLinEnable ^ := FALSE ;
END_IF
//Get error codes
IF NOT bInitialized THEN
nErrorIDO := GetErrorCode ( Error_NotInitialized ) ;
ELSIF pbSenManipInEnd ^ OR NOT pbSenManipOutEnd ^ THEN
nErrorIDO := GetErrorCode ( Error_EndSensorActivated ) ;
END_IF
//Determine next state
IF bResetI THEN
eState := eTransManipState_Reset ;
END_IF
eTransManipState_Reset
//Outputs
bErrorO := FALSE ;
nErrorIDO := 0 ;
LCT_mockup_4M230.project
5-2-2013 19:07
:
Page 4 of 5
POU: FB_TransModManipAct
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
//internal variables
IF bInitialized THEN
pbActLinEnable ^ := FALSE ;
END_IF
//Determine next state
IF NOT bResetI THEN
eState := eTransManipState_Disabled ;
END_IF
END_CASE
IF bInitialized THEN
//END sensors activated --> problem
IF pbSenManipInEnd ^ OR pbSenManipOutEnd ^ THEN
eState := eTransManipState_Error ;
ELSIF NOT bEnableI AND eState <> eTransManipState_Disabled
eState <> eTransManipState_Error THEN //disable function block
eState := eTransManipState_MoveInSlowDis ;
END_IF
AND
//set outputs
bSenManipInO := NOT pbSenManipIn ^ ;
bSenManipOutO := NOT pbSenManipOut ^ ;
bSenManipInEndO := pbSenManipInEnd ^ ;
bSenManipOutEndO := pbSenManipOutEnd ^ ;
END_IF
fbTimer ( ) ;
LCT_mockup_4M230.project
5-2-2013 19:07
Page 5 of 5
Method: M_Init
1
2
3
4
5
6
7
8
9
//name: M_Init
//Version: 1.2
//Date: 08-02-2013, Joni Scholten
//This method initializes the manipulator actuator in the Transport module
METHOD PUBLIC M_Init : BOOL
VAR_INPUT
stInit
: ST_M_FB_TransModManipAct_Init ;
END_VAR
1
2
3
timeFastMovement
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
:=
stInit . timeFastMovement ;
//check if speeds are well defined between 0.0 and 100.0, otherwise initialisation failed
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
M_Init := FALSE ;
RETURN ;
ELSE
nSpeedFast
:= REAL_TO_INT ( stInit . fSpeedFast / 100 * ( EXPT ( 2 ,
15 ) - 1 ) ) ;
nSpeedSlow
:= REAL_TO_INT ( stInit . fSpeedSlow / 100 * ( EXPT ( 2 ,
15 ) - 1 ) ) ;
END_IF
pbActLinEnable
pnSetPlus
pnSetMin
pbSenManipInEnd
pbSenManipOutEnd
pbSenManipIn
pbSenManipOut
:=
:=
:=
:=
:=
:=
:=
stInit
stInit
stInit
stInit
stInit
stInit
stInit
.
.
.
.
.
.
.
pbActLinEnable ;
pnSetPlus ;
pnSetMin ;
pbSenManipInEnd ;
pbSenManipOutEnd ;
pbSenManipIn ;
pbSenManipOut ;
bInitialized := TRUE ;
M_Init := TRUE ;
LCT_mockup_4M230.project
8-2-2013 9:57
Page 1 of 1
118
Appendix D
Software extra
D.1
GetErrorCode
Providing a user with information about the occurrence of an error is crucial for debugging
purposes. 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 codes
found in the MC function blocks of the Tc2 MC library. All error codes starting with 4... in
hexadecimal coding are directly related to the TwinCAT tc2 MC library. More information
on 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.1
shows 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 FB
statemachine. Future users can introduce new error codes when needed by adding a new line
(a) Structured text code of
E 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. Figure
D.3 shows how to use the GetErrorCode function, the example is taken from the statemachine
of 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. This
function can be called from any test program, instead of initializing all modules inside every
new test program.
120
POU: Initialize_all
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
//15-01-2013 Joni Scholten
//this function is used to initialize all modules of the 1 link mock-up.
//NB: calibration of the encoders is not performed with this function
FUNCTION Initialize_all : bool
VAR_INPUT
END_VAR
VAR
//IO module
stInitIOLiftAct
:
ST_M_FB_IOModLiftAct_Init ;
stInitIOModule
:
ST_M_FB_IOModule_Init ;
afLiftPosistions
:
ARRAY [ 1 .. 10 ] OF LREAL ;
nCounter
:
BYTE ;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
//initialize I/O module
FOR nCounter := 1 TO 10 DO
afLiftPosistions [ nCounter ] := ( nCounter - 1 ) * 14.0 ;
END_FOR
stInitIOLiftAct . afLiftPositionsI := afLiftPosistions ;
stInitIOLiftAct . fOffsetI := 10.0 ;
stInitIOLiftAct . pbSenLiftBottom := ADR ( bIOLiftBottomEndSenI ) ;
stInitIOLiftAct . pbSenLiftTop := ADR ( bIOLiftTopEndSenI ) ;
stInitIOLiftAct . pbEncoderIndex := ADR ( bIOLiftEncoderIndexI ) ;
stInitIOLiftAct . fSpeedCalibSlow := 0.5 ;
stInitIOLiftAct . fSpeedCalibFast := 2.5 ;
stInitIOLiftAct . fSpeedNormal := 50.0 ;
stInitIOModule . stLiftInit := stInitIOLiftAct ;
stInitIOModule . pbWaferSensor := ADR ( bIOWaferSensorI ) ;
//disable IO module
fbIOModule . bEnableI := FALSE ;
fbIOModule . bExecuteI := FALSE ;
fbIOModule . bResetI := FALSE ;
//Transport module
stInitTransLiftAct
stInitTransRotAct
stInitTransManipAct
stInitTransportModule
afTransRotPositions
END_VAR
:
:
:
:
:
ST_M_FB_TransModLiftAct_Init ;
ST_M_FB_TransModRotAct_Init ;
ST_M_FB_TransModManipAct_Init ;
ST_M_FB_TransportModule_Init ;
ARRAY [ 1 .. 4 ] OF LREAL ;
//initialize Transport module
//lift actuator
stInitTransLiftAct . pbMoveLiftAct := ADR ( bTransLiftEnableO ) ;
stInitTransLiftAct . pbDirLiftAct := ADR ( bTransLiftDirectionO ) ;
stInitTransLiftAct . pbSenLiftUp := ADR ( bTransLiftSenUpI ) ;
stInitTransLiftAct . pbSenLiftDown := ADR ( bTransLiftSenDownI ) ;
//disable lift actuator
//fbTransModLiftAct.bExecuteI:=FALSE;
//fbTransModLiftAct.bEnableI:=FALSE;
//Rotation actuator
FOR nCounter := 1 TO 4 DO
afTransRotPositions [ nCounter ] := ( nCounter - 1 ) * 90 ;
END_FOR
stInitTransRotAct . afRotPositionsI := afTransRotPositions ;
stInitTransRotAct . fOffsetI := 9.25 ;
LCT_mockup_4M230.project
4-2-2013 16:00
Page 1 of 2
POU: Initialize_all
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
stInitTransRotAct . pbSenRotEnd1 := ADR ( bTransRotSenEnd1I ) ;
stInitTransRotAct . pbSenRotEnd2 := ADR ( bTransRotSenEnd2I ) ;
stInitTransRotAct . pbEncoderIndex := ADR ( bTransRotEncoderIndexI ) ;
stInitTransRotAct . fSpeedCalibSlow := 0.2 ;
stInitTransRotAct . fSpeedCalibFast := 2.5 ;
stInitTransRotAct . fSpeedNormal := 150 ;
//manipulator actuator
stInitTransManipAct . fSpeedFast := 40 ;
stInitTransManipAct . fSpeedSlow := 5 ;
stInitTransManipAct . pbActLinEnable := ADR ( bTransManipEnableO ) ;
stInitTransManipAct . pbSenManipIn := ADR ( bTransManipSenInI ) ;
stInitTransManipAct . pbSenManipOut := ADR ( bTransManipSenOutI ) ;
stInitTransManipAct . pbSenManipInEnd := ADR ( bTransManipLimSenInI ) ;
stInitTransManipAct . pbSenManipOutEnd := ADR ( bTransManipLimSenOutI ) ;
stInitTransManipAct . pnSetMin := ADR ( nTransManipSetMinO ) ;
stInitTransManipAct . pnSetPlus := ADR ( nTransManipSetPlusO ) ;
stInitTransManipAct . timeFastMovement := T#900MS ;
//transport module
stInitTransportModule . stLiftInit := stInitTransLiftAct ;
stInitTransportModule . stManipInit := stInitTransManipAct ;
stInitTransportModule . stRotInit := stInitTransRotAct ;
//disable transport module
fbTransportModule . bEnableI := FALSE ;
fbTransportModule . bExecuteI := FALSE ;
fbTransportModule . bResetI := FALSE ;
fbTransportModule . bEnableManipI := FALSE ;
Initialize_all := fbIOModule . M_Init ( stInitIOModule ) AND fbTransportModule
. M_Init ( stInitTransportModule ) ;
63
LCT_mockup_4M230.project
4-2-2013 16:00
Page 2 of 2
D.3
Connecting a variable using TwinCAT IO
This section explains how to establish a link between a variable in a PLC program and a
physical EtherCAT channel under TwinCAT 3. As an example the variable associated with
the 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: line
three bIOLiftEncoderIndexI. Notice the AT%I* notation. The next step is to link this global
variable to an EtherCAT channel using the TwinCAT I/O tab. This is shown in Figure
D.5, which shows that bIOLiftEncoderIndexI is linked to channel 1 of an EL1124 EtherCAT
terminal.
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 3
I/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 DC
motor controllers with incremental encoder, that are used in the mock-up, is treated. This
is followed by a description of the tuning of relevant parameters related to the real time
performance of TwinCAT 3.
Position control: DC motor with incremental encoder
The mock-up consists of two DC motors with incremental encoder. Both these motors are
controlled by a Beckhoff EL7342 DC motor controller, which is a hardware proportional
integrator (PI) controller, as shown in the CoE Online registers beginning with index 8021
in [2]. Configuring the controller is done using the Motion tab of TwinCAT 3, since this project
uses TwinCAT 3, as stated in Chapter 8. TwinCAT automatically recognizes the EL7342 as
part of an axis, so it creates an axis in the motion tab of TwinCAT 3. An axis in TwinCAT
3 always contains, among other tabs, an textitCtrl tab, as shown in Figure E.1a. Ctrl is an
abbreviation for controller and this tab contains all options with respect to the controller of
the axis. TwinCAT 3 offers various controller types. The EL7342 is an PI controller, as stated
earlier, but more complicated controllers can be selected, in which case the PC is partly used
to calculate a controller. Both a textitposition controller P (proportional controller) and an
position controller PID (with Ka) (proportional integration and differentiation) were tested
on the lift of the IO-module. The transfer function of the PID controller implemented in
TwinCAT Motion is shown in (E.1). A plain P controller worked fine, but a steady state
error remained, as is always the case with this type of controller. The steady state error was
reduced by introducing the integration term in the controller. Simple tests can be run on
an NC axis using the online tab of an Axis under the Motion tab in TwinCAT 3, as shown
in Figure E.1b. To enable the axis, click the set button and then click ”all” in the pop-up
screen. Now it is possible to move the axis by means of the buttons in the left bottom corner
in Figure E.1b. The functions tab in Figure E.1b provides simple but useful tasks for the
axis, like for instance ”move to 10 mm with a speed of 10 mm/sec”.
G(s) = Kp (1 +
1
Tv s
+
)
Tn s 1 + Td s
(E.1)
125
(a) The Motion tab in TwinCAT 3 for the 1 link LCT (b) The online test environment of an Axis under the TwinCAT 3
mock-up.
motion tab.
Tuning the PI controller
Many books and articles have been written about the tuning of a PI controller. Some of the
methods require a complete model of the system to be available, while others are based on
some basic measurements on the actual system. For this project a method called The Good
Gain 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. The
control signal is provided to the system using the online part of the axis tab in motion part of
TwinCAT. 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 Transport
module.
Using the right settings, a step signal was approximated, and using TwinCAT Scope a step
response was obtained, as can be seen in Figure E.1. This step response is used to determine
Tou , which is the time between the undershoot (marked by blue line) and overshoot (marked
by green line), as described in [8]. Next the integral action time Tn in (E.1) is set equal
to Tn = 1.5Tou = 25ms. In practice it turns out that the system is less noisy when Tn is
increased to 60ms as can be seen in Figure E.2. An integration term generally slows down
the system’s response. To make the response faster, a differentiating term can be used. A
downside of this term is amplification of noise, as explained in [8]. The settling time of the lift
is about 0.2 seconds, as shown in Figure E.2, which is fast enough. Therefore, a differentiating
term is not used, meaning that both Tv and Td in (E.1) are set to zero. Figure E.3 shows
that 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 shape
of the plot.
126
Figure E.1: Determining Tou for the lift in the I/O module, as described in [8]. Screen shot
of 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. They
determine the timing of all components (NC-tasks, PLC-tasks, etc.) and can result in unexpected behavior when poorly chosen. One of the most critical tasks in any machine is its
initialization procedure. The standard RT settings of TwinCAT resulted in undefined behavior during initialization. The reference position was not always the same, for the complete
procedure see Chapter 8. Sometimes the lift would pass the index signal without resetting its
position 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 of
the transport module are equipped with an incremental encoder, for more information
read [22, p.18]. The index signal of these encoders is synchronized with either channel
A or B. The general formula for calculating the resolution is shown in (E.2).
resolution =
2π · pulleyRadius
inc/rev · gearratio
(E.2)
2π·22.28
I/O module lift The theoretical resolution is resolution = 512·185193/2197
= 0.0032436246[mm/inc].
It turned out that this value resulted in a small offset. Through measurements a
more 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 PLC
loop 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 numeric
controller (NC) is recalculated.
These parameters together determine how fast the lift can move during initialization. The
following constraint must be met: the index signal should remain true for at least the input
filter time and cycle time together. The input filter time is irrelevant, since the cycle time is
50000 times higher than the input filter time. The index signal of the encoder is synchronized
with either channel A or B, which are both true during two increments. This means that the
index signal is true for a distance of 2 · resolution = 0.006516mm. A new TwinCAT project
always has a PLC cycle time of 10ms. With this setting, the lift must not move faster than
0.006516
= 0.65[m/s]. During normal operation however, the lift is not moving at a constant
0.01
speed, but its speed varies with a deviation of ±1[m/s], as Figure E.5 shows. Therefore, the
lift is not guaranteed to move slower than 0.65[m/s]. To make the initialization procedure
more robust, the cycle time is set to 2.5ms as shown in Figure E.4. This means that the lift
must not move faster than 0.006516
0.0025 = 2.6[m/s], which is easier satisfied and therefore more
robust. 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 to
0.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 a
five inputs, located on the right of the circuit. The input connected to the green dotted line
is supposed to be connected to the output of the initialize button of the user interface as
introduced 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 be
connected to the output of a safety sensor chain, as shown in Figure 7.3. The chip used in
this circuit is the TEXAS 74ACT11032 Quadruple 2-input positive-OR gates chip. The OR
inputs are supposed to be either 0 or 24 Volt. R1 and R2 form a voltage divider to reduce
the 24 Volt signals to 5 Volt signals, to make the signals fall within the operating range of
the 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-up
tool, divided in both input signals and output signals. The system in the coding is straight
forward. The first letter in the code represents the module it belongs to, the digit then can
be looked up in the table for the exact signal it resembles. In Table G.1 the inputs are shown
and in Table G.2 the outputs are shown.
133
I/O module
Label
I1
I2 grey
I2 yellow
I2 blue
I2 green
Transport module
T1
T2
T3
T4
T5
T6 yellow
T6 blue
T6 black
T8
T9
Buffer module
B
Process modules
P1
P2
P3
Table G.1: Input signals for the ethercat modules.
EtherCat
EL7342.1 +EL1124.1
2.1
2.2
2.3
OR Gate 1 +EL7342.1
encoder signals (yellow = A, blue = B, green = Index)
wafer sensor (black = signal, blue =0V, brown = 24V)
top end sensor
bottom end sensor
hardware enable
description
I/O module
I/O module
I/O module
I/O module
I/O module
EL7342.2
2.4
3.1
3.2
3.3
3.4
4.1
Linked to T10 blue
4.2
OR Gate 2
4.3
4.4
5.1
Transport module encoder signals (yellow = A, blue = B, green = Index)
Transport module lift down (black=signal, blue=0V, red=24V)
Transport module lift up (black=signal, blue=0V, red=24V)
Transport module manipulator sensor In (black=signal, blue=0V, brown=24V)
Transport module manipulator sensor Out (black=signal, blue=0V,brown=24V)
Transport module manipulator limit sensor In
Transport module manipulator limit sensor Out
Transport module manipulator HW enable
Transport module rotation end sensor 1 -¿ HW enable
(black=signal, blue=0V,brown=24V)
Transport module rotation end sensor 2 -¿ calibration sensor
(black=signal, blue=0V,brown=24V)
Buffer module wafer sensor (black=signal, blue=0V,brown=24V)
Process module 1 wafer sensor (black=signal, blue=0V,brown=24V)
Process module 2 wafer sensor (black=signal, blue=0V,brown=24V)
Process module 3 wafer sensor (black=signal, blue=0V,brown=24V)
134
135
I/O module
IM
Transport module
T6 Red
T10 yellow
T10 Green
T10 Blue
T11 yellow
T11 blue
TM
Transport
Transport
Transport
Transport
Transport
Transport
Transport
module
module
module
module
module
module
module
manip HW enable
manip set+
manip setmanip to HW enable of motor amplifier
lift enable
lift direction
rotation motor voltage
I/O module lift motor voltage
Table G.2: Output signals from the ethercat modules
2.3
1.1
1.2
Linked to T6 black
2.1
2.2
136
Appendix H
Contact information
This appendix contains the information of every supplier that is used in the last two phases of
this project. Some components are hard to find, for example the LED indicators on the user
interface 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 person
that is reached. This will all an easy trace if the communication is not smooth. If there is no
contact 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 and
I/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 the
manipulator uses a linear guidance that is made by Hepcomotion. The delivery time can vary
with 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 buffer
modules. 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 axis
of 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 interfaces. 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 products
that 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)70
5119322
Baco
Baco is the supplier of buttons and lamps that are used in the control panel of the user
interface. The prices of these products are not always available on the website. The prices
can 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’s
are 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 and
estimate the cost before the part is ordered. For smaller parts Henri Vliegen can be asked in
the workshop of mechanical engineering.
Phone Harrie: +31 (0)40 2473496 Location Harrie: TNO 0.097 Phone Henri: +31 (0)40
2473722 Location Henri: Gemini North 1.50
139