Hardware-in-The-Loop Simulation of a High Speed Servo System

(1)

Hardware-in-The-Loop Simulation of a High Speed Servo System

EIÐUR ÁGÚSTSSON

Master of Science Thesis MMK 2013:77 MDA 461 KTH Industrial Engineering and Management

Machine Design

SE-100 44 STOCKHOLM

(2)

(3)

Acknowledgements

I would like to express my gratitude to Bengt Eriksson, my supervisor at the Mechatronics department at KTH. His advice and guidance has proven invaluable to the success of this project. I would also like to thank Robert Axelsson, my supervisor at Micronic Mydata, for his useful and constructive recommendations and support on this project.

Finally, I wish to thank my family for the support and encouragement given throughout

the duration of this thesis project.

(4)

(5)

.

Master of Science Thesis MMK 2013:77 MDA 461 Hardware-in-The-Loop Simulation of a High Speed Servo

System

Eiður Ágústsson

Approved: Examiner: Supervisor:

2013-09-06 Mats Hanson Bengt Eriksson

Commissioner: Contact person:

Micronic Mydata AB Robert Axelsson .

Abstract

.

In production industries there is a constant demand for shorter time to market and lower development costs. Using models and simulations has been shown to decrease devel- opment time and increase product quality. One reason for this is that these methods allow development and testing of control systems before actual prototypes are available.

The purpose of this thesis is to implement a Hardware-in-the-loop simulation of the MY500 solder jet printer, which is produced by Micronic Mydata AB. The MY500 has high accuracy and speed requirements, resulting in a short control loop, which puts hard constraints on the model calculation time. The simulation is implemented on a dSPACE MicroAutoBox, using the MATLAB toolboxes Simulink and SimMechanics. It communi- cates with the control system via SPI and implements an existing SimMechanics model and a newly developed Simulink model.

The Simulink model developed in this thesis was found to be a sufficiently realistic simplification of the SimMechanics model. Furthermore, the findings show that the Sim- Mechanics model cannot be run in closed loop on the chosen hardware due to its extensive complexity. The thesis also shows that when using the internal clock, even the shortest model step time allowed by the hardware is not sufficient to perform a stable HIL simula- tion. Lastly, the SPI implementation tested in this thesis introduced computational delays into the control loop of the MY500, which led to the system only being able to calculate one axis.

This thesis concludes that even though the current implementation has some limita- tions, there is reason to continue the work and making a good simulator of the MY500.

Two main avenues of investigation are; firstly, implementing an external interrupt for the

HIL simulation, which should allow a larger time step and eliminate jitter in the model

output. Secondly, moving the SPI communication code out of the control loop and instead

implementing it directly on the FPGA, which should minimize the computational delay

added by SPI and thereby allows control of more than one axis.

(6)

(7)

.

Examensarbete MMK 2013:77 MDA 461 Realtids simulering av hög hastighets servo system

Eiður Ágústsson

Godkänt: Examinator: Handledare:

2013-09-06 Mats Hanson Bengt Eriksson

Uppdragsgivare: Kontaktperson:

Micronic Mydata AB Robert Axelsson .

Sammanfattning

.

I produktionsbranscher finns det en ständig efterfrågan på kortare tid till marknad och lägre utvecklingskostnader. Modeller och simuleringar har visat sig vara ett sätt att minska utvecklingstiden och öka produktkvalitén. En anledning till detta är att dessa metoder tillåter utveckling och testning av styrsystem innan de faktiska fysiska prototyperna är tillgängliga.

Syftet med detta examensarbete är att genomföra en realtids simulering av lödpastaskri- varen MY500 som tillverkas av Micronic Mydata AB. MY500 har hög krav på noggrannhet och hastighet, vilket resulterar i en kort samplingstid som i sin tur sätter hårda restriktioner på modellens beräkningstid.

Simuleringen genomförs på en dSPACE MicroAutoBox tillsammans med simuleringsverk- tyg i MATLAB. närmare bestämt Simulink och SimMechanics. Simulatorn kommunicerar med styrsystemet via SPI och implementerar en befintlig SimMechanics modell och en nyutvecklad Simulink modell.

Simulink modellen, som utvecklats i detta examenarbete, visade sig vara en tillräckligt realistisk förenkling av SimMechanics modellen. Vidare visar resultaten att SimMechanics modellen inte kan köras på den valda hårdvaran p.g.a. dess komplexitet. Studien visar också att, när den interna klockan används, även med det kortaste tidssteget som hårdvaran klarar av, kommer inte HIL simuleringen att vara stabil. Slutligen, SPI-kommunikationen som testas introducerade fördröjningar i MY500 reglerloopen, vilket ledde till att systemet enbart kunde beräkna en axel.

Slutsatsen som dras är att även om den nuvarande tillämpningen har nackdelar, finns

det ändå skäl för att fortsätta arbetet och att göra en bra simulator. De två mest relevanta

utvecklingar är: för det första, implementeringen av en extern interrupt borde tillåta ett

större tidssteg och även eliminera jitter i modellens output. Sedan, med att flytta SPI-

kommunikationskoden ur reglerloopen och istället implementera den direkt på en FPGA

borde beräkningsfördröjningar, komna från SPI, minimeras och därmed kontroll av mer än

en axel möjliggörs.

(8)

(9)

List of Abbreviations

DSP Digital signal processor

FPGA Field-programmable gate array HIL Hardware-in-the-loop

IC Integrated circuit LCD Liquid crystal display MABX dSPACE MicroAutoBox MBD Model-based development MIL Model-in-the-loop

MM Micronic Mydata

PCB Printed Circuit Board

PIL Processor-in-the-loop

RTOS Real-time operating system

SIL Software-in-the-loop

SMT Surface Mount Technology

SPI Serial Peripheral Interface bus

(12)

(13)

Chapter 1

Introduction

1.1 Background

Micronic Mydata

Micronic Mydata AB (MM) is a publicly traded Swedish high-tech company engaged in de- veloping and manufacturing production solutions for the electronics industry. The company has two business areas;

• Pattern Generators, including mask writers and direct writers. MM offers equip- ment for production of photomasks and substrates used in photolithography for pro- duction of integrated circuits(ICs) and LCD backplanes.

• Surface Mount Technology (SMT) equipment, including pick and place and jet printing solutions. MM offers complete solutions for SMT production lines, from applying solder to placing components on printed circuit boards (PCBs).

The SMT business area has customers worldwide and focuses on high-mix and medium to low volume production.

MY500 Jet-Printer

In 2005 Micronic Mydata released a new product in their SMT line, the MY500 solder jet-printer. It is a revolutionary product which introduced a new way of applying solder to printed circuit boards, by employing jet-printing to place solder on the PCB. The MY500 sprays the solder through a nozzle onto each pad, similar to how a jet-printer puts ink onto a paper. This new method has been shown to be more flexible than the conventional method of using masks to cover parts of the PCB that should not receive solder[1, 2].

The MY500 has 3-axes of movements, as seen in Figure 1.1. Firstly a beam moves on the Y-axis. Secondly, on the beam there is a wagon holding the jetting head that moves on the X-axis. Finally, the wagon has a jetting head assembly that moves on the Z-axis.

During the development of the MY500, a mechanical simulator of the machine axes was produced. The simulator uses rotary motors to provide an approximation of the linear motion in the machine. The purpose of the simulator is to develop and test the control system

¹

for the machine. A photo of the simulator can be seen in Figure 1.2.

1The embedded system that controls the movement of all axes and the behavior of the machine

(14)

CHAPTER 1. INTRODUCTION

Figure 1.1. MY500 overview, the moving parts are; A beam in Y-axis, a wagon in X-axis, and a jetting head in Z-axis.

Figure 1.2. MY500 Mechanical simulator. The simulator can simulate three axes and uses rotational inertia to replicate the different axes.

In 2011 a physical model of axes X and Y, as seen in Figure 1.1, was developed using Mathworks SimMechanics by Joel Rundgren. Since then the model has been modified and extended to also include dynamics originating from the supports of the machine. The model has been validated and verified to be a realistic representation of the real system [2].

To make further development of the MY500 easier and faster, there is interest at MM in making a new simulator. This simulator will use the newly developed SimMechanics model, instead of rotary motors, to simulate the dynamics of the machine.

The company hopes this will result in a more flexible development platform, as well as being a way to perform more extensive and more automated testing of the control system.

The new simulator should be able to function in scenarios where the real system is currently being used.

2

(15)

1.2. PURPOSE AND PROBLEM STATEMENT

By implementing the simulator into their development process, the company should be able to; create a more robust product, since they are able to test more, and have a shorter time to market, since testing can be done earlier in development.

1.2 Purpose and problem statement

The purpose of this thesis is to investigate real-time simulation of a dynamical model under actuation by a real control system running a fast control loop of 200µs, a so called Hardware- in-the-loop simulation. It should also investigate the feasibility and use of such a simulation, as well as methods of transferring data to and from the simulator.

During this work, the following research questions are considered:

• Is real-time simulation of the existing SimMechanics model possible when the control system has a 200µs loop time?

• If the control system loop is 200µs, how fast should the model loop be so that simulated system behaves as the real machine?

• Can a serial interface (SPI) be used instead of a normal input/output interface during real-time testing?

To answer these questions a simulator is built. The simulator interfaces a model of the X and Y axes of the MY500 jet printer with the regular control system of the machine.

The main part of it is realized using a real-time simulation platform, see Chapter 3, and connected via a serial interface to the control system. A Simulink model is also developed to evaluate whether simulation of a model with less dynamics affects the behavior of the control system. This model also makes it easier to run within the limits of the control loop.

1.3 Delimitations

A requirement from the company is that the interface by which the simulator should com- municate with the control system is SPI. The focus of the thesis is therefore directed to testing whether using SPI has a negative effect on the simulated system, compared with the real system. The thesis will not evalulate other methods of communcation.

The simulation platform used in this thesis is the dSPACE MicroAutoBox (MABX), which is described in Chapter 3. The MABX is chosen for two main reasons; the author has positive previous experience and knowledge of the equipment, and the platform is ready and available when the work is started.

Modifications of the MY500 control system will be minimal. Analysis of the control loop time in [2] showed that 200µs is very close to the maximum allowed time.

The work in this thesis is assumes that the existing SimMechanics model is valid and and verified to be a true representation of the real MY500, as shown in [2].

1.4 System description

1.4.1 MY500 servo system

The MY500 servo system consist of two control loops, one for each axis. A system schematic

is shown in Figure 1.3. The control system (CMOT3) controls the current to a motor and

(16)

CHAPTER 1. INTRODUCTION

reads the position from an encoder. The system can achieve speeds up to 2m/s while still maintaining accuracy down to 10µm. Following is a description of each subsystem.

Figure 1.3. MY500 control system schematic. The control system sends signals to motors which move each axis. The movement is measured by an encoder and sent to the control system.

CMOT3 Control system

The MY500 runs control system named CMOT3, which is developed in-house. The system is a combination of a digital signal processor(DSP) for processing information and a field- programmable gate array(FPGA) for input/output operations. The high speed and high accuracy requirements of the MY500 lead to a fast control loop with a 200µs control period.

Motors

Each motor subsystem consist of a motor and an amplifier in a separately tuned control loop.

For the purpose of this thesis the motor system is considered to have a linear translation from input current to output force.

Mechanics

As described in Section 1.1, a beam on Y-axis and a wagon on X-axis are the moving parts of the system.

Encoders

The encoders are high resolution linear encoders with scales. They use interpolation and have a resolution of 0.2µm.

1.4.2 Simulator hardware

For the implementation of the simulator, hardware from dSPACE named MicroAutoBox II (MABX) will be used. The MABX is a portable simulation platform with many peripherals available, a detailed description is provided in Section 5.1.

The simulator will communicate with the control system via a serial interface, instead of normal I/O. This is done because of requirements from MM, and also so that more

4

(17)

1.5. METHOD AND THESIS OUTLINE

information can be sent to the simulator. This should also make it as simple as possible to connect the simulator to the control system. The system schematic when the simulator is connected can be seen in Figure 1.4. The simulator appears as an extra layer that encapsulates the model of the machine.

Figure 1.4. System schematic with simulator connected. The control system communicates via Serial Peripheral interface with the simulator, see Chapter 3, the platform runs the model and returns the status of the model.

1.5 Method and thesis outline

Chapter 2 starts with research on Model-based development (MBD). Further investigation is made on how simulation can be used to improve the development process, specifically during testing and verification. Chapter 3 goes on to describe the function and components of a real-time simulation platform. Finally, the methods of running a model in real-time are discussed.

Chapter 4 focuses on modeling. The existing SimMechanics model is described, a Mat- lab/Simulink model is developed and the models are analyzed. Chapter 5 documents the implementation of the SimMechanics and Simulink models on the real-time simulation plat- form. This includes creating a communication scheme and configuring the platform to run the models in an optimal way.

In Chapter 6 results from the previous section are presented and analyzed. Lastly,

in Chapter 7, the author’s conclusions are discussed. An attempt is made to answer the

research questions and finally recommendations are made for future work.

(18)

(19)

Chapter 2

Model-based development

The complexity of control systems is ever increasing. This is driven by demands of bet- ter performance and more functionality and enabled by more capable hardware. As the complexity grows the development time increases. This goes against other demands by the industry, such as faster time to market and cheaper products [3]. With increasing complex- ity of the system, testing becomes a larger and larger part of the development cost. Safety concerns also bring the need for more thorough testing. These demands have created a need for companies to concurrently develop hardware and software. Concurrent development has been proven to affect development time and cost positively [3, 4], as shown in Figure 2.1.

Software and hardware designs are improved by this method, since problems identified on either front are propagated to the other. This results in a better performing system than if the parts had been developed in series [3].

Figure 2.1. Development time of concurrent development and sequential development.[3]

(20)

CHAPTER 2. MODEL-BASED DEVELOPMENT

2.1 Model-based development

A popular way of achieving the concurrency is by using model-based development(MBD) methods [5]. To cope with the increasing complexity, these methods suggest constructing models with different levels of abstractions. These models should have overlapping views of the system and together they give a complete picture of the system and its functions [6]. The reason for doing this is that the complexity of the systems has risen to such an extent that understanding the system is virtually impossible without some abstraction [6].

In a mechatronic context, modeling physical systems is a big part of the development of a product. These models can be thought of as virtual prototypes, which can be analyzed and tested.

2.2 Simulation as a tool

During the development cycle of a product, prototypes are usually produced. Physical prototypes can be expensive and hard to produce until the final stages of development. One way of prototyping for concurrent development is by simulating dynamical system models in programs such as Mathworks Matlab/Simulink/Simscape and Modelica [2, 6, 7, 8].

Simulation and modeling, even before any of the actual hardware is available, are very good methods for initial prototyping and design. As more parts of the actual product become available the scope changes and more and more parts of the actual product can be implemented in the simulation. There are four main focus points for simulation of embedded systems [9, 10], as seen in Figure 2.2.

Figure 2.2. Scope of simulation for Model-in-the-loop (MIL), Software-in-the-loop (SIL), Processor-in-the-loop (PIL) and Hardware-in-the-loop (HIL). The scope ranges from the whole system being simulated in MIL, to only the plant in HIL.

2.2.1 Off-line simulation

Model-in-the-loop (MIL) and Software-in-the-loop (SIL) simulations are performed off-line, which means that the simulation is not done on the target hardware, and usually not in real time. This is the first stage of simulation, and is done on a regular desktop PC.

Model-in-the-loop (MIL)

In MIL simulation the whole system, or parts of it are simulated. The simulation is not in real-time and often in very high fidelity. Changes can be applied immediately and their effect tested. Simulation time at this stage is wildly different than for the real system and can be orders of magnitude lower or higher, depending on the complexity and scope of the simulation. The focus of MIL is the design and development of control algorithms that fulfill requirements [11].

8

(21)

2.2. SIMULATION AS A TOOL

Software-in-the-loop (SIL)

In SIL simulation the focus has moved over to testing and verification. This simulation technique is very similar to the MIL, except the controller that was developed in MIL has been replaced with program code, often C. The code can be hand-coded or auto-generated.

As MBD grows in popularity, auto-generation from models becomes more and more popular.

SIL simulation is used to test the code before it is deployed on real hardware, and to verify that it behaves in the same way as the model that was tested in MIL simulation [9].

2.2.2 On-line simulation

Processor-in-the-loop and Hardware-in-the-loop simulations are performed on-line, which means that the simulation is done on the target hardware or an evaluation board for the architecture that will be used.

Processor-in-the-loop (PIL)

In a PIL simulation, the verified code from SIL is run on the target hardware or on an evaluation board. PIL simulation is not done in real-time, instead the PC simulator con- trols how the hardware perceives time, and controls when it runs. PIL is used to verify performance of the control code on the hardware and, like in SIL, that the behaviour is the same as in MIL. It is possible to monitor memory use and runtime information such as execution time, this is called profiling the system [12].

Hardware-in-the-loop (HIL)

In HIL the controller code runs on the target hardware and is interfaced via actual I/O to

the simulation. A model of the dynamic system is simulated in real-time and the response

of sensors and actuators is electronically emulated. HIL is a sort of last step of testing

before running the whole system. HIL can be used to verify and validate the performance

and behaviour of the real control system on the intended target platform [13].

(22)

(23)

Chapter 3

Hardware-in-the-loop simulation platform

Nomenclature

T

m

Model time-step T

s

Controller sample time T

c

Controller actuation delay u

c

Controller output

y

c

Controller input y

m

Model output u

_m

Model input

3.1 Platform

Many different vendors offer products for real-time simulation, such as National Instru- ments, dSPACE and Mathworks. A HIL simulation platform consists of a computer running a Real Time Operating System (RTOS) and input/output interfaces. For systems requiring very fast calculations and communication a FPGA is often added[14]. Usually a PC is also connected to the simulator to allow control and monitoring of the simulation. A typical setup for HIL simulation can be seen in Figure 3.1.

3.2 Interfacing with the real-time simulation

Selection of interface between the simulation and the control system depends on the pur- pose of the simulation and the capabilities of the control system. The most common way for control systems to communicate with periperals is by reading or setting voltages with digital-to-analog and analog-to-digital converters or using discrete digital signals for TTL, differential or PWM[13]. Sometimes the system communicates with peripherals via serial connection such as RS-232, RS-422 or SPI. In more complex products the control system is only a part of the whole system. In those cases it may be necessary to implement bus type communication, such as CAN or Ethernet. Some sensors can be hard or impossible to model correctly and instead device simulators, such as transducers or thermocouples, may be connected.

3.2.1 Selecting the right interface

When designing the test platform, the tester may decide to use a different interface than is

present in the final product. This can for example be because of logistics, i.e. cabling for a

(24)

CHAPTER 3. HARDWARE-IN-THE-LOOP SIMULATION PLATFORM

Figure 3.1. Typical HIL simulation setup. The control system communicates with a simu- lator which is controlled by the user via a personal computer.

serial interface is much easier to manage than for multiple sensors and actuators.

However by using a different interface than in the final product, the testing is degraded to some degree. The final interface has not been tested and the control code presumably has to be modified to use the secondary interface that is in the testing. The tester must then investigate or preferably take into account dynamics added by the new interface, as well as the dynamics removed by not using the actual interface, in the simulation.

3.2.2 Serial Peripheral Interface Bus(SPI)

SPI is a synchronous serial bus protocol designed by Motorola supporting up to 10Mbps data rate. The interface has become an unofficial industry standard and is widely used [15]. SPI is for instance used to communicate with flash memory, SD cards and sensory equipment like touchscreens and temperature sensors.

SPI supports synchronous full-duplex master/slave communication [15]. Full-duplex communication is when data can be simultaneously sent in both directions, in SPI this is achieved by separate signal lines. A good example of a full-duplex communication device is a cellulare telephone, where both parties can talk at the same time.

SPI is a master/slave protocol, where one device is designated master and other devices on the bus are designated slaves. The master is the only device that can initiate com- munication, and only the master can communicate with the slave devices. Synchronous communication means both master and slave are running on the same clock. During each clock cycle a full-duplex transmission is executed, the master sends data to the slave and the slave responds by sending data to the master.

12

(25)

3.3. REAL-TIME SCHEDULING

3.3 Real-time scheduling

During normal running, a simulator performs the actions shown in Figure 3.2. The model is updated with a fixed time interval, this interval is called the model time-step T

_m

. The distribution of actions over the time-step is shown in Figure 3.3. Updating outputs and reading inputs is near instantaneous. Calculation time is mainly affected by the complexity of the model and the performance of the simulator.

Figure 3.2. Flowchart of the actions performed by a running real-time simulator. After the initialization, the simulators output is triggered at the beginning of each step.

t 0

1 Update outputs

2 Read inputs

3 Calculate 4

Wait

T

m

Figure 3.3. Timing graph for actions during each time-step of model. Input/output takes a small time, compared with calculating the model.

3.4 Selection of time-step

In real-time simulations, the period, or time-step (T

_m

), of the model must be constant and selected before running. If T

m

is not constant, it cannot be guaranteed that the model has the correct state at a given time. When selecting T

m

two things must be kept in mind;

T

m

must be small enough that the simulation is numerically stable and does not produce erroneous output and T

m

must also be equal or less than the controller sample time T

s

, else the model does not take all inputs from the controller into account. In the case of a servo controller, T

s

becomes smaller and smaller as accuracy requirements go up. This means the simulator has less and less time to calculate the model.

Let us now explore different selections of T

_m

and how it affects the performance of the system.

Typical control system

First consider a typical closed loop control system, as the one shown in Figure 3.1, where

the controller output is u

c

and the model output is y

m

. The control loop of the system

has a sample time T

s

and the time until the control signal has been updated is T

c

. This

time can vary depending on system load and priority of other tasks running on the control

system. In each control loop the system samples its inputs, calculates a new control signal

and updates the output, then it waits for the next loop, see Figure 3.4.

(26)

CHAPTER 3. HARDWARE-IN-THE-LOOP SIMULATION PLATFORM

Figure 3.4. Flowchart of the actions performed by a running control system. After the initialization, the control system reads inputs at the beginning of each control loop.

3.4.1 Real machine

The ultimate goal of a HIL simulation is to be indistinguishable from the real system. The real system is therefore presented as a baseline for performance. The machine operates in continuous time, so u

_c

= u

_m

when the control signal is sent and y

_m

= y

_c

when the control system reads the position of the machine. As seen in Figure 3.5, the control system reads y, calculates the control signal, u, and sends it to the machine.

Control System Interface Machine

Get y

y_m yc

Calculate

Set u_c

um

Wait Control loop Control loop

(a) Sequence diagram for one control loop

t

T_s Tc

u(t)

u_c u_m y(t)

y_m

yc

(b) Signal propagation, the continuous machine is sampled with rate Ts

Figure 3.5. Control system running with real machine. Communication between the control system and machine is instantaneous.

3.4.2 Triggering the model

There are two ways of triggering the model time-step (telling the model when a new period has started); using the internal clock (unsynchronized), or using an external signal from the control system (synchronized). To run in synchronized mode, an additional digital input is used to send the clock signal.

14

(27)

3.4. SELECTION OF TIME-STEP

3.4.3 Internal clock triggering

In HIL the model is normally run with the internal clock of the simulation platform. In [16] it is suggested that when using the internal clock a maximum T

_m

of 1/5 T

_s

should be used. The reason is that T

s

may vary according to T

m

. This can for instance happen due to other processes in the control system having higher priority. The maximum delay in input or output is one model time-step T

m

[16]. The effect of this variation can be seen in Figure 3.6. A delay of both input and output signals is observed. A side effect of this issue is that the number of time-steps seen by the control system can vary between loops.

Presuming that measured signal is position, the effect would be observed as jitter in speed.

t

T_s T_c T_m u(t)

u_c

u_m y(t)

ym

yc

Figure 3.6. Signal propagation when Tsand Tmare unsynchronized. Both input and output signals are delayed until the next read.

3.4.4 External triggering

With external triggering the control system sends a signal to the simulator for each time- step. This makes the system more predictable, and the variation in sample time becomes irrelevant. Now we want to test whether this added predictability gives opportunities to run fewer model time-steps during each control loop. This would allow more complex models to be run with faster control systems.

Model and controller running in same period

Setting T

m

= T

s

and triggering the model at the start of the control loop results in the

sequence diagram in Figure 3.7. The propagation of the actuation signal lags behind by

one model time-step. Looking at Table 3.1, the problem is apparent at time t

1

. Since the

model is running in the same period as the control system, but the output of the control

system happens at time T

c

after the period starts. The simulation platform adds a delay of

T

_s

− T

c

to the input of the machine and assumes that the output happened at t

1

.

(28)

CHAPTER 3. HARDWARE-IN-THE-LOOP SIMULATION PLATFORM

Control System Interface Interface Model

Calculate

Wait Set u_c

u(n − 1) Wait

Start loop

Set ym y(n) Get yc

y(n)

Calculate Get u_m

u(n − 1)

Calculate

Wait Set uc

u(n) Wait Control loop Control loop

Start loop

Set y_m y(n + 1) Get y_c

y(n + 1)

Calculate Get u_m

u(n)

Figure 3.7. Sequence diagram when Tsand Tmare equal. Here there is a delay between uc

and umequal to Ts− T_c.

Table 3.1. Inputs and outputs of model and control system when Ts and Tcare equal and synchronized. Here there is a delay between ucand umequal to Ts− Tc. The signals are bold where there is a delay.

Time u

_c

u

_m

y

_m

y

_c

c

Triggering on the actuation signal

Another way of synchronizing the control system and model would be to trigger the model when the output of the control system has been set. As can be seen in Figure 3.8, this leads to a delay in the actuation signal. The delay is equal to T

m

− T

c

.

16

(29)

3.4. SELECTION OF TIME-STEP

Control System Interface Interface Model

Set y_m y(n − 1) Get u_m u(n − 1)

Calculate

Wait Model loop

Model loop

Start loop Set uc

u(n − 1) Wait

Get yc y(n − 1) Calculate

Set u_c u(n) Wait Control loop Control loop

Start loop

Set ym y(n) Get um

u(n)

Calculate

Wait Get yc

y(n) Calculate

Figure 3.8. Sequence diagram when Ts and Tc are equal and Ts is synchronized with Tc. Here there is a delay between ymand ycequal to Ts− Tc.

Table 3.2. Inputs and outputs of model and control system when Ts and Tcare equal and Tsis synchronized with Tc. Here there is a delay between ymand ycequal to Ts− Tc. The signals are bold where there is a delay.

Time u

_c

u

_m

y

_m

y

_c

_m

Oversampling

The usual way to tackle the problem of delays introduced by the simulation platform is

oversampling. This means running the model with a time-step that is smaller than the

(30)

CHAPTER 3. HARDWARE-IN-THE-LOOP SIMULATION PLATFORM

period of the control system. That is, T

m

=

_n¹

· T

s

where n >= 1. When oversampling the model and running with an external clock, as shown in the previous section, one can choose between two scenarios:

• No delay in u and possible delay of one T

_m

in y

• No delay in y and possible delay of one T

m

in u

Generally it should be better for the stability of the system to have no delay in input, since the controller assumes a constant interval between reading y. However, if T

m

is sufficiently large the system may become unstable.

18

(31)

Chapter 4

Modeling

4.1 SimMechanics model

In the SimMechanics model, all bodies are modeled as rigid. The bodies are inter-connected with one or more joint blocks that limit the movement of the bodies with respect to each other. The system has six degrees of freedom. Figure 4.1 shows how the bodies are con- nected. The frame is connected to ground by four feet, then four bearings hold the beam in place on which the wagon connects via two bearings. The location of bearings connecting the beam to the frame, and the wagon to the beam is shown in Figure 4.2. The feet of the machine are located on the corners of the frame.

Figure 4.1. Diagram showing the physical connections in the SimMechanics model. The frame is connected to ground by four feet, then four bearings hold the beam in place on which the wagon connects via two bearings.

(32)

CHAPTER 4. MODELING

Figure 4.2. Physical location of bearings on the MY500 beam(Y-axis) and wagon(X-axis).

The beam is supported by four bearings, while the wagon sits on two.

4.2 Simulink model

Because of the tight deadlines imposed by the control system, a Simulink model with limited dynamics is developed. The model is a simplification of the SimMechanics model. It will allow evaluation of whether the dynamics present in the SimMechanics model have an effect on the test performance. The model is a simplification of the SimMechanics model. The model has two degrees of freedom, considering only movement in X and Y direction. The two axis are independent and do not affect each other. The model reduces the mechanical system of each axis to an actuated mass affected by friction as seen in Figure 4.3.

The system can be described by a force balance as shown in Equation 4.1.

F

mass

= F

motor

− F

f riction

(4.1) where

F

_mass

= m · ¨ y (4.2)

F

motor

= K

t

· i (4.3)

Figure 4.3. Free body diagram for Simulink model. The motor acts on the mass, and the friction resists the motion.

20

(33)

4.3. REQUIRED PARAMETERS

> F

c

F

_c

· sgn(v) + d · v otherwise

(4.4)

where F

f

is the friction force, F

c

is the Coulomb friction level, d is the viscous friction coefficient and F

a

is the applied force.

Dynamic model

Substituting Equations 4.2, 4.3 and 4.4 in Equation 4.1 gives our model:

¨ y =



 

 

1

m

(K

_t

· i − F

_a

) when − dv < v < dv and F

_a

< F

_c

1

m

(K

t

· i − F

c

· sgn(F

a

)) when −dv < v < dv and F

a

> F

c 1

m

(K

_t

· i − F

c

· sgn(v) − d · v) otherwise

(4.5)

The resulting Simulink model can be seen in Figure 4.5

4.3 Required parameters

To be able to run the Simulink model, there are six unknown parameters that need to be

acquired;

(34)

CHAPTER 4. MODELING

Figure 4.5. Block diagram for Simulink model. The input is current [A], while the main output is position[m].

• Static and dynamic friction for X and Y-axis.

• Mass of beam (Y-axis) and wagon(X-axis)

• Motor constants for the motor controlling each axis.

There are three sources of information regarding these parameters.

CMOT3 source code

The control code implements a feed-forward model of the mechanics. The friction model is similar to the one implemented in this thesis, and the parameters are on the correct form.

SimMechanics model

The SimMechanics model implements a similar feed-forward model as the control code, and the parameters are on the same form.

Settings in production machines

Settings can also be viewed in machines in a testing lab at MM. This is done to validate the parameters found in source code and the SimMechanics model. The parameters in the machines were the same as in the SimMechanics model.

The parameter information differs somewhat depending on source since they can vary from machine to machine. The controller feed-forward model implements both good esti- mates and specially calibrated values for the parameters.

4.4 Results

To compare the models and verify that the Simulink model has similar characteristics as the SimMechanics model, different actuation signals are applied to them. The models are run in open loop, meaning that they are not controlled based on their output. Firstly the models are actuated with a high frequency sine wave. Then a 26 A step is applied to analyze the step response of the models. Finally, to check the performance of the friction model, a low

22

(35)

4.4. RESULTS

amplitude sine wave is applied to the system. This should show how the models behaves when the velocity is close to zero.

4.4.1 Sine wave

Both axes are now actuated with a 26 A, 100 Hz sine wave control signal. This is done to analyze how well the Simulink model follows the SimMechanics model when it receives a high frequency wave. The Simulink model leads the SimMechanics model by a small bit.

This is possibly because of the damping in the SimMechanics model.

X-axis

Figures 4.6, 4.7 and 4.8 show that the models are very similar. The SimMechanics signal is rather erratic, but the models still conform well.

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

−300

−200

−100 0 100 200 300

Time [s]

Acceleration [m/s2]

SimMechanics Simulink

Figure 4.6. Acceleration when X-axis actuated with a 26 A, 100 Hz sine wave. The acceler- ation of the SimMechanics model is rather erratic, but the models still conform well.

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

−0.2 0 0.2 0.4 0.6 0.8

Time [s]

Velocity [m/s]

Figure 4.7. Velocity when X-axis actuated with a 26 A, 100 Hz sine wave. The models have very similar behavior, but the Simulink model seems to lead the SimMechanics model.

(36)

CHAPTER 4. MODELING

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

0 1 2 3 4 5 6 7 8x 10⁻³

Time [s]

Position [m]

Figure 4.8. Position when X-axis actuated with a 26 A, 100 Hz sine wave. The position of the SimMechanics model is rather erratic, but the models still conform well.

Y-axis

The Simulink model also has similar behavior to the SimMechanics model in the Y-axis when actuated with a sine wave, as seen in Figures 4.9, 4.10 and 4.11. Just like on the X-axis, the Simulink model leads the SimMechanics model by a small bit. This is possibly because of the damping in the SimMechanics model.

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

−50 0 50

Time [s]

Acceleration [m/s2]

Figure 4.9. Acceleration when Y-axis actuated with a 26 A, 100 Hz sine wave. Same as on the X-axis, the acceleration of the SimMechanics model is rather erratic, but the models still conform well.

24

(37)

4.4. RESULTS

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

−0.05 0 0.05 0.1 0.15

Time [s]

Velocity [m/s]

Figure 4.10. Velocity when Y-axis actuated with a 26 A, 100 Hz sine wave. The models have very similar behavior, but the Simulink model seems to lead the SimMechanics model.

0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02

−2 0 2 4 6 8 10 12 14x 10⁻⁴

Time [s]

Position [m]

Figure 4.11. Position when Y-axis actuated with a 26 A, 100 Hz sine wave. The position of the SimMechanics model is rather erratic, but the models still conform well.

4.4.2 Step

Now the response of the models when receiving a step input of 26 A is analyzed. The step response gives much information about the stability and performance of the system.

X-axis

The higher order of the SimMechanics model can be seen clearly in Figure 4.12. The final

acceleration value of the models is the same.

(38)

CHAPTER 4. MODELING

0.04 0.045 0.05 0.055 0.06 0.065 0.07 0.075 0.08 0.085 0.09

−100 0 100 200 300 400 500 600 700

Time [s]

Acceleration [m/s2]

Figure 4.12. Acceleration when X-axis actuated with a 26 A step. The SimMechanics model has a much longer settling time than the Simulink model.

Y-axis

In the Y-axis the higher order of the SimMechanics model is also very obvious, as seen in Figure 4.13.

0.04 0.045 0.05 0.055 0.06 0.065 0.07 0.075 0.08 0.085 0.09

−50 0 50 100 150 200

Time [s]

Acceleration [m/s2]

Figure 4.13. Acceleration when Y-axis actuated with a 26 A step. Like in the X-axis, the SimMechanics model has a much longer settling time than the Simulink model.

4.4.3 Low amplitude sine wave

To analyze the performance of the friction model, a low amplitude sine wave is applied to the system. This should show how the models behaves when the velocity is close to zero.

The sine wave input frequency is 5 Hz for both axes, but the amplitude is 0.5 A for X-axis and 0.8 A for Y-axis.

X-axis

In Figure 4.14 it can be seen that the friction model of the SimMechanics model has some problems when the velocity is very close to zero. The Simulink model still follows the SimMechanics model fairly well, as seen in Figure 4.15 and Figure 4.16, but there is a slight difference in position.

26

(39)

4.4. RESULTS

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−8

−6

−4

−2 0 2 4 6 8

Time [s]

Acceleration [m/s2]

Figure 4.14. Acceleration when X-axis actuated with a 0.5 A, 5 Hz sine wave. The acceler- ation of the SimMechanics model is very erratic, especially when velocity is close to zero.

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−0.08

−0.06

−0.04

−0.02 0 0.02 0.04 0.06 0.08

Time [s]

Velocity [m/s]

Figure 4.15. Velocity when X-axis actuated with a 0.5 A, 5 Hz sine wave. The velocity of the two models is very similar.

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−0.5 0 0.5 1 1.5 2 2.5

3x 10⁻³

Time [s]

Position [m]

Figure 4.16. Position when X-axis actuated with a 0.5 A, 5 Hz sine wave. The position of the two models is very similar but there is a slight difference at maximum deviation from 0.

Y-axis

For the Y-axis, the Simulink model also follows the SimMechanics model fairly well, as seen

in Figure 4.18 and 4.19. Figure 4.17 shows the same behavior in the Y-axis as Figure 4.14

(40)

CHAPTER 4. MODELING

does for the X-axis. As said before, this is due to the friction model of the SimMechanics model having some problems when the velocity is very close to zero.

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−3

−2

−1 0 1 2 3 4

Time [s]

Acceleration [m/s2]

Figure 4.17. Acceleration when Y-axis actuated with a 0.8 A, 5 Hz sine wave. Same as on the X-axis, the acceleration of the SimMechanics model is very erratic, especially when velocity is close to zero.

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−0.02

−0.015

−0.01

−0.005 0 0.005 0.01 0.015 0.02

Time [s]

Velocity [m/s]

Figure 4.18. Velocity when Y-axis actuated with a 0.8 A, 5 Hz sine wave. The velocity of the two models is very similar, but the Y-axis does not follow as well as the X-axis.

28

(41)

4.5. SUMMARY

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

−2 0 2 4 6 8 10x 10⁻⁴

Time [s]

Position [m]

Figure 4.19. Position when Y-axis actuated with a 0.8 A, 5 Hz sine wave. The position of the two models is very similar but there is a difference in position during deceleration.

4.5 Summary

The Simulink model is a fairly good simplification of the SimMechanics model. The Simulink

follows the SimMechanics model much better in the X-axis, than in the Y-axis. The re-

sponse of the SimMechanics model lags behind the Simulink model. This is likely due to

unmodeled dynamics in the Simulink model. The effects of these unmodeled dynamics may

be seen when the tests are performed with the real-time platform. The friction model of

the SimMechanics model has problems when the velocity is close to zero, resulting in the

acceleration becoming erratic for both X and Y-axis.

(42)

(43)

Chapter 5

Implementation

5.1 dSPACE MicroAutoBox II

The real-time simulation platform used in this project is the dSPACE MicroAutoBox II (MABX). The MABX is a very portable and rugged platform, and is often used for rapid control prototyping(RCP) and field testing [18]. The system used in this thesis consists of a DS1401 base board and a DS1507 I/O board. A DS1552 Multi I/O Module is attached and it is used for SPI communication.

System specifications[18]:

• Processor: IBM PowerPC 900Mhz

• Memory: 16MB main/6MB for host communication

• Interfaces: Ethernet/CAN/RS232/USB/SPI

• Input/Output:

Analog: 12-bit resolution (0-5V)

Digital: 16-bit resolution (5V TTL or up to 40V)

• SPI communication is provided by the DS1552 I/O extension.

• Connection to host computer via Ethernet.

The system is supported by an extensive blockset for Simulink.

5.2 Simulator configuration

5.2.1 Hardware

As mentioned earlier, the hardware used in the implementation consists of the CMOT3 controller and a dSPACE MicroAutoBox connected via SPI, as seen in Figure 5.1. The setup is conceptually identical to the one shown in Figure 3.1.

5.2.2 Software

The software, running on the simulator is made up from three main blocks, see Figure 5.2.

A communications block for sending/receiving messages, a switch to choose internal or

external control signal and the MY500 model. The communication block is triggered when

(44)

CHAPTER 5. IMPLEMENTATION

Figure 5.1. The hardware setup of the simulator. The MABX is connected via the SPI interface to the CMOT3 controllers debug port. A laptop (not shown) is used to control the MABX.

the communication interface receives data. The switch and model run on the step time specified before starting the simulator. The communication block has highest priority and will preempt the other processes running on the simulator. The user interface which is used to manipulate the model and view data is described in Appendix C. All parameters of the model are available for modification during run-time.

Figure 5.2. The three basic elements in the simulator loop. Communications block for sending/receiving messages, a switch to choose internal or external control signal and the MY500 model.

32

(45)

5.3. COMMUNICATION

5.3 Communication

As mentioned in Section 1.4.1 the simulator communicates with the control system via SPI. The protocol is designed to send data to the simulator for logging and to control the dynamical model. A more detailed description of the protocol is included in Appendix A.

The communication has two modes; firstly the controller can send control signals to the model and control it in a normal way, secondly the controller can reset the model and set the current position of both X and Y axes. The mode is decided by the first byte in the SPI message. A whole cycle of the SPI communication protocol occurs in each control loop.

The control system (CMOT3) is master and initiates all communication.

Transfers of data are triggered twice during each SPI cycle. After the first byte is received from the control system the model output is read and sent via SPI. While the simulator reads the model output, the control system must wait. The minimum wait time was determined to be 10µs, a shorter time lead to lost messages. The second interrupt happens after the last byte has been received.

To verify that the communicated messages are valid, a checksum is calculated at the end of each SPI cycle. A checksum is calculated on both sides for sent, and received data.

The checksum is compared on the simulator side.

5.4 Changes to controller code

To enable control over SPI, changes are needed in the CMOT3 controller.

• Add code to enable SPI hardware.

• Add code to send and receive SPI messages.

• Add code to calculate checksum.

• Modify code to use spi data for control purposes.

The modification of the code involved changing the control loop so that the controller

sends and receives SPI messages at correct times in the loop, as seen in Appendix A. The

modifications and additions made in this thesis are rather implementation specific. Even

so, a pseudo code implementation of a control loop with SPI communication is included in

Appendix B.

(46)

(47)

Chapter 6

Results and analysis

6.1 Calculation time

First the models are tested running in open loop to determine how long it takes to calculate one time-step. Tests of different step sizes are made. The selection of step times is based on the control loop time. Firstly we test having a step time equal to the control loop, 200µs.

However according to [16] the model should run at least 5 times faster than the control loop. Since the control loop is 200µs, a 40µs step time is tested. Results of these tests are presented in Table 6.1. Tests show that the fastest possible step time when running in closed loo is 30µs, even though the calculation time is only 8.5µs. The reason it can not run faster is that there are other tasks running on the HIL simulator, such as the SPI communication.

Table 6.1. Model calculation time on HIL platform

Model Step size Average calculation time

SimMechanics 30µs 50ms

40µs 50ms

200µs 50ms

Simulink 30µs 8.5µs

40µs 8.5µs

200µs 8.5µs

The calculation time did not change depending on the step size. The SimMechanics model is completely unable to run within the limits set by the control system, running 250 time slower than the control loop. The Simulink model requires much less time to calculate and runs 20 times faster than the control loop. Since the SimMechanics model is unable to run in real time on the platform, it is not used in the closed loop testing.

6.2 Closed loop simulation

For closed loop testing the trajectory is a move of the wagon from 1.50m to 1.25m. This move is chosen because it covers a large part of the machines movement. First the move is performed on the actual machine. Then moves are performed with the Simulink model.

Hardware-in-The-Loop Simulation of a High Speed Servo System