Eindhoven University of Technology

MASTER

Investigation of EtherCAT for the motion building blocks

Rajappa, Raghu

Award date:
2017

Link to publication

Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student
theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document
as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required
minimum study period may vary in duration.

General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
Department of Mathematics and Computer Science
Electronics Systems Group

Investigation of
EtherCAT for the
Motion Building
Blocks
Master Thesis

Raghu Rajappa

Supervisors:
Nabi Najafabadi, M.
[Link] [Link]
Laurens van de Laar
Nico Meijerman

1.0 version

Eindhoven, June 2017

 Declaration of Authorship

I, Raghu Rajappa, declare that this thesis titled, “Investigation of EtherCAT for theMo-
tion BuildingBlocks” and the work presented in it are my own. I confirm that:

• This work was done wholly while in candidature for the [Link]. degree at Eindhoven
5 University of Technology.

• I have clearly attributed every instance at which I have consulted the published work
of others.

• Where I have quoted from the work of others, the source is always given. With the
exception of such quotations, this thesis is entirely my own work.

10 • I have acknowledged all main sources of help.

The citation conventions usual to the discipline in question here have been respected.
Throughout this report, as a personal choice, I have used a third-person writing approach,
hence using we instead of I from here on. This written work may be tested electronically
for plagiarism.
15

Signed:

Date:

ii Investigation of EtherCAT for the Motion Building Blocks

 Abstract

20 This thesis project is done at NTS-Group, a high tech company which specializes in
low to medium-volume, high-complexity industrial systems. One area of focus at NTS is
industrial automation with precision motion control. The setup of these complex systems
usually include master-slaves. This thesis project is specifically about the communication
interface between the master and slaves.
25 Since over a decade, NTS-Group has been using proprietary communication protocols
for their complex systems. For the communication from master to slave, they use Unit
Communication Protocol (UCP) and for communication amongst the slaves, they use a
hard real-time protocol called Real Time Data Networks (RTDN). Both these protocols
are asynchronous serial communication protocols using the CAN bus hardware layer. Until
30 now, this communication has been sufficient. As the company foresees the systems getting
more complex, some of RTDN’s shortcomings are becoming apparent. These shortcomings
include limited baud rate, limited physical bus length of CAN, portability constraints
and limited payload size. The thesis project was done primarily to investigate an alternate
communication protocol called EtherCAT and to explore control system architectures with
35 the ethercat performance results.
This project includes several phases. The first is phase has been identification, design,
implementation and testing a master-slave system communicating over EtherCAT. With
a successful implementation of and testing, which also included three slaves (scalability
test), we can now extract performance metrics.
40 The second phase includes synchronization of the distributed clocks across the slaves
and the master for synchronized actions and also for synchronized timestamps. The per-
formance analysis helps us understand the advantages and limitation of EtherCAT. The
biggest advantage includes ten fold improvement in performance of EtherCAT over the
CAN based protocols. And contrary to initial assumptions, the bottleneck has been the
45 system latency at the master side and not the slave ethercat implementation done in the
project.
The third phase of the project was to investigate whether a centralized control architec-
ture over EtherCAT is feasible for high precision motion control. This includes developing
and integrating MATLAB/Simulink into the TwinCAT (master) and running control al-
50 gorithm at the master (centralized) instead of at the slaves (de-centralized or distributed).
It has been observed that with a large delay in the control loop (for the setup), a centralized
architecture is not yet feasible for high precision control.

Investigation of EtherCAT for the Motion Building Blocks iii

 The final phase is to use all the information in hand, to explore two different control
architectures and propose a modified architecture that can combine the strengths of the
55 two architectures.
To extract and log data into the local hard-disk, PLC program was implemented and
integrated into TwinCAT.

iv Investigation of EtherCAT for the Motion Building Blocks

 Acknowledgements

I would like to thank NTS Systems development, part of the NTS-Group, because
60 without them I would not have had this opportunity to do this project.
I would like to also express my sincere gratitude to those who helped and supported
me during this master thesis work. In particular, I would like to thank Nabi Najafabadi,
M., Laurens van de Laar, Reinder J. Bril, Nico Meijerman, Sohan Walimbe, Marco van
Nieuwenhoven for their extensive support with helping make this project a success.
65 There are many others who I would like to thank, including Bart Verkoeijen, Patrick
van der Mijden, Mike Curvers, Bert de Swart, Alessandro Figini, Santosh Athur, Garbi
Singla Lezcano, Ferry Schoenmakers, for helping me, at the drop of a hat, with several
questions about TwinCAT, Texas Instrument’s controller, ethercat protocol and general
implementation.

Investigation of EtherCAT for the Motion Building Blocks v

70 Contents

Contents vi

List of Figures viii

List of Tables xi

1 Introduction 1

75 2 Background 4
2.1 Unit Communication Protocol (UCP) . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 UCP Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
80 2.2 Real-Time Data Networks (RTDN)? . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Operating Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 EtherCAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
85 2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Operating Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Significance of EtherCAT for industrial control application . . . . . 13
2.3.4 CANopen over EtherCAT . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Synchronization - Distributed Clocks (DC) . . . . . . . . . . . . . . . . . . 18
90 2.4.1 Operating Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Serial Peripheral Interface (SPI) . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1 Operating Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Design 23
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
95 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 EtherCAT system design overview . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 The Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 TwinCAT 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vi Investigation of EtherCAT for the Motion Building Blocks

 CONTENTS

3.4.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
100 3.4.3 Simulink Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.4 PLC program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 The Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.1 EtherCAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 SPI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

105 4 Implementation 44
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Slave Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 EtherCAT slave software . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Serial Peripheral Interface . . . . . . . . . . . . . . . . . . . . . . . 52
110 4.3 ESC description file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Performance Evaluation and Analysis 60

5.1 EtherCAT Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1 Update Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 Frame Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
115 5.1.3 Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.4 Clock deviation or Distributed Clock Jitter . . . . . . . . . . . . . . 62
5.1.5 Minimum Response Time . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Centralized Control using Simulink . . . . . . . . . . . . . . . . . . . . . . 64
5.3 A Study of Control System Architectures . . . . . . . . . . . . . . . . . . . 68
120 5.3.1 Comparative study of the three architectures . . . . . . . . . . . . . 72

6 Conclusion and Future Work 77

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3 Continuation of Current Project . . . . . . . . . . . . . . . . . . . . . . . . 78
125 6.3.1 Ethernet over EtherCAT (EoE) . . . . . . . . . . . . . . . . . . . . 78
6.3.2 H-Bridge control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.3 Dual port Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.4 Texas Instrument’s newer chipset - AM335x . . . . . . . . . . . . . 79
6.4 New possibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
130 6.4.1 RTDN or UCP over EtherCAT . . . . . . . . . . . . . . . . . . . . 79
6.4.2 New/Improved Configuration Tool . . . . . . . . . . . . . . . . . . 79
6.4.3 Profinet against EtherCAT . . . . . . . . . . . . . . . . . . . . . . . 79

Bibliography 80

Investigation of EtherCAT for the Motion Building Blocks vii

 List of Figures

135 1.1 Master-Slave EtherCAT system with encoder/motor . . . . . . . . . . . . . 2

2.1 Existing master-slave network using UCP and RTDN communication . . . 4

2.2 The UCP tasks and interface layers in the software as related to the OSI
model [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 The UCP structure shown for an example segment of 29 bytes length. . . . 6
140 2.4 RTDN protocol shown against OSI model layers . . . . . . . . . . . . . . . 7
2.5 RTDN message format. Each message includes a frame (message ID). Each
Window represents pre-configured length of data for each device. . . . . . . 8
2.6 Each RTDN byte consists of a start and stop bit along with the data. . . . 8
2.7 EtherCAT layers compared with the OSI model. . . . . . . . . . . . . . . . 11
145 2.8 EtherCAT frame format[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9 EtherCAT network topology [3] . . . . . . . . . . . . . . . . . . . . . . . . 13
2.10 Several device profiles and protocols can co-exist side by side [4] . . . . . . 15
2.11 Architecture of CANopen over EtherCAT [5] . . . . . . . . . . . . . . . . . 15
2.12 EtherCAT and corresponding CANopen state diagram [6]. . . . . . . . . . 17
150 2.13 An example of CANopen over EtherCAT SDO request message from the
master to slave [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.14 Distributed Clock synchronization in an ethercat network. One slave’s clock
is configured as reference (R) and the other slave’s local clocks are adjusted
to this reference clock. [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
155 2.15 The deviation of the local clocks compared to the reference clock during
initialization of DC and during operational state. [7] . . . . . . . . . . . . . 19
2.16 Example offset measurement calculation shown as a sequence of actions
between the master and slave within an ethercat network. [8] . . . . . . . 20
2.17 Example delay calculations shown again as a sequence between master and
160 slave within an ethercat network. [8] . . . . . . . . . . . . . . . . . . . . . 20
2.18 Bit by bit, simultaneous transfer, between master and slave. [9] . . . . . . . 21
2.19 Storing data to write and read in buffer in the SPI master (MBB).The figure
also shows configurable baud rate. [9] . . . . . . . . . . . . . . . . . . . . . 22

viii Investigation of EtherCAT for the Motion Building Blocks

 LIST OF FIGURES

3.1 High level EtherCAT master-slave design. The PC is the master and the
165 ESC along with the proprietary Motion Building Block (MBB), together
make up the slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 A master-slave ethercat system with the implemented components indicated
in green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 EtherCAT master-slave system setup at the company. It consists of a Beck-
170 hoff drive that works as another slave and is used as a drive control. . . . . 26
3.4 EtherCAT Slave Information contains mandatory and optionally specified
information about the slave. This information is given as input to TwinCAT
to be parsed and stored. [10] . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Simulink model integrated into TwinCAT. [11].This is not an image of our
175 own PI controller. The reason being because of the use of trial licence of
TwinCAT, the visualization is not available. . . . . . . . . . . . . . . . . . 28
3.6 Integrating Simulink within TwinCAT . . . . . . . . . . . . . . . . . . . . 29
3.7 PLC program, integrated in TwinCAT, to log data . . . . . . . . . . . . . 30
3.8 Beckhoff’s piggyback controller FB1111-014x[12] . . . . . . . . . . . . . . . 31
180 3.9 EtherCAT Slave including the Motion Building Block board (consists of
Texas Instrument’s DSP) and the Beckhoff’s piggyback ASIC which handles
the ethercat communication- also called Ethercat slave controller. . . . . . 32
3.10 Process of configuring Ethercat Slave Controller (ESC), as per the require-
ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
185 3.11 EtherCAT state machine [13] . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.12 Actions/Tasks to be performed, at the slave, during the state transition. All
other (not indicated in the figure) state transitions are invalid and lead to
updating the error register with the appropriate invalid state transition error. 35
3.13 EtherCAT slave Init state necessary implementation. . . . . . . . . . . . . 36
190 3.14 Actions performed during EtherCAT slave Pre-Op state. . . . . . . . . . . 37
3.15 Actions/Tasks performed during EtherCAT slave Safe-Op state. . . . . . . 38
3.16 Actions/Tasks performed during EtherCAT slave Op state. This is when
the slave is fully operational . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.17 SPI interface hardware connections between the ESC and the TI DSP . . . 39
195 3.18 SPI interface hardware connections between the ESC and the MBB . . . . 40
3.19 SPI write/read state machine. . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.20 SPI Read sequence diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.21 SPI Write sequence diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 The master and the MBB accessing the ESC through EtherCAT and SPI. 45
200 4.2 The flow diagram shows the ethercat slave software sequence. . . . . . . . . 46
4.3 Cyclic SYNC signal from the ESC to MBB. The SYNC signal is generated
using the precise DC clock of the ESC. . . . . . . . . . . . . . . . . . . . . 51
4.4 Packing of three variables of different lengths (for TI, default length is 16 bit). 52
4.5 SPI frame with a maximum of 12 characters of SPI data (and 4 characters
205 of SPI header), at a time. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Investigation of EtherCAT for the Motion Building Blocks ix

 LIST OF FIGURES

4.6 ESC description files (.xml and .c) are programmed to the master, ESC and
slave for uniform ethercat communication. . . . . . . . . . . . . . . . . . . 56
4.7 SOES configuration tool used to generate the ESC description file. . . . . . 57
4.8 SOES configuration tool showing the configurable settings and the CAN-
210 open’s Object dictionary way of description. . . . . . . . . . . . . . . . . . 57

5.1 EtherCAT frame delay for a single slave system. . . . . . . . . . . . . . . . 61

5.2 EtherCAT master system latency highlighted in red. . . . . . . . . . . . . . 62
5.3 The deviation of the local clocks compared to the reference clock during
initialization of DC and during operational state. [7] . . . . . . . . . . . . . 63
215 5.4 Centralized control architecture with the use of timestamps to measure the
control loop delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Simulink model of PI controller used as the central control model. This
model is run in TwinCAT runtime environment with a 1ms cyclic task. . . 66
5.6 Estimated control loop delay for the centralized control architecture. . . . . 66
220 5.7 Reference simulink model used as a benchmark. . . . . . . . . . . . . . . . 67
5.8 Reference simulink model used as a benchmark. . . . . . . . . . . . . . . . 67
5.9 Execution time of the PI controller model used as the central control al-
gorithm for the different experiments conducted. It can be observed that
the average execution time is about 1.5ms and in practise this leads to a
225 considerable control precision loss. . . . . . . . . . . . . . . . . . . . . . . . 68
5.10 Example used to explain the control architectures - Printer with a printer
head moving in the 2D axes. . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.11 Comparing the de-centralized and centralized control architectures for the
H-bridge printer that is shown in Figure 5.10. . . . . . . . . . . . . . . . . 71
230 5.12 Proposed architecture with a dual core slave running a general purpose ARM
processor and a specific purpose co-processor (example DSP) for higher com-
putational power. The ARM processor runs High Level OS or Real Time OS
or both and handles the communication. The co-processor handles intensive
tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

x Investigation of EtherCAT for the Motion Building Blocks

235 List of Tables

2.1 Components of the RTDN frame . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 The four wires in the SPI communication . . . . . . . . . . . . . . . . . . . 21
2.3 The four modes of SPI operation . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 EtherCAT software file structure . . . . . . . . . . . . . . . . . . . . . . . 50

240 4.2 SPI Read/Write header information used to read/write data from/to the ESC. 54

5.1 The count of clock deviations (positive and negative deviations) and the
value in µs with respect to the reference clock. . . . . . . . . . . . . . . . . 63
5.2 The three control architectures and their performance across the various
metrics. Green indicates the best of the three, while Yellow indicates a
245 moderate performance and Orange stands for a poor performance of the
metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Investigation of EtherCAT for the Motion Building Blocks xi

 Chapter 1

Introduction

At NTS-Group, one of the ongoing projects include design and implementation of an

250 industrial printer. This printer consists of several proprietary motion control boards also
called as Motion Building Blocks (MBB). These motion building blocks are centrally con-
trolled by an ink-jet PC. This setup can be visualised as a master-slave system where
the ink-jet PC is the master and the MBB boards are the slaves. The communication
between the PC (master) and the boards (slaves) uses proprietary ”Unit Communication
255 Protocol” (UCP) application protocol over the CAN-bus. Due to the nature of a PC,
this master-slave communication is non-real time. Hence, this non-real time communica-
tion is separated from the communication amongst the boards (slaves). This is done to
keep the boards synchronized for precise control, hence adhering to real-time constraints.
The communication amongst the boards use ”Real Time Data Network” (RTDN), another
260 proprietary protocol which also uses the CAN transceivers and CAN-bus as the physical
layer. The system setup and more details about the RTDN is shown in the ”Background”
chapter.
NTS-Group intends to shift from the proprietary protocols to an EtherCAT based
network. There are several reasons to make the switch. Larger and more complex systems
265 with larger number of slave nodes is one such reason. Centralized controlling is one way
forward for the company as it allows to build complex control algorithms in the central PC
and communicate to standardized, readily available slaves hence improving modularity of
the system and shorter development times. For example, it is more efficient to purchase
an off-the-shelf servo drive for control and connect it to the central PC. Keeping the
270 control in the PC means investing more time in developing more complex control and
less time invested in the controller architectures as well as lesser time spent in developing
the servo drive and it’s interface. Another important requirement is high speed precision
control. NTS specializes at high speed precision control. This means that it is desirable
to have a communication protocol that maintains very short cycle times, low latency, very
275 high update frequency (of the order of 10s of KHz) while still keeping the hard real-time
constraints. The most fitting protocol that serves well for all the mentioned requirements
is EtherCAT. It is very efficient when sending large sum (made from small amounts of data
from each node) of high speed, real-time, cyclic data within the system.

Investigation of EtherCAT for the Motion Building Blocks 1

 CHAPTER 1. INTRODUCTION

Figure 1.1: Master-Slave EtherCAT system with encoder/motor

With this understanding, we intend to investigate the consequences of replacing these

280 two proprietary communication protocols by EtherCAT uniformly. For this we design,
implement and test an EtherCAT master-slave system, shown in Figure 1.1. Then im-
plement distributed clock synchronization, use reference clock to timestamp and observe
performance of this EtherCAT master-slave system. With atleast a 10 fold performance
improvement over the proprietary protocols, an EtherCAT network might support a cent-
285 ralized control system providing sufficient performance for precise control. To investigate
this, we implemented a simple simulink model, integrated it into TwinCAT and again
time-stamped the peformance. This time though, contrary to expectation, the centralized
control loop performance was well over 2ms which is not practically viable for precise
control. This outcome led us to investigate the advantages/disadvantages of centralized
290 and de-centralized control architectures and propose a combined control architecture that
combines the advantages of the two architectures while reducing the disadvantages of the
two architectures.
From the future perspective, Industry 4.0 and Industrial Internet of Things means the
future smart factories will stay connected to the Internet. And the most established wired
295 protocol for the Internet is Ethernet. This means using EtherCAT, which packs itself into
the Ethernet frame using Ethernet over EtherCAT (in the future), will help making the
systems more future proof while adding innumerable possibilities for expansion and data
analytics.
The thesis report is organized into several chapters. The next chapter ”Background”

2 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 1. INTRODUCTION

300 consists of information of the various technologies learnt to implement the system. These
technologies include the existing RTDN and UCP communication, EtherCAT, CANopen
over EtherCAT, Disctributed Clock Synchronization and Serial Peripheral Interface.
”Design” chapter lists the generic requirements for the project and the design of in-
dividual software components that make up the EtherCAT based master-slave system.
305 The ”Implementation” chapter describes the implementation of the new EtherCAT based
system and some of the difficulties faced during the implementation.
”Performance Evaluation and Analysis” chapter describes the research goals, the pro-
cess involved in extracting the required data and the analysis of the data to map the
performance of the new system. It also includes the study of the centralized control sys-
310 tem and extending that to the comparison of the control architectures while proposing a
new control architecture. The ”Conclusions” chapter speaks about the conclusions drawn
from the project and how the project can be taken forward for future implementation.

Investigation of EtherCAT for the Motion Building Blocks 3

 Chapter 2

Background

315 Several concepts learnt, to implement this project are introduced in this chapter. The
master-slave setup, currently in use at the company, is shown in Figure 2.1. The figure
shows the communication between the master and slaves - Unit Communication Protocol
(UCP) as well as the communication amongst the slaves - Real Time Data Networks
(RTDN) which adheres to hard-real time constraints. Sections 2.1 and 2.2 describe the
320 existing proprietary communication protocols used by NTS-Group and the source of in-
formation is the NTS internal documentation.

Figure 2.1: Existing master-slave network using UCP and RTDN communication

These two proprietary protocols shall be uniformly replaced by one communication

protocol - EtherCAT. Section 2.3 describes relevant topics related to the EtherCAT com-
munication that are useful for the implementation of this project.

4 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

325 2.1 Unit Communication Protocol (UCP)

2.1.1 Introduction
Every complex system consists of several sub-systems that coordinate with each other
to achieve the system’s functionality. It can be looked at as a master-slave setup where
the sub-systems are slaves. These sub-systems are also called as ”Units”. The interaction
330 between the master (usually a central PC) and these Units (slaves) uses the company’s
proprietary ”Unit Communication Protocol (UCP)” which proposes a structured inter-
face protocol that allows these ”Units” (sub-systems) to work together in a uniform way,
independent of the physical interface used (TCP-IP, CAN, . . . ).
One simple example is the master sending a ”START/STOP” message to a unit (sub-
335 system/slave). The transmission of this ”START/STOP” message can be over CAN or
any other physical bus.
Units described above are subdivided into logical and physical units. The logical units
provide the functionality which is accessed via the physical units (gateway). These logical
units are further divided into interfaces which are further divided into tasks. Figure 2.2
340 shows the logical unit, tasks, UCP interface handling in the software, the way UCP protocol
stacks up against the conventional OSI model layers.

Figure 2.2: The UCP tasks and interface layers in the software as related to the OSI
model [1].

Investigation of EtherCAT for the Motion Building Blocks 5

 CHAPTER 2. BACKGROUND

2.1.2 UCP Structure

The UCP is a message based protocol. The messages are packed into segmented data
blocks which are transmitted over a physical bus. An example of a segmented data block
345 (with a block of 29 bytes) transmitted over CAN physical bus consisting of a header of 11
bits, is shown in [Link] this level of abstraction, we can understand the advantages
and disadvantages of UCP in the following section.
0 7 10 15 23 31 63

Header Data START

Data Intermediate odd segment
Data Intermediate even segment
Data END

Figure 2.3: The UCP structure shown for an example segment of 29 bytes length.

2.1.3 Significance
The advantages and the limitation of the UCP protocol, hence leading to the imple-
350 mentation of EtherCAT, are as follows.

Advantages
• Reusability - suitable logical units, interfaces and tasks can be reused for slaves(units).
This helps in quickly scaling the software.

• Hardware independence - UCP can be used over CAN, TCP/IP, or even EtherCAT.

355 • Platform neutral way of describing - The physical unit, logical units, interfaces and
tasks are described using XML.

Disadvantages
• Interoperability - Every new sub-system needs to be modified to be operable with the
existing NTS systems because the new sub-systems may not be able to understand
360 UCP. This increases development costs for NTS.

• Proprietary - UCP is NTS-Group proprietary protocol which does not yet have a
widespread acceptance and standardization. This increases the developmental and
maintenance costs when working with newer more complex systems.

• Larger payload - As the systems at NTS-Group get more complex, the data logging,
365 analysis and diagnostic need more data increasing the payload sizes of messages. At

6 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

the moment even though in theory the payload is not limited, in practise to restrict
one ID taking up more time within the CAN network, the payload size of a messsage
is restricted to maximum of 128 bytes.

2.2 Real-Time Data Networks (RTDN)?

370 2.2.1 Introduction
UCP is soft real-time due to the nature of the PC. To have a hard real-time commu-
nication protocol, NTS-Group have developed RTDN that is used as the communication
protocol amongst the slaves. One of the slaves takes the role of initiating the communica-
tion periodically. The choice of which slave shall take this initiator role, is a compile time
375 decision.
RTDN uses CAN bus hardware as its physical layer 1 . The stack, using reference OSI
model, is shown in Figure 2.4. As we see from this figure, RTDN does not have an applic-
ation stack and is a bare bone protocol. The operation principle of the RTDN is indicated
in the following subsection.
380

Figure 2.4: RTDN protocol shown against OSI model layers

1
The CAN data link or application layer is not used, instead a custom protocol is used.

Investigation of EtherCAT for the Motion Building Blocks 7

 CHAPTER 2. BACKGROUND

2.2.2 Operating Principle

Since RTDN uses the CAN transceiver, the basic working of the protocol has similarities
with CAN protocol. These include:

• Using dominant (logical ‘0’) and recessive bits (logical ‘1’).

385 • Monitor the bus lines even while transmitting data.

• Limitations of CAN hardware also applies.

Apart from these similarities, it is useful to know that the RTDN protocol follows the non
destructive bit-wise arbitration principle to keep the real-time constraints or in a scenario
where the RTDN is out of sync. The RTDN message format is shown in Figure2.5, and
390 the fields within this message are explained in Table2.1.
An interesting observation here is that this format is very similar to EtherCAT’s mes-
sage format which consists of a header and logical windows pre-configured for each slave
device based on the number of inputs/outputs each slave devices requests2 . Each byte3 in
an RTDN message is formatted as shown in Figure 2.6.

0 9 19 29 39 49 59 69 75

Frame Window1 Window2 ··· WindowN CRC

Figure 2.5: RTDN message format. Each message includes a frame (message ID). Each
Window represents pre-configured length of data for each device.

0 1 2 3 4 5 6 7 8 9

Start Data Stop

Figure 2.6: Each RTDN byte consists of a start and stop bit along with the data.

2
Request is made through the configuration file for the slave device, hence at compile time the window
size is allocated, to all slave devices in the network, by the master
3
Each RTDN byte consists of 10 bits instead of the standard definition of byte which is 8 bits

8 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

This byte indicates the start of a new RTDN frame along with an iden-
tifier for the frame. The maximum number of frames is 8. The frame
#Frame number will have a duplicate contents in the upper and lower nibble of
the byte:
Frame 1: 0x11 . . . Frame 8: 0x88
Communication window. A node has its own communication window
inside a RTDN frame transfer. This window contains one ore more data
bytes that will be published on the bus, and will be monitored by all
other nodes. The communication window content is application specific
WindowX and may also vary between different frames numbers.
Each node will know when it may publish its communication window
on the bus. It will also know exactly what information other nodes will
publish. A node will monitor its data on the bus and detect if the data
is published correctly.
A 16-bit CRC checksum calculated over all previous data, #frame and
window data, by the master. The #frame byte is used as ‘seed’ for the
CRC
CRC calculation. To uniquely identify the CRC checksum, the multi-
processor bit in the second CRC byte (LSB byte) will be set

Table 2.1: Components of the RTDN frame

395 The RTDN message will be built up in byte-frames. The master will start this frame
by transmitting the frame number. Thereafter the master will publish its data window on
the bus (Window 1). After that the next slave will publish its data window on the bus
(Window 2) and so on, until all slaves have published their data (up to Window N). From
there the master will take over again and write a two-byte CRC checksum to the bus.
400 When an RTDN transfer fails for whatever reason, the frame is ignored. It is important
that all nodes ignore the received data, although they may have received all data correctly.
This way all nodes will work with exactly the same information. A failed RTDN transfer
will be retried. The frame number is not incremented and the frame will be re-transmitted
with the most recent application data.

405 2.2.3 Significance

At NTS, RTDN is primarily used to perform synchronized tasks across the slaves. One
such example is synchronized motion control. Some of the advantages and disadvantages
of RTDN are mentioned in this section to understand the need to investigate a replacement
to this protocol.

410 Advantages

• Real time - RTDN is real time in nature. This is essential for precison motion control.

Investigation of EtherCAT for the Motion Building Blocks 9

 CHAPTER 2. BACKGROUND

• Uses CAN hardware - CAN as a transceiver is secure and reliable (high Electro-
Magnetic interference resistance) which is essential.

• Every slave in the network is aware of the contents of every frame. Each slave keeps
415 a local database copy and hence the slave knows the data relevancy. This custom
solution keeps the communication minimal and straightforward.

Disadvantages
Even though interestingly RTDN is conceptually similar to EtherCAT, there are dis-
advantages to RTDN mainly due to the use of CAN as the message carrier. UCP’s disad-
420 vantages are applicable to RTDN as well. But the most important disadvantage of RTDN
is limitation in payload size. Another limitation is RTDN cannot yet be used for master-
slave communication, hence limiting it’s use within the complex system to only slave-slave
communication.

2.3 EtherCAT
425 2.3.1 Introduction
EtherCAT means ”Ethernet for Control Automation technologies”. It is an Ethernet
based fieldbus protocol which has been invented by Beckhoff GmBH. The protocol is stand-
ardized and is being widely adopted [14], [15]. The main principle behind EtherCAT is to
transmit large amounts of data that require short update cycles and with very low jitter.
430 EtherCAT with respect to the OSI model is as shown in the Figure 2.7.

2.3.2 Operating Principle

An EtherCAT network is composed of a master device and several slaves connected to
each other in a daisy chain fashion. Taken from an youtube video explaining EtherCAT
- An EtherCAT network can be visualized to a railway network where each station (slave
435 device) can off-load and re-load people (data) into the train (ethercat frame) while the
train moves through the station.
The communication is always initiated by the master. The master transmits an Eth-
erCAT message consisting of datagrams. The message traverse through all the connected
slaves in the network and are then reflected at the end of the network back to the master.
440 The unique principle of EtherCAT is “processing-on-the-fly”[16]. This means EtherCAT
messages are not destined for specific slave nodes. Instead, messages are forwarded to the
next immediate slave node connected to it even if there is no data for that particular slave
to consume. This causes a large number of slaves to be addressed by only one message
frame hence optimizing bandwidth usage [14].
445 As mentioned above, while the message traverses through the slaves and back to the
master (EtherCAT is implemented on a full duplex architecture, meaning sending and

10 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

Figure 2.7: EtherCAT layers compared with the OSI model.

receiving happens on separate lines), each node reads its inputs and adds its outputs to
the message frame. Input data to a node is read as the message passes through that node’s
input port and output data is inserted while the frame passes through the output port to
450 the next node. A single message consisting of a summation of all the data is issued by the
EtherCAT master. Thus when the message arrives back at the EtherCAT Master every
node in the network has received new input data from the Master and returned new output
data to the master. Overall, the delay as the message frame passes through each node
(input and output ports) is a few nanoseconds. An EtherCAT network can be compared
455 to a train (message frame) originating at a station (master), moving through every station
(slave nodes) in the network and then back to the originating station through the same
route. At each station (slave nodes) the train can off-load and re-load train compartments
with people/goods (input-output data) while the train moves through the station [17].
Now that we know how the EtherCAT operates, let us understand a few concepts about
460 EtherCAT essential to the project.

The EtherCAT frame (datagram) format

EtherCAT protocol is based out of the ethernet protocol. The EtherCAT frame replaces
the Ethernet Data portion of an Ethernet datagram. This is shown in Figure 2.8. As we
see from the figure, the ethernet header is followed by a 2 byte ethercat header. The data
465 part of the EtherCAT frame is divided into multiple datagrams to be consumed by different
slave nodes. Each of these datagrams are sub-divided into a datagram header of 10 bytes,
a data section and a working counter of 2 bytes. The working counter is automatically

Investigation of EtherCAT for the Motion Building Blocks 11

 CHAPTER 2. BACKGROUND

incremented by all devices that process the associated datagram, hence used as an effective
diagnostic tool. As indicated earlier, the main advantage of EtherCAT is based on the
470 possibility to pack data of several devices into one single summation frame. [17].

Figure 2.8: EtherCAT frame format[2]

EtherCAT cycletime
The cycle time is an important performance metric for industrial communication sys-
tems. It is defined as the time necessary to exchange the input/output data between the
controller and all networked devices once. The minimal cycle time of an industrial com-
475 munication system based on EtherCAT depends on several terms. Some of those factors
are payload per device, used topology and Ethernet type e.g. 100MB or 1GB. Typical
minimum cycle time for EtheCAT based on the 100Mbps BASE-TX connection, is approx-
imately around 100µs.

Topology
480 EtherCAT uses full-duplex Ethernet physical layers for communication. When an Eth-
erCAT device detects a port to forward the frame and this port is closed, the frame is
automatically returned back to the master device, through the same route. Due to these
two features (full-duplex mode and returning data back through the same route when
closed port is detected), EtherCAT can support almost any physical topology such as line,
485 tree or star. It is also possible to combine topologies with any EtherCAT device with three
or more ports which can act as junction. One example EtherCAT network topology is

12 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

shown in Figure 2.9. If an EtherCAT network is wired in ring configuration (requires two
ports on the master device), it can provide cable redundancy.

Figure 2.9: EtherCAT network topology [3]

In theory, as claimed by the EtherCAT Technology Group, we can have upto 65535 slave
490 devices connected to a network. Assuming we can use 100BASE-TX Ethernet physical
connection, two slave devices can be separated by upto 300 ft distance.

2.3.3 Significance of EtherCAT for industrial control application

Several characteristics that makes EtherCAT a suitable protocol for industrial control
applications are listed below,

495 • It satisfies both hard and soft real-time requirements along with deterministic re-
sponse times.

• An ethercat network consists of a maximum address space of 64Kbyte. Due to

this space, in theory, EtherCAT can support upto 65,535 individual slaves in one
network. What this means is, in practise, a large number of slaves can be attached
500 to the master.

• Flexible topology - EtherCAT can use any network topology (line, star, tree) and
any combination of them. Due to the operating principle of EtherCAT, the topology
of EtherCAT has little to no effect

• It uses standard Ethernet hardware, making it a cheap solution to adapt.

Investigation of EtherCAT for the Motion Building Blocks 13

 CHAPTER 2. BACKGROUND

505 • EtherCAT masters can be implemented on many devices with a standard network
card. The slaves, though, do need special hardware to be fully compatible with
EtherCAT.

• EtherCAT supports packing data in the form of CANopen application over Eth-
erCAT (CoE), Servodrive-Profile over EtherCAT (SoE), Ethernet over EtherCAT
510 (EoE), Functional Safety over EtherCAT (FSoE). The protocol can be adapted to
support custom application protocol over EtherCAT. The best example for this is
UCP protocol of NTS-Group can be adapted to be transmitted over EtherCAT.

• The other advantage of EtherCAT supporting so many application layer protocols

is interoperability. Multiple devices understanding different application protocols
515 (supported ones) can communicate with each other over a common EtherCAT bus
with minimal initial (development and integration) efforts.

• This extensive support can be used to NTS’s advantage by using multiple vendors as
sources to off-the-shelf components without having to worry about cross-compatibility
between vendors. In practice, this is not always the case because EtherCAT is open
520 source leading to more vendors improvizing on EtherCAT in their own unique way.
But atleast in theory this is an advantage.

• In theory, using EtherCAT 1000 devices can updated in 30µs. In practise, this
translates to supporting µm precision motion control.

• Clock synchronization - In an EtherCAT network, the master-slaves can be syn-

525 chronized to less than 1µs. The master-slaves system can operate with very low
jitter without the need of additonal hardware.

2.3.4 CANopen over EtherCAT

CANopen is a communication protocol for systems used in automation. CANopen
implements the layers above and including the network layer [18]. The primary idea of
530 CANopen is to have a message format that incorporates a standardized addressing scheme
and information (application layer) that can be understood by any other device that under-
stands CANopen message format. Typically, CANopen has been implemented to function
over CAN, but it can also run on other protocols, like EtherCAT, as in this case. Similar
to CANopen, there are several other protocols, such as Ethernet over EtherCAT (EoE),
535 File Access over EtherCAT (FoE), etc, that can co-exist over the EtherCAT framework as
shown in Figure 2.10. Here we shall focus on CoE for this project.
CANopen uses two types of messages - Service Data Objects (SDO) and Process Data
Objects (PDO) to communicate information between the master and the slaves. SDOs are
typicall mailbox which are acyclic and PDOs are typical cyclic exchange of information.
540 The architecture of CANopen over Ethercat (leaving out the other co-existing protocols
mentioned in the previous paragraph) is shown in Figure 2.11.

14 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

Figure 2.10: Several device profiles and protocols can co-exist side by side [4]

Figure 2.11: Architecture of CANopen over EtherCAT [5]

Examples of slave settings done with SDO are enabling an encoder counter, or the offset

Investigation of EtherCAT for the Motion Building Blocks 15

 CHAPTER 2. BACKGROUND

of an analog output, or the period of a PWM signal. SDO settings are stored in a non-
volatile memory of the terminal, so the settings are remembered also when the terminals
545 loses power [19].

Examples of PDO data can be: a value sent to a digital output, a value received by a
digital input, a value send to an analog output, an encoder value received from an encoder
interface. PDOs are normally sent and received at a high frequency. Control signals of the
controller are sent with PDOs [19].

550 In the current implementation we are using Beckhoff’s TwinCAT at the master’s node.
Beckhoff’s CANOpen implementation uses EtherCAT’s states, shown in Figure 2.12 and
to effectively use SDOs and PDOs. Depending upon the state (shown in red, yellow and
green), different functions are accessible or executable in the EtherCAT slave. In the
Pre-Operational state SDO settings are possible, but PDO can’t be used. The the Safe-
555 Operation state the PDO can be used, although the slave keeps its outputs in a safe state,
while the input data are updated cyclically. In the Operational state the slave copies the
output data of the masters to its outputs [19].

16 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

(b) CANopen state diagram with color coded

EtherCAT states.

(a) EtherCAT state diagram.

Figure 2.12: EtherCAT and corresponding CANopen state diagram [6].

In the case of CANopen over EtherCAT (CoE), the SDO protocol is used directly, so
that existing CANopen stacks can be used practically unchanged. Optional extensions are
560 defined that lift the 8-byte limit and enable complete readability of the object list [20]. An
example of an SDO request message is as shown in Figure 2.13.

Investigation of EtherCAT for the Motion Building Blocks 17

 CHAPTER 2. BACKGROUND

Figure 2.13: An example of CANopen over EtherCAT SDO request message from the
master to slave [2].

2.4 Synchronization - Distributed Clocks (DC)

The slave devices need to be time synchronized in order to perform synchronized motion
control or other synchronized actions in the network. One possible way to do this in the
565 case of EtherCAT is to use distributed clocks.
The basic idea is to have one reference clock and transmit information through the
ethercat frame such that all the slaves in the network know the exact time on that reference
clock and adjust their local clocks to match the reference time. The master transmits a
broadcast message. This message frame’s arrival time is latched by each slave, once when
570 the frame is coming from the master and once when the frame is going back to the master
(ethercat is full duplex). The latched information is then read by the master, the delay
to each slave is then calculated accordingly and this delay is transmitted in successive
ethercat frames indicating to each slave how it needs to adjust it’s local clock to be in sync
with the reference. This special frame is sent periodically to compensate for drift or jitter
575 within the network.

18 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

The length of the distributed clock is 64 bit with a resolution of 1ns and a base starting
time is at January 1,2000,0:00 [7]. The first 32 bit measure 4.2ms and all the 64 bits
measure over 580 years. Figure 2.14 shows one slave clock to be reference (indicated by
R) and other slave clocks shall be adjusted to this reference clock. Figure 5.3 shows the
580 deviation of clocks from the reference clock during initialization and then during operational
phase.

Figure 2.14: Distributed Clock synchronization in an ethercat network. One slave’s clock is
configured as reference (R) and the other slave’s local clocks are adjusted to this reference
clock. [7]

Figure 2.15: The deviation of the local clocks compared to the reference clock during
initialization of DC and during operational state. [7]

2.4.1 Operating Principle

The synchronization procedure including the offset and delay calculations are shown in
two Figures, 2.16 and 2.17

Investigation of EtherCAT for the Motion Building Blocks 19

CHAPTER 2. BACKGROUND

Figure 2.16: Example offset measurement calculation shown as a sequence of actions

between the master and slave within an ethercat network. [8]

Figure 2.17: Example delay calculations shown again as a sequence between master and
slave within an ethercat network. [8]

20 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 2. BACKGROUND

585 2.5 Serial Peripheral Interface (SPI)

The Serial Peripheral Interface bus (SPI) is a serial communication protocol. It is
synchronous in nature and is used primarily in embedded systems for short distance high
speed communication. In this project, it is used as a communication interface between the
EtherCAT Slave controller (ESC) and the Motion Building Block (MBB) board.
590 SPI is a four wire, full duplex communication protocol that uses a master-slave system.
With reference to SPI in this project, the master is the MBB board and the slave is the
ESC. For both reading and writing, the initiator of the communication is always the master.
The four wires are indicated in the table 2.2.

CLK Clock line outputted from master

MOSI Master Out Slave in - Data output from master to slave.
MISO Master In Slave Out - Data input to the master from slave.
Enable line (or Slave Select) from the master to activate and keep the
EN(SS)
communication active.

Table 2.2: The four wires in the SPI communication

2.5.1 Operating Principle

595 Figures 2.18 and 2.19 show the working of a master-slave SPI. Each bit is shifted in/out,
of the data registers at the master and slave, at each clock cycle. This bit by bit transfer
is simultaneous - As the master is sending/receiving a bit, the slave also receives/sends a
bit simultaneously.

Figure 2.18: Bit by bit, simultaneous transfer, between master and slave. [9]

There are several modes of operation along with other modifiable parameters such as
600 baud rate, number of bits per character and read/write buffer sizes. The mode of operation
is determined by polarity of clock and the instant at which the data is latched (clock phase).
This is shown in the table 2.3.

Investigation of EtherCAT for the Motion Building Blocks 21

CHAPTER 2. BACKGROUND

Figure 2.19: Storing data to write and read in buffer in the SPI master (MBB).The figure
also shows configurable baud rate. [9]

SPICLK Scheme CLOCK POLARITY CLOCK PHASE

Rising edge without delay 0 0
Rising edge with delay 0 1
Falling edge without delay 1 0
Falling edge with delay 1 1

Table 2.3: The four modes of SPI operation

22 Investigation of EtherCAT for the Motion Building Blocks

 Chapter 3

Design

605 3.1 Introduction

This chapter includes the requirements and a high level design of the components
implemented in this ethercat master-slave system.

3.2 Requirements
NTS-Group specializes in low/medium volume, high complexity systems. The primary
610 reason for NTS-Group to investigate EtherCAT technologies is to be a solution provider
and a part of the EtherCAT ecosystem which is growing rapidly. They also intend to move
away from custom solutions like RTDN, UCP and use readily available components to
prototype tailor made modules (customized to requirements) and then use the company’s
”value engineering” capability to produce cost-effectively. With these intentions, NTS have
615 certain questions about EtherCAT that are interesting to explore. These questions in the
form of requirements are as follows.

Experimental evaluation of EtherCAT’s performance There are theoretical claims

to the performance of ethercat and they are also compared with other fieldbus protocols.
Can we evaluate the performance of EtherCAT through experimental setup to confirm
620 these claims? The follow list consists of the open questions put forth by NTS-Group.

• What is the best achievable (lowest possible) response time with the components
available? What is EtherCAT’s update rate frequency?

• How does the frame delay scale corresponding to the variation in frame size (bytes
of payload)?

625 • What is the achievable frequency of operation for the EtherCAT with the setup and
implementation?

Investigation of EtherCAT for the Motion Building Blocks 23

 CHAPTER 3. DESIGN

• How does the jitter of the network scale with distributed clock synchronization?
• What are the costs (delay, licences, etc) of integrating Simulink in TwinCAT?

EtherCAT based centralized control Architecture The other consequential require-

630 ment is to study the effects of ethercat performance on centralized control architecture as
opposed to what is being used at NTS presently which is a de-centralized architecture.

Control Architecture Choice The final objective is understand if this information has
any consequences on control architecture choices?
The following sections explain the design process of the master-slave system that is
635 used to implement and investigate ethercat’s performance. The implementation, testing
and results are a part of the chapters to follow.

3.3 EtherCAT system design overview

The EtherCAT based master-slave system is shown in Figure3.1. This figure is abstrac-
ted consisting of the master and the slave. Figure3.2 shows the next level of detail. All the
640 components designed and implemented in the project are shown in green. These compon-
ents are listed below. Finally Figure 3.3 shows the experimental setup at the company.

Figure 3.1: High level EtherCAT master-slave design. The PC is the master and the ESC
along with the proprietary Motion Building Block (MBB), together make up the slave.

• Master runs TwinCAT-3.1 and Windows-7.

– Configuration information of each slave in the network, called as EtherCAT
Slave Information (ESI) file. Usually written in .xml format.
645 – Simulink Integration with TwinCAT runtime to run centralized control al-
gorithm.
– PLC (or C++) to log slave specific information (that can be transmitted to the
master via ethercat), into the PC’s hard-disk.

24 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

• Slave runs a modified Open source ethercat framework called Simple Open EtherCAT
650 Slave (SOES) stack.

– Modified SOES EtherCAT to be able to run on the NTS’s Motion Building

Blocks (MBB).

– Serial Peripheral Interface used to communicate between the EtherCAT Slave

Controller (ESC) and the MBB.

Figure 3.2: A master-slave ethercat system with the implemented components indicated
in green.

Investigation of EtherCAT for the Motion Building Blocks 25

 CHAPTER 3. DESIGN

Figure 3.3: EtherCAT master-slave system setup at the company. It consists of a Beckhoff
drive that works as another slave and is used as a drive control.

655 3.4 The Master

In this project, we have used a Windows 7 based general purpose computer as the
master. TwinCAT3.1 is a Beckhoff specific software that converts any Windows PC into a
Real time control PC [21]. Hard real time constraints or soft real time constraints depend
on the Network Interface Card’s (NIC) compatibility (which indirectly means the NICs
660 hardware capability).

Alternatives to TwinCAT - TwinCAT is only one of the options there is, to convert-
ing a PC into an real time control system. An alternative to TwinCAT is Simple Open
EtherCAT Master (SOEM) which also provides a similar suite, as TwinCAT, for Windows
(and Linux). Another alternative to TwinCAT software is IntervalZero. This is a software
665 suite that converts any Windows based PC into an RTOS (just like TwinCAT). But Inter-
valZero does not directly provide support for EtherCAT. It works closely with companies
that make EtherCAT master stacks for IntervalZero RTOS. These master stacks are not
as commonly used as TwinCAT.
The reason to choose TwinCAT is simply because it has a better Graphical User In-

26 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

670 terface and a considerably larger user-base which implicitly means better support (either
directly or through forums).

3.4.1 TwinCAT 3.1

3.4.2 Configuration
How does a master recognize a slave? For this we need to provide the EtherCAT Slave
675 Information (ESI) to the master (in this case TwinCAT). Figure 3.4 shows the mandatory
and optional information within the configuration file. This is provided to TwinCAT in
an XML Schema for TwinCAT to parse. The parsed information is then stored within the
master and is used to identify the slave in the network during the initialization process.

Figure 3.4: EtherCAT Slave Information contains mandatory and optionally specified in-
formation about the slave. This information is given as input to TwinCAT to be parsed
and stored. [10]

Investigation of EtherCAT for the Motion Building Blocks 27

 CHAPTER 3. DESIGN

3.4.3 Simulink Integration

680 Modern PCs processing power combined with a protocol that can achieve very low cycle
time (data can be transmitted/received quickly) means we can implement centralized (PC)
control architectures. For NTS-Group, this essentially means lower development times for
distributed and co-odrinated actions at individual slave controllers. Other advantages
include reducing dependency on subsystem suppliers, developing more complex algorithms
685 and testing them (simulate/emulate) without the hardware (easier prototyping). [22]
TwinCAT has a provision for this. It supports several languages to implement applica-
tions with the TwinCAT environment and then integrating the applications with EtherCAT
within the TwinCAT software. C + +, PLC programming and Simulink are few options.
Simulink, with a large database, strong emphasis on graphical development and ease of
690 creating components, was chosen to be implemented in this project. Simulink also provides
the option to create models and generate them, into PLC structured text, to run them on
TwinCAT runtime environment (this feature however is only available in 64 bit Windows).
In figure 3.5, it shows the integrated Simulink model inside the TwinCAT environment.
This figure is not an image of our own PI controller. The reason being because of the use
695 of trial licence of TwinCAT, the visualization is not available. This simulink model can be
integrated in multiple ways in TwinCAT, providing flexibility of operation of the model.
One possible way to integrate is shown in figure 3.6.
One important information to note is TwinCAT does not provide the tools to ”create”
a simulink model within it’s environment. Simulink provides the tools (Simulink Coder
700 tool box) to generate a simulink model to run in the TwinCAT runtime environment.

Figure 3.5: Simulink model integrated into TwinCAT. [11].This is not an image of our
own PI controller. The reason being because of the use of trial licence of TwinCAT, the
visualization is not available.

28 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

Figure 3.6: Integrating Simulink within TwinCAT

3.4.4 PLC program

TwinCAT has some limitations. One such limitation is that there exists no easy options
to log the data that is interesting to the user. Hence alternative option is to write our
own program to log data. Initially the plan was to implement C++ program that will
705 store chosen data into a buffer and then once this buffer is full, data will be written
asynchronously to a file on the local hard-disk. But due to the steep learning curve to use
TwinCAT specific C++ functions, we changed our decision and went with implementing
PLC code. The idea is the same - copy necessary data into a buffer and when the buffer
is full, write the contents of the buffer asynchronously into a file on the hard-disk. This is
710 shown in figure 3.7

Investigation of EtherCAT for the Motion Building Blocks 29

 CHAPTER 3. DESIGN

Figure 3.7: PLC program, integrated in TwinCAT, to log data

3.5 The Slave

The EtherCAT slave must comprise of several basic hardware components to success-
fully send/receive ethercat data. These components include,

• LAN/Ethernet port

715 • EtherCAT specific ASIC/FPGA that can process data on-the-fly.

• Microcontroller/DSP to handle tasks other than the EtherCAT communication.

The proprietary Motion Building Block (MBB) does not include LAN ports as well as
ethernet physical layer. It also does not support processing ethercat frames on the fly.
These two important and essential shortcomings have been managed by including a special
720 ASIC from Beckhoff. This ASIC is a piggyback EtherCAT Slave Controller (ESC) that
handles the ethercat communication. Figure 3.8 shows the specific piggyback controller
used in the project - Beckhoff’s FB1111-014x. Figure 3.9 shows the piggyback controller
interface with the MBB board. Serial Peripheral Interface (SPI) is used as an asynchronous
communication between the MBB board and the ESC. The SPI protocol is explained in

30 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

725 the background chapter 2.5. The implementation of this SPI interface for the project has
been explained the the following section.

Figure 3.8: Beckhoff’s piggyback controller FB1111-014x[12]

Investigation of EtherCAT for the Motion Building Blocks 31

 CHAPTER 3. DESIGN

Figure 3.9: EtherCAT Slave including the Motion Building Block board (consists of
Texas Instrument’s DSP) and the Beckhoff’s piggyback ASIC which handles the ether-
cat communication- also called Ethercat slave controller.

3.5.1 EtherCAT
To develop the Slave EtherCAT software, we had two options of ethercat framework -
1. Beckhoff’s EtherCAT Slave stack
730 2. Simple Open EtherCAT Slave stack(SOES), is Open source.
Because of complications and delay in obtaining the Beckhoff’s slave stack license and
also because SOES is open source, we chose SOES to develop the ethercat slave code.
The SOES provides a skeletal framework for implementing EtherCAT slave and it can be
downloaded and distributed for free from the SOES website.

735 EtherCAT processing-on-the-fly

One of the important features of EtherCAT is the ability of the slave device to process
the ethercat frame (messages) on the fly hence the frame experiences negligible delays at
very slave. This is taken care of by the special ASIC hardware from Beckhoff, also called
EtherCAT Slave Controller (ESC). The ESC handles the receiving and transmitting of
740 data based on configured parameters.
The ethercat frames are received from the master and the data specific to the slave
device is extracted, stored in the buffer and the input data to the master is inserted into

32 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

the frame. This frame is then transmitted to the next port to the next slave in the network.
If the next port is not connected, then it transmits the frame back to the master through
745 the other duplex channel of the same ethernet cable.
From the software developer’s perspective, the important task here is to configuration
of the ESC. This configuration is then transmitted by the master, through ethercat, during
initialization of the network which is shown in figure 3.10.

Figure 3.10: Process of configuring Ethercat Slave Controller (ESC), as per the require-
ments.

EtherCAT Slave stack

750 Now we understand that the ethercat frames’ reception/transmission is handled by the
ESC. The appropriate data to be read/written is handled within the MBB board. Using
the SOES skeletal framework, we can design this slave stack code specific to the MBB
board. Hence from the software developer’s perspective, the ethercat slave includes read-
ing/writing data from/to the MBB board to/from the ESC during the relevant EtherCAT
755 state.
The EtherCAT state machine is as shown in figure 3.11. One possible way to de-
velop ethercat slave stack code is by designing the ethercat slave to incorporate relevant
tasks/actions during the ethercat states. The ethercat states are explained in the following
sub-sections [23].
760 Designing the intermediate transitions from one state to another is also shown in figure

Investigation of EtherCAT for the Motion Building Blocks 33

CHAPTER 3. DESIGN

3.12.

Figure 3.11: EtherCAT state machine [13]

34 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

Figure 3.12: Actions/Tasks to be performed, at the slave, during the state transition. All
other (not indicated in the figure) state transitions are invalid and lead to updating the
error register with the appropriate invalid state transition error.

Init state This is the default power-on state of the ESC which is contained in a register
- ”Data Link-layer Status” (DLStatus) register. The Sync Managers (SM) responsible for
mailbox communication are initialized in this state. The Init state is an indicator that the
765 ESC is ready for mailbox communication (but does not communicate).Figure 3.13 shows
the actions to be performed during the Init state of the ESC.

Investigation of EtherCAT for the Motion Building Blocks 35

 CHAPTER 3. DESIGN

Figure 3.13: EtherCAT slave Init state necessary implementation.

Pre-Op state The Sync Managers (SM) responsible for mailbox communication are val-
idated in this state. In our project we use CANopen as the application layer to exchange
all information, over the EtherCAT data link layer (hence called CoE). In CANopen ter-
770 minology, mailbox communication is also called as SDOs (Service Data Objects).

Hence, SDO communication takes place during Pre-Op state. Process Data Objects
(PDO) are not, yet, communicated in this state. The Sync Managers responsible for PDO
communication is initialized and other settings for this PDO transfer are also communicated
through the SDOs, as shown in figure 3.14.

36 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

Figure 3.14: Actions performed during EtherCAT slave Pre-Op state.

775 Safe-Op state The SMs for process data exchange (PDOs), the Functional Memory
Management Units (FMMUs), Distributed Clock configuration and initialization are all
done during the transition from Pre-Op to Safe-Op state. The slave devices validates all
these configurations against it’s own object-list (present in the MBB board in our project)
and prepares the ESC for PDO communication.

780 In the Safe-Op state, the slave transmits/receives mailbox (SDO) and only the input
(output from master) process data (PDOs). The output (input to the master) PDOs are
still in ”safe” state hence the slave does not transmit the output PDOs. Actions/Tasks
performed during Safe-Op state is shown in as shown in figure 3.15.

Investigation of EtherCAT for the Motion Building Blocks 37

 CHAPTER 3. DESIGN

Figure 3.15: Actions/Tasks performed during EtherCAT slave Safe-Op state.

Op state [H] The slave is in fully operational state. Mailbox (SDOs) and process data
785 (PDOs) are communicated in this state.
In this state, both inputs and outputs are transmitted/received by the slave. This is
shown in figure 3.16.

Figure 3.16: Actions/Tasks performed during EtherCAT slave Op state. This is when the
slave is fully operational

Bootstrap state From Init, the master can change the state of a slave to Bootstrap if
there is a need to update/write firmware into the EEPROM. This state is not shown in
790 figure 3.12 because it is a special state that is not used normally.

38 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

3.5.2 SPI Interface

Now we understand that the master initiates an ethercat frame. This frame passed
through the ESC (processing on the fly) where the inputs to the slave is filled into the
input buffer and the outputs (input to the master) are inserted into the frame from the
795 output buffer. The MBB board handles these buffers through it’s interaction with the
ESC. This interaction uses the SPI interface.
Development of the SPI driver and data link layer was part of the project. The SPI
was also designed as a state machine.

Hardware Connections
800 The figure 3.17 shows the physical connections between the Ethercat Slave Controller
(ESC) and the Texas Instruments DSP (TMS320F2812) which is the processor used in the
MBB board. The figure also shows the Vcc supply and the ground connections essential for
the ESC to operate. Figure 3.18 shows the soldered connections between the MBB and
the ESC.

Figure 3.17: SPI interface hardware connections between the ESC and the TI DSP

Investigation of EtherCAT for the Motion Building Blocks 39

 CHAPTER 3. DESIGN

Figure 3.18: SPI interface hardware connections between the ESC and the MBB

805 SPI software design

The software design of the SPI interface in the form of state machine is shown in the
figure 3.19. The SPI is initialized to an IDLE state. Every interaction between the MBB
and the ESC either puts the SPI into write mode or read mode and it’s respective buffers
are handled to make a successful communication.

40 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

Figure 3.19: SPI write/read state machine.

810 SPI Functionality

The flow diagram of Read and Write function of the SPI are shown in figures 3.20 and
3.21.

Investigation of EtherCAT for the Motion Building Blocks 41

CHAPTER 3. DESIGN

Figure 3.20: SPI Read sequence diagram.

42 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 3. DESIGN

Figure 3.21: SPI Write sequence diagram.

Investigation of EtherCAT for the Motion Building Blocks 43

 Chapter 4

Implementation

815 4.1 Introduction

A disproportionate amount of time has been spent in implementation and testing this
ethercat master-slave system. Due to constraints in time, at the design stage it has been
decided that we would implement the ethercat slave software but not implement the master
software. For the master we have used a readily available TwinCAT-3.1 software. Hence,
820 in this chapter, we discuss mostly about the slave implementation only.

4.2 Slave Implementation

As indicated in the design chapter 3, the EtherCAT slave consists of two primary
hardware components:

• The EtherCAT Slave Controller (ESC) that handles the EtherCAT communication.

825 • The Motion Building Block (MBB) that handles the ESC and the information that
needs to be exchanged.

The software components implemented in the slave software includes:

• the EtherCAT slave software with distributed clock.

• Serial Peripheral Interface (SPI) which is used as communication between the MBB
830 and the ESC.

The software components are explained in brief in the following paragraphs and will be
details in the later sections of this chapter.

44 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

Serial Peripheral Interface (SPI) A preposterous amount of time was spent in es-
tablishing the SPI communication between the Texas Instruments(TI) DSP on the MBB
835 board and the ESC. For the SPI communication, the TI DSP is the SPI master and the
ESC is the SPI slave. As indicated in the design, the SPI peripheral is initialized (along
with the GPIO pins used for the SPI communication) and held in the Init state. From
here, the SPI peripheral is invoked, either to write or to read data to/from the ESC.

Distributed clock synchronization We use a distributed clock to synchronize all the

840 clocks in the network hence allowing us to perform synchronized tasks or actions. Using
configuration, we write the DC settings into the ESC. A cyclic ”SYNC” signal is generated
appropriate to the settings. This signal interrupts the DSP and the necessary application
task is performed. In our project we use this signal to read/write data from/to the ESC
(ofcourse only after checking the ESC state).

845 4.2.1 EtherCAT slave software

We have just seen that the slave consists of two hardware components - the ESC and
the MBB. We will see briefly what software is used in the ESC and then explain the slave
software in the MBB.

ESC Software The ESC we use in our setup is an ASIC from the German company,
850 Beckhoff GmbH. It is pre-programmed with Beckhoff’s software and we have no access to
the code, which makes it essentially a ”black box”. Beckhoff provides elaborate manuals
which describe how we can configure the ESC to respond in a certain manner and also
describes how we can interact with the ESC. From the MBB, we use SPI to interact with
the ESC and from the master (PC) we use EtherCAT to interact with the ESC as shown
855 in Figure 4.1.

Figure 4.1: The master and the MBB accessing the ESC through EtherCAT and SPI.

Investigation of EtherCAT for the Motion Building Blocks 45

 CHAPTER 4. IMPLEMENTATION

The EtherCAT slave software is written in C and programmed into the MBB. There are
multiple vendors providing the skeletal framework for the slave software. We have chosen
Simple Open EtherCAT Slave software as the framework because it is open source and can
be re-used without licensing hassle. I personally felt we could have worked with Beckhoff
860 provided slave software framework but this was at a much later stage with a steep learning
curve for the time remaining, hence reluctantly did not make the switch.
The core idea is, at startup, this software first initializes the peripherals needed to
interact with the ESC and then initializes the ESC to ”INIT” state. Then, cyclically, the
state of the ESC (EtherCAT state machine) is monitored and if any events are pending,
865 corresponding actions are executed. The flow diagram is shown in Figure 4.2. The code
shown in Listing 4.1 consists of the hardware and software initialization.

Figure 4.2: The flow diagram shows the ethercat slave software sequence.

v o i d main ( v o i d )
{
870 ...
...
CPU init ( ) ; // I n i t i a l i z e t h e CPU o f t h e TI c o n t r o l l e r
CPU DELAY US( 5 0 0 0 0 ) ; // Wait t i l l t h e power s o u r c e s a r e s t a b l e
I n i t G p i o ( ) ; // I n i t i a l i z e SPI s p e c i f i c GPIO p i n s

46 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

875 I n i t S P I ( ) ; // I n i t i a l i z e EtherCAT s p e c i f i c SPI p i n s and p l a c e i n i n i t

state
EtherCAT init ( ) ; // Reset ESC t o i n i t s t a t e
...
...
880 e x t e r n a l i n t i n i t i a l i s e ( ) ; // EtherCAT D i s t r i b u t e d Clock Sync s i g n a l
interrupt
...
...
885
}

Listing 4.1: Initialization of the EtherCAT slave

Hardware initialization The hardware initialization include initializing the General

Purpose Input/Output pins and the SPI communication hardware. This is shown in the
code Listing 4.2.
890 //GPIO i n i t i a l i z t i o n
void InitGpio ( void )
{
...
// Enable t h e f o u r I /O p i n s f o r t h e SPI i n t e r f a c e
895 GpioMuxRegs .GPFMUX. b i t . SPISIMOA GPIOF0 = 1 ; // Master Out , S l a v e In
GpioMuxRegs .GPFMUX. b i t . SPISOMIA GPIOF1 = 1 ; // Master In , S l a v e Out
GpioMuxRegs .GPFMUX. b i t . SPICLKA GPIOF2 = 1 ; // SPI Clock p i n
GpioMuxRegs .GPFMUX. b i t . SPISTEA GPIOF3 = 1 ; // S l a v e Transmit Enable p i n
...
900 }
// SPI i n i t i a l i z t i o n
void InitSPI ( void )
{
...
905 // I n i t i a l i z e SPI RX FIFO r e g i s t e r s
...
// I n i t i a l i z e SPI TX FIFO r e g i s t e r s
...
// D e f i n e SPI C h a r a c t e r Length
910 SpiaRegs . SPICCR . b i t . SPICHAR = 0 x7 ; // C h a r a c t e r Length = 8 b i t s
...
// D i s a b l e TX, RX i n t e r r u p t s − Use p o l l i n g i n s t e a d o f e v e n t d r i v e n f o r
d e t e r m i n i s t i c outcome
...
915 // Enable SPI mode − 3 − P o l a r i t y = 1 , phase = 0 ( Not Motorola s t a n d a r d )
SpiaRegs . SPICCR . b i t .CLKPOLARITY = 1 ; // R i s i n g edge
SpiaRegs . SPICTL . b i t . CLK PHASE = 0 ; // 1/2− c y c l e d e l a y o f Clk wrt
SPISTEA ( 0 − no d elay , 1 − d e l a y )
...
920 // Reset SPI ( I n i t S t a t e )
}

Listing 4.2: Hardware Initialization

Investigation of EtherCAT for the Motion Building Blocks 47

 CHAPTER 4. IMPLEMENTATION

Software initialization The EtherCAT Slave Controller is rest to ”Init” state by clear-
ing the errors and resetting the Sync-Managers(SM). The code Listing 4.3 refers to this
925 software initialization step.

Sync Manager The sync managers are responsible for synchronizing the access to the
ESC. What this means is the SM prevents simultaneous access to the ESC hence keeping
the data consistent. Also either the master or the MBB can disable this SM causing the
ESC to become inaccessible, hence no input/output update will occur. Again enabling the
930 SM will enable transactions to happen.
// I n i t i a l i z e t h e ESC t o ”INIT”
v o i d EtherCAT init ( v o i d )
{
935 // Wait u n t i l t h e ESC i s powered on by r e a d i n g t h e DataLink S t a t u s (
DLSTATUS) r e g i s t e r
...
...
// Reset i n p u t v a r i a b l e s t o d e f a u l t
940 ...
...
/∗ r e s e t ESC t o i n i t s t a t e ∗/
ESC ALstatus ( ESCinit ) ; // A p p l i c a t i o n Layer S t a t u s r e g i s t e r i s r e s e t
ESC ALerror (ALERR NONE) ; // C l e a r e r r o r s
945 ESC stopmbx ( ) ; // Stop Mailbox communication
ESC stopinput ( ) ; // Stop Input comm .
ESC stopoutput ( ) ; // Stop output comm .
}

Listing 4.3: Software (ESC) initialization

950 Task Loop The task in hand is to read the state of the ESC, check for pending events
like change of state or request to write/read and then finally execute the application task.
The code Listing 4.4 refers to this task loop. The Application task is shown in the following
code Listing 4.5. It is important to note that output and input throughout the code is with
reference to the EtherCAT master (PC). Hence input means input to the PC and output
955 from the ESC. Similarly for output, it is the input to the ESC(slave) from the PC(master).
//ESC Task l o o p t o be i n v o k e d c y c l i c a l l y
v o i d EtherCAT task ( v o i d )
{
960
i f ( ( ESCvar . ALstatus & 0 x 0 f ) == ESCinit )
{
/∗ I f INIT s t a t e , then r e s t o r e RX and TX PDO s e t t i n g s t o d e f a u l t
s i z e ∗/
965 ...
...
...

48 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

}
//Read t h e system time from t h e ESC .
970 ...
// Check f o r pending a p p l i c a t i o n e v e n t
ESC ALevent ( ) ;
//Read t h e ESC s t a t e
ESC state ( ) ;
975

// C o n f i g u r e CoE communication i f mailbox communication i s e n a b l e d

i f ( ESC mbxprocess ( ) )
{
ESC coeprocess ( ) ;
980 }

A p p l i c a t i o n P r o c e s s ( ) ; // E i t h e r c a l l e d h e r e on i n DC i f DC i s e n a b l e d
}

Listing 4.4: Task Loop invoked to check ESC state and execute the application
985
// A p p l i c a t i o n Loop
void ApplicationProcess ( void )
{
// Keep t r a c k o f WATCHDOG t i m e r
990 ...
// Check i f t h e A p p l i c a t i o n S t a t u s i n t h e ESC i s ” Output ” ( with r e s p e c t
t o e t h e r c a t master )
i f (App . s t a t e & APPSTATE OUTPUT)
{
995 /∗ SM2 ( Output ) t r i g g e r e d and pending ? ∗/
i f ( ESCvar . ALevent & ESCREG ALEVENT SM2)
{
ESCvar . ALevent &= ˜ESCREG ALEVENT SM2 ; // Event acknowledged
RXPDO update ( ) ; //Read t h e Output b u f f e r
1000
// Perform t a s k s based on t h e output v a l u e s
...
}
}
1005 // I f WATCHDOG e r r o r , h a n d l e t h e e r r o r − Stop outputs , update e r r o r f l a g s
, change t h e s t a t e o f t h e ESC .
i f ( watchdog == 0 )
{
...
1010 ...
}
// Check i f t h e A p p l i c a t i o n S t a t u s i n t h e ESC i s ” Input ”
i f (App . s t a t e )
{
1015 set Inputs () ; // Update t h e i n p u t s t o be s e n t t o t h e master
TXPDO update ( ) ; // Send t h e updated i n p u t s through SPI w r i t e f u n c t i o n
}
}

Investigation of EtherCAT for the Motion Building Blocks 49

 CHAPTER 4. IMPLEMENTATION

Listing 4.5: Application loop performs the read/write from/to the ESC

1020 The difference functionalities are seggregated into different files as shown in Table 4.1
below.

File Name Functionalities

objectlist.c a list of structures that consists of ESC description
consists of the software initialization and application functons. It also
ethslave.c
consists of ESC states handler functions.
The main file for the project which also includes timer interrupts
MAIN.c
service routines.
esc.c Functions that handle data link and mailbox communication
esc.h header for the esc.c functions, pack and unpack functions.
The hardware initialization and the hardware access (SPI write,
esc hw.c
writeblock, read and readblock functions)
esc coe.c the CoE module
esc coe.h header file for the esc coe.c functions
config.h header file containing marcro defintions of SM and mailbox sizes.
functions that aid in manual unpacking of data transmitted from the
unpack func.c ESC to the MBB. The TI compiler does not provide support for
packing/unpacking
functions that aid in manual packing of data transmitted to the ESC
pack func.c
from the MBB.
consists of cpu initialization functions and also the DC clock sync
cpu.c
interrupt service routine.
contains the input output structures that hold a copy, in the MBB,
utypes.h
of the input/output data at the ESC.

Table 4.1: EtherCAT software file structure

Clock Synchronized Signal We can make use of the ESC’s precise clock to cyclically
generate a signal to the MBB. This signal is generated from the DC sub-system in the
ESC, hence prior to the signal generation, the clocks need to synchronized with the ref-
1025 erence. Repeating what was in the design chapter, the DC synchronization occurs in the
SAFE-OP state and then in the OP state, the sync signal is generated cyclically. There
are two such signals available to be used from the ESC - SYNC0 and SYNC1. Depend-
ing on the direction of the signal, it is called either SYNC0 /SYNC1 (ESC to MBB) or
LATCH0 /LATCH1 (MBB to ESC).
1030 In this project we use one SYNC0 signal as shown in Figure 4.3. This interrupt is
used to trigger the application task. Earlier the application task was being invoked in
the ESC task. Now we separate the state and event monitor from the actual application

50 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

task. We know from the above description that the application task is used to update
the input/outputs if the ESC is in the appropriate state. We use the SYNC interrupt
1035 to generate a more synchronized input/output update. The code Listing 4.6 shows the
external interrupt being used to invoke application task. In the project, the external
interrupt has been configured to be an ”ISR type” of interrupt as the this type of interrupt
provides the fastest response time when compared to all other interrupt types used in TI’s
DSP [24].
1040
// E x t e r n a l I n t e r r u p t g e n e r a t e d u s i n g SYNC s i g n a l from t h e ESC
//#pragma CODE SECTION( x i n t 1 i s r , ”FAST CODE RAM” ) ;
i n t e r r u p t void x i n t 1 i s r ( void )
{
1045 ...
ApplicationProcess () ;
// This i s needed t o w r i t e t o EALLOW p r o t e c t e d r e g i s t e r s
EALLOW;
// Acknowledge t h i s i n t e r r u p t t o g e t more from group 1 i n t e r r u p t s
1050 P i e C t r l R e g s . PIEACK . a l l = PIEACK GROUP1 ;
// This i s needed t o d i s a b l e w r i t e t o EALLOW p r o t e c t e d r e g i s t e r s
EDIS ;
}

Listing 4.6: SYNC interrupt used in the MBB to perform a synchronized application task.

Figure 4.3: Cyclic SYNC signal from the ESC to MBB. The SYNC signal is generated
using the precise DC clock of the ESC.

1055 Packing/Unpacking The ESC transmits/receives only packed data. The Texas Instru-
ments compiler on the other hand does not support packing/unpacking of data. Every
single structure related to the EtherCAT that consisted of uneven variable lengths had to
be manually packed and unpacked when transmitting and receiving. Bit by bit calculations
had to be done to see if the data was packed correctly or incorrectly. Figure 4.4 shows one
1060 example of packing and Listing 4.7 shows one sample unpacking function written.

Investigation of EtherCAT for the Motion Building Blocks 51

 CHAPTER 4. IMPLEMENTATION

Figure 4.4: Packing of three variables of different lengths (for TI, default length is 16 bit).

v o i d unpack COEsdo ( COEsdo ∗ dst , MBX ∗ c o n s t s r c )

{
u i n t 1 6 t ∗ cdest = ( u i n t 1 6 t ∗) dst ;
1065 u i n t 1 6 t ∗ ptr = ( u i n t 1 6 t ∗) s r c ;
c d e s t [ 0 ] = p t r [ 0 ] ; // mbxheader . l e n g t h
c d e s t [ 1 ] = p t r [ 1 ] ; // mbxheader . a d d r e s s
/∗ u i n t 1 6 t c h a n n e l : 6 ; u i n t 1 6 t p r i o r i t y : 2 ; u i n t 1 6 t mbxtype : 4 ;
u i n t 1 6 t mbxcnt : 4 ; ∗/
1070 cdest [ 2 ] = ptr [ 2 ] ;
c d e s t [ 3 ] = ( ( p t r [ 4 ] & 0 xFF)<<8) | ( p t r [ 3 ] & 0 xFF) ; // c o e h e a d e r . n u m b e r s e r v i c e
dst−>command = p t r [ 5 ] & 0 xFF ;
dst−>i n d e x = ( ( p t r [ 7 ] & 0 xFF)<<8) | ( p t r [ 6 ] & 0 xFF) ;
dst−>s u b i n d e x = p t r [ 8 ] & 0 xFF ;
1075 dst−>s i z e = ( ( ( ( p t r [ 1 2 ] & 0 xFF)<<8)<<8)<<8) | ( ( ( p t r [ 1 1 ] & 0 xFF)<<8)<<8) |
( ( p t r [ 1 0 ] & 0 xFF)<<8) | ( p t r [ 9 ] & 0 xFF) ;
}

Listing 4.7: one unpacking function that stores the received (from ESC) mailbox
information into another local structure (at the MBB)

4.2.2 Serial Peripheral Interface

1080 The initialization of the SPI has already been covered in the previous section. Two other
important SPI functions include the write and read functions. Due to the limited size of

52 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

16 FIFO buffers to receive/transmit and using up 4 header bytes, we can receive/transmit

only 12 SPI characters at a time. The 4-byte header information consists of ESC address
and whether it is a read/write command and is shown in Table 4.2. 12 bytes of SPI data
1085 transmission is shown in figure 4.5. Also the size of one character is 8 bits in our project.
8 bits is chosen because the smallest addressable length in the ESC is 8 bits or one byte1 .
To read/write more than 12 bytes at a time, we repeatedly call the SPI write and read
functions till all the bytes are exchanged. This is done in the WriteBlock and ReadBlock
functions. The code Listing 4.8 and 4.9, shows the SPI write and read functions.
1090 One of the key problems while implementing the SPI has been that the ESC is a black
box. Data skipped once in many bytes is very hard to detect if there is no access to the SPI
slave(ESC in this case). The TI DSP is a relatively older DSP. It’s SPI clock’s jitter (and
drift) is reasonably high. The ESC on the other hand has a very tight constraint on the
clock while latching data. Due to this, data is read wrong once in many (random number)
1095 bytes. We had to find a way to tackle the problem by introduced a delay between each
transmitted byte. To keep the SPI speeds as high as possible, we started with a higher
”safe” delay and reduced the delay iteratively till the error occured again.

Figure 4.5: SPI frame with a maximum of 12 characters of SPI data (and 4 characters of
SPI header), at a time.

1
Texas Instruments DSP considers 16bits as one byte because that is the smallest addressable length.
But for this report, we consistently use a byte as 8 bits

Investigation of EtherCAT for the Motion Building Blocks 53

 CHAPTER 4. IMPLEMENTATION

Byte 0 A[12:5] (12 to 5 bits out of the 16bit Address)

Byte 1 A[4:0]+0x06 (0x06 is 3-byte address extension)
Byte 2 A[15:13] + CMD[2:0] (CMD is READ/WRITE command)
Byte 3 0xF F (Wait state command)

Table 4.2: SPI Read/Write header information used to read/write data from/to the ESC.

v o i d ESC write ( u i n t 1 6 t o f f s e t a d d r , v o i d ∗ wrdata , u i n t 1 6 t l e n , v o i d ∗

1100 tALevent )
{
// I n i t i a l i z e l o c a l v a r i a b l e s
...
...
1105 /∗ C o n s t r u c t SPI−w r i t e h e a d e r and s t o r e i n l o c a l b u f f e r ∗/
cmd =( o f f s e t a d d r & 0x1FE0 ) <<3; // o f f s e t a d d r [ 1 2 : 5 ] i s 1 s t a d d r e s s
phase byte , s h i f t t o upper byte
cmd |= ( ( ( o f f s e t a d d r & 0x1F ) << 3 ) | ESC ETHERCAT 3BYTEADDR) ;
w r i t e p h a s e [ 0 ] = cmd ;
1110 numwords++;
cmd = 0 x0000 ;
cmd = ( ( ( o f f s e t a d d r & 0xE000 ) >> 8 ) | (ESC ETHERCAT 3BYTEADDR << 2 ) ) <<
8;
cmd |= ( ( ( o f f s e t a d d r & 0xE000 ) | (ESC ETHERCAT WRITE <<10) ) >> 8 ) ;
1115 w r i t e p h a s e [ 1 ] = cmd ;
numwords++;

// S t o r e t h e data t o be t r a n s m i t t e d i n l o c a l b u f f e r
...
1120 ...
// D i s a b l e g l o b a l I n t e r r u p t s
// Send data t o t h e SPI TX b u f f e r ( with d e l a y between each byte )
...
CPU DELAY US( 2 ) ;
1125 ...
...
CPU DELAY US( 1 0 ) ; // Wait f o r t h e data be t o r e c e i v e d
w h i l e ( SpiaRegs . SPIFFRX . b i t .RXFFST < j ) ; // number o f b y t e s r e c e i v e d same
a s number o f b y t e s s e n t ?
1130 ...
//Read r e l e v a n t i n f o r m a t i o n and i g n o r e t h e o t h e r s .
...
...
// Reset FIFO and SPI t o be ready t o t r a n s m i t a g a i n .
1135 ...
// Enable g l o b a l i n t e r r u p t
}

Listing 4.8: SPI write function

1140 v o i d ESC read ( u i n t 1 6 t o f f s e t a d d r , v o i d ∗ buf , u i n t 1 6 t l e n , v o i d ∗ tALevent )

54 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

{
// I n i t i a l i z e l o c a l v a r i a b l e s
...
...
1145 /∗ C o n s t r u c t SPI−r e a d h e a d e r and s t o r e i n l o c a l b u f f e r ∗/
cmd =( o f f s e t a d d r & 0x1FE0 ) <<3; // o f f s e t a d d r [ 1 2 : 5 ] i s 1 s t a d d r e s s phase
byte , s h i f t t o upper byte
cmd |= ( ( ( o f f s e t a d d r & 0x1F ) << 3 ) | ESC ETHERCAT 3BYTEADDR) ;
r e a d p h a s e [ 0 ] = cmd ;
1150 numwords++;
r e a d p h a s e [ 1 ] = ( o f f s e t a d d r & 0xE000 ) | (ESC ETHERCAT READ WAIT <<10) |
ESC ETHERCAT WAIT ;
numwords++;

1155 // S t o r e junk data t o be t r a n s m i t i n l o c a l b u f f e r ( t o r e a d one byte t h e

master has t o one byte )
...
...
// D i s a b l e g l o b a l I n t e r r u p t s
1160 // Send byte by byte t o t h e SPI TX b u f f e r ( with d e l a y between each byte )
...
CPU DELAY US( 5 ) ;
...
CPU DELAY US( 1 0 ) ; // Wait f o r t h e data be t o r e c e i v e d
1165 w h i l e ( SpiaRegs . SPIFFRX . b i t .RXFFST < j ) ; // number o f b y t e s r e c e i v e d same
a s number o f b y t e s s e n t ?
...
//Read t h e b y t e s and s t o r e i n t h e o r i g i n a l d e s t i n a t i o n
...
1170 ...
// Reset FIFO and SPI t o be ready t o r e a d a g a i n .
...
// Enable g l o b a l i n t e r r u p t
1175
}

Listing 4.9: SPI read function

4.3 ESC description file

As already indicated, the ESC’s software is from the company, Beckhoff, and that code
is inaccessible. It has also been mentioned that the master interacts with the ESC through
EtherCAT and the MBB interacts with the ESC through SPI. What that also indicates
1180 is that the ESC is the intersection between the master and the MBB. For the interaction
between all the three hardware components to be uniform and safe, we need to have a
uniform description of the ESC at the master, the MBB and in the ESC. One description
of the ESC is contained in the master, copy of that description is transmitted to the
ESC through EtherCAT (other possibilities exist but are not discussed here) and another
1185 description is written in the MBB that must match with the one used in the master and

Investigation of EtherCAT for the Motion Building Blocks 55

 CHAPTER 4. IMPLEMENTATION

the ESC. This is shown in Figure 4.6. Failing to have a consistent description across the
devices will prohibit the ESC from functioning correctly.

Figure 4.6: ESC description files (.xml and .c) are programmed to the master, ESC and
slave for uniform ethercat communication.

To prevent the tedious task of writing a configuration file for the master and replicating
that in C code in the MBB, we use the SOES configurator tool2 which is shown in Figure
1190 4.7. Figure 4.8 shows the various settings options and the object dictionary which is the
CoE way of description. The description file to the master is written in XML Schema and
the description in the MBB is written in C. An example XML file in shown in code Listing
4.10.

2
It generates a wrong output but can be easily modified still saving enormous amounts of time

56 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

Figure 4.7: SOES configuration tool used to generate the ESC description file.

Figure 4.8: SOES configuration tool showing the configurable settings and the CANopen’s
Object dictionary way of description.

1195 <? xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>

<EtherCATInfo>
<Vendor>
<Id>#x00000939</ Id>
<Name LcId=” 1033 ”>NTS−Group</Name>
1200 </ Vendor>
<D e s c r i p t i o n s>
...
<D e v i c e s>
...
1205 <Fmmu>Outputs</Fmmu>
<Fmmu>I n p u t s</Fmmu>

Investigation of EtherCAT for the Motion Building Blocks 57

 CHAPTER 4. IMPLEMENTATION

<Fmmu>MBoxState</Fmmu>
<Sm Co nt ro lB yt e=”#x26 ” D e f a u l t S i z e=” 128 ” Enable=” 1 ” S t a r t A d d r e s s=”#
x1000 ”>MBoxOut</Sm>
1210 <Sm Co nt ro lB yt e=”#x22 ” D e f a u l t S i z e=” 128 ” Enable=” 1 ” S t a r t A d d r e s s=”#
x1080 ”>MBoxIn</Sm>
<Sm Co nt ro lB yt e=”#x24 ” D e f a u l t S i z e=” 8 ” Enable=” 1 ” S t a r t A d d r e s s=”#
x1100 ”>Outputs</Sm>
<Sm Co nt ro lB yt e=”#x20 ” D e f a u l t S i z e=” 8 ” Enable=” 1 ” S t a r t A d d r e s s=”#
1215 x1180 ”>I n p u t s</Sm>
<RxPdo Fixed=” t r u e ” Mandatory=” t r u e ” Sm=” 2 ”>
...
</RxPdo>
<TxPdo Fixed=” t r u e ” Mandatory=” t r u e ” Sm=” 3 ”>
1220 ...
</TxPdo>
<Mailbox>
<CoE CompleteAccess=” f a l s e ” PdoUpload=” t r u e ” S d o I n f o=” t r u e ” />
</ Mailbox>
1225 <Dc>
<OpMode>
<Name>DC−Synchronous</Name>
<Desc>DC−Synchron</ Desc>
<A s s i g n A c t i v a t e>300</ A s s i g n A c t i v a t e>
1230 <CycleTimeSync0>1</ CycleTimeSync0>
</OpMode>
</Dc>
<Eeprom>
...
1235 </Eeprom>
...
</ EtherCATInfo>

Listing 4.10: ESC desciption file in XML Schema to be loaded into the Master and the
ESC through the master
The description file in the MBB contains one very important file which is the objectlist.
1240 The objectlist file is a list of structures that contain the same information as the XML
description file written in the master which is shown above. A small code snippet of this
file is provided in Listing 4.11.
...
1245 static const char acName1000 [ ] = ” De v ic e Type” ;
static const char acName1000 0 [ ] = ” D ev ic e Type” ;
static const char acName1008 [ ] = ” De v ic e Name” ;
static const char acName1008 0 [ ] = ” D ev ic e Name” ;
static const char acName1009 [ ] = ” Hardware V e r s i o n ” ;
1250 ...
static const char acName100A 0 [ ] = ” S o f t w a r e V e r s i o n ” ;
static const char acName1018 [ ] = ” I d e n t i t y Object ” ;
static const char acName1018 00 [ ] = ”Number o f Elements ” ;
static const char acName1018 01 [ ] = ” Vendor ID” ;
1255 static const char acName1018 02 [ ] = ” Product Code” ;

58 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 4. IMPLEMENTATION

s t a t i c c o n s t c h a r acName1018 03 [ ] = ” R e v i s i o n Number” ;
s t a t i c c o n s t c h a r acName1018 04 [ ] = ” S e r i a l Number” ;
...
...
1260 s t a t i c c o n s t c h a r acName1C00 01 [ ] = ” Communications Type SM0” ;
s t a t i c c o n s t c h a r acName1C00 02 [ ] = ” Communications Type SM1” ;
s t a t i c c o n s t c h a r acName1C00 03 [ ] = ” Communications Type SM2” ;
s t a t i c c o n s t c h a r acName1C00 04 [ ] = ” Communications Type SM3” ;
s t a t i c c o n s t c h a r acName1C12 [ ] = ” Sync Manager 2 PDO Assignment ” ;
1265 s t a t i c c o n s t c h a r acName1C12 00 [ ] = ”Number o f Elements ” ;
...
c o n s t o b j d SDO1000 [ ] =
{
{0 x0 , DTYPE UNSIGNED32, 3 2 , ATYPE RO, acName1000 0 , 0 x01901389 , NULL} ,
1270 };
c o n s t o b j d SDO1008 [ ] =
{
{0 x0 , DTYPE VISIBLE STRING , 4 0 , ATYPE RO, acName1008 0 , 0 , ” s l a v e ” } ,
};
1275 c o n s t o b j d SDO1009 [ ] =
{
{0 x0 , DTYPE VISIBLE STRING , 2 4 , ATYPE RO, acName1009 0 , 0 , ” 1 . 0 ” } ,
};
c o n s t o b j d SDO100A [ ] =
1280 {
{0 x0 , DTYPE VISIBLE STRING , 2 4 , ATYPE RO, acName100A 0 , 0 , ” 1 . 0 ” } ,
};
c o n s t o b j d SDO1018 [ ] =
{
1285 {0 x00 , DTYPE UNSIGNED8, 8 , ATYPE RO, acName1018 00 , 4 , NULL} ,
...
{0 x04 , DTYPE UNSIGNED32, 3 2 , ATYPE RO, acName1018 04 , 0 x00000000 , NULL} ,
};

1290 c o n s t o b j e c t l i s t SDOobjects [ ] =
{
{0 x1000 , OTYPE VAR, 0 , 0 , acName1000 , SDO1000 } ,
...
{0 x6003 , OTYPE RECORD, 1 6 , 0 , acName6003 , SDO6003 } ,
1295 ...
};
...
...

Listing 4.11: Objectlist file contains the description of the ESC in C

Investigation of EtherCAT for the Motion Building Blocks 59

1300 Chapter 5

Performance Evaluation and Analysis

This chapter explains the research in the thesis. It includes two parts.

• EtherCAT performance.

• Centralized control system performance.

1305 • Comparative study of Control architectures and proposal of a modified architecture.

5.1 EtherCAT Performance

The plan at NTS-Group is to replace RTDN/UCP with EtherCAT. For this we need
to map the performance of EtherCAT to examine if it is a feasible alternative. Until now,
there has been several theoretical performance statistics and claims in different research.
1310 In this thesis, we extract the performance metrics from an actual setup designed and
implemented by us.
There are several parameters that we shall explore in the following subsections.

5.1.1 Update Rate

Since the master of the system is always the message initiator, the update rate is
1315 related to the master. To understand the update rate of the ethercat master, we need
to understand the message initiation. The master sends an ethercat message (frame)
containing information for all the slaves in the network. This message is ”processed-on-
the-fly” by each slave and then transmitted back to the master either through the same
ethernet bus or in case of ring topology the bus that connects the last slave to the master.
1320 Because the ethernet bus is full-duplex, what this means is that the master need not have
to wait for the return of the message before sending out the next ethercat message.
The only bottleneck for the update rate is the time by each slave to ”process-on-the-
fly”. The concept basically means that at each slave node, data specific to the slave is
copied in and replaced with the data intended to be output. This frame is then passed

60 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

1325 on to the next slave or back to the master if the next port is closed. This ”processing-on-
the-fly” is done by special hardware and hence the delay is hardware dependent and not
implementation dependent.
The update rate is proportional to the number of slaves times delay experienced by an
ethercat message frame at each slave. In the case of our Beckhoff ESC with 2 ports, the
1330 delay provided by Beckhoff is approximately 1.2µs.

5.1.2 Frame Delay

The time taken by the frame to traverse through the network and return back to the
master (initiator) is defined as the frame delay or also called as Roundtrip time. To
compute the frame delay, we simply timestamp the start of each message and the return
1335 of that message. The difference between the two timestamps is the frame delay. There
is observable increase in the delay with respect to the size of the ethercat message frame
(number of bytes). A graph of the variation in frame delay v/s the number of bytes in the
ethercat frame for a single slave ethercat network is as shown in figure 5.1.

Figure 5.1: EtherCAT frame delay for a single slave system.

5.1.3 Cycle Time

1340 The time difference between two consecutive ethercat message frames is the cycle time
of that ethercat network. In theory, the minimum cycle time will be equal to the frame
delay of that ethercat network. But in practise, there is one limiting factor to having the
minimum cycle time or to having maximum frequency. That is the system latency.

Investigation of EtherCAT for the Motion Building Blocks 61

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

The system latency - TwinCAT integrates into Windows as a kernel mode driver.
1345 What this means is as a kernel driver, TwinCAT has hardware access to the RAM and
CPU to schedule CPU time based on the project settings. But because of this integration,
higher priority windows tasks take away CPU time and this causes latency in execution
of the twincat tasks. Another contributing factor to this system latency is the Network
Interface Card (NIC). Due to the NIC being used for both ethercat and ethernet, the access
1350 to the NIC is distributed hence providing a bottleneck. In TwinCAT, it is possible to
measure the latency caused, by comparing the entry of consecutive frames and subtracting
the value with the cycle time. Figure 5.2 shows the system latency hovers around 100µs.
The cycle time cannot be made lower than this system latency. Hence the best achievable
cycle time for the current setup has been 100µs.

Figure 5.2: EtherCAT master system latency highlighted in red.

1355 5.1.4 Clock deviation or Distributed Clock Jitter

Beckhoff’s ethercat slave controller provides a very precise ns resolution clock. Using
this reference clock, we can measure the jitter or clock deviation for the master or other
slaves. For the master (PC side), in TwinCAT there is an option to run diagnostics
to visualize the clock jitter with respect to the reference clock. Table 5.1 shows the clock
1360 deviation with respect to the reference clock. Deviation values greater than 200µs occurred
during the initial synchronization (phases shown in figure 5.3). During the stable state,
the maximum deviation observed was less than or equal to 100µs. With one example this
is how the table is to be read - The number of frames that had a negative deviation of less
than 1µs with respect to the reference clock is 114655 and the number of frames that had
1365 a positive deviation of less than 1µs with respect to the reference clock is 96652.

62 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Deviation(in µs) Negative Count Positive Count

<1 114655 96652
<2 98018 59358
<5 128041 70741
<10 53089 23643
<20 20045 39764
<50 2319 75081
<100 48 8682
<200 96 1911
<500 312 178
>500 2408 4

Table 5.1: The count of clock deviations (positive and negative deviations) and the value
in µs with respect to the reference clock.

Figure 5.3: The deviation of the local clocks compared to the reference clock during ini-
tialization of DC and during operational state. [7]

5.1.5 Minimum Response Time

In an EtherCAT slave device, the input data to the device is ”extracted” from the
frame and output data is inserted into the ethercat frame before transmitting the frame
to the next destination. It can observed here that the processing of this input does not
1370 happen in the same cycle. Hence, in the best case scenario, the processed information
is only available for the next cycle. The output is available atleast one cycle late. The
minimum response time can be defined as the time taken by two consecutive cycles - one
where the input is updated and one where the processed output is updated. With this
information, we can conclude that,
ResponseT imemin = 2 ∗ CycleT imeeth + Jitter (5.1)
1375 Considering jitter to be zero for the best case scenario,
ResponseT imemin = 2 ∗ CycleT imeeth (5.2)

Investigation of EtherCAT for the Motion Building Blocks 63

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

The achievable minimum response time is therefore equal to 200µs.

5.2 Centralized Control using Simulink

Modern PCs are getting very powerful. If deterministic computing is guaranteed on the
PC then that opens up endless possibilities to implement complex control systems. Twin-
1380 CAT provides support to several programming platforms to develop such complex control
systems to run on a conventional PC. For example, TwinCAT supports integration with
PLC programming, C++ or Simulink. It also provides interoperability support between
these platforms by using TwinCAT standard libraries. Simulink is a powerful model-based
software which is widely used to make complex control algorithms. The main advantage
1385 of using Simulink is quick prototyping.

We wanted to explore if using Simulink control model in TwinCAT to make a centralized

control algorithm, will provide good performance for precision control.

Control Loop Delay - One performance metric that is essential for precision control is
the control loop delay. It can be defined as the delay between reading the encoder value and
1390 updating the actuator value after processing. The larger the control loop delay, the lower
the precision achievable hence it is essential to keep the control loop delays to the lowest
possible values. Figure 5.4 shows the centralized architecture and the use of timestamps
to measure the control loop delay.

The estimation used for the control loop delay τkcontrol is shown in the following equation.
1395 The delay between reading the encoder and transmitting the value to the PC as input to
the simulink controller is τkEC . The execution delay of the simulink controller is defined by
τkC . The delay between reading the encoder and transmitting the value to the PC as input
to the simulink controller is τkCA .

τkcontrol = τkEC + τkC + τkCA (5.3)

64 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Figure 5.4: Centralized control architecture with the use of timestamps to measure the
control loop delay.

To investigate if this delay is in the acceptable limits of NTS’s precision control, we

1400 implemented a simple single linear axis PI controller in Simulink and generated the model
to run on TwinCAT (and Windows) environment. Along with this, we also ran another
model without the control algorithm just as reference to compute the delay caused by the
simulink model itself.
The first set of experiments were to run the simulink model with the PI controller.
1405 We accumulated the control loop delay information into log files. The physical motion
control was not carried out due to the inaccuracy of the PI model parameters. But the
delay information is essential for us and not an accurate actuator value. Figure 5.5 shows
the Simulink model PI controller. Figure 5.6 shows the control loop delays obtained when
using an input/output task cycle time of 100µs and simulink model task cycle time of 1ms.

Investigation of EtherCAT for the Motion Building Blocks 65

CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Figure 5.5: Simulink model of PI controller used as the central control model. This model
is run in TwinCAT runtime environment with a 1ms cyclic task.

Figure 5.6: Estimated control loop delay for the centralized control architecture.

66 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

1410 The next set of experiments, used as reference, involves a simple simulink model as
shown in figure 5.7. Using the control loop delays of this model (shown in figure 5.8), we
can calculate the actual execution delay of the PI controller in the simulink model. Figure
5.9 shows the calculated execution times for the simulink PI controller model.

Figure 5.7: Reference simulink model used as a benchmark.

Figure 5.8: Reference simulink model used as a benchmark.

Investigation of EtherCAT for the Motion Building Blocks 67

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Figure 5.9: Execution time of the PI controller model used as the central control algorithm
for the different experiments conducted. It can be observed that the average execution
time is about 1.5ms and in practise this leads to a considerable control precision loss.

Inference - We observe from Figure 5.9 the execution times of the simulink PI controller
1415 is approximately around 1.5ms. If we assume a typical precision loss of 1m per 250µs
(update frequency of 4KHz) that translates to a loss of 6m in case we use a centralized
architecture as in the experiment. For the current setup, with TwinCAT, using Simulink
model as a central control algorithm, we cannot yet achieve the delays achieved using a
de-centralized setup up. Also it can be observed that this delay is typically unacceptable
1420 for high precision motion control applications. Summarizing, the control loop performance
of a centralized architecture using Simulink in TwinCAT, is very poor. In the following
section, we shall explore alternative architectures that we think provide the best of both
the worlds (centralized and de-centralized architectures).

5.3 A Study of Control System Architectures

1425 By understanding the performance of EtherCAT and EtherCAT master-slave system
with centralized control architecture, we can extrapolate the information to study control
system architectures.
NTS-Group’s unique selling point is ”value engineering”. Hence understanding the
costs of each of the architecture will allow them to effectively use architecture based on
1430 system prototyping and the volume of production. The primary focus of this comparison

68 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

is to understand the pros-cons and consequences of choosing particular architectures in the

industrial automation domain.
The two commonly used architectures are the centralized and the de-centralized control
architecture. We shall make a comparison of these two architectures and use the inform-
1435 ation to propose an architecture that combines the benefits of the two architectures. The
new proposed architecture is a combination and also a middle path, hence named control
architecture-2.
To explain the three architectures, we shall use an example. The example is a printer
with a printer head that moves along two axes (forms a H-Bridge), as shown in figure 5.10.

Figure 5.10: Example used to explain the control architectures - Printer with a printer
head moving in the 2D axes.

1440 The three control architectures are,

• De-centralized control architecture (Control Architecture-1)

• Hybrid Architecture (Control Architecture-21 )

• Centralized control architecture (Control Architecture-3)

It is important to note that the network for all the control system architectures presented
1445 here are EtherCAT based.

Control Architecture-1 (De-centralized Control) In the case of the decentralized

control architecture, the control tasks are distributed within the slaves. The PC runs
Windows/Linux and is used for non-real time communication with the slaves. One of the
slaves act as the master for the hard real time applications. The slaves handle their own
1
The proposed architecture is named 2 just to highlight the middle-path nature of the architecture

Investigation of EtherCAT for the Motion Building Blocks 69

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

1450 application tasks and the PC has non real time interaction with the slaves and conducts
diagnostics or network analysis.

An example of this architecture is as shown in figure 5.11a. At present, NTS-Group

also uses a similar architecture with CAN (RTDN/UCP) in place of EtherCAT.

Control Architecture-3 (Centralized Control) In case of the centralized control

1455 system, the data from each stroke (long and cross stroke of the printer) is sent from the
slaves to the master, the data is then processed in the master (central control algorithm)
and then each slave receives appropriate information to act upon. Here the emphasis is
on the all powerful master (PC). The master runs either Windows or Linux and an RTOS
(TwinCAT, RTX, Matlab XPC, IntervalZero) in parallel which guarantees the real time
1460 performance needed to have deterministic control. All the intelligence is in the master and
the slaves are ”dumb” devices that act according to the information from the master. An
example of this architecture is as shown in figure 5.11b.

Control Architecture-2 (Hybrid Control Architecture) A new architecture is in-

troduced as shown in the figure 5.12. The differentiating component is the use of a dual
1465 processor System on Chip (SoC) as the slave. One general purpose ARM processor is used
for general purpose computing which can run a High Level OS (HLOS) or a Real Time
OS (RTOS) like TwinCAT/RTX/IntervalZero (or both) and one co-processor (example
a DSP) for more dedicated task computations. This architecture is a moderation of the
above two architectures which makes a middle path in costs but has a very high perform-
1470 ance as compared to the other two architectures. Two example processor series that suit
this role are the Texas Instruments Concerto microcontrollers and the Texas Instruments
Sitara series of microcontrollers [25], [26].

70 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

(a) De-centralized control architecture with each slave controlling one of the axis of the H-bridge
printer.

(b) A centralized control architecture with the slaves only reading/actuating their respective axis
of the H-bridge printer. The control is part of the master (PC).

Figure 5.11: Comparing the de-centralized and centralized control architectures for the
H-bridge printer that is shown in Figure 5.10.

Investigation of EtherCAT for the Motion Building Blocks 71

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

5.3.1 Comparative study of the three architectures

As mentioned earlier, NTS Group is using a de-centralized control architecture ap-
1475 proach. Control applications are written in C++/C and are embedded within the MBB
boards (slaves), hence these MBB slave devices have their own local control.
Using one performance metric at a time, we can compare the three control architectures
for their strengths and weaknesses. We shall use color coding to highlight the strengths
and weaknesses - Green indicated best, Yellow indicates moderate and Orange indicates
1480 the worst of a particular metric.

Non-Recurring Engineering (NRE) Costs

Non-Recurring Engineering costs is the initial investment into design, development and
testing of new prototypes.

Developmental Costs - This metric can be expressed as man-hours needed to make

1485 a complex system using the three different architectural approaches. The primary differ-
entiating factor for this parameter is the support for model-based development (example
Simulink) and the availability of assistance for the software/hardware products. In the
case of a de-centralized control architecture, the support for model-based development on
specific microcontrollers, though on the rise, is limited at the moment. Hence development
1490 using the conventional techniques (loop of design, conventional programming, integration
and testing) costs more man-hours. Even the assistance is heavily supplier dependent. The
case is partially true for Architecture-2 (hybrid architecture) where it costs less man hours
to implement applications on the ARM because it would support high level OS, while more
efforts are still needed to develop applications on the DSP. The dependency for assistance is
1495 the same as for the de-centralized control architecture. In the case of the completely cent-
ralized architecture, due to the extensive support of model-based development available
for Windows/Linux, it relatively quicker for prototyping and deployment. It is also easier
to find more 3rd party applications and larger user base providing greater assistance for
the software. Software flexibility is also greater (example TwinCAT provides integration
1500 support for Simulink, PLC programming languages and C++) providing greater choice of
developmental tools. These reasons make the centralized control architecture best suited
for quick and complex development.

Hardware/Software costs - A hardware setup and software licensing costs is another

important metric to consider while choosing an architecture. One consideration point is
1505 if the initial costs is much greater than the developmental man-hours times the wage per
hour, required to setup an architecture, than the value or advantage of that architecture
reduces. It is harder to weigh an architecture against this parameter because there is
not a clear standard man-hour wage. For example, if setting up a high performance PC,
converting it into a Real time PC and obtaining all the software licenses to run complex
1510 applications is more expensive than the total man-hours (times the wages) needed to

72 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

develop a de-centralized architecture, then atleast from the perspective of NRE costs,
there is no advantage of the centralized architecture. Ofcourse the benefits of NRE costs
also depends on the volume of production. The higher the production volume, the lower
is the NRE cost per system but for our calculations, we have assumed the volume to be
1515 consistent.

Architecture-1 Architecture-2 Architecture-3

(De-centralized) (Hybrid) (Centralized)
NRE Costs

Quality of Service (QoS)

There are three important QoS metrics for a control system - cycle time, sensor to
actuator delay and jitter. Because the network is the same (in this case ethercat) across
the three architectures, we can normalize the cycle time delay and the ethercat network
1520 jitter for the three architectures. The one distinguishing component is the control loop
delay (sensor to actuator). In the case of experiment done in this thesis, this sensor to
actuator delay includes transmitting the sensor value from slave to the master, this value
being processed at the master and then being transmitted back to the slave. Because
the transmission delay is more or less the same across the architectures (only variation
1525 in length adds 5ns/m delay), the primary delay component of the control loop is in the
processing of the input (PI model in the case of the experiment).
In the case of the centralized architecture, using a combination of Windows, Twin-
CAT3.1 and Simulink, the processing time of the PI model was estimated to be roughly
over 1ms. This value is realistically unacceptable for a high precision motion control. In
1530 the case of a decentralized architecture this processing time is proportional to the total
lines of control code which is typically negligibly small when compared to the average
1.5ms execution time. What this implies is the combination Simulink with TwinCAT on a
conventional PC is not yet execution efficient. For architecture-2, because of the dual core
nature, we can implement the control in the DSP hence making it as fast as a de-centralized
1535 option (minus the delay in transmission of the data from the ARM core to the DSP). The
CPU clock speed, memory management has been discounted in this argument to make the
comparison less complicated.
It is also useful to note that the performance of the PC depends on the other application
processes accessing the Window’s kernel simultaneously which puts a load on the windows
1540 scheduler which needs to guarantee deadlines for the real time applications. In the case
of a centralized control architecture, along with running system specific applications, if
the PC is overloaded with other windows applications, there is a probability of the system
latency increasing beyond a desirable threshold. This is not the case for a de-centralized
architecture because the slaves will typically run a lightweight operating system. In the
1545 case of a hybrid architecture, the soft-real time applications (or in case of an RTOS, real
time applications also) can be allowed to run on the ARM core while the computationally

Investigation of EtherCAT for the Motion Building Blocks 73

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

demanding applications can be scheduled to run on the DSP. QoS for the three architectures
can be summarized (color coded) as,

Architecture-1 Architecture-2 Architecture-

(De-centralized) (Hybrid) 3(Centralized)
QoS

Security
1550 It is easier to find software that provides great security for the PC and at the same time
the PC is also more prone to security threats. This makes a centralized architecture highly
vulnerable to security risks as compared to a de-centralized architecture. There is concrete
evidence about using central master (industrial PLC) to hack into slave components and
alter their operation [27]. This leads us to believe a decentralized architecture, where only
1555 necessary data is shared with the master, maybe less prone to security attacks. Another
plausible explanation in favor of a de-centralized architecture is it is not guaranteed that
the whole system would always use one specific OEM’s equipment uniformly hence making
it less futile to target, for hackers. The hybrid architecture can be viewed essentially as a
de-centralized architecture from the security viewpoint, hence making it just as secure as
1560 the de-centralized alternative.

Architecture-1 Architecture-2 Architecture-3

(De-centralized) (Hybrid) (Centralized)
Security

Scalability
To understand scalability, it is useful to understand the bottleneck to scalability for each
of the architectures. In the case of a de-centralized control architecture, the bottleneck is
the Slave device that is acting as the master for real time communication. Increasing the
1565 number of slaves is feasible only till this device (acting as the master) gets overloaded.
Similar to this is the hybrid architecture. Due to the combination of a general purpose
processor with a DSP for each slave, the combination allows for more slaves to be cascaded
hence increasing the threshold before getting overloaded.
Contrary to this, in case of a central control architecture, it is easier to scale the
1570 system because of the use of a very powerful PC as the master(which can also be upgraded
depending on the requirement).
In all the cases, the ethercat network is not the bottleneck because of it’s performance.
Also assuming correct implementation, each additional slave device is as simple or complex
as the device’s configuration.

74 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Architecture-1 Architecture-2 Architecture-3

(De-centralized) (Hybrid) (Centralized)
Scalability

1575 Robustness

In case of a centralized control architecture, the breakdown of the PC, the backbone of
the system, will result in breakdown of the system. For critical applications, this architec-
ture will be the least robust option. In the case of a de-centralized system, the breakdown
of one or more slaves cause localized fractures (sub-systems failing) in the system while the
1580 breakdown of the master PC will result in less serious consequences as compared to the
centralized control architecture. If a slave’s ARM processor fails in the hybrid architecture
the DSP can steer the sub-system to safe operational state while the same can be said if
the DSP of the slave fails. Hence making this architecture more robust than any of the
other two architectures.

Architecture-1 Architecture-2 Architecture-3

(De-centralized) (Hybrid) (Centralized)
Robustness

1585 Diagnostics and Maintenance

Using a centralized architecture, the master PC has a wide suite of readily available
software applications that aid in easy diagnostics and maintenance of the system. With
the use of a PC, we can easily send data to cloud servers allowing for remote data analytics
and also access of the system’s parameters outside of the system (for example accessing
1590 the plant’s health over the phone using Internet of Things). The centralized architecture
is by far the most suitable option for this purpose.
In the hybrid architecture, each slave device consists of an ARM core (general puspose
processor). Though this processor is not as powerful as the PC, some of the advantages
mentioned above also applied to this architecture. The least effective architecture for the
1595 purpose of maintenance and diagnostics is the de-centralized architecture. The complexity
of the diagnostic tools is proportional to the DSP’s performance and ease of development.

Architecture-1 Architecture-2 Architecture-3

(De-centralized) (Hybrid) (Centralized)
Diagnostics and
Maintenance

Investigation of EtherCAT for the Motion Building Blocks 75

CHAPTER 5. PERFORMANCE EVALUATION AND ANALYSIS

Conclusion
Summarizing the metrics and the efficiency of the three architectures for each of the
metrics in the table 5.2 below.

Performance Met- Architecture-1 Architecture-2 Architecture-3

ric (De-centralized) (Hybrid) (Centralized)
QoS
Security
Robustness
NRE Costs
Scalability
Diagnostics and
Maintenance

Table 5.2: The three control architectures and their performance across the various metrics.
Green indicates the best of the three, while Yellow indicates a moderate performance and
Orange stands for a poor performance of the metric.

76 Investigation of EtherCAT for the Motion Building Blocks

1600 Chapter 6

Conclusion and Future Work

6.1 Conclusion

We started by designing and developing a EtherCAT master-slave system to study the

performance of EtherCAT and the bottlenecks of the system. All this with the intention to
1605 uniformly replace the two proprietary protocols at NTS-Group with EtherCAT. With this
promising EtherCAT performance, we intended to see if it is feasible to have a centralized
control system over an EtherCAT network. A centralized control architecture paves way
for very complex and highly adoptable systems. For this, we integrated Simulink with
TwinCAT at the master PC, developed a simple PI controller to run in the TwinCAT
1610 runtime environment. The controller would receive inputs from the slave, process it and
then generate actuator output to the slave. Contrary to our expectations, a central control
algorithm designed with Simulink and integrated into TwinCAT, produced delays (of over
2ms) that cannot be practically viable. The bottlenecks include master (PC) system
latency and more importantly the execution time of the model itself.
1615 With the performance analysis of a centralized system providing undesired results, we
studied the the other advantages and disadvantages of centralized v/s de-centralized control
architecture to arrive at a combined architecture that would keep the benefits but reduce
the limitations of the two architectures. This combined architecture consists of a dual core
slave in which one general purpose core will provide the processing power to run high level
1620 OS, high level applications and also handle the communications with the master and other
slaves. This combined with a specialized controller (example - DSP) for specialized tasks
will provide the necessary performance that matches a de-centralized architecture while
still maintaining the other advantages of a centralized architecture.
The possibilities to explore were unlimited but time was one constraint that was limited.
1625 In the following section, we will discuss some of the possibilities that might be interesting
for other internships or thesis opportunities.

Investigation of EtherCAT for the Motion Building Blocks 77

 CHAPTER 6. CONCLUSION AND FUTURE WORK

6.2 Future Work

The EtherCAT protocol is open sourced allowing innumerable possibilities. This chapter
is divided into two sections such that one section highlights possibilities of future work as
1630 a continuation of this project itself and the other section highlights new possibilities into
the EtherCAT domain.

6.3 Continuation of Current Project

6.3.1 Ethernet over EtherCAT (EoE)
At this moment, for this project, due to time constraints, we used PLC program to
1635 log data into the hard-disk for analysis at a later stage. Even though this works, it’s not
necessarily the most elegant solution to logging data. The data is stored locally on the
hard-disk and it is also limited by the amount of data that can written. An alternative to
this is to use Ethernet over EtherCAT to transmit data to the outside world to be stored
remotely(either local server or cloud).
1640 The ethercat frame format is derived from the ethernet frame format, hence making
them similar. Using the widespread LAN, we can send the data being collected at the
PC through TwinCAT, directly to a remote location. The biggest advantage of this can
be seen as Industrial Internet of Things (IIOT). Logging all the necessary data remotely
(hence no space constraints) can be helpful for diagnostics and optimization of the system.

1645 6.3.2 H-Bridge control

Due to time constraints, we could only simulate linear motion control using the ethercat
communication. Even though linear motion control is a good enough approximation to
conceptualize the integration of simulink and Twincat, it is at best an approximation. It
would be ideal to use a centralized control algorithm of a H-bridge and control the setup
1650 using ethercat as the communication protocol. Two possiblities are making Simulink model
and a PLC model for the same and comparing the two as a centralized control setup. My
intuition says the PLC program will generate lesser delay than the simulink model given
all other parameters are constant and same for both the models.

6.3.3 Dual port Master

1655 Having a dual port Network Interface Card (NIC) at the master (PC) should help
achieve lower/better minimum cycle times and better jitter performance. But this can be
tested in practise as a part of a smaller internship project. Also the performance limit (base
time) of the current NIC is 50µs. Getting better NIC (compatible ones) should technically
reduce the current base time.

78 Investigation of EtherCAT for the Motion Building Blocks

 CHAPTER 6. CONCLUSION AND FUTURE WORK

1660 6.3.4 Texas Instrument’s newer chipset - AM335x

With a dual core system, the AM335x can be used as an integrated EtherCAT Slave
Conroller + DSP for other operations. It is also specifically designed to provide support
for Industrial Ethernet protocols like Ethercat. Using this chipset, we can achieve greater
performance. I could not find documentation on whether this chipset supports Gigabit
1665 ethernet, but if it does, it would be a good project to explore Gigabit EtherCAT.

6.4 New possibilities

6.4.1 RTDN or UCP over EtherCAT
EtherCAT can be viewed as only the carrier of the message. The format of the carrier is
standardized while the format of the message itself can be user specific. Hence integrating
1670 UCP as a vendor-specific protocol over EtherCAT is one major development. Implementing
UCP/RTDN over EtherCAT will prevent NTS-Group’s decade of development from being
futile. Ofcourse there are Cons (proprietary, cannot use off-the-shelf components, etc ) to
this which is the primary reason for doing this thesis project in the first place.

6.4.2 New/Improved Configuration Tool

1675 One of the difficulties in the project has been to generate a new configuration file for
every project and integrate the changes in various files into the project to run every time.
This alone has cost atleast an average of half an hour a day. Even though initially I
did not foresee this, I personally think it’s a good investment in time to create our own
configuration tool that incorporates multiple projects into a configuration file and can later
1680 be selected one at a time. This is very similar to the existing NTS’s projects with different
build configurations that can be selected/deselected at any given time.
Other minor difficulties include inability of the configuration tool to incorporate struc-
tures within an array or arrays within a structure essentially making it less flexible for the
programmer. Overcoming this might be helpful in cutting the project development time.

1685 6.4.3 Profinet against EtherCAT

From the journal article [28], it can be seen that the minimum cycle time of Profinet
improves over EtherCAT as the bandwidth of ethernet connection increases and also as
the payload (or number of devices) increases. At this point in time, NTS-Group does
not communicate large payload and it is limited at tens of bytes per slave device. But in
1690 the future, if NTS-Group foresees larger payload or the more immediately realistic option,
grater number of slave devices, then investing time in development of Profinet might be
fruitful.

Investigation of EtherCAT for the Motion Building Blocks 79

 Bibliography

[1] “Internal Documents of NTS-Group.”. viii, 5

1695 [2] “Introduction to EtherCAT,” [Link]

viii, viii, 12, 18

[3] F. Essler, “EtherCAT topology variations drive system performance.” viii, 13

[4] “Moving up to Industrial Ethernet.” viii, 15

[5] L. H. D. M. J. M. S.-H. B. Jie Sheng, Sam Chung, “JAUS to EtherCAT bridge:

1700 toward real-time and deterministic joint architecture for unmanned systems,” Journal
of Control Science and Engineering, 2014. viii, 15

[6] B. Automation, “CANopen over EtherCAT,” [Link]

b110/html/ax2000-b110c [Link] = . viii, 17

[7] E. T. Group, DC (Distributed Clocks). viii, viii, x, 19, 63

[8] E. M. Control, “EtherCAT Distributed Clocks,” tech. rep. viii, viii, 20

[9] T. Instruments, “Serial Peripheral Interface C28x,” tech. rep. viii, viii, 21, 22

[10]
1705 O. E. Society, “SOES tutorial.” ix, 27

[11] Beckhoff, Matlab/Simulink. ix, 28

[12] Beckhoff, “FB1111 — EtherCAT piggyback controller board.”

[Link] b1122f [Link]. ix, 31

[13] Beckhoff, BECKHOFF AX2000-B110: CANopen over EtherCAT. ix, 34

[14] “EtherCAT Technology Group.” [Link] 10

[15] “EtherCAT.” 10

[16]
1710 “EtherCAT,” [Link] 10

80 Investigation of EtherCAT for the Motion Building Blocks

 BIBLIOGRAPHY

[17] P. A. M. Kumar and B. S. Kumar, “A Study on the Suitability of Ethernet/IP and Ether-
CAT for Industrial Time Critical Applications,” International Journal of Future Computer
and Communication, vol. 2, 2013. 11, 12

[18] H. Boterenbrood, “CANopen - high-level protocol for CAN-bus,” Master’s thesis, NIKHEF,
1715 Amsterdam, 2000. 14

[19] B. Burgers, “Automated I/O access with CoE in Orocos,” Master’s thesis, University of
Twente, 2010. 16

[20] CANopen over EtherCAT. 17

[21] Beckhoff, “TwinCAT 3 — eXtended Automation (XA),” 26

[22]
1720 M. Rostan and J. E. Stubbs, “EtherCAT enabled Advanced Control Architecture,” 2010.
28

[23] Beckhoff, BECKHOFF EtherCAT: Communication basics, EtherCAT State Machine. 33

[24] N. Lethaby and S. Prasad, Using DSP/BIOS in C2800 Applications with High Interrupt
Rates. [Link] 51

[25]
1725 “Texas Instruments F28M35H52C Concerto Microcontroller.”
[Link] 70

[26] “Texas Instruments Sitara AM335x Processors.” [Link] orte

a8/am335x/[Link]. 70

[27] “Stuxnet.” [Link] 74

[28] E. R. T. D. J. Robert, J.P. Georges, “Minimum Cycle Time Analysis of Ethernet-Based

Real-Time Protocols,” INT J COMPUT COMMUN, ISSN 1841-9836, vol. 7, pp. 743–757,
1730 2012. 79

[29] Beckhoff, Hardware Datasheets of EtherCAT Piggyback Controller Boards, 2011. 82

Investigation of EtherCAT for the Motion Building Blocks 81

 Glossary

ARM expands as Advanced RISC Machine. It is a family of processors that uses the
reduced instruction set architecture.. 70

1735 ASIC means Application Specific Integrated Circuits. In this project it refers to the
Beckhoff’s EtherCAT Slave Controller, FB1111-0141 [29]. 30, 32

BIOS means Basic Input/Output System. It is a software that describes basic functions
that the computer can do without the need to access the programs on a disk.. 82

CAN means Controller Area Network. CAN is a message based communication protocol
1740 used by devices to communicate amongst each other without necessarily the help of
a host computer.. 82

EtherCAT means ”Ethernet for Control Automation Technology”. It was invented by a

company - Beckhoff Automation. This communication protocol is suitable for both
hard and soft real-time requirements in automation technology”.. 4, 10

1745 Industry 4.0 is current technologies in the industrial automation which includes cloud
computing technologies and Internet of Things.. 2

ISR type is a NON BIOS type of an interrupt used in Texas Instruments controllers. It
is characterized by the keyword ”interrupt” in front of the interrupt name.. 51

MBB is the motion building blocks used at NTS-group. It is the propertiary motion
1750 control boards built around the Texaas Instruments’ digital signal processing unit
and consists of several digital/analog inputs/outputs.. 1, 82, 83

OSI refers to Open Systems Interconnection model, which is the communication protocol
specification standard that partitions a communication system into abstract layers
based on functionality.. 7

1755 RTDN means Real Time Data Network. This is a synchronous communication protocol
which uses the CAN hardware layer to achieve hard real time communication between
the MBB boards which is used for control.. 1, 4, 7, 9

82 Investigation of EtherCAT for the Motion Building Blocks

 Glossary

SOES Simple Open EtherCAT Slave is a software framework for the EtherCAT slave
controller from the Open EtherCAT Society.. 56

1760 SPI is ”Serial Peripheral Interface” communication. It is an asynchronous communication

protocol used to transmit/receive data.. 30

TI - Texas Instruments.. 39

UCP refers to Unit Communication Protocol which is a proprietary application layer

software used to manage the CAN communication from the master embedded PC to
1765 the slaves. Due to the nature of the PC, running Windows OS, the UCP protocol
is soft-real time in nature and hence used only to communicate from the PC to the
MBB boards.. 1, 4, 7

Investigation of EtherCAT for the Motion Building Blocks 83