Università degli Studi di Ferrara - VUB · Università degli Studi di Ferrara . DIPARTIMENTO DI INGEGNERIA . Corso di Laurea Magistrale in Ingegneria Meccanica . MULTI-AXIS VIBRATION

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].


___________________________________________________________________________

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.


___________________________________________________________________________

5

Figure 1 – CX8090 overview, source [6]


___________________________________________________________________________

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


___________________________________________________________________________

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


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


___________________________________________________________________________

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


___________________________________________________________________________

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]


___________________________________________________________________________

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


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


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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].


___________________________________________________________________________

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]


___________________________________________________________________________

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


___________________________________________________________________________

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


___________________________________________________________________________

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


___________________________________________________________________________

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


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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].


___________________________________________________________________________

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]


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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.


___________________________________________________________________________

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

Documents

Università degli Studi di Ferrara - VUB · Università degli Studi di Ferrara . DIPARTIMENTO DI INGEGNERIA . Corso di Laurea Magistrale in Ingegneria Meccanica . MULTI-AXIS VIBRATION