Università degli Studi di Ferrara
DIPARTIMENTO DI INGEGNERIA
Corso di Laurea Magistrale in Ingegneria Meccanica
MULTI-AXIS VIBRATION CONTROL OF A SIX-AXIS MOTION PLATFORM FOR EARTHQUAKE WAVEFORM REPLICATION
Tesi di laurea di: LUDOVICO ZANELLATI
Relatore: Prof. EMILIANO MUCCHI
Correlatori:
Dr. BART PEETERS Ing. UMBERTO MUSELLA
Anno Accademico 2016-2017
___________________________________________________________________________
i
Abstract
The aim of this thesis is to allow the use of a motion simulation platform as a shaker for
earthquake replication. The challenges are linked to the whole communication chain that need
to be established between the data acquisition system and the platform. The output of the
controller for vibration control testing is normally an analog signal whereas motion simulation
platforms typically requires UDP datagrams to communicate with any external hardware, due
to internal safety checks on the signals that cannot be by passed. The connection needs to be
fast and reliable. The investigated and developed solution requires the use of an embedded PC
for Ethernet as additional layer. This PC needs to convert the analog signals in an UDP datagram
with all the information required by the platform. The effectiveness of the proposed solution is
shown replicating the scaled waveforms of the 1940 El-Centro (California) earthquake. The
results obtained promote the use of a standard off-the-shelf vibration controller with a motion
simulation platform for earthquake waveform replication.
___________________________________________________________________________
___________________________________________________________________________
iii
Contents
Abstract ................................................................................................................................................ i
Introduction ......................................................................................................................................... 1
Chapter 1 ................................................................................................................................................. 3
Equipment introduction ........................................................................................................................... 3
1.1 PLC Hardware and software ................................................................................................... 3
1.1.1 Beckhoff CX8090 ........................................................................................................... 4
1.1.2 EL3104 ............................................................................................................................ 9
1.1.3 TwinCAT 2 ................................................................................................................... 11
System Manager ............................................................................................................................ 11
PLC Control .................................................................................................................................. 11
Libraries add-ons ........................................................................................................................... 11
1.2 MOOG Platform .................................................................................................................... 13
1.2.1 System description ........................................................................................................ 13
MOOG motion platform................................................................................................................ 13
System specification ...................................................................................................................... 14
System control ............................................................................................................................... 18
1.2.2 MOOG controller .......................................................................................................... 18
PVA Setpoints ............................................................................................................................... 19
1.2.3 CONCURRENT Machine ............................................................................................. 21
1.3 UDP/IP Protocol .................................................................................................................... 23
1.3.1 UDP description ............................................................................................................ 23
1.3.2 Attributes ....................................................................................................................... 23
1.3.3 Packet structure ............................................................................................................. 24
1.3.4 Checksum computation ................................................................................................. 24
1.4 Siemens LMS SCADAS and Test.Lab.................................................................................. 25
1.4.1 Time Waveform Replication ......................................................................................... 26
___________________________________________________________________________
iv
1.4.2 Communication SCADAS-MOOG ............................................................................... 27
Chapter 2 ............................................................................................................................................... 29
PLC Program ......................................................................................................................................... 29
2.1 How the PLC executes the program ...................................................................................... 29
2.2 PLC program: conversion and sent ....................................................................................... 30
Chapter 3 ............................................................................................................................................... 35
Test ........................................................................................................................................................ 35
3.1 Test setup ............................................................................................................................... 36
3.1.1 Communication chain setup .............................................................................................. 36
Configuration of host PC ............................................................................................................... 36
Configuration of the BeckHoff CX8090 ....................................................................................... 36
Configuration of Conccurrent Simulation Workbench .................................................................. 41
3.1.2 MOOG Motion Platform setup .......................................................................................... 47
SCADAS and DC Accelerometers ................................................................................................ 47
BeckHoff CX8090 ......................................................................................................................... 51
3.2 Preliminary Tests ................................................................................................................... 52
3.3 Time Waveform Replication ................................................................................................. 53
3.3.1 TWR MATLAB code .................................................................................................... 54
3.4 TWR Test: El Centro target ................................................................................................... 59
3.4.1 System Identification ..................................................................................................... 61
3.4.2 El Centro TWR test with scaling factor of 1 ................................................................. 64
3.4.3 El Centro TWR test with scaling factor of 2 ................................................................. 68
Chapter 4 ............................................................................................................................................... 71
Conclusions ........................................................................................................................................... 71
Bibliography ...................................................................................................................................... 73
Introduction
___________________________________________________________________________
1
Introduction
Nowadays a wide range of exciters is available to run environmental tests. These tests are
controlled closed-loop applications. For vibration control tests, it is common to use shakers
excitation.
MIMO (multiple input multiple output) vibration control testing requires fast and reliable
connections between the data acquisition system and the exciter. Furthermore, these tests need
a high communication speed and reliability.
For the test a Time Waveform Replication (TWR) approach has been chosen. This approach
consists of an offline iterative learning control and the challenge of this application is to
replicate a target signal in time domain that the unit under test is submitted to.
The target chosen for the test is the 1940 El Centro earthquake [1] evaluated with different
scaling factor. Furthermore, this target has been chosen in accordance with the new study about
the earthquake simulator of the university of Pavia[2]. With this type of excitation and with
exciters used during this thesis work, the challenge is to understand the behavior of the structure
and the non-structural parts submitted to the shock.
As mentioned before, the exciters usually used for this test are shaker, but other kind of exciter
can be used.
The exciter used for this study is a motion simulation platform and the platform chosen for this
study is the MOOG Motion platform MB-E-6DOF/24/1800KG [3]. Most specifically this
platform is a six degrees of freedom motion platform and it is moved by six electro mechanic
actuators.
The main focus of this thesis is to allow an effective and stable communication between an off-
the-self controller and a motion simulation platform.
The MOOG Motion platform is usually suitable for motion simulation and uses a Motion
Cueing model [4] through which it is possible to perform the so-called simulation mode, such
as flight simulation, drive simulation and motorcycle simulation. The six DOFs motion
platforms are widely used in motion simulation, for which the aim is to use the platform to
replicate the motion of an object in the three-dimensional space.
The MOOG motion platform requires an UDP datagram [5] to communicate with the external
hardware. Its payload contains different information, depending on the chosen mode for
controlling the platform. The payload of the UDP datagram can be, for instance, the
Introduction
___________________________________________________________________________
2
displacement information for each degree of freedom (PVA Control). In this configuration it is
possible to control different degrees of freedom simultaneously.
Theoretically, the only step to combine this type of hardware with a data acquisition system and
a vibration control software is to translate the drives in actuators displacements required by the
motion platform. However, additional layers to the communication chain bring practical
challenges.
As mentioned before, allowing the analog output of the SCADAS to be recognized by the
platform which, as stated before, requires an UDP datagram. The communication requires an
additional layer that converts the analog signal to its digital representation and forwards the
information via Ethernet to the MOOG Motion platform.
A very important preliminary study has been done to understand the potential effect of
considering the platform as a shaker for vibrational testing.
A secondary concern is the performances of the MOOG Motion Platform because it is not
possible to determine them beforehand thus the need to verify them. Therefore, an experimental
testing campaign has been made with the aim of understanding the platform's limitations.
The tests have proven good performances of the platform with this configuration. The target
has been replicated with successfully and the additional layer has not given any sort
communication problem.
Cap. 1: Equipment introduction
___________________________________________________________________________
3
Chapter 1
Equipment introduction
In this chapter the specification of hardware and software used for this purpose will be
introduced. The first part is devoted to the main part of this application, the PLC make by
Beckhoff, the CX8090, and the modules EL3104.
The second part is focused about MOOG Platform, that is another important part of the
purpose, and Concurrent Machine with Simulation Workbench, that include the motion
hardware and the software to communicate with them.
The third part concerns the type of communication between these parts of the communication
chain.
The last part is focused about SCADAS and TestLab, a Siemens hardware and software that
will control the platform with a feedback.
1.1 PLC Hardware and software
The main topic of this paragraph is the specification of hardware used to convert signal from
analog to digital and to send it via UDP, the CX8090, and the software to program it.
CX8090 [6] is an embedded PC made by Beckhoff that it uses two plug-in modules to read
analog input from -10V to +10V. The communication between the embedded PC and extra
modules is established by EtherCAT, a protocol of communication of Beckhoff, which is the
faster communication protocol for PLC.
Fieldbus modules used to read analog input are two EL3104 modules[7].
Cap. 1: Equipment introduction
___________________________________________________________________________
4
1.1.1 Beckhoff CX8090
This PLC [6] is a device of the family of programmable controllers with 32-bit ARM-based
CPU, which can be used for the of PLC programs for higher level fieldbus systems. The device
includes 32-bit processors that are more efficient than the 16-bit processors used by the others
PLC. The PC automatically recognizes which terminal system is connected with (relates to)
integrated EtherCAT terminal (E-bus) and it gaves rise to further option connections with the
integration of further bus system such as RT-Ethernet, EAP, ModbusTCP, TCP/IP, UDP/IP and
Web Services.
CX 8090 device is programmed and commissioned via Ethernet interface, which can also be
used for the connection of the control system with a regular network. The other connections on
the lower plug level are fieldbus-specific.
Under the cover at the upper housing level there is an exchangeable button cell for date and
time, a set of DIP switch for setting functions modes, a slot for Micro-SD Falsh memory card
and a type B USB connection.
Microsoft Windows CE is used as the operating system and in absence of a monitor port,
operating system and its virtual display can only be accessed via the network. The TwinCAT
software is used for system configuration and programming of the PLC functionality with a
preinstalled TwinCAT PLC runtime environment. These functionalities and user data files are
stored on the Mirco-SD Flash card. The CX8090 controlled is programmed according to IEC
61131-3 standard, source[8].
The configuration is carried out using TwinCAT, the fieldbus interface and the real-time clock
can be configurated and parameterized via the System Manager, which can read all connected
devices and Bus terminals.
Cap. 1: Equipment introduction
___________________________________________________________________________
5
Figure 1 – CX8090 overview, source [6]
Cap. 1: Equipment introduction
___________________________________________________________________________
6
Table 1– CX8090 System specification, source [6]
Technical data CX8090
Processor 32 bit, 400 MHz, ARM9
Internal main memory 64 MB RAM (internal, not
extendable)
Operating system Microsoft Windows CE 6.0
Web-based Management yes
Flash memory MicroSD card (ATP) 512 MB
(optionally 1, 2, 4 GB)
Interfaces
1 x USB device (behind the front
panel)
1 x RJ45 Ethernet, 10/100 Mbit/s
2 x RJ45 switched, 100 Mbit/s
Protocols Realtime-Ethernet, ADS,
ModbusTCP, TCP/IP, UDP/IP
Interface for I/O terminals K-bus or E-bus, automatic detection
Process data at K-Bus max. 2 kByte input data
max. 2 kByte output data
Diagnostics LED 1 x power, 1 x TC status, 2 x bus
status
Clock
Internal clock with battery backup
(RTC) for time and
date (battery replaceable)
Operating system Microsoft Windows CE
Control software TwinCAT PLC runtime (from
version 2.11 R3)
Programming TwinCAT PLC
Programming languages IEC 61131-3
Cap. 1: Equipment introduction
___________________________________________________________________________
7
Online Change Yes
Up/download code Yes/Yes
Power supply 24 VDC (-15 %/+20 %)
UPS 1-second UPS
Power supply for I/O terminals (K-
Bus or E-Bus) 2 A max.
Power contact current load 10 A max.
Max. power loss 3,0 W (including system interfaces)
Dielectric strength 500 V (supply / internal electronics)
Dimensions (W x H x D) 64 mm x 100 mm x 73 mm
Weight approx. 180 g
Permissible ambient temperature
during operation 0 °C to +55 °C
Permissible ambient temperature
during storage -25 °C to +85 °C
Relative humidity 95 % no condensation
Vibration / shock resistance conforms to EN 60068-2-6 / EN
60068-2-27
EMC immunity/emission conforms to EN 61000-6-2 / EN
61000-6-4
Protection class IP20
Cap. 1: Equipment introduction
___________________________________________________________________________
8
Table 2– CX8090 Ethernet X001 specification, source [6]
System data X001 Ethernet (CX8090)
Transmission medium 4 x 2 twisted pair copper cable
category 5 (100 Mbaud)
Cable length 100 m from switch to CX8090
Data transfer rate 10/100 Mbaud
Topology star wiring
Protocols
all non- real-time-capable protocols
that are based on TCP or UDP and
require no real-time extension
Table 3 – CX8090 Ethernet X101/102 specification, source [6]
System data X101/102 Ethernet (CX8090) real-time
interface
Transmission medium
4 x 2 twisted pair copper cable
category 5 (100
Mbaud)
Cable length 100 m from switch to CX8090
Data transfer rate 10/100 Mbaud
Topology Star-form cabling, line topology
Protocols (real-time) RT-Ethernet, EAP
(publisher/subscriber)
Protocols (non-real-time)
all non-real-time-capable protocols
that are based on TCP or UDP and
require no real-time extension
Cap. 1: Equipment introduction
___________________________________________________________________________
9
1.1.2 EL3104
The EL3104 [7] analog input terminals measure input voltage from -10V to +10V. The voltage
is digitized to a resolution of 16 bits, and is transmitted, electrically isolated, to a higher-level
automation device. The input channels of this EtherCAT Terminal are differential inputs and
the common reference ground is connected to the 0V power contact. There are 4 input channels
for module and two input modules are used for this application.
Figure 2 – EL3104 overview, source [7]
Figure 3 – EL3104 Measurement range, source [7]
Cap. 1: Equipment introduction
___________________________________________________________________________
10
Table 4 – EL3104 System specification, source [7]
Technical data EL3104
Analog inputs 4 (differential)
Signal voltage -10 V ... +10 V
Distributed Clocks yes
Distributed Clocks precision 200 kΩ
Input filter limit frequency 5 kHz
Common mode voltage Ucm max. 35 V (referring to power
contact)
Resolution 16 bit (including sign)
Measuring error (full measuring
range)
< ± 0.3% (at 0 °C ... +55 °C, relative
to the full scale value)
< ± 0.5% (when the extended
temperature range is used)
Supply voltage for electronic via the E-bus
Electrical isolation 500 V (E-bus/field voltage)
Bit width of the process image
(default setting)
Inputs: 4 x 16 bit;
Status: 4 x 8 bit
Weight approx. 65 g
Permissible ambient temperature
range during operation
-25°C ... +60°C (extended
temperature range)
Permissible relative humidity 95%, no condensation
Dimensions (W x H x D) approx. 15 mm x 100 mm x 70 mm
(width aligned: 12 mm)
Vibration/shock resistance according to EN 60068-2-6/EN
60068-2-27
Cap. 1: Equipment introduction
___________________________________________________________________________
11
1.1.3 TwinCAT 2
TwinCAT 2 [9] is a development environment of Beckhoff for their PLC. The main tools used
to program and to configure the embedded PC are PLC Control and System Manager.
System Manager
System Manager [13] is a TwinCAT tool used to configure the hardware setting and to choose
and set CX8090 system parameters. In it is allocated the main hardware part, such as PLC CPU,
PLC system and EtherCAT devices. All of these devices have parameters that must be set for a
correct work during the operational life. Furthermore, in this environment has been attached the
PLC program, or rather the list of written command that the PLC performs while working. It is
also possible to switch the PLC mode in two different state: config mode or run mode. In config
mode, all parameters, the libraries and the program are set and saved in the PLC storage. In run
mode, the PLC executes the program.
PLC Control
PLC Control [10] is a tool used to write in structured text, or in the other languages included in
the standard IEC 61131[8], that will be saved and executed from the PLC. The programming is
supported by bookstore that includes function and add-ons of the PLC used.
It is also possible with this tool to create a boot project. Boot project is a specific PLC program
that it is stored in PLC memory. When PLC is turned on, it performs the project and it has all
the libraries and add-ons stored in the memory, which mean that it doesn’t need to be configured
every time that is turned on and the routine coded, the setup of the machine and the libraries do
not need to be loaded again.
Libraries add-ons
For this project standard libraries of TwinCAT 2 and CX8090 are not enough, because it is
necessary to communicate with a host machine via UDP and with these two libraries it is not
possible. To create a UDP socket and to send a data package via UDP it is necessary to use a
specific package of TwinCAT, called TwinCAT TCP Server for Windows CE platforms.
Cap. 1: Equipment introduction
___________________________________________________________________________
12
This package contains the libraries necessary to create a UDP socket, to send a message via
UDP socket and to close a UDP socket. Without this package, these operations are not possible.
All of these operations are extendable to the TCP communication protocol if needed.
Cap. 1: Equipment introduction
___________________________________________________________________________
13
1.2 MOOG Platform
This paragraph is concerns the specification of the MOOG motion platform as well as the
systems that drive and control the displacement of 6 DOFs. The system is composed from
MOOG motion platform, MOOG controller, which controls the movement of the platform, and
Concurrent Machine, which controls and sends the message to MOOG controller with the
information to move the platform.
The MOOG Platform is a steward platform used for simulation purpose, such as driving
simulation or fly simulation. The challenge is to convert it as shaker with one additional layer.
1.2.1 System description
The components of the system that moves the platform control different communication
function and they use different software to create, to send and to receive information between
the machines.
MOOG motion platform
MB-E-6DOF/24/1800KG [3] is the platform that it has been made by MOOG. This platform is
a six DOFs moved from six electric actuators with different stroke for each degree of freedom.
Its gross moving payload is 1800 kg. The platform has six degrees of freedom: Surge (Tx),
Sway (Ty), Heave (Tz), Roll (Rx), Pitch (Ry) and Yaw (Rz). It is possible to control each degree
of freedom simultaneously.
Cap. 1: Equipment introduction
___________________________________________________________________________
14
Figure 4 -MOOG steward platform overview [3]
System specification
The installation of the platform must take place with specified requirements and must follow a
procedure written by MOOG, source [9].
The dimension of the platform has been reported in Table 5/Table 6, source [3], and will be
discussed with the support of Figure 5/Figure 6, source [3].
The maximum parameters reachable to platform, most specifically position, velocity and
acceleration, are written in Table 7/Table 8/Table 9, source [3].
Cap. 1: Equipment introduction
___________________________________________________________________________
15
Table 5 – MOOG floor frame
Item Value Remark
Depth 2466 mm A
Width 2848 mm B
Wrapping circle ~3300 mm C
Figure 5 – MOOG dimension floor frame[3]
Cap. 1: Equipment introduction
___________________________________________________________________________
16
Table 6 – MOOG upper frame
Item Value Remark
Depth 2018 mm A
Width 2264 mm B
Wrapping circle ~2700 mm C
Figure 6 – MOOG dimension upper frame
Cap. 1: Equipment introduction
___________________________________________________________________________
17
Table 7 – MOOG 6 DOFs excursion
Platform excursions – Single DOF Value
Surge (Tx) +0.56 m
-0.44 m
Sway (Ty) +0.46 m
-0.46 m
Heave (Tz) +0.38 m
-0.38 m
Roll (Rx) +22 deg
-22 deg
Pitch (Ry) +25 deg
-22 deg
Yaw (Rz) +24 deg
-24 deg
Table 8– MOOG 6 DOFs velocities (measured with sine wave at frequency 0.5Hz)
Platform velocities – Single DOF Value
Surge (Tx) ±0.7 m/s
Sway (Ty) ±0.7 m/s
Heave (Tz) ±0.56 m/s
Roll (Rx) ±33 deg/s
Pitch (Ry) ±34 deg/s
Yaw (Rz) ±35 deg/s
Cap. 1: Equipment introduction
___________________________________________________________________________
18
Table 9– MOOG 6 DOFs accelerations (Measured with sine wave (frequency 3 Hz); peak
acceleration measured at drive current saturation point)
Platform accelerations – Single DOF Value
Surge (Tx) ±6.5 m/s2
Sway (Ty) ±6.5 m/s2
Heave (Tz) ±9.0 m/s2
Roll (Rx) ±220 deg/s2
Pitch (Ry) ±220 deg/s2
Yaw (Rz) ±360 deg/s2
System control
In the lower part of the platform, in the middle of the actuators attach, there is the cabinet. Inside
it there are the hardware that controls every actuator. The hardware is composed with a servo
drive labels and it communicates via EtherCAT with the MOOG Controller.
1.2.2 MOOG controller
The MOOG Controller [4] is a real-time computer and communicates with the hardware in the
cabinet to control the displacement and the status of the Moog Motion platform.
The Real-time software has several functionalities. It can run in either simulation mode or test
mode. In simulation mode, the application responds to the run command sent via host interface
and in test mode it responds to the run command from Moog Explorer or one of the other
applications of the Moog Test suite.
The real-time software of MOOG communicates with the external hardware via UDP data
package, sent by a host PC. The MOOG controller receives the information with a specific
payload of the UDP data package that is called HOST_TO_MOTION (Figure 7). With an
internal algorithm it recognizes the motion model used and converts the information in
movement of the MOOG Motion platform. It is possible to control the platform with three
different models. The first is the Motion Cueing model that is suitable for the simulation
application, such as driving simulator, motorcycle simulator or flight simulator. It is based on
Cap. 1: Equipment introduction
___________________________________________________________________________
19
the information of a vehicle dynamics model. The second one, the PVA (Position, Velocity and
Acceleration) Model, reads the displacement of each degrees of freedom separately and with
this model it is possible to control every displacement of the platform simultaneously. The third
model is called Special Effect Mode, and it is possible to send a special kind of signal (ex. sine
wave, noise, etc…) to the MOOG Platform. Another important information in the UDP data
package regards the status of the machine.
Furthermore, the MOOG Controller sends a package that is called MOTION_TO_HOST. This
package contains the information about the status of the machine and the information about
position, velocity and acceleration of each degree of freedom.
Figure 7 – MOOG Controller model execution
PVA Platform Control is the model used to control the platform by the SCADAS and it will be
discussed below.
PVA Setpoints
PVA is the acronyms of Position, Velocity and Acceleration. With this mode, the platform
receives via host the displacement of each degree of freedom. Their movement concerns the
Cap. 1: Equipment introduction
___________________________________________________________________________
20
centre of the platform. The information is received with a special data in the payload of the
UDP package, where the coordinates of the set points are sent with a specific order. These
information regards Surge (Tx), Sway (Ty), Heave (Tz), Roll (Rx), Pitch (Ry) and Yaw (Rz).
The minimum frequency of receipt must be 60 Hz and the maximum frequency of platform
movement is 20 Hz.
In order to perform the aim of this study, this model has been chosen to control the MOOG
Motion platform.
Cap. 1: Equipment introduction
___________________________________________________________________________
21
1.2.3 CONCURRENT Machine
CONCURRENT Machine (CCUR Machine), or most specifically Simulation Workbench [15],
is a software of Concurrent installed on the iHawk host computer. These components are made
by Concurrent.
Simulation Workbench (SimWB) is a real-time software where runs a Simulink real-time
model. It sends to the MOOG Controller via UDP the data package required by it. The MOOG
Controller has been set to simulation mode in order to establish a communication between the
MOOG Controller and Simulation Workbench.
A specific block has been used in Simulink in order to create analog points in SimWB. The
analog points are data inputs or data outputs that SimWB uses to communicate with the other
host machines. A specific SimWB ML toolkit is required in order to load these block in the
Simulink library and to load the Simulink project in SimWB.
There are two different type of analog points:
• FromRTDBc: this Simulink block defines the input in SimWB received from a host
machine (Figure 8);
• ToRTDBc: this Simulink block define the output in SimWB sent to a host machine
(Figure 8).
Figure 8 – RTDB Simulink blocks
A Simulink project is made using these blocks that will run in the SimWB.
The Simulink model is made in a host PC and loaded on the storage of the Concurrent Machine
with a specific toolkit of MATLAB.
Cap. 1: Equipment introduction
___________________________________________________________________________
22
In the Concurrent Machine, a RTDB project is used and it is made in SimWB. In this project
the UDP messages sent and received by the CCUR Machine are created. This step is very
important because the fields of the message are set through the I/O Mapping
The input message is set through the structure of the datagram, the host machine that sent the
data package, the transmission protocol and the bit order. The analog points are then associated
at the data of the message received. The same step is executed for the output message that will
be sent to the platform.
The test session is defined thereafter. The Simulink project is loaded and associated to the
RTDB project. This step is fundamental because all the parameters of the simulation are set,
such as time simulation of the Simulink project, the log session, the status of the platform while
the PVA parameters sent to the platform are monitored, such as the displacement of every
degree of freedom.
It isn’t possible to remove this machine between PLC and MOOG Motion platform because the
latter requires a complex message to control it. Indeed, it is not possible to generate all data
requires from the platform by the PLC.
Cap. 1: Equipment introduction
___________________________________________________________________________
23
1.3 UDP/IP Protocol
UDP [5] is the acronyms of User Datagram Protocol and it is one kind of communication
protocol of the Internet protocol suite (IP). With this kind of protocol, computer applications
can send messages to other hosts on an Internet Protocol network. Prior communications are
not required to set up transmission channels or data paths.
1.3.1 UDP description
UDP uses a simple connectionless transmission model and it provides checksums for data
integrity and port numbers for addressing different function at the source and destination of the
datagram. There is not guarantee of delivery, ordering or duplicate protection and this protocol
thus exposes user’s program to any unreliability of the network.
UDP is a lost protocol of communication. It is preferable in time-sensitive application because
dropping packets is better than waiting for delay package, which may not be possible in real-
time applications.
UDP applications must generally be willing to accept some loss, error or duplication and it is a
protocol lacking reliability. In real-time applications loss of packets is not usually a fatal
problem.
1.3.2 Attributes
This kind of datagram is a minimal message-oriented transport layer protocol. UDP provides
no guarantees to the upper layer protocol for message delivery and the UDP layer retains no
state of UDP messages once sent. For this reason, UDP sometimes is referred to as Unreliable
Datagram Protocol. The lack of retransmissions delays makes it suitable for real-time
applications.
These applications use datagram sockets to establish host-to-host communications. An
application binds a socket to its endpoint of data transmission, which is a combination of an IP
address and a service port. UDP provides application multiplexing (via port number) and
integrity verification (via checksum) of the header and payload, source [5].
Cap. 1: Equipment introduction
___________________________________________________________________________
24
1.3.3 Packet structure
UDP header consists of 4 fields, each of which is 2 bytes.
• Source port number: this field identifies the sender’s port when meaningful and should
be assumed to be the port to reply to if needed.;
• Destination port number: this field defines the receiver’s port and it is required;
• Length: a field that specifies the length in bytes of the UDP header and UDP data;
• Checksum: this field may be used for error-checking of the header and data.
Figure 9 – UDP header [5]
Source port and checksum are optional in IPv4.
1.3.4 Checksum computation
The method used to compute the checksum is defined in RFC 768. All 16-bit words are summed
using one’s complement arithmetic. Add the 16-bit values up, each time is carry-out (17th bit)
is produced, swing that bit around and add it back into the least significant bit, source [5].
When UDP runs on IPv4, the checksum is computed using a pseudo header that contains some
information of the real IPv4 header.
The source and destination addresses are those in the IPv4 header. The protocol is UDP, the
UDP length field is the length of header and data filed is for the transmitted data.
Figure 10 – IPv4 pseudo header [5]
Cap. 1: Equipment introduction
___________________________________________________________________________
25
1.4 Siemens LMS SCADAS and Test.Lab
Siemens Simcenter LMS Test.Lab [11] and SCADAS [11] are a package made by Siemens
Industry Software.
SCADAS is a hardware made by LMS, which can be used to do all testing requirements. The
SCADAS suite of data acquisition system provides data qualities and formats for all types of
noise, vibration and durability measurements in the laboratory or in the field. The integration
with LMS Test.Lab gives another important support to accelerate measurements setups and data
acquisitions.
The LMS SCADAS offers hardware solutions for front-end signal conditioning and data
acquisition. There are different types of SCADAS each of which is suitable for various
applications. SCADAS family is divided in two main sub-families: SCADAS Portable and
SCADAS Lab.
In both versions is possible to change modules of acquirement data. There are a lot of modules,
each one providing integrated signal conditioning and supporting a variety of transducers, such
as strain gauges and accelerometers, which allows to capture a broad range of a sensor in a
single test run. LMS SCADAS provides high precision data including state-of-the-art
capabilities for limiting harmonic distortion and best-in-class inter-channel specifications with
a phase match better than 0.2˚ at a frequency of 10 kHz.
For this application, a SCADAS Mobile has been used. Most specifically a SCADAS with six
±10 V output, that are used to drive the platform, and eight input that are linked to the
accelerometers located on the platform.
Test:lab is a software that allows to use to the best the SCADAS.
Test.Lab is a suite that allows interface with SCADAS to do all testing requirements. It is
possible to find a very large choice of tool for each application.
Most specifically, LMS Test.Lab Environmental, provides with a powerful, high-speed multi-
channel vibration control system for dynamic environmental testing.
The solution is easy to use for routine random, shock, sine and combined modes testing and has
everything is needed for state-of-the art control and extensive data analysis.
It is designed for parallel acquisition and online reduction of vibration channel during random
or sine closed-loop vibration control testing.
Cap. 1: Equipment introduction
___________________________________________________________________________
26
Furthermore, LMS Test.Lab MIMO Random Control is an advanced solution for vibration
testing and closing-loop multi shaker control that implements a fast and accurate control
algorithm.
It gives a support to control multiple shakers and measurements channels simultaneously for
multiple input multiple output closed loop random control. The environmental control options
are multiple, and they include the standard random, swept sine, tacked sine dwell, shock testing,
waveform replay and combined test modes for single output control. It provides to define and
control a random excitation that matches a predefined PSD profile.
With these features, the software provides facilities for qualifying test subjects on multi-shaker
installation and gives insight into its dynamic. Additionally, it helps with the online data
acquisition and visualization of measured and processed data.
Another tool of Test.Lab is Time Waveform Replication, which will be discussed more in the
next subparagraph.
1.4.1 Time Waveform Replication
As already mentioned, Time Waveform Replication (TWR) is a testing practice and its feature
is to replicate a real target, that the user can define in a specific system, in a dyno run or a
shaker. The interface of the software is the same of the other Test.Lab tools.
Time waveform replication (TWR) is the current state of art for drive file generation. This
procedure is used to simulate in a laboratory the real-life condition of the system and it is an
offline iterative learning control method. This test is called “service load simulation” and a
successful test is performed with an accurate replication of the service load. This is possible if
the actuator drive signals are generated with the “drive file generation” procedure.
After making the setup in the laboratory and set the SCADAS, the first step is the system
identification. It is possible to choose from a list of estimators and a list of signals to do it. It is
usually done with a specific type of signal with a less amplitude than the target signal definition,
so that eventual damage to the structures that will be tested is avoided.
After the system identification, the following step is to create the drive to perform the target
chosen. The drives are generated using the transfer function acquired in the system
identification.
Cap. 1: Equipment introduction
___________________________________________________________________________
27
Following the drive file generation in the system verification, the parameters in the TWR Drive
Tuning are set, such as the max number of iteration, the type of convergence and the drive gain
ratio for the beginning of the test.
1.4.2 Communication SCADAS-MOOG
As mentioned above, the output of the SCADAS is a voltage, that is an analog signal. The
MOOG Platform requires an UDP package with a specific payload. The challenge of this thesis
is to create a communication chain to control the platform with the SCADAS. An additional
layer is required, i.e. the PLC BeckHoff CX8090. Another important step is to evaluate the
effect of an additional layer in the communication chain [12].
The first component of the chain is the SCADAS. It gives six output voltages and send them to
the BeckHoff CX8090 with six BNC cable. The PLC converts, with an internal script, the
voltages in displacement for each drive channel, such as Tx, Ty, Tz, Rx, Ry and Rz. After the
conversion, it makes the payload of an UDP data package with a specific bytes order and send
it via UDP to the Concurrent real time machine. The CCUR, that receives the data package
from the PLC, takes the data package and, with a script Simulink, makes a specific UDP data
package that required by the platform. This package contains the displacement for each degree
of freedom and the status of the machine.
The full communication chain is depicted in Figure 11.
Cap. 1: Equipment introduction
___________________________________________________________________________
28
Figure 11 – Communication Chain
Cap. 2: PLC Program
___________________________________________________________________________
29
Chapter 2
PLC Program
This section will discuss the methodology and the structure of the program that run in the PLC.
The PLC is an embedded PC and a program is needed to make it work. This program contains
the configuration about the commands that will execute and the information about the plug-in
modules that are attached to the PLC.
As already mentioned the PLC Beckhoff CX8090 is integrated with the analog input modules
EL3104.
2.1 How the PLC executes the program
The logic of control of the PLC (programmable logic controller) is based on the concept of
cyclic execution.
Windows CE, a real-time edition of Windows, and TwinCAT 2, which has the scope to execute
the main operation stored on the memory of the PC, are preinstalled in the PLC
The project, which is stored on the memory of the PLC (Figure 12), needs files originated in
the programming phase. These files contain the POU (program organization unit) and are
divided in subparts. The most important part is the main program and is composed by the list
of the commands that the PLC executes. Another part is about the function generated in the
main program. The last part is about the task priority and the library needed to execute some
special function, such as the communication via UDP, the state of the plc, etc… This part of
the project is generated from the PLC Control [10] tool of TwinCAT 2 installed on a host PC.
Cap. 2: PLC Program
___________________________________________________________________________
30
The most important part regards the task priority, because the cyclic execution of all the
functions in the project is based at this execution time. Indeed, this time gives to the PLC an
important information about the maximum time of execution of the program. If the plc for any
problem is not able to execute it in the maximum time, the system automatically goes on error
state.
Another POU part is related to the configuration of the PLC. Indeed, it needs the configuration
of the plug-in modules and, most specifically, at which part of the program relates the physical
I/O attached to it. This part is generated from the System Manager [13] tool on a host PC.
Figure 12 – PLC scheme
2.2 PLC program: conversion and sent
The purpose of the program that runs on the plc is to convert an analog signal into digital signal
and to multiply it for a gain value, each for degrees of freedom. After the multiplication, the
digital signals are displacements and they are filled in a vector that will be they payload of the
UDP data package sent to the Concurrent real-time machine.
These operations must be written in different parts of the program. The sequence of the
operations is showed in Figure 13. Before doing these operations, some preliminary operation
must be performed concerning the UPD socket, since an UDP socket is needed to send an UPD
data package.
Cap. 2: PLC Program
___________________________________________________________________________
31
Figure 13 – Main step of the program
In the main program, the first operation is closing all the opened socket when it is executed,
namely when the PLC is turned on. After this operation, the PLC begins a loop of operations
included in a subprogram and they finish when the socket is closed from the host PC.
This subprogram is divided in cases, each of them called from a specific variable. It starts with
the creation of an UDP socket. In this field, the PLC creates a socket with a specific IP address
and a specific port with the function FB_SocketUdpCreate (Figure 14). The output of this
function is used to switch to the next case and the information about the destination of the socket
is the information about IP address and port of the Concurrent Machine.
Cap. 2: PLC Program
___________________________________________________________________________
32
Figure 14 – Function block creation UDP socket, source [14]
After the creation of the socket, the program switches to the next case and it uses the variables
in output from the creation of the socket to activate the next case
The first operation of the second case is to read and convert the input from the plugin modules
that read the voltages in input with a high resolution and a high frequency ratio.
Most specifically the voltages are read, from -10V to +10V, by the module and converted them
in Integer (int32). Subsequently, the voltages are multiplied for a gain value and they are
converted in displacement that the platform can read. The format of the new variables are Real
(float) and the vector is made with the displacement of the six degree of freedom (Figure 15).
Figure 15 – Field of the message
The output of this function is now available to be taken from the next function, the shipping of
the message via UDP.
Cap. 2: PLC Program
___________________________________________________________________________
33
The function block FB_SocketUdpSendTo (Figure 16) is now ready to be used. It takes in input
the variables generated by the creation of the socket in the first case, the message with the field
that has just made and the information about IP address and port of the destination of the UDP
message, in this purpose the CCUR Machine. Now the function is ready to send the message at
the CCUR and the shipping frequency is set in the task priority.
Figure 16 - Function block sent UDP socket, source [14]
As already mentioned, the task is fundamental for a PLC logic. If it is not set, the PLC can’t
run the control program.
Now the PLC is ready to execute in loop the case of conversion and to send message to the
CCUR machine (Figure 17).
After making the program, it is loaded with the setup of the machine in the storage as boot
project. This function is very useful because when the plc is turned on, it is ready to work, and
the program doesn’t need to be loaded again.
Now the PLC is ready to be connected with the CCUR machine and to communicate with it.
Cap. 2: PLC Program
___________________________________________________________________________
34
Figure 17 – Loop execution cycle
Cap. 3: Test
___________________________________________________________________________
35
Chapter 3
Test
In order to validate if the conversion of the platform has been successfully done, a very
important part of this thesis is about the test with the MOOG Platform. In this chapter the
preparation of each hardware, from the PLC to the MOOG platform, and the setup of the test
will be discussed.
The first part of this chapter is devoted to the setup of the communication chain and to the
problem of its setting.
The application chosen to drive the platform with the SCADAS is Time Waveform Replication
[11], an application of Test.Lab Environmental.
A MATLAB code with an application of Time Waveform Replication has been made. It is
important to understand the parameters that should be used in order to understand the right
evaluation of the error and with this code it is possible. This script simulates a two degrees of
freedom system and corrects the drive to reach a response from the system equal to the target
chosen.
As far as the test campaigns concerned, the target chosen to replicate for the test with the
MOOG Motion platform is the 1940 El Centro earthquake [1][16]. It has been evaluated with
different scaling factors and with different metrics error in TWR for a different feedback by the
platform.
Cap. 3: Test
___________________________________________________________________________
36
3.1 Test setup
3.1.1 Communication chain setup
The hardware of the communication chain must be set with specific parameters and it is
necessary to follow a specific procedure.
Configuration of host PC
To communicate with BeckHoff CX8090 and Concurrent Real Time Machine it is necessary to
set the IPv4 of the PC in the same domain. It is possible to change it from the control panel in
the propriety of the ethernet adapter.
To follow this operation, it is necessary to open Network and Sharing Center, Change adapter
setting. In the proprieties of LAN/Ethernet adapter setting it is possible to change the IP in
internet protocol IPv4, proprieties (Figure 18).
Figure 18 – Set the IP address of the PC
Configuration of the BeckHoff CX8090
TwinCAT System Manager
• Connect the PLC
Cap. 3: Test
___________________________________________________________________________
37
If a new project is created in Twincat System Manager, afther the selection of Choose
Target, Search (Ethernet) the address ifno is set to IP address (Option 2 in Figure 19)
and the Broadcast Search is ready to begin. The CX8090 will appear in the list of
device and is selected. The state of the connection is visible on the right corner of the
System Manager (Figure 20).
Figure 19 – Add device in System Manager
Figure 20 – State connection and device connected
• Scan I/O
After adding the PLC to working device, the PLC must be switched to Config Mode
(Figure 21) and it will restart in Configuration Mode (Blue led in the case of it).
Figure 21 – System Manager switch to config mode
Cap. 3: Test
___________________________________________________________________________
38
To scan the device attached to it, in the tree of configuration, in I/O device after the scan
of it (Figure 22), the configuration will be showed (Figure 23) and Term 2 and Term 3
are the devices connected as Analog Input
Figure 22 – Scan device
Figure 23 – Box connected to PLC
• Append PLC project and link the variables
The PLC program must be attached in order to execute the script. Namely, it is necessary
because there are all the information and the commands that it will execute during the
working life. The variables of the PLC will be loaded with this operation. It is built in
the PLC Control and is created an image of it that it will be imported in the System
Manager (Figure 24).
Cap. 3: Test
___________________________________________________________________________
39
Figure 24 – Add PLC program
This project creates input variables that must be linked to the hardware input in the
modules of the PLC. With this operation, the PLC recognizes in real time which analog
input is reading and modifies the linked variables (Figure 25).
Figure 25 – Linked I/O of PLC with I/O of the program
Now the PLC is ready to the Mapping (1 in Figure 26) and to go to Run Mode (2 in
Figure 26).
The next step is to load the PLC script through the PLC Control.
Cap. 3: Test
___________________________________________________________________________
40
Figure 26 – Mapping and Run Mode
TwinCAT PLC Control
The program attached in the System Manager is opened in the PLC Control. It contains the
operation and the library necessary for the PLC in its working life.
In the Online function, after Login (3 in Figure 27), the program is downloaded with Download
(4 in Figure 27) and a boot project is created with Create Bootproject (5 in Figure 27). Now the
plc is ready to work and when it is turned on the program loaded will be executed because a
boot project has been created.
Figure 27 – PLC Program online
Cap. 3: Test
___________________________________________________________________________
41
Configuration of Conccurrent Simulation Workbench
A Simulink model is created and uploaded to the Concurrent Realtime Machine. This is
necessary because a Simulink project with a specific architecture and blocks runs in the
Simulation Workbench.
Simulink project
The Simulink project is used to create the right datagram required by the platform. Furthermore,
there are the status command of the platform and the feedback displacement from it.
The project (Figure 28) is composed of three parts, i.e. the status of the platform, the signal
conversion to the motion platform and the signals from the motion platform.
Figure 28 – Simulink model main view
Motion platform status command is the part of the model Simulink in which the status of the
platform is sent and received (Figure 29). It’s necessary because this part sends the command
to it and reads its feedback from the platform.
Figure 29 - Motion platform status command
Cap. 3: Test
___________________________________________________________________________
42
In Signal to the motion platform (Figure 30), the signal is received from the PLC and converted
to double. For safety reason, a saturation block with the full scale of the stroke of the platform
for each degree of freedom it has been added. After these blocks, the signal is converted again
in single and sent to the platform in the PVA set. The gravity is added into the Simulink model
because the platform in simulation mode requires the gravity into the PVA set.
Figure 30 – Signals to the motion platform
In Signals from the motion platform, the signal is received from it and it is converted in a
readable format for the CCUR.
Cap. 3: Test
___________________________________________________________________________
43
Figure 31 – Signals from the motion platform
Now some parameters of the project must be changed. The solver option must be a fixed-step
type and discrete solver (Figure 32). It is important to set the fundamental sample time because
it will be the same time of the simulation on CCUR.
Figure 32 – Simulink solver parameters
Furthermore, in the code generation option (Figure 33) the system target selection must be
changed in the format added from the SimWB ML Toolkit.
Cap. 3: Test
___________________________________________________________________________
44
Figure 33 – Code generator
Now the project is ready to be loaded on the CCUR through the SimWB Toolkit (Figure 34).
This tool creates a direct connection between a host PC and the CCUR. With this direct
connection, the project is loaded in two steps. The first step creates the RTDB, a special kind
of file reads from Simulation Workbench and creates the input and the output for the simulation.
The second step is the code generation, where the Simulink project is converted in the format
readable from the Simulation Workbench and creates the connections and the functions between
input and output.
Figure 34 – Connect with SimWB Toolkit
Cap. 3: Test
___________________________________________________________________________
45
Simulation Workbench on CCUR
This is a simulation software that runs on Concurrent Realtime Machine. All the steps done so
far are fundamental, but an important part will be done now.
Simulation Workbench [15] (SimWB) (Figure 35) needs a specific setting for this purpose.
Figure 35 – Simulation Workbench main view
After opening it, it is necessary to load the RTDB. This is a specific file made through the
Simulink project. The RTDB load the Input/Output in the simulation and they are the special
blocks of Simulink added with the SimWB toolkit (Figure 8 and Figure 28). However, they
must be mapped in the I/O Mapping (3 in Figure 35 and Figure 36) because, for each UDP
package received or sent, a pack of RTDB blocks must be arranged. The input message from
the PLC contains six field and each of them is associated at the RDTB blocks. The same
procedure must be done in the message to the MOOG Motion Platform for each degree of
freedom. Furthermore, the status of the platform is also mapped in the message to the MOOG.
With this operation, its status will be monitored and changed directly with the SimWB interface.
Cap. 3: Test
___________________________________________________________________________
46
Figure 36 - Create messages and associate variables in I/O Mapping
The Simulink project is just ready to be paired with the simulation in the Test field (4 in Figure
35 and Figure 37). This operation guarantees the connection between the RTDB Simulink
blocks. It’s necessary to pair with at the RTDB project, otherwise the field of the message in
input and in output aren’t able to communicate, the message received from the PLC will be lost
and the message to the MOOG Motion Platform will be empty because there is no
communication between input and output in the simulation. If this operation is skipped, there
is no connection between them and the simulation is not ready to start.
This allows to check the communication line and the simulation is now ready to start.
Cap. 3: Test
___________________________________________________________________________
47
Figure 37 – Append Simulink model
3.1.2 MOOG Motion Platform setup
In this paragraph the equipment used for the test session will be discussed, such as
accelerometers, acquisition hardware, sensors position, etc.…
SCADAS and DC Accelerometers
The SCADAS (Figure 38), used for this purpose, is a mobile version with six BNC output,
which send output voltages from -10V to +10V, one for each degree of freedom. One Syscon
Vybco module and one DAC4 module [17] have been used for the output.
The input modules are four, three VB8-II and one VB8E. The sensors are plugged in the VB8-
II [17] modules because DC accelerometers have been used, which need power supply as active
sensors.
For the test, with the El Centro earthquake as target, the SCADAS has been positioned behind
the MOOG Motion Platform (Figure 39) because the displacements of the platform aren’t too
big.
Cap. 3: Test
___________________________________________________________________________
48
Figure 38 – SCADAS Mobile
Figure 39 – SCADAS position for El Centro run test
The PCB Piezotronics [18] are the accelerometers used, most specifically a try axial sensor of
the series 3713E [19]. This is an active sensor with a high frequency range and a high sensitivity
(Error! Reference source not found.). This setup needed this kind of sensor because the
frequency range and the forces are very small. Most specifically the frequency range of the
MOOG Motion platform is from 0 Hz and the spectrum of the target, the earthquake, is from
0.5 Hz. After this observation, this kind of sensors are needed, because if the first part of the
frequency range is lost, it is not good for the aim of the study.
Cap. 3: Test
___________________________________________________________________________
49
Table 10– PCB 3713E datasheet
PCB 3713E Performance
Sensitivity (±3 %) 200 mV/g
Measurement Range ±10 g pk
Frequency Range (±3 dB) 0 to 1000 Hz
Frequency Range (±3 dB) 0 to 500 Hz
Phase Response (100 Hz)
Cap. 3: Test
___________________________________________________________________________
50
Figure 40 – Sensors position
Figure 41 – Setup sensor plugged
Cap. 3: Test
___________________________________________________________________________
51
BeckHoff CX8090
The PLC has been set with the program showed in the Chapter 2.2. It reads the analog inputs
sent from the SCADAS and converts them in a digital signal as displacement for each degrees
of freedom. After reading the inputs, it fills them in a UDP package and sent it to CCUR
Machine. It is the main part for the communication chain, since without this operation it is
impossible to establish the communication and the MOOG Platform doesn’t move.
The CX8090 is connected at the SCADAS with six BNC cable (Figure 42) and at the CCUR
with an Ethernet hub (Figure 43)
Figure 42 – BeckHoff connected to the setup
Figure 43 – Ethernet hub
Cap. 3: Test
___________________________________________________________________________
52
3.2 Preliminary Tests
Before starting the real test with TWR application, the first step has been to try the platform
with the MOOG Explore suite. It is a MOOG interface and it is possible to send a signal to the
platform by choosing from a list of signals. This stage is very important because it’s necessary
to understand the limit of the platform with different kind of signals. A random signal doesn’t
give problem but, with a sine signal greater than a specific frequency and less than specific
amplitude, it gives a problem at the actuator. Most specifically, the actuators are an
electromechanical actuation with a recycle bearing screw. If the movement of each actuator is
a very small displacement at high frequency, they give a bearing fault waring (Figure 44). This
is given for safety reason to avoid a possible damage of the actuator.
This basically could give problem with some kind of signal, in particular with high frequency
and low amplitude signal of the sine family, such as sine signal, shaped sine signal, etc…
Figure 44 – MOOG Motion platform limit
Cap. 3: Test
___________________________________________________________________________
53
3.3 Time Waveform Replication
Time Waveform Replication, as already mentioned, is an application of Siemens Simcenter
Test.Lab [11].
Time Waveform Replication (TWR) is used to replicate multiple time histories, for a user
defined number of control channels, by driving multiple shakers or the multiple degrees of
freedom of a multi-axis shaking system.
The control target is a set of reference time recordings (e.g. acceleration time histories) to be
replicated. Also in this case, before the actual control test, a System Identification is run to get
a low level random estimation of the system’s FRFs. With this information and the spectra of
the target r(f), the drives that theoretically return the reference time histories can be easily
computed as:
u(t) = iFFT[Z�(f) r(f)] ( 1)
However, inevitable mismatches between the estimated system and the real system’s dynamic
behavior, bring the necessity of iterative correcting the drives, as shown in Figure 45, in order
to compensate for the error between the recorded responses and the reference signals [20].
The complete error time histories need to be used to correct the drives. The control loop,
contrarily to the MIMO random’s one, takes place off-line and the full re-play of the corrected
drives needs to be performed before the next iteration. It is remarkable to notice that, as shown
in the block scheme of Figure 45, a control gain diagonal matrix K (with entries between 0 and
1) weights the error to be corrected in the next iteration, in order to prevent control instabilities.
Different metrics can be used to define the convergence rate of the process. A meaningful choice
is to have as metric a Composite Error, combining the peak and the rms error:
ecomp(t) = rms[e(t)]rms[r(t)]
α + peak[e(t)]peak[r(t)]
(1 − α) ( 2)
where α is a tunable weighting factor between 0 and 1. The threshold set on the defined metric
determines the Convergence Reached status of the test. A user-defined maximum number of
iterations can also be set as limit to end the test. As stated by U. Musella et al.[12].
Cap. 3: Test
___________________________________________________________________________
54
Figure 45 – Time Waveform Replication general block scheme, source [12]
3.3.1 TWR MATLAB code
As already mentioned, this MATLAB code has been done to understand how TWR works.
The system simulated in the code is a two degrees of freedom mass-spring-dashpot and it is
showed Figure 46.
Figure 46 – Two degrees of freedom system
Cap. 3: Test
___________________________________________________________________________
55
The first step of the control code is the System Identification. The FRF’s of the system are
estimated with the input, or the drive, and the output, or the response, as showed in Figure 47.
Figure 47 – System identification step
After the System Identification, the targets chosen for the simulation are two sine signals with
different amplitude and phase.
At the beginning of the process an initial drive is calculated using the targets, the Inverse System
FRFs and the iteration parameters, in this case a gain value of 0.5.
This drive signal is used for the simulation of the system and the response during the simulation
is measured. The error, the difference between the targets and the responses, is calculated.
For the next iteration a drive correction is calculated based on the error trace of the previous
iteration, a gain value (Qj), to avoid the divergence of the run, and with the Inverse System
FRFs. The drive correction is then added to the previous drives and these signals are again sent
to the system for another simulation.
This process is repeated until the error between the target trace and the response of the system
is below a defined threshold.
The control step of the MATLAB code has been shown in Figure 48.
Cap. 3: Test
___________________________________________________________________________
56
Figure 48 – Matlab control code (main step)
The results of the simulation, most specifically the response of the two degrees of freedom, the
targets and the error for each iteration, are showed in Figure 49 and Figure 50.
Cap. 3: Test
___________________________________________________________________________
57
Figure 49 – X response and error for each iteration of the system
Figure 50 – Y response and error for each iteration of the system
Cap. 3: Test
___________________________________________________________________________
58
To evaluate the error and choose the convergence parameters, a simplified formula has been
used, that is called Composite Error, as reported in the paragraph 3.3 with formula (2).
This formula is composed by two parts, one about the rms and one about the peak. These two
parts are combined by a weighting factor α.
For the simulation of the two degrees of freedom system, the convergence of the run is
reached if the composite error is less than the 15%. The evolution of the composite error is
reported in Figure 51.
Figure 51 – Composite error of the run
Cap. 3: Test
___________________________________________________________________________
59
3.4 TWR Test: El Centro target
The target for the test is El Centro earthquake, which took place in the 1940 in the Southern
California, near the international border of the United States and Mexico [1]. The maximum
amplitude of the signal is among the N-S direction (Ty for the platform reference). Its magnitude
is 6.9 Mw with a force of 0.3487 g. El Centro is a famous earthquake because it has caused a lot
of damage (Figure 52) and it was the first major earthquake to be recorded by a strong-motion
seismograph located next to a fault rupture. It was the strongest recorded earthquake to hit the
Imperial Valley, and caused widespread damage to irrigation systems and led to the deaths of
nine people [1].
Figure 52 – Collapsed building in Imperial California, source [1]
The recording data of this earthquake are easy to obtain in the achievement [16].
The recording data before being used as a target in Time Waveform Replication, have been
processed because the signal, put from the database, aren’t suitable for Test.Lab. The
accelerometric signal from the acquisition has been made. Sample frequency and signal length
have been changed to match with the test setting and the results is showed in Figure 53.
Cap. 3: Test
___________________________________________________________________________
60
Figure 53 - Signal processed of El Centro
Now the signal is ready to be the target of a Time Waveform Replication run. It is suitable for
this application because it is a real acquired target and it is suitable for a test with structure
submitted a real-life condition.
For safety reason the maximum frequency of the signal will be cut at 15 Hz and for problems
of survey from the DC accelerometers the minimum frequency of the signal is set at 1 Hz.
Furthermore, the recorded data has been scaled down of a factor 10 and a fade in/out effect is
applied to reduce the instant movement of the platform when the run is begun.
Different run has been done with the scaled recoded data as target, most specifically with one
and two as scaling factor. This scaling factors are referred at the scaled recorded data and the
new peak of the force is 0.03487g.
Cap. 3: Test
___________________________________________________________________________
61
3.4.1 System Identification
This is an important part of the testing process. In TWR, the first drive and the correction of the
drive to replicate the target in the unit under test are calculated with the system identification.
The sensors configuration is sowed in Figure 54.
Figure 54 – Sensors configuration
The control channels are DC1:+X, DC1:-Y,DC1:-Z, DC3:-Y, DC3:-Z and DC4:-Z.
This sensors configuration has been choosing because it needs to be able to fully capture the
six degrees of freedom motion. Most specifically the problem is not given by the three
translations because they need to have one channel per axis. For the roll, pitch and yaw rotation
is not easy to capture them because the sensors choice of the control channel influences the
FRFs matrix.
A useful tool to check upfront if the configuration chosen is able to capture the full six-degrees
of freedom motion is the rank of transformation matrix T. A matrix T with rank smaller than
six indicates that two or more DOFs are linearly dependent with the configuration chosen. The
X
Y
Z
Z
Y
Z
DC1
DC3
DC4
Cap. 3: Test
___________________________________________________________________________
62
setup used for the tests, as shown in Figure 54 returns a full rank transformation matrix. As
stated by U. Musella et al.[12].
The frequency range of the system identification is from 1 Hz to 15 Hz with H1 estimator [22].
The results are showed in Figure 55.
The MOOG Motion platform behaves like a rigid body and the FRFs show the delay of the
communication chain.
Figure 55 – System identification with full rank
Cap. 3: Test
___________________________________________________________________________
63
Figure 56 – Multiple coherence with full rank
Figure 57 – Singular Value ratio
Cap. 3: Test
___________________________________________________________________________
64
3.4.2 El Centro TWR test with scaling factor of 1
The first test, with El Centro as target, has been done with the target processed and scaled of a
factor of ten with respect to the real recorded data of the earthquake.
The test has been performed with one accelerometers as control channel, most specifically the
DC1 Accelerometers with the X, Y and Z axes. For these tests the full rank is not needed
because the control of the platform is performed with the translational degrees of freedom and
not with the rotational.
The first drive has been calculated by using the 50% of the target, in order to gradually get the
test level. The control gain is set to 0.5. the composite error threshold has been set to 0.1 in ten
iterations.
The evolution of the error for each iteration is showed in Figure 58, while the results of the last
iteration are showed in Figure 59.
Figure 58 – Evolution of the error for each iteration
Cap. 3: Test
___________________________________________________________________________
65
Figure 59 – Last iteration of the run
As showed in Figure 59, in the last 20 seconds of the signal the amplitude of the error is like
the amplitude of the response. In Figure 60 is possible to see better this result, with the plot of
the last 20 seconds.
Figure 60 – Last 20 seconds of the run
Cap. 3: Test
___________________________________________________________________________
66
The amplitude of the last 20 seconds of the scaled recorded data is very small and the system
has some difficulties to replicate it. This problem doesn’t persist in the first part of the signal.
After this results the signal has been cut at 31 seconds and a new test has been performed.
The result is showed in Figure 61.
Figure 61 – Last iteration with cut signal
The composite error has been evaluated for different weighting factors and the two runs, with
full and cut signal, have been compared.
In terms of composite error, the results confirm the prior assumption. For every weighting factor
the results of the cut signal are better than the full signal, as sowed in Figure 62.
Furthermore, the Y axis has a better composite error than the other two axes. This shows a limit
of the system in terms of amplitude of the signal chosen as target, because the Y axis is the
recorded data with the high amplitude than the other two axes.
Cap. 3: Test
___________________________________________________________________________
67
Figure 62 – Composite error of the runs
Cap. 3: Test
___________________________________________________________________________
68
3.4.3 El Centro TWR test with scaling factor of 2
This test has been done with a scaling factor of two with respect to the signal of the first test.
The other parameters and the setting of the test are the same of the first test. The run has been
performed with a composite error of 0.1 in 10 iterations. Furthermore, as explained before, the
targets evaluated are two, the full signal and the cut signal.
The last iteration of the run with the full signal is showed in Figure 63 and the last iteration of
the cut signal is showed in Figure 64.
As far the composite error is concerned, also for these tests have been evaluated for different
weighting factor. The difference between the full signal and the cut signal, in terms of error, is
very small, as showed in Figure 65. This confirm the difficulties of the system to replicate a
target with small amplitude. Furthermore, the error of the axes is similar contrariwise at the
runs before.
Figure 63 – Last iteration of the full signal with scaling factor of two
Cap. 3: Test
___________________________________________________________________________
69
Figure 64 – Last iteration of the cut signal with scaling factor of two
Cap. 3: Test
___________________________________________________________________________
70
Figure 65 – Composite error of the runs
Cap. 4: Conclusions
___________________________________________________________________________
71
Chapter 4
Conclusions
Vibration control tests are usually performed with traditional shakers. In this study the vibration
control has been combined with a six degrees of freedom MOOG Motion platform. The
platform has been used to replicate the 1940 El Centro earthquake in a Time Waveform
Replication test.
The conversion of the MOOG Motion platform into an exciter has required an additional layer,
a suitable embedded PC for Ethernet
The main program runs continuously on the PLC. The information can be read by a real-time
operative system that forwards the data to the platform. Therefore, communications between
different layers has been successfully established.
Programming the PLC was crucial to allow the aforementioned communication.
Before starting the vibration tests, some preliminary tests revealed the platform’s boundaries
and its performance when driven by a SCADAS.
This allowed to highlight the limits in terms of frequency range and signal amplitude. The 1940
El Centro earthquake (scaled for safety reason of a factor 10) has been chosen as a target to be
replicated by means of the Time Waveform Replication application, since this earthquake had
a frequency range very similar to the one of the platform.
As already mentioned, the target has been scaled with a factor 10 for safety reasons to avoid
damage at the platform, because the limit of the platform was not known before the preliminary
tests.
The tests then showed excellent results. A tool has been used for the optimal sensors
configuration and it allowed to capture the six degrees of freedom movement, as started by
U.Musella et al. [12].
Cap. 4: Conclusions
___________________________________________________________________________
72
The first test performed in TWR using target 10-fold scaled signal showed a limit on the system.
This limit appears to be the difficulty of replicating signals with very small amplitude and has
emerged in the last 20 seconds of the signal. This limit is given because the platform is not able
to replicate a target with small amplitude.
As a consequence, the target was then shortened by deleting the last part of the signal and a new
test was performed. Convergence of results could then be proven and the new target could be
replicated with a negligible mistake.
A second test has then been performed using the two signals adopted in the previous test, i.e.
the complete one and the cut one, with a scaling factor of 2.
In this second test has been performed using the two signals adopted in the previous test with a
scaling factor of 2.
The platform does not have difficulty replicating both targets. The problem with a small
amplitude signal showed in the first test doesn’t persist in this second test.
This confirms the difficulty of the system to replicate small amplitude signals.
In conclusion the addition of a layer did not produce system performance losses and the MOOG
Motion platform was efficiently used as a shaker bringing promising results.
Indeed, this study represent an important test for future conversion of this kind of platform as a
shaker able to perform a vibration control test.
As for the choice of the target, it may be useful for the future developments for an earthquake
simulator with this kind of shaker, i.e. the MOOG Motion platform.
The development can be based on studies conducted by the University of Pavia [1], in which
an earthquake simulator has been built. This earthquake simulator is aimed at investigating the
effects of earthquakes on structures and their subcomponents.
Future developments may concern also the improvement of the PLC program in order to bring
th