software system for controlling web-based laboratory final year … · 2004. 8. 18. · interesting...

Software System for Controlling Web-Based Laboratory

Final Year Thesis

Written By: Timothy Davies Supervisor: A/Prof James Trevelyan

Due Date: 04/11/2002

Abstract

In the aim to provide a more efficient learning environment for students, the

ability for reliable control of laboratory equipment over the Internet has been

achieved. This project is part of the Telelabs initiative and involved the

development of a LabVIEW-coded hardware controller for the Mechanical

Engineering Department’s Position Control Rig.

Several major objectives were involved to achieve this aim. Last year, the

hardware received modification to allow for computer control (Lin 2001), so this

year, the project consisted of writing the software to control the hardware locally

and via the Internet. Some of the complications of streaming live video over the

Internet in a LabVIEW/Telelabs environment were also addressed, with some

success. Finally, the system was tested using students enrolled in the third

year “Control and Mechatronics 322” unit. The students were then asked to

participate in an online survey about the system and their responses were

analysed.

Testing yielded many positive results about the reliability of the software. Over

half the students enrolled in the unit participated in the survey and many

interesting suggestions were received that could improve the learning

environment the system provides. At this time, there are still more students that

prefer performing their laboratory experiments in the classroom. This proportion

should decrease considerably however, when the suggestions they made have

been addressed. Most students also indicated that they thought they would

learn more from the remote experiment than from a simulation alone.

For the laboratory to be completely remote next year, there are several issues

that require attention. The most important of these is the results collected by

students, must be more consistent. Hardware fatigue is the cause, so the rig

should be overhauled early next year. If the other suggestions from students

are also completed, the laboratory should be a great success for students next

year.

Timothy Davies

85 Stafford Way

Wanneroo 6065

Western Australia

30 October 2002

The Dean

Department of Engineering

University of Western Australia

Nedlands 6009

Western Australia

Dear Sir,

It is with great pleasure to submit my thesis entitled:

Software System for Controlling Web-Based Laboratory

This thesis was undertaken with the Department of Mechanical and Materials

Engineering, as part of the requirement for my Bachelor of Engineering degree.

It was taken under the supervision of Associate Professor James Trevelyan.

Yours sincerely,

Timothy Davies

Contents iv

Contents

Abstract ........................................................................................................... ii

Contents ......................................................................................................... iv

Figures and Tables........................................................................................ vii

Acknowledgements .......................................................................................viii

List of Acronyms............................................................................................. ix

Chapter 1 ...........................................................................................................1

Introduction......................................................................................................1

1.1 Objectives .........................................................................................2

1.2 Scope of this Thesis..........................................................................3

1.3 Experimental Setup...........................................................................5 1.3.1 Hardware Components used by the Position Control Rig .................................. 5

Chapter 2 ...........................................................................................................6

Background and Related Work........................................................................6

2.1 The Need for Web-based Laboratories .............................................6

2.2 “Information Technology Online” .......................................................7

2.3 “A Collaborative WebLab” .................................................................8

2.4 A “Telerobotic Training System”........................................................9

2.5 A “Framework for Internet Telerobotics”..........................................10

2.6 Analysis of Other Universities .........................................................11

2.7 Telelabs ..........................................................................................11

Chapter 3 .........................................................................................................13

The Simulations.............................................................................................13

3.1 Using Dynamic Equations of Motion ...............................................14 3.1.1 The Mathematical Model................................................................................... 14

3.2 Using Control Theory ......................................................................17 3.2.1 The Simulation’s Objectives.............................................................................. 18 3.2.2 Simulation Design ............................................................................................. 18 3.2.3 Simulation Testing............................................................................................. 19

Chapter 4 .........................................................................................................20

Local Control .................................................................................................20

4.1 Overview of Local Control ...............................................................20

4.2 The Hardware Master .....................................................................21

Contents v 4.2.1 The PID Controller ............................................................................................ 21

4.3 Interface Design..............................................................................22

4.4 FieldPoint® .....................................................................................23 4.4.1 FieldPoint® Components .................................................................................. 23 4.4.2 FieldPoint® Operation....................................................................................... 24 4.4.3 Real-time Data Collection and Control.............................................................. 24 4.4.4 Using Watchdog Timers.................................................................................... 25

Chapter 5 .........................................................................................................26

Remote Control .............................................................................................26

5.1 The Remote Client ..........................................................................27

5.2 DataSocket .....................................................................................27 5.2.1 DataSocket Fundamentals................................................................................ 27 5.2.2 The DataSocket API.......................................................................................... 27 5.2.3 The DataSocket Server..................................................................................... 28

5.3 The Bandwidth Problem..................................................................28

5.4 Packet Loss and Packet Surging ....................................................29

5.5 Communications in the Telelabs .....................................................29

Chapter 6 .........................................................................................................31

Real-Time Video Transmission .....................................................................31

6.1 Problems associated with Video Transmission ...............................31

6.2 Choosing a Camera ........................................................................31

6.3 User Datagram Protocol..................................................................32

6.4 Design of Camera Software ............................................................32

6.5 Camera Testing...............................................................................33

Chapter 7 .........................................................................................................34

Feedback from Students ...............................................................................34

7.1 Analysis of Results..........................................................................35

Conclusions...................................................................................................44

Recommendations for Future Work...............................................................46

References ....................................................................................................49

Appendix I...........................................................................................................I

The Hardware Master as a Service ..................................................................I

Appendix II...................................................................................................... XII

Rig Configuration on the LOL-Server ........................................................... XII

Appendix III.................................................................................................... XIII

Components of the Position Control Rig ..................................................... XIII

Contents vi

Appendix IV ....................................................................................................XV

Communication Protocols ............................................................................XV

Appendix V ...................................................................................................XVII

Calculating the Response Function............................................................XVII

Figures and Tables vii

Figures and Tables

Figure 1: The Position Control Rig.................................................................................................5 Figure 2: Flow of data with the Information Technology Online system. (Stoll & Hopp 2002) .....7 Figure 3: The architectural setup. (Marin & Sanz 2002) ................................................................9 Figure 4: Framework used by The Telerobot...............................................................................10 Figure 5: The Telelabs System Architecture................................................................................12 Figure 6: Components used in the mathematical model. ............................................................14 Figure 7: The finite state machine used to model friction. ...........................................................17 Figure 8: The Simulation Interface...............................................................................................18 Figure 9: Manual and computer controlled operation of the Position Control Rig. (LIn 2001)....21 Figure 10: Configuration tab of the Hardware Master..................................................................22 Figure 11: The FieldPoint® Modules.. .........................................................................................24 Figure 12: Illustration showing the rate of signal change.............................................................25 Figure 13: The Remote client interface........................................................................................26 Figure 14: The transfer of data between the publisher and the subscriber. .................................28 Figure 15: Representation of a potentiometer. ...........................................................................XIII Figure 16: Differencing circuit used by the Position Control Rig.................................................XIII Figure 17: The PID circuit used by the Position Control Rig...................................................... XIV Figure 18: The servo-amplifier used by the Position Control Rig. ............................................. XIV Figure 19: Representation of a gearbox. ................................................................................... XIV

Table 1: Symbols used for the mathematical derivation of the simulation model. .......................14 Table 2: Parameters used to model the motor. ............................................................................16 Table 3: The time the students spent on the equipment in the laboratory for task1. ...................38 Table 4 Reasons why students performed the experiment for the time they did. ........................38 Table 5: Reasons why students preferred local control. ..............................................................39 Table 6: Reasons why students preferred remote control. ..........................................................39 Table 7: Reasons why students would prefer real hardware. ......................................................40 Table 8: Reasons why students felt comfortable controlling the rig remotely. .............................40 Table 9: Reasons why students felt uncomfortable using the rig remotely..................................41 Table 10: What did you like about using the rig remotely? ..........................................................41 Table 11: What did you like about using the rig locally? ..............................................................41 Table 12: What did you dislike about using the rig remotely?......................................................42 Table 13: What did you dislike about using the rig locally?..........................................................42 Table 14: Can you think of anything we could do to improve the laboratory? .............................42 Table 15: Do you have any other comments?..............................................................................42

Acknowledgements viii

Acknowledgements

There have been many people that have assisted me throughout this project’s

duration all of whom require thanks.

I would especially like to thank my parents for their never-ending love and

support. Without them, it would not have been possible for me to be here at this

stage of my life.

A/Prof. J. Trevelyan has been an excellent supervisor for the whole year and I

would particularly like to thank him for the times when he provided assistance at

times where I have not been able to diagnose server faults.

Dr Wenge Liu also requires thanks, as he allowed suitable access through the

Mechanical Engineering Department’s computer network firewall for me. This

made it possible for a large amount of development and testing to be done from

my computer at home. Without this access, this project would have been

considerably more difficult and time consuming.

Last of all, I would like to thank Mr. Yan Baranski and Dr. Alex Le Dain, for

providing technical support for my project.

List of Acronyms ix

List of Acronyms

TCP – Transmission Control Protocol

IP – Internet Protocol

PID – Proportional, Integral and Differential

UDP – User Datagram Protocol

ISO – International Standards Organisation

OSI – Open Systems Interconnect

I/O – Input/Output

URL – Uniform Resource Locator

ADSL – Asynchronous Digital Subscriber Line

ISDN – integrated Services Digital Network

DSTP – DataSocket Transfer Protocol

HTTP – Hypertext Transfer Protocol

API – Application Programming Interface

LOL – Laboratories-on-Line

MOM – Message Oriented Middleware

ACK - Acknowledgement

PPP – Point to Point Protocol

ISP – Internet Service Provider

IPv4 – Internet Protocol version 4

IPv6 – Internet Protocol version 6

OLE – Object Linking and Embedding

OPC – OLE Process Control

LAN – Local Area Network

WAN – Wide Area Network

CORBA – Common Object Request Broker Architecture

MATLAB – Mathematics Laboratory

DSP – Digital Signal Processor

A/D – Analogue to Digital

D/A – Digital to Analogue

ASCII – American Standard Code for Information Interchange

UWA – The University of Western Australia

List of Acronyms x

DVD – Digital Video Disk

kb/s – Kilobits per second

Mb/s – Megabits per second

OS – Operating System

VI – Virtual Instrument

CD – Compact Disk

MSI – Microsoft® Installer

CCChhhaaapppttteeerrr 111

Introduction

With the ever-advancing use of technology in industry, machinery is being

designed with an ever-increasing proportion of electronics with computer

control. Distributed control and monitoring systems in industry have been

developed that use computers to monitor machine operation and to send control

signals from remote locations when required. Many of these systems operate

using a private Local Area Network (LAN) or Wide Area Network (WAN).

As the popularity of the Internet has increased considerably in the last decade,

connectivity throughout the globe has reached a level where many people can

work from home instead of from the office. It also has provided the facility for

people to monitor and control machinery from anywhere in the world.

This technology can also benefit students, as it can allow them to perform

laboratory experiments on equipment from any computer connected to the

Internet. From this, the Telelabs initiative has evolved.

Telelabs is an online-laboratory management system, developed at The

University of Western Australia (UWA), aimed at allowing students to perform

laboratory experiments from home, in their own time. It manages queues of

students waiting to use the different experiments controlled by the system. An

interface is also provided for academics and laboratory supervisors to mange

laboratories performed on each of the experiment rigs.

Objectives 2

With the traditional laboratory system, it is often not possible for all students to

control the equipment due to time and resource constraints. With a web-based

system, all students are able to control the hardware from home, so they can

spend all the time they need to understand the concepts. This allows students

to become more aware of what they are learning and will be more likely to gain

a lasting knowledge of the experiment topic. The resources required can be

considerably reduced, as the students do not have to be at university when they

perform their experiment.

It is possible to have many different hardware devices managed by this system.

These, for example, could be devices that analyse convection currents in

horizontal pipes, devices that use PID control and devices that analyse

vibration. Integrating control of an experiment rig into the Telelabs system is

the major aspect of this project so remote control can be provided for the

students. The experiment rig chosen for this project was the Position Control

Rig, used for the third year “Control and Mechatronics 322” (CM322) unit.

1.1 Objectives

The major aim for this project was to facilitate an effective Telelabs system

using the Position Control Rig. There were six major objectives for this aim: an

accurate simulation; a stable hardware controller; effective remote interfaces; a

tele-vision system; system reliability testing, and to obtain student feedback.

The simulation involved developing a mathematical model of the system and

implementing that model using the LabVIEW software development

environment. There were several possible approaches and two of these were

analysed for suitability.

The hardware master is the program executed on the runtime computer to

provide control over the hardware to the Telelabs server. This was written with

LabVIEW to use the existing hardware architecture implemented by Lin (2001).

A template was provided, written by Trevelyan (2002) that contained the

necessary software for communication with the Telelabs system. This was

used as the starting point for this part of the development.

Scope of this Thesis 3

The remote client is the interface the students are presented when they perform

their laboratory experiments. This provides access to the hardware master via

the Telelabs ‘Labs-On-Line’ (LOL) server. The development of the remote

client also started from a software template written by Trevelyan (2002).

Effective streaming of real-time video data is a difficult task. The viability of

providing ‘live video’ to students while they are performing their experiments

has been tested with an AXIS2100 network camera, which was purchased this

year. All the software required for this application was written from scratch and

is still under development.

The Telelabs system was tested constantly throughout the project to determine

any areas of unreliability. When items of concern were found, appropriate

action was taken to rectify the problem.

Gathering students’ response to using the system over the Internet was the last

objective. These were analysed so further development of the Telelabs project

can head in a suitable direction.

1.2 Scope of this Thesis

The structure of this thesis follows the order in which the objectives were

developed.

Chapter 2 presents a literature review, which discusses the need for web-based

laboratories and compares the development approaches from other universities

with that used by The University of Western Australia. The first university, The

University of Massachusetts, uses Java client/servlet technology. The second

university, The Technical University of Clausthal, uses a Java/MATLAB

environment. The third university is Jaume-I University, which uses ‘Java3D’

and Common Object Request Broker Architecture (CORBA). The fourth is The

University of Western Australia’s Telerobot. These approaches are compared

and leads to a description of the approach used for the Telelabs system.

Scope of this Thesis 4

Simulation development of the operation of the hardware was the first objective

for this project. Two approaches are discussed in Chapter 3, which were the

use of motion theory, using dynamic equations of motion and control theory,

using transfer functions and Laplace transforms. The design and

implementation is described for both of these approaches.

Chapter 4 describes how the rig is controlled by a local computer. This includes

a discussion about the collection of real-time data and the use of FieldBus

technology in the Telelabs environment. The design of the interface for the

hardware master and the design of the PID controller are also discussed. The

software design specifics of the hardware master template are not mentioned,

as this is proposed for documentation by Trevelyan (2003).

To provide a remote connection to the hardware, knowledge about

communications protocols was required. Ethernet, TCP and IP are only generic

protocols, so they are included in Appendix IV. DataSocket however, is

described in Chapter 5 as it is a major component in the design for remote

control. The transfer of information between the remote client and the hardware

master, and problems such as limited bandwidth and packet loss are discussed.

The ergonomics of the remote interface is important for the students to be able

to perform the laboratory effectively and is discussed in Chapter 5. The

software design specifics of the remote client template are not mentioned, as

this is also proposed for documentation by Trevelyan (2003).

Chapter 6 discusses the design and implementation of the real-time video

transmission system. It includes a description of the problems that were faced

and the approaches to the design that were taken to minimise these problems.

It also describes the theory about why the Universal Datagram Protocol (UDP)

was chosen. The conclusions about the implementation of the live-video

system are then discussed with recommendations for how it could be improved.

Obtaining feedback from students was an important aspect for determining how

effective this online laboratory system is. This was achieved by supervising

laboratories with students working locally on the runtime computer and remotely

Experimental Setup 5

from other computers in the department or from their homes. An online survey

was written and the results are analysed in Chapter 7, but should be analysed

further by someone with more experience with student behaviour

1.3 Experimental Setup

The Control and Mechatronics 322 unit has used the Position Control Rig for

many years. In 2001, the original circuit board (Chew 1997) was modified to

allow for computer control and a basic software system was written for web-

based control. (Lin 2001) This section describes the hardware components

used by the rig.

1.3.1 Hardware Components used by the Position Control Rig

The hardware used for this experiment, shown in Figure 1, consists of the basic

requirements of a feedback, position control system. These components

include:

Figure 1: The Position Control Rig.

• Potentiometers – The set point and feedback potentiometers for

determining desired position and current position.

• Power Supply – To convert 240V AC to 12V DC.

• Gearbox – To increase the velocity of the pointer.

• Servo-Amplifier – To provide control over the amount and polarity of

voltage to the motor.

• Controller – A Proportional, Integral, Differential type controller.

• Servomotor – To provide the motion of the pointer.

• Computer – To read, manipulate and transmit the data.


2.1

Background and Related Work

Technology is integrating rapidly into academia and has led to the development

of new teaching techniques called ‘tele-learning’ and ‘tele-laboratories’. This

chapter discusses the tele-laboratory approaches that are being developed by

other universities. These approaches have been compared with that used by

UWA with the Telerobot and leads to a description of the new approach

currently being developed.

The Need for Web-based Laboratories

The ‘traditional’ laboratory, currently used in the Faculty of Engineering, forms a

significant part in the assessment of students. Usually they are two to three

hours each and supervised by post-graduate students. The number of students

is kept to a minimum wherever possible, but timetabling and cost restraints

usually keep this number between five and ten students for each laboratory

session. The cost of a laboratory includes materials consumed in the exercise,

hire of the facility, hire of the supervisor, and the provision of written material for

the students.

A virtual laboratory only requires a computer with an internet connection and

can allow for an almost unlimited number of students to participate in the

laboratory exercise simultaneously. This means that all expenses related to

“Information Technology Online” 7

physical equipment are avoided, but unfortunately, many ‘quirks’ involved with

real equipment in the real world are difficult to address.

A compromise between these two extremes exists that can reduce the

resources required for laboratory exercises considerably. This is different from

a virtual environment in that the equipment is real, but the students can perform

the experiment from a different location. This use of computers as human to

laboratory interfaces can reduce the impact of many of the disadvantages with

the traditional system. (Boden 2000) For this reason, many universities are

currently developing web-based laboratories.

2.2 “Information Technology Online”

“Information Technology Online”, is an approach to tele-learning in the field of

control systems technology. Stoll and Hopp wrote this case study, in 2002, at

The Technical University of Clausthal in Germany. The way they are

developing this system is slightly different to many other studies that were read,

as it uses Java and the MATLAB/Simulink environment with a DSP card.

Figure 2: Flow of data with the Information Technology Online system. (Stoll & Hopp 2002)

The operation of the system is shown in Figure 2. On the user side, a Java

applet is running as a TCP client within a web browser. The applet opens a

socket connection to a TCP server implemented inside MATLAB. In this applet,

the user can enter the control parameters. The data is transmitted via the

socket to the MATLAB server. After the results have been examined for

validity, they are sent directly to a real-time system containing a Digital Signal

Processor (DSP).

“A Collaborative WebLab” 8

The DSP is connected to the rig by Analogue to Digital (A/D) and Digital to

Analogue (D/A) channels. The values measured from the rig are transmitted to

the DSP and then transmitted via MATLAB, to the applet. The data is

transferred as American Standard Code for Information Interchange (ASCII)

vectors and are sent at approximately two second intervals. If an interruption

occurs while the socket is open, the connection loss triggers an automatic

shutdown of the system to return the hardware to a safe state.

They have reported that there has been positive feedback about the technical

aspects of the project, but they did not specify what these aspects were.

2.3 “A Collaborative WebLab”

The “Collaborative WebLab for Online Microelectronics Device Categorisation”,

recently developed at The University of Massachusetts (MIT) uses Java

client/servlet technology. (Chang and del Alamo 2002) The system, originally

designed for a single user was too restrictive, so they integrated a “modification

token” scheme to allow concurrent connections.

On the client applet, an option has been provided to establish a persistent

socket connection between the applet and the collaboration server. To do this

effectively, they designed a new communications protocol consisting of thirteen

commands for obtaining the users’ status, for token delegation and for

pushing/pulling data to/from the server. The user can obtain the token by

default, by handover or by inheritance. Inheritance operates at random when

the holder disconnects from the collaboration server. An assumption they have

made is that no user will ‘hog’ the token and they have proposed a voting

mechanism to “impeach the hog”.

The user connects to two domains: the group domain and the individual

domain. The holder of the modification token can modify frames in the group

domain. The individual domain remains under the control of the local user

where he/she can perform tests without affecting the group domain.

They have reported success from student testing; however, they did not specify

the areas where the success occurred.

A “Telerobotic Training System” 9

2.4 A “Telerobotic Training System”

The “Telerobotic Training System through the Web”, is an approach being

developed by Marin and Sanz (2002) at Jaume-I University in Spain. It has

been designed to use a virtual 3D Java environment as well as a real robot.

The system architecture design is shown in Figure 3. The client side consists of

a single process implemented in Java and running through a web browser. It

uses the CORBA and HTTP standards to communicate with the server

machine, which consists of several concurrent processes. The communication

between the server and the clients is channelled through the HTTP port of the

computer to avoid firewalling problems.

Figure 3: The architectural setup. (Marin & Sanz 2002)

The server uses three modules. The first is called the “Robot Server” that

accepts the CORBA request to move the robot to a given real world coordinate

position. The second is the “Grasping Server”, which is responsible for the

grasping points for every object present in the scene. The third is the “Camera

Server”, which provides an HTTP interface using a WebCam32 camera.

The main project innovation is that the control program responds to commands

such as ”Pick up the big pen”, which uses an object recognition module that

A “Framework for Internet Telerobotics” 10

operates through CORBA. Details of how they developed this part of the

system were not discussed in this article.

There was no mention of results from student testing.

2.5 A “Framework for Internet Telerobotics”

“A Distributed Framework for Internet Telerobotics”, describes the approach

used by Dalton (2000) for developing the framework for “Australia’s Telerobot”

at UWA. This review is from chapter three of his Ph. D. thesis, which made

considerable contributions to the structure adopted for the Telelabs project.

The framework developed occurred after significant testing on a Common

Gateway Interface (CGI) system developed by Dalton and Taylor (1997) and is

illustrated in Figure 4.

Figure 4: Framework used by The Telerobot.

It uses a hub-based architecture that consists of a Message Oriented

Middleware (MOM) server that allows any number of clients to connect to it.

This architecture was chosen to minimise the number of connections in the

system, while still adhering to Java security rules. The framework provided a

Analysis of Other Universities 11

good basis for developing distributed telerobotic applications, which can easily

be used for mechatronic applications.

Dalton found in the development of the system, that there were many problems

with the use of Java. He found that developing a reliable Java applet was

significantly harder than developing a Java application. Part of this was the

requirement that applets were to adhere to internet security restrictions,

whereas the applications did not. The security restrictions were found to be the

most problematic during the development of the project.

He also found that the ‘virtual machines’ that were incorporated into common

web browsers, proved to become unstable when operated for long periods of

time and often caused the browser or the entire operating system to stop

responding.

2.6

2.7

Analysis of Other Universities

Many of the case studies that were analysed have chosen a Java type

configuration, some with similar ideas used by Dalton because of the cross-

platform and internet capabilities. It has been found now with the Telerobot that

complex Java applications and applets do not perform in terms of long-term

reliability. For this reason, the high-level programming language ‘G’, which

uses the LabVIEW software development environment, has been chosen for its

robust base for cross-platform support instead of Java for the Telelabs project.

Telelabs

“Towards Cost Effective On-Line Laboratories” (Trevelyan 2001) describes the

approach UWA is using for the development of tele-laboratories using the

experience gained with the Telerobot. The system architecture implemented by

the Telelabs project is illustrated in Figure 5.

Telelabs is a means to provide staff and students with remote access to

laboratory equipment in a cost-effective manner using the Internet. The server

and backbone of the software has been designed by UWA and the code was

built by Icon Technologies to provide a rugged, maintainable framework. This

Telelabs 12

system has been designed to allow students to build software modules to add

specific laboratory experiments to the system.

Figure 5: The Telelabs System Architecture.

Students need to be able to collaborate in many laboratory classes. When one

student moves the controls, all the other students in the group can see the

controls on their own panels move at the same time and the name of the

student moving the controls is displayed to the others. This arrangement also

allows staff and students to use the system at the same time so staff can

provide remote assistance. A chat window allows text communication between

all simultaneous users. A separate chat window allows communication

between students waiting in the queue.

A robust system must allow for connection failures, particularly as students use

older computers and may not be able to afford high-quality internet connections.

This system can restore broken connections without interrupting experiments.

In these circumstances, the system waits until the student re-connects and the

results are sent by e-mail even if the student does not. If the queuing time is

long, students can disconnect and rejoin the queue closer to the time when they

are likely to gain access.


The Simulations

Simulations are useful in many fields of engineering. These range from flight

simulators for pilots to computer games for children. Many industries also use

simulations to model an operation, such as a machine, or how many machines

or processes interact with each other. A change of parameters on the

simulation can show outcomes without affecting the real world application,

which is useful for learning new concepts and beneficial when making

decisions, as possible performance benefits or losses can be previously

determined.

The simulation used with the Position Control Rig allows students to practise

before they control the equipment. This provides them with an opportunity to

gain a good understanding of how to use the controls and understand the

underlying principles. When they use the rig, they should have greater

confidence due to a better understanding of its operation and should achieve

better results. This hypothesis should be confirmed with later studies.

Two versions of the simulation were created using two different models to

represent the system. The first uses dynamic equations of motion and the

second uses a transfer function with a Laplace transform. Both simulations

were designed to look as close as possible to the remote client interface.

Additional controls were added in both cases however, to allow additional

understanding and greater variability to the simulation’s application.

Using Dynamic Equations of Motion 14

3.1 Using Dynamic Equations of Motion

The first model for the simulation used motion theory, as this was the approach

used for the simulation written for the torsional vibration rig (Trevelyan 2002). A

mathematical model was formed and then coded in the LabVIEW software

development environment. This model was never completed, as it was

superseded with the second model.

3.1.1 The Mathematical Model

This section describes the approach to developing a mathematical relationship

that could be used to represent the system. The symbols used for the

development are shown in Table 1 and the components included iare illustrated

in Figure 6.

Figure 6: Components used in the mathematical model.

Table 1: Symbols used for the mathematical derivation of the simulation model.

mτ - Motor Torque frictionτ - Torque due to Friction

mk - Motor Torque Constant pτ - Torque on the Pointer

mi - Motor Current pθ - Angular Acceleration of the Pointer

ek - Motor BackEMF Constant tI - Total System Inertia

mθ - Angular Motor Velocity mI - Inertia of the Motor

1n - Number of Teeth on Gear 1 mθ - Angular Position of the Motor

2n - Number of Teeth on Gear 2


The total torque generated by the motor can be modelled with two components.

These are the motor torque and the retarding torque caused by back

Electromotive Force (EMF). The motor torque and back EMF constants were

found in the motor data sheet, so were modelled in this way. The formula is

shown in equation(1.1).

m m m ek i k mτ θ= − (1.1)

The output torque of the motor can be used to calculate the torque at the

pointer by including parameters to represent the gear friction and the gear ratio.

This is shown by equation(1.2).

2

1p m m e m friction

nk i kn

τ θ τ = − − (1.2)

Another equation that can be used to calculate the torque at the pointer uses

the total moment of inertia of the system and the angular acceleration of the

pointer. This is shown by equation(1.3).

p t pIτ θ= (1.3)

Combining equations (1.2) and (1.3) forms a second degree differential

equation that can be used to model input current to output position. This is

shown by equation(1.4).

2

1m m e m friction

pt

nk i kn

I

θ τθ

− − ∴ = (1.4)

If we let u pθ= , we can separate the second-degree differential equation into

two single degree differential equations that can easily be solved by a

computer. These equations are shown by equation(1.5) and equation(1.6).

2

1m m e friction

pt

nk i k unu

I

τ − − = (1.5)

p uθ = (1.6)


The following constants shown in Table 2 were found from the Portescap

22N28 motor specifications sheet:

Table 2: Parameters used to model the motor.

Motor Torque Constant 19.3mNm/A

Terminal Resistance 5.80ohms

Back EMF Constant 2.02V/1000rpm

Gear Ratio 160:1

Rotor inertia 3.00kgm^2x10^-7

The equations used to model friction were taken from a handout (Trevelyan

2002), showing the simulation derivation of the torsional vibration rig and can be

modelled as a finite state machine with three states. The software module was

part of the supplied code and its operation is described in this section.

Static State: Torque available = 0

Velocity of motor = 0

Applied torque = 2

1m m

n k in

If ( ) 10%mtorqueapplied f θ> + start to move in either positive or negative

direction.

Positive Rotation:

Torque available = applied torque - ( )mf θ

(2

1m m e m m

n k i k fn )θ θ− − (1.7)

The velocity of the motor is calculated by integration. If velocity < go to

static state. Velocity = 0 and Torque = 0 if enacted immediately (t=0).

limv

Using Control Theory 17

Negative rotation:

Torque available = applied torque + ( )mf θ

(2

1m m e m m

n k i k fn )θ θ− + (1.8)

If velocity > go to static state. Velocity = 0, Torque = 0 if enacted

immediately (t=0).

limv−

Figure 7: The finite state machine used to model friction.

The friction function uses several components. These are friction due to:

eccentricity of gear one, which is 2

1

sin 2 nn

π θ

∝ , eccentricity of gear two, which

is

)(sin 2πθ∝ , surface errors, which are ( )R θ∝ and tooth period which

is ( 2sin 2 n )π θ∝ . Friction due to eccentricity of the gears follows a cyclic pattern

due to the changing of radius of the gears at the contact point. As both gears

have eccentricity, the relationship between the eccentricities is also important.

This is modelled by analysing the tooth period. The surface irregularities are

modelled using a random number generator. These sum together to obtain a

cumulative friction function shown by equation(1.9).

( ) ( ) ( ) (22

1

sin 2 sin 2 sin 2n )f R nn

θ θ πθ π θ π

= + + +

θ

3.2

(1.9)

Using Control Theory

The second simulation was written to model the system using control theory.

This gave students the opportunity to experiment with control systems with


different transfer functions and the opportunity to see the effects of different

step sizes on different numerical integration techniques.

Figure 8: The Simulation Interface.

It was built using the LabVIEW simulation toolbox, which is part of the add-ons

package that came with the UWA license.

3.2.1 The Simulation’s Objectives

Having already studied Control and Mechatronics 322 (CM322), the important

aspects of the course were already known. This then meant determining how

all of these aspects could be incorporated into the Position Control Rig

simulation.

Analysis of a control system (at the third year level) can be performed in the

Laplace, frequency and time domains. To provide analysis in these realms, a

response plot, Bode plot, Nyquist plot and root locus plot were developed.

3.2.2 Simulation Design

The simulation was first written as a standalone application, but when its

performance was at a suitable level, it was incorporated into the remote

interface. The design of the interface is shown in Figure 8.


3.2.3 Simulation Testing

Considerable testing remains, as there are many unresolved issues. These

have been documented for students that will continue with this project. The

testing method used was to compare the results with those calculated last year

when studying CM322. Testing was done on the time response chart against

the response of the rig itself. It was found that similar parameters gave similar

looking responses in most cases, but had very different amplitudes of

oscillation. A suggested reason for this discrepancy is the way LabVIEW

calculates integrals. This is the major issue with this simulation and requires

resolution.


4.1

Local Control

There are two types of local control available with the Position Control Rig. The

first is the analogue control that uses the set point potentiometer, which was

included with the original design of the rig. (Chew 1997) The second is digital

control using the hardware master on the runtime machine. This chapter will

only deal with the use of the hardware master.

To provide control over the Internet, the rig was modified (Lin 2001) to provide

access to the set point, feedback and velocity signals and to provide control to a

relay and to the motor. This enables the runtime machine access to these

voltages via the FieldPoint® modules. This chapter deals with how the signals

were retrieved from the rig, how they were processed by the computer and how

they were sent back to the rig.

Overview of Local Control

Analogue control does not provide the flexibility to students to be able to modify

the PID parameters, as they must be set with a screwdriver on the circuit board.

Figure 9 shows the changes made to the control loop to allow for computer

control and PID parameter modification.

With the rig physically able to be controlled by a computer, suitable software

could be developed.

The Hardware Master 21

4.2 The Hardware Master

The hardware master is the control software used that provides local, digital

control and access from the Internet. At the commencement of this project, the

Torsional Vibration Rig control software (Trevelyan 2002) was undergoing

testing. This software provided a framework that was adapted for the Position

Control Rig as it used good design rules that aimed at reliability and long-term

maintainability.

Figure 9: Manual and computer controlled operation of the Position Control Rig. (LIn 2001)

4.2.1 The PID Controller

Although the hardware master template formed a strong base for the control

software, many modifications were required to adapt it for use with the Position

Control Rig. One of the major additions was the PID controller. A major

teaching objective of the Position Control Rig is for students to learn about the

characteristics of PID control, so it was important to develop a module that

modelled the pointer response correctly.

Interface Design 22

Three previously written PID controller modules could have been used. The

first one was included with the LabVIEW PID add-on package, but this used

automatic tuning parameters so it was rejected because this experiment was to

use the normal PID gain parameters. Lin (2001) wrote another, but this was

rejected also, as it required considerable modifications to be incorporated into

the new system. The other was written by Harjono (2001) and was accurate

(Zhou 2002), but was also rejected because it was written with poor

programming techniques. It was used however, as a model for the new

controller developed during this project’s duration.

Modern programming techniques emphasise the use of abstraction and

encapsulation (Object Oriented Programming 224 Unit), so these were used to

code a new PID controller.

Figure 10: Configuration tab of the Hardware Master.

4.3 Interface Design

The design of control panels on computers forms part of the Human Computer

Interaction (HCI) field of study. It is important to understand how human

characteristics impact the way an interface should be designed. This includes

the size of the text and information, and the perception and discrimination of

colours. It is also important to understand human cognitive performance

capabilities, for instance, knowing how humans make decisions and how they

process information. (Redman & Rajan 1997)

FieldPoint® 23

Figure 10 shows the most complex looking tab used by the hardware master.

For this to seem as simple as possible, all the different sections were grouped

together so their purpose could be distinguished more easily. The colours used

were to allow for easy distinguishing of the groups, to be aesthetically pleasing

and to have an attempt at a soothing effect on the subconscious. These effects

however, have not been tested. The other tabs used by the hardware master

also follow these design rules.

The controls in the left-hand pane were originally designed using dials. These

were changed to the digital controls however, due to requests from the students

that performed the laboratory, as they could not obtain the required level of

accuracy when collecting their results.

4.4 FieldPoint®

FieldPoint® is an easy-to-use modular hardware platform developed by

National Instruments for distributed Input/Output (I/O) that allows

communication between the control software and the hardware. The generic

term for these devices is ‘FieldBus’ and they are becoming increasingly popular

in industry as an alternative to Programmable Logic Controllers (PLC) due to

their ability to be remotely located and their compact size. They use a high-

level language called “G” as their control language instead of ladder logic or

assembly language, and can be programmed with the LabVIEW software

development environment, which is another major advantage.

4.4.1 FieldPoint® Components

Each FieldPoint® bank consists of a network module, terminal bases and I/O

modules. FieldPoint® also includes a variety of both analogue and digital I/O

modules that can be selected. The ones used for the Position Control Rig are

the AI-100, which is an 8-channel 12-bit analogue input module; the DI-301,

which is a 16-channel discrete input module; the DO-401, which is a 16-channel

discrete output module and the AO-210, which is an 8-channel analogue-

voltage output module.

The Ethernet module currently used in the Telelabs is an FP1600. It can

connect directly to standard Ethernet and Fast Ethernet networks using TCP/IP

FieldPoint® 24

and automatically negotiates with the network for communication at 10Mb/s or

100Mb/s baud.

Figure 11: The FieldPoint® Modules..

4.4.2 FieldPoint® Operation

When an Ethernet module receives a signal from the network, it is transferred

via the bus to the appropriate module. The signal is conditioned and then

transmitted to the hardware. The type of conditioning on the signal depends on

the module involved. It may be filtered and, with the use of specialised

electronics, produce the signal specified by the FieldPoint® configuration file to

be transmitted to the hardware.

An input signal works in a similar manner. The input module receives the raw

electrical signal from the hardware where it is conditioned and passed along the

bus to the Ethernet module and then transmitted to the network card of the

runtime machine. The Object Linking and Embedding (OLE) Process Control

(OPC) server, which is embedded in “FPLVMgr.dll”, then passes the data to the

control software.

FieldPoint® Explorer is a configuration utility provided as an add-on to

LabVIEW. It is used to configure entire banks of FieldPoint® modules including

the range of input values, safety shutdown states, and timeout parameters.

4.4.3 Real-time Data Collection and Control

The latency of each component and transport medium add together to form an

overall delay time. This means the data collected by the computer is not

actually real-time data. However, as it can be determined what happened in

real-time, the data is “deterministic”.

FieldPoint® 25

For the deterministic data to be the best representation of the real-time data, the

sampling speed is an important factor. There are three issues to consider when

dealing with FieldPoint® sampling speed. These are the channel update rate,

data throughput rate and the rate of signal change. The slower of these is the

limiting factor. The channel update rate is how fast the data can be read from

the channels. The National Instruments website and their catalogue provide

these figures. The data throughput rate is how fast the data can travel through

the network module to the computer. The rate of signal change, also known as

a transient is represented by Figure 12.

On state A

Off state t

Transient

Figure 12: Illustration showing the rate of signal change.

It is possible that the I/O module will sample data faster than it can be read.

This is called over-sampling and sometimes the I/O module will read the data

faster than it can be refreshed. This is called under-sampling. FieldPoint® has

no built-in features to prevent the loss of data due to overwriting the prior from

update.

4.4.4 Using Watchdog Timers

A watchdog timer is a safety feature built into the FieldPoint® modules.

Watchdogs are used when control data during transmission is interrupted for a

preset minimum amount of time. The Position Control Rig requires a null-

reference voltage for the motor input of 5V. At this voltage, the pointer velocity

is zero. If transmission of the motor control signal were interrupted, the last

signal would still be sent to the motor. This could make the pointer revolve at

full velocity in either direction, which would require the interruption to be

removed, or the hardware to be reset. Watchdogs have been configured in the

FieldPoint® configuration file to set the null-reference voltage for the motor

signal to stop the motor and 0V for the digital signal to return the rig to analogue

control.

C a t r 5 CChhhaappptteeerr 55

Remote Control

Understanding how the rig was to be remotely controlled required a

considerable amount of research. A lot of this was not directly required by the

scope of this thesis, but was required to gain a better understanding of how the

rig was able to communicate the way it did. This additional understanding was

very useful when diagnosing problems and understanding the properties of the

different communication protocols that were used.

Figure 13: The Remote client interface.

The remote client interface was required to communicate with the LOL server

using the MOM server technique. This was shown to work most effectively by

Dalton (2000) and was redesigned to use DataSocket and TCP/IP. How this

The Remote Client 27

design is affected by problems such as limited bandwidth, transmission lags

and packet loss are also discussed in this chapter.

5.1

5.2

The Remote Client

The remote client is the interface students use to control the hardware over the

Internet. The most important objective was to provide an easy to use interface

for visualising the data and to send control signals. The interface that was

designed, shown in Figure 13, uses the same colour scheme as the hardware

master and allows the user to change the colour of the traces to their own visual

preference. The chart can also be paused, so students can use the zoom

function to calculate required parameters.

DataSocket

DataSocket is an internet programming technology developed by National

Instruments that simplifies data exchange between computers and applications.

It enables programmers to efficiently pass raw data to multiple users over the

Internet without the complexity of low-level TCP programming.

5.2.1 DataSocket Fundamentals

To transfer ‘live’ data with TCP/IP, code must be written to convert the data into

an unstructured stream of bytes in the broadcasting application, as well as the

code to parse the stream of bytes back into its original form in subscribing

applications. DataSocket however, transfers data in a self-describing format

that can represent data in an unlimited number of formats, including strings,

scalars, Booleans, and waveforms. The DataSocket read and write operations

transparently convert the data to and from the underlying byte streams,

eliminating the need to write complicated parsing code. (National Instruments

2001) With DataSocket, the resource name is in the form of a URL. For

example: dstp://130.95.52.245/position.token. The “dstp” (DataSocket Transfer

Protocol) tells a subscribing application to open a DataSocket connection to a

machine with that IP address (the LOL server) and read a file named

“position.token”.

5.2.2 The DataSocket API

DataSocket consists of two components – the DataSocket Application

Programming Interface (API) and the DataSocket Server. The DataSocket API

The Bandwidth Problem 28

is a protocol-independent, language-independent, and OS-independent API

designed to simplify binary data publishing. It consists of four basic actions:

open, read, write, and close. The user’s measurement data is automatically

converted into the stream of bytes that is sent across the network. The

subscribing DataSocket application automatically converts the stream of bytes

back into its original form. (National Instruments 2001)

5.2.3 The DataSocket Server

DataSocket Server simplifies internet communication by managing the TCP/IP

programming. The DataSocket Server is a stand-alone component with which

programs using the DataSocket API can broadcast live measurement data at

high rates across the Internet to several remote clients concurrently.

Broadcasting data with the DataSocket Server requires three components – a

publisher, the DataSocket Server, and a subscriber.

Figure 14: The transfer of data between the publisher and the subscriber.

A publishing application uses the DataSocket API to write data to the server. A

subscribing application uses the DataSocket API to read data from the server.

Both the publishing and the subscribing applications are “clients” of the

DataSocket Server. (National Instruments 2001)

5.3 The Bandwidth Problem

Unfortunately, most students do not have 100Mb/s internet connections and

usually use up to 56kb/s modems or ADSL. With all these different connection

speeds, the throughput of data ranges considerably. In any case, it is desirable

to transmit the minimum amount of data, which contains the maximum amount

of relevant information. This involves the use of a compression technique. It is

possible to “enable software compression” in the dial-up settings in the

Windows operating system, but not in the Mac or Linux operating systems.

Fortunately, it is enabled by default, as many users are not aware of this

feature.

Packet Loss and Packet Surging 29

In addition to this, a mechanism has been designed (Trevelyan 2002) to

compress the data to be transmitted. This module was used as part of the

supplied code.

5.4

5.5

Packet Loss and Packet Surging

TCP/IP packets are numbered at transmission time and reordered when they

reach their destination. This is required as IP can route packets differently,

which means that the packets can arrive in a different order than they were

transmitted. If, after a timeout period an acknowledgement (ACK) packet has

not been received from the receiver, the packet is resent. The packets that

have been received cannot be assembled until that retransmitted packet is

received. This shows the phenomenon of packet surging. There is very little

we can do to minimise these two problems because they are mostly caused by

noise by poor quality components on external networks cannot be minimised by

this project. Packet loss can also occur when a packet collision occurs. When

this occurs, the machine that sent the data waits a random amount of time

before resending the packet and keeps trying until an ACK packet has been

received. This can be a major problem on congested networks and will soon

become a more noticeable problem on the Mechanical Engineering LAN.

Communications in the Telelabs

When a student logs into the LOL server, they are presented with the tasks they

are required to perform. They choose a task and join the queue for that

experiment. When they have been notified that they or a group member has

reached the front of the queue, a remote client is spawned on their computer.

When the student modifies the controls, the control data is transmitted using

TCP/IP to the LOL server, where the hardware master to send the control signal

to is determined and then transmits it there using TCP/IP. The hardware

master converts the data to an appropriate voltage, which is sent through the

appropriate channel on the FieldPoint® modules to the hardware. Sensors on

the rig then update the hardware master using different channels, where it is

determined if there has been a change in state. The data-log, which contains

the new state, the change in positions and the control data, is sent to the LOL

server for storage.

Communications in the Telelabs 30

The state data needs to be updated in the remote clients, so it is transmitted

using DataSocket to the DataSocket server. The control data also needs

updating and is transferred from the LOL server to the DataSocket server,

where both state and control data are transmitted to the remote clients.

While the experiment is operating, the hardware master receives images

pushed from the network camera over TCP/IP where the individual images are

queued and transmitted to the remote clients over UDP/IP at calculated

intervals.

When the students have completed the task and quit the experiment, they are

given an option to email the data-log accumulated by the LOL server. If they

choose to send the data, it is transmitted through the DataSocket server to the

remote user’s configured email account.


6.1

6.2

Real-Time Video Transmission

The transmission of ‘live’ video data has received much funding for its

development largely due to the internet pornography industry but has had

limited success. (Personal communication, Trevelyan 2001) This technology is

also beneficial for remotely monitoring the motion of hardware. A suitable

method for quality video over slow internet connections however, has still not

been developed. An attempt to minimise some of the associated problems has

been undertaken in this project, but only with limited success.

Problems associated with Video Transmission

There are several major problems with real-time video transmission. The

largest is the bandwidth problem and is easily explained with an example. The

bit-rate of Digital Video Disk (DVD) technology is 10Mb/s and when this is

compared with an “average students’” internet throughput rate of up to 10kb/s, it

can be seen that achieving high quality video data over the Internet is currently

impossible. Attempts to maximise the amount of ‘important’ data to be

transmitted and to maximise throughput were addressed in the design of the

camera software and are still being developed.

Choosing a Camera

A comparison between the use of a web-camera with different software

packages and the use of network cameras was undertaken. (Davies and Chan

2002) This showed there were many benefits for the use of a network camera

that outweighed the considerable purchase cost. The advantages included:

User Datagram Protocol 32

configurable bandwidth usage, configurable resolution of images, easy

installation, remote administration, configurable triggering of transmission, they

were standalone devices that can be placed anywhere on a LAN and used

Active-X controls, which could be used by LabVIEW.

6.3

6.4

User Datagram Protocol

The User Datagram Protocol (UDP) provides the ability to send information to

other programs with a minimum of ‘handling’. It contains a minimum of header

information (eight bytes), but does not guarantee the receipt of reliable data

streams. (Postel 1980)

UDP is a connectionless protocol with higher performance; this is because it is

not required to establish a connection with a destination before the data is sent

or received. Instead, the destination for each datagram is configured at the

server and the client listens on an appropriate port. An additional benefit is that

operating systems do not report transmission errors. (National Instruments

2000)

It should be noted that many firewalls and routers at ISPs are configured to

disallow the forwarding of UDP packets. (Dalton 2000)

Design of Camera Software

The designs of the camera software involved an analysis of the problems and

then develop strategies to minimise them. Most of the design however, was to

exploit as many of the network camera’s advantages as possible.

UDP was chosen, as it did not require a checksum calculation so it did not have

to resend incorrect data. Retransmission was deemed unnecessary because

several incorrect pixels or a dropped frame is not detrimental. It also has the

benefit of a larger throughput and faster transmission speeds due to a minimum

of packet handling during transmission.

LabVIEW queues were used to pass the buffered, ordered sequence of JPEG

frames from the camera output to the (proposed) sorting subVI without the

elements being removed. This method was chosen so multiple streams of

Camera Testing 33

different frame rates could be configured and appropriate ones could be

transmitted to users with differing connection speeds.

VIs were created separately from the hardware master and remote client, as it

was easier to work on the modules separately. When they were complete and

had been tested, they could be incorporated into them with minimal debugging.

6.5 Camera Testing

There are many configurable parameters built into the camera software. These

can be found at http://130.95.52.185. Most of these however, only affect the

transmission to the camera master. The most important parameter that was

configurable at this address was the image size. Obviously, we required the

smallest possible image size that still had enough definition to understand the

image. It was found that 3kB images were a suitable compromise.

Most of the testing was done on the remote camera client over a 10Mb/s

internet link, which provided a very smooth image stream. When testing was

performed on a modem link connected at 26kb/s, the stream was of very poor

quality. Transmission was made at 10frames/second and it was initially hoped

that packet loss and UDP would work together to form a suitable stream that

changed automatically for different connection speeds. This however was not

the case and the received data was found to be pointless.

The next step in the development of the camera software is to change the

transmission protocol to DataSocket and to retest the performance.

http://130.95.52.185/


Feedback from Students

Obtaining feedback from the students was the most significant contribution to

Telelabs that this project provided. This was the opportunity to check that

Telelabs is heading in the correct direction and outcomes from this survey will

effect the direction of future development. It was not required for critical

analysis of the students’ responses in this project, as someone with more

knowledge about human behaviour will arrive at the conclusions with

psychological evidence. This is because the author does not have the training

to provide this; however, a subjective analysis has been made to get a general

idea of the students’ opinions.

The feedback was obtained using students enrolled in CM322 to perform a local

and a remote task and then to complete a survey. The first task, called ‘task1’,

was the laboratory performed the ‘traditional’ way. This involved the students

performing a two hour laboratory task and to complete a formal report to be

handed in as a ‘hard copy’. The second task, called ‘task2’, was considerably

shorter, as it was an extra task for the students and was not worth any marks

for the unit. This task involved logging into the Telelabs system and using the

remote client for the Position Control Rig. A fifteen minute exercise was asked

of them to see how they responded to the way the remote client operated.

The survey was created using an HTML form and aimed at obtaining answers

to several major questions that could influence the direction of Telelabs. These

Analysis of Results 35

were not asked directly, as some students often complete questionnaires by

answering with comments they think are expected and not with what they really

mean. It was then possible to cross-reference their responses to different

questions to determine the answers to the major questions, which were:

1. Do students prefer to control the equipment locally or remotely?

This is an important question and needed to be carefully worded to obtain

accurate results. As the students performed two different tasks, it was

difficult to obtain unbiased answers.

2. Would they learn the same amount if they only used a simulation?

Only their opinions could be tested here, but it allowed us to determine

whether the extra complications of controlling hardware was required.

3. Do students require image data to visualise what is happening?

This question asks if we need to supply a live video feed to students and

deal with the inherent problems associated with it. This question affects the

direction taken for providing the imagery needed by students to understand

the concepts provided by the laboratory exercise.

7.1 Analysis of Results

Analysis was performed on sixty-seven submitted surveys. The actual

questions asked are described in this section, with comments about the results.

1. Your Details: • Student Number:

• Age:

• Gender:

• Ethnic Background:

When designing this survey, it was decided that more students would complete

it if they were under the impression that it might be accessed. This was easily

achieved by asking for their student number. It may have been better to ask the

students to perform the task anonymously, but it was decided that not many

students would have participated in the survey if this were the case.


The other three parts were included, as it was noted when task1 was being

supervised, that these factors influenced the way the students behaved. The

‘ethnic background’ question received many complaints, which was expected,

and approximately ten percent of students refused to answer it correctly.

2. Task 2 Results: • Enter the rise time:

• Enter the percentage overshoot:

• Enter the settling time:

• Enter the subsidence ratio:

These questions were added so the students would have something to achieve

when they logged in and would learn something about PID control systems.

This also provided the opportunity to determine who had actually completed the

task and who was just doing the survey only and guessing the answers.

3. Did you have any difficulties obtaining the results? This was a multipurpose question, as people that actually did task2 and were

filling in the survey accurately should have answered yes. This was because

the proportional gain parameter that they were asked to use, gave an unstable

waveform from which it was impossible to obtain the results. Thirty-seven

students said they had problems, but only sixteen of them said they had

problems with the proportional gain. It cannot be said that only sixteen students

completed the survey correctly however, because it was mentioned in the

procedure that if this parameter was a problem, they should reduce it until they

could obtain the results. But, they were asked to supply the value that they

used.

The next major complaint was the variance of the results, which obtained seven

votes. This is because the hardware does not provide consistent results. This

major area needs urgent attention.

The next complaint was that the results could only be estimated, this could have

been due to the variance of the results, or that students could not use or were

unaware of the zoom feature. There was one suggestion, which was to add a

coordinate readout from the position of the mouse pointer. This seems like a

good suggestion.


The last problem was two people could not log in. They did not say why, but a

person emailed the author several times about setting up the system from his

own computer. It seemed like he had problems with a corrupt download so he

was directed to the distribution CDs that were supplied.

Thirty students replied ‘no’ to this question and the general comment was that

the task was easy.

4. If you had never seen the rig before, do you think you would understand what the graph traces represented?

Fifteen students replied yes to this question and the general comment was that

they thought it was an easy concept to understand.

Twenty students answered that they were unsure. This was probably due to

them having the knowledge already, but only one response confirmed this. Two

people suggested that a picture should be supplied. Another two suggested

that an animation or a short video should be provided. One person mentioned

that the graph should have its axes labelled. One student suggested that a

good explanation would suffice.

There were thirty-one ‘no’ responses, eleven of which said they would require a

picture, one student mentioned the axes labels and only three said they would

need to perform the task while physically watching the rig.

5. Do you think a camera image of the rig in motion is important? This question was aimed at asking the students for their opinion about how

much visualisation they required to understand the concepts. The popular

response to this question was ‘yes’ with forty-six votes, meaning that some sort

of visual aids are required.

Fifteen responses suggested that they wanted to see what was happening, two

said they needed it for better visualisation and two students said they thought

that without a camera, the task was just like a simulation. Six students said

they were unsure and suggested that they thought an animation or a video


would be sufficient. There were fourteen ‘no’ responses, two of which

suggested that they thought the bandwidth requirements were not justified and

five suggested that pictures or an explanation would suffice.

6. How much time did you spend actually operating the controls on the rig in the laboratory for task 1?

When the students were supervised in the laboratory for task1, it was noted that

many people stood at the back at just watched. This question was aimed at

determining why these students behaved this way.

Table 3: The time the students spent on the equipment in the laboratory for task1.

Option Number of Responses

• I just watched 28

• Less than 10 minutes 8

• Between 10 and 20 minutes 14

• Between 20 and 30 minutes 5

• Between 30 minutes and 1 hour 6

• Greater than 1 hour 5

This question provided some sample answers that the students could select so

they would get an understanding of the sort of responses that were required.

These are shown in Table 4.

Table 4 Reasons why students performed the experiment for the time they did.


I did not know what I was required to do 10

Other people were operating 40

I did not feel confident controlling the rig with other people

watching

6

I could not be bothered, other people were getting the results

for me

3

I felt there was not enough time for everyone to have a turn 16

I came back and used the rig in my own time 11

This was all the time I needed to get the results 15

Additional responses added by the students were the “Know it alls hogged the

controls”; they used the rig in their own time to ‘play’ with it, and the most


popular response was they thought that there were too many people in the

laboratory.

7. Do you have access to a computer and the Internet at home? This generic question was useful to see how many students had the basic

requirements to perform the exercise from home. Sixty-one students replied

‘yes’, five replied ‘no’.

8. After performing both tasks, do you think you would prefer to do task 1 locally or remotely? (Still handing in a formal lab report.)

After they had completed both tasks, the students should have had an idea of

how they would be able to perform the in class laboratory exercise on-line. This

question received thirty-one preferences for local control and seventeen for

remote control.

Table 5: Reasons why students preferred local control.


Needed to see it working. 14

Need a lab demonstrator. 7

Prefer hands-on experience. 12

Easier collaboration between students. 6

Problems can be dealt with immediately. 3

Problems occurred with remote lab. 3

Remote software installation was a problem. 5

Need a lab report to understand concepts better. 1

Table 6: Reasons why students preferred remote control.


Too many people in lab for task1 2

Can do in own time 6

Can use own computer. 1

Can work at own pace 1

Would require a camera. 2

This lab was suited to one person at a time. 1

The responses from students were interesting to find out why they preferred

local control. It is possible that when the students have a better understanding


of the Telelabs system, they will find out about the chat feature and will be able

to collaborate with that. Telelabs also has a feature for a supervisor to be

online and answer questions through a chat window. The most important

aspect was the need to see the rig in action. When the camera software has

been developed further, this may be an adequate substitute.

9. Do you think it is necessary to perform the lab on real equipment or do you think the simulation alone would provide the same experience?

This question was found by students to be badly worded, so they answered it as

if it were two separate questions. It was found that the majority of the students

preferred the real equipment for various reasons, most of these were so they

would be able to learn the extra things like effects from manufacturing flaws or

‘quirks’ with the design of the system. The most popular responses are shown

in Table 7.

Table 7: Reasons why students would prefer real hardware.


Need real equipment 44

Badly worded question 6

Would need to be properly developed 3

A simulation is as good as the real thing. 7

10. Did you feel comfortable controlling the rig remotely? It is not desired for students to feel awkward controlling the hardware they need

for their experiment. This question was misinterpreted by some students

because of the word ‘comfortable’, but most of the students understood and

replied with fifty-three responses for ‘yes’ and thirteen for ‘no’. Table 8 and

Table 9 show the suggestions for why they chose the response they did.

Table 8: Reasons why students felt comfortable controlling the rig remotely.


It was simple 23

Link from forum suggested for login 1

Interface looked the same so it was easy to use 5

Was comfortable, as Telelabs had been used before. 4

Analysis of Results 41 Table 9: Reasons why students felt uncomfortable using the rig remotely.


Same as a simulation 1

It didn’t work 4

Need to visualise 1

Lost confidence due to erratic results 1

The next set of questions could be more valuable to the analysis, as the

students had a chance to compliment or complain as much as they liked. They

also had to think of the responses themselves because there was minimal

prompting, so these suggestions are closer to what the students actually feel.

These questions are all grouped together, as many of the responses were

intertwined in the answers. A discussion about the results follows the tables.

Table 10: What did you like about using the rig remotely?


Can do it in own time. 21

Did not like it. 13

Got a chance to use it. 4

Not cramped like in the lab. 1

The controls were attractive. 2

It was simple to use. 5

It moves the hardware. 3

Could work at my own pace. 8

Could do it from home. 5

Table 11: What did you like about using the rig locally?


Can see it move. 32

Ask demonstrator questions. 10

Realism. 7

Collaboration. 6

Hands on experience. 5

Hearing the motor response. 4

Working in a group. 1

Analysis of Results 42 Table 12: What did you dislike about using the rig remotely?


Too long to download and install software. 10

No visuals. 14

Cannot ask questions. Need a lab demonstrator. 4

Nothing. 4

Waiting in the queue. 4

Table 13: What did you dislike about using the rig locally?


Too many people in the lab. 25

Waiting for other people. 16

Watching people who do not know what they are doing. 3

Nothing. 10

Not enough time to get a good understanding. 5

Table 14: Can you think of anything we could do to improve the laboratory?


Need smaller groups. 13

Have theory taught in lectures before it is taught in lab. 4

Inform about online part sooner. 7

Need a camera image. 7

Demonstrate in lectures and then perform experiment at home. 4

Column headings needed in emailed results. 2

Table 15: Do you have any other comments?


Provide hands-on and remote lab with an option of which one to

do.

2

Labs on Line system does not promote communication or team

work.

1

The survey was too long. 1

The survey does not always submit correctly. 2

The survey should be anonymous to get students real opinions. 1

The remote lab by itself would be better. 1

The consensus from the students indicates that the reason for them preferring

the local control of the laboratory equipment was that they could not see the


hardware move. This problem will be solved for many students if video data

was provided, but may satisfy enough of them if an animation, image and good

explanation of what is actually happening was provided on the webpage.

Another major point of interest with the remote task was that students required

a demonstrator so they could work out how to use the system and could ask

questions if problems arose during the laboratory exercise. For task2, there

was no demonstrator, as there was no set time for them to perform the task.

Laboratory exercises held in the future will be able to use the supervisor

interface that has already been built into the Telelabs system.

Overcrowding in the in-class laboratory was mentioned many times. This is a

problem directly addressed by Telelabs. It would have been much better if the

classes were kept to minimum numbers. The students had the option of ten

sessions they could have gone to, the first few laboratories times were not fully

booked, and the last few were very crowded. This phenomenon will probably

transfer to the amount of time waiting in the queue for the remote exercise.

The last major ‘gripe’ that students had with the system was the downloading

and installing of the software. As notification about this problem was received

during the exercise, some distribution CDs were created that determined the

software for each computer and installed everything required automatically and

even put an icon on the user’s desktop. The students were notified that these

were available, but only five of the ten provided were used. As there was

limited time for the students, a software rollout was performed to all of the

machines in the computer laboratories in the Mechanical Engineering

Department.1 There were no more difficulties received by email after this.

There were positive comments that were received. Most of these were

comments that they were able to do the task in their own time.

These results indicate that the current direction of the Telelabs project is

correct, but still needs addition in some minor areas. 1 IT Support will probably know how to do this. It is recommended to mention Microsoft®

Installer (MSI) packages and Group Policies when speaking with them.

Conclusions

At the end of this project, it can be seen that completing the initial objectives

was slightly too ambitious and was not quite obtained. Much has been learned

however, and overall, this project has been a success.

The first objective was to provide an accurate simulation. This was not

completed, as two simulations were developed instead, which are not quite

finished. This objective would have been completed if only one of the

simulations was developed. Positive results from this can be obtained however,

as future students will be aware of the integral calculation problem with the

simulation toolbox and will be able to avoid it.

The second objective was to provide a stable hardware master. This objective

was achieved and exceeded by adding the ability for it to be run as a Windows®

service. The procedure for creating the service can be found in Appendix I.

An effective remote client was created and was tested by students. No client

related software failures were reported, except for installation related problems,

indicating that it is reliable. This objective has therefore been achieved.

Good progress with the development of a tele-vision system has been made,

but was unfortunately was not completed. When the transmission protocol is

changed to DataSocket, the software should provide an effective vision system

that will be portable to any network camera that uses ActiveX controls.

It was found that the camera was suitable for slow moving objects, but pointless

for use with fast moving objects. This was because the frame rate/bit rate quite

simply requires more than the current bandwidth than the Internet provides.

Testing of the system reliability was done during both the in-class laboratory

and the remote laboratory. Some problems were found during this testing, but

these have now been corrected.

Conclusions 45

The electronic survey was able obtain student feedback, providing some useful

indicators about the project. This feedback will prove to be invaluable for the

Telelabs project as it indicates the areas where students are having problems.

Most of these problems were related to students not being able to visualise the

hardware when used remotely. This indicates that a tele-vision system is

required. The other major problem was students were unable to unzip two files

to a specified directory.

Recommendations for Future Work 46

Recommendations for Future Work

The most important recommendation is to read the comments made by the

students and to address these as best as possible.

When the students performed their laboratory experiment, several hardware

faults were determined that will soon require attention. These caused

inconsistent results that made it difficult for students to understand the

properties of the controller.

The first problem noticed was the pointer is making contact with the frame in

one position. This changed the response of the system when the pointer was

operating in that range compared to when it was not operating in that range.

This is because the frame is twisted.

The second problem was a slight imbalance of the pointer. This was found as

the ideal parameters changed when the set point was vertical compared with

when the set point was horizontal.

The third problem was the angular velocity of the motor was different for anti-

clockwise directions compared with clockwise directions. This changed the

response of the system, which confused students.

Although this fault will not cause inconsistencies in results, it should be noted

that the pointer is cracked around one of the grub screws that mount the pointer

to the shaft. This looks like it was caused by over tightening of the screw and

may cause problems when the rig is overhauled. This in conjunction with the

pointer’s imbalance may mean a new pointer should be made.

For the laboratory next year, it is recommended that the technicians rectify

these problems, so there is not as much confusion.


Many students asked questions over email about problems with the Java

simulation. This indicates that the LabVIEW simulations that were started with

this project should be completed and tested.

The simulation using the equations of motion requires the parameters to be

scaled to suitable units and the simulation controls cluster needs to have the

precision increased. After this has been done, the coding of the differential

equation can be tested. The remote client that this is contained in will then

need updating to the current version.

The problem with the control theory simulation is the LabVIEW integration

technique. This simulation could be recoded in a similar manner, except using

the Runge-Kutta module (Trevelyan 2001) and the PID controller (Davies 2002).

Another suggestion with the simulation is to check the gains that are used for

the transfer function. This is because the old gains are still in use even though

the circuit board has been rebuilt.

The network camera has the ability to be turned on and off remotely. This

would save considerable local bandwidth if this feature were incorporated into

the hardware master.

Changes to the structure of the camera software should be changed, so the

transmission protocol used is DataSocket instead of UDP. This is now the

chosen protocol as it automatically compensates for different connection

speeds. When the video streams are split, it may be easier to create individual

DataSockets for each stream.

The use of LabVIEW queues may not be as an attractive idea as they first

seemed. The reason for this is the images are not deleted from memory when

they are deleted from the queue, so the memory resources of the machine are

quickly consumed, causing system failure.


When the software has been tested more thoroughly, the thread priority

problem caused by the camera software with the hardware master and remote

client could be addressed.

Some students mentioned that they would find the experiment more ‘real’ if they

could hear the motor. The AXIS2100 has an audio module that can be

purchased that integrates very easily into the camera control software.

A simple to understand explanation of the operation of the rig should be added

to the website. In addition, many students had problems with the derivation of

the response function required for the lab report, so this should also be

uploaded. An electronic copy of this can be found in Appendix V.

As the students were concerned about collaboration, it may be an idea to add a

voice transmission feature to the chat section of the Telelabs interface.

A student complained that they thought they were getting erratic results from

someone ‘hacking’ the system. After some thought, this may have been due to

other students in G19 playing around with the pointer while the student was

performing the remote task. It is suggested that the rig is placed in G21, so this

cannot occur.

References 49

References

Trevelyan J. 2002, Towards Cost Effective On-Line Laboratories, Networked

Learning Conference, Berlin.

Stoll S., Hopp C. 2002, Information Technology Online, Networked Learning

Conference, Berlin.

Marin R., Sanz P. 2002, Telerobotic Training System Through the Web,

Networked Learning Conference, Berlin.

Chang V., del Alamo J. 2002, Collaborative WebLab, Networked Learning

Conference, Berlin.

Chew A. S. 1997, Development of a Feedback System for Position Control,

Honours Thesis, The University of Western Australia, Perth.

Dalton B. 2000,Telerobotic Development, Ph. D. thesis, The University of

Western Australia, Perth.

Baranski J. 2000, SCADA System Development, Design Study, The University

of Western Australia, Perth.

Boden A. 2000, Telelabs Preliminary Investigation, The University of Western

Australia, Perth.

Davies T., Chan D. 2002, Network Cameras versus Streaming Video, Vacation

work project, The University of Western Australia, Perth.

National Instruments Knowledgebase [online] http://www.ni.com were the

source for the following PDF documents:

Building an Interactive Webpage with DataSocket.pdf

http://www.ni.com/

References 50

DataSocket for LabVIEW.pdf

DataSocket Technical Overview.pdf

AI-100 Calibration Procedure.pdf

FP-1600 Spec Sheet.pdf

FP-1600 User Guide.pdf

FP-1600-Quick Start Guide.pdf

FP-AI-100 Operating Instructions (2).pdf

FP-AI-100 Operating Instructions (3).pdf

FP-AI-100 Operating Instructions.pdf

FP-AI-100 Spec Sheet.pdf

FP-AO-210 Calibration Procedure.pdf

FP-AO-210 Operating Instructions.pdf

FP-AO-210 Spec Sheet.pdf

FP-DO-401 Operating Instructions (2).pdf

FP-DO-401 Operating Instructions.pdf

FP-DO-401 Spec Sheet.pdf

FP-TB-1 Spec Sheet.pdf

Control and Simulation Toolkit Reference Manual.pdf

Internet Developers Toolkit.pdf

Internet Toolkit Reference Manual.pdf

Axis Cameras knowledgebase [online] http://www.axis.com supplied the

following documents:

2100user_guide.pdf

AxisCamControl1031.pdf

AxisCamControl.doc

Internet Encyclopedia [online] http://www.freesoft.org/CIE/index.htm supplied

the following documents:

Postel J. 1980, RFC768,

Plummer D 1982, RFC826

Redman F., Rajan J. 1997, Human Factors for Safety-Critical Systems,

http://www.axis.com/

http://www.freesoft.org/CIE/index.htm

Appendix I

The Hardware Master as a Service

To allow students with different logins to use the runtime machine while it is

running the hardware master, a wrapper for the executable was configured.

This provides the ability for the service to be managed from a remote location.

To manage a service from outside the department, a minimum of local

administrator access is required through the department’s firewall.

1. Extract srvany.exe and srvinstw.exe from compmgmt.cab on the

Windows 2000 Resource Kit CD.

2. Rename srvany.exe to the name you would like to call the wrapper

service. For this example: Position HW Master Service Wrapper.exe.

3. Execute srvinstw.exe

4. Select “Install a service

The Hardware Master as a Service II

5. Select Local Machine

6. Type the Name for the service

The Hardware Master as a Service III

7. Enter the path to the service wrapper

8. Select Service is its own process

The Hardware Master as a Service IV

9. Use the system account to use the system user security settings

10. The service is to be started when the machine starts up, so select

Automatic

The Hardware Master as a Service V

11. Click Finish

You should receive a confirmation message

Then launch regedit

The Hardware Master as a Service VI

Navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Position

Control HW Master

Create a new Key

With the name: Parameters

The Hardware Master as a Service VII

Select the parameters key

Then create a new value

name it: Application

The Hardware Master as a Service VIII

Then modify this key

Close the registry editor

Right click “My Computer” and select “Manage”. Then you can configure the

service by using the Computer Management Snap in.

Navigate to your newly created service. Right click and select properties.

The Hardware Master as a Service IX

On the recovery tab, select the following options

The full console message to IT Support is “net send ashbrook The Position

HW Service failed to start.”

On the general tab, select start

The Hardware Master as a Service X

Click OK

Press Ctrl-Shift-Esc to bring up the Task Manager

The Hardware Master as a Service XI

Ensure Position HW Master Service Wrapper.exe and position hw

master.exe are running.

Rig Configuration on the LOL-Server XII

Appendix II

Rig Configuration on the LOL-Server

The following details are used for the creation of a rig, course and task entry on

the LOL server.

Rig Record

Rig ID 5 First free integer (others in

use)

Rig Name Position Control

Rig Comment

Position Control Experimental Rig

Fault Email

[email protected] Where emails are sent if

faults occur

Base URL Dstp://130.95.52.244/position The location of the client

library

IP Address

130.95.249.86 The address of the machine

running the hardware master

Rig Status OPEN (OFFLINE) Rig status for users

Reset Limit

1.00min The reset limit

mailto:[email protected]

Components of the Position Control Rig XIII

Appendix III

Components of the Position Control Rig

Figure 15: Representation of a potentiometer.

Figure 16: Differencing circuit used by the Position Control Rig.

Components of the Position Control Rig XIV

Figure 17: The PID circuit used by the Position Control Rig.

Figure 18: The servo-amplifier used by the Position Control Rig.

Figure 19: Representation of a gearbox.

Communication Protocols XV

Appendix IV

Communication Protocols

The Internet can use various means of transmission, but they are generally

based on the ISO OSI seven-layer model. This section discusses the protocols

used for this laboratory.

Ethernet The Ethernet protocol is a layer-two mechanism that converts an IP address

into a 48-bit Ethernet address. An address resolution module within the

hardware driver is checked to find this pair in a table. If it finds the pair, it gives

the corresponding 48-bit Ethernet address back to the caller’s hardware driver,

which then transmits the packet. The sender hardware address and sender

protocol address are necessary and these fields are reset in the translation

table every time the router or the machine containing the Ethernet card is

rebooted. If the pair is not found, the packet is broadcast and the driver on the

destination machine replies with an acknowledgment. The sender then updates

its table. If there is no reply, the packet is dropped as it is assumed that the

handling is done by a higher-level protocol. (Plummer 1982)

Internet Protocol IPv4 can address up to 2^32 locations IPv6 can address 2^128 locations.

Subnetting allows private networks to be configured so the flow of network

traffic between hosts to be segregated based on a network configuration. By

Communication Protocols XVI

organizing hosts into logical groups, subnetting can improve network security

and performance.

The model of operation is that an internet module resides in each host engaged

in internet communication and in each gateway that interconnects networks.

These modules share common rules for interpreting address fields and for

fragmenting and assembling internet datagrams. In addition, these modules

(especially in gateways) have procedures for making routing decisions and

other functions.

The Internet Protocol uses four key mechanisms in providing its service: Type

of Service, Time to Live, Options, and Header Checksum. The type of service

is a generalized set of parameters, which characterise the service choices to be

used by gateways to select the actual transmission parameters for a particular

network, the network to be used for the next hop, or the next gateway when

routing an internet datagram. The Time to Live is an indication of an upper

bound on the lifetime of an internet datagram. It is set by the sender of the

datagram and reduced at the points along the route where it is processed. If the

time to live reaches zero before the internet datagram reaches its destination,

the internet datagram is destroyed. The Header Checksum provides verification

that the information used in processing the internet datagram has been

transmitted correctly. (Defence Advanced Research Projects Agency 1981)

Calculating the Response Function XVII

Appendix V

Calculating the Response Function

( )1

o

o

HH sH

=+

where: 2

1o pot oA A T RH K K K K K

Js Bs=

+

2

22

( )1

pot oA A T R pot oA A T R

pot oA A T R pot oA A T R

K K K K K K K K K KJS BS JH s K K K K K K K K K KBSSJS BS J J

+∴ = =+ + +

+

let 3

24

(5.31 10 )( 0.08)( 2)(160) 271.9 /5 10

pot oA A T Ro

K K K K Krad s

Jω

−

−

× − −= = ≈

×

and 4

0.011532 0.6992 5 10 2 16.49o

o

B BJ J

ξω ξω −= ⇒ = = ≈

× × ×

then 2

22( )

2o

o o

H sS S

ωξω ω

=+ +

Using the partial fractions technique:

( ) ( )( )

222

2 22 2 22

2

2 2 2o oo

o o o o o o

A S S S BS CA BS CSS S S S S S S

ξω ωωξω ω ξω ω ξω ω

+ + + ++= + =

+ + + + + +

generates coefficients of:

Calculating the Response Function XVIII

112 o

ABC ξω

== −= −

so that 22

21( )2

o

o o

SH sS S S

ξωξω ω+

= −+ +

As ( )i tθ is a step function:

00

1( ) st st ioi io ios e dt e

S Sθθ θ θ

∞∞ − − = = − ∫ =

and ( ) ( )( ) ( ) ( ) ( ) ( )( )o i

o ii

s sH s s H s s H ss S

oθ θθ θθ

= ⇒ = =

( )22

2( )

2io oio

oo o

Ss

S S Sθ ξωθθ

ξω ω+

∴ = −+ +

Applying an inverse Laplace transform:

[ ] ( )1 1 122

2( ) ( )

2io oio

o oo o

St L s L L

S S Sθ ξωθθ θ

ξω ω− − − + = = − + +

( ) cos sinot oo io io d d

d

t e tξω ξωθ θ θ ω ωω

− = − +

t

where 21d oω ω ξ= −

manipulating to the same form as used in the simulation:

( ) ( ) ( ) (( ) 1 exp 11.5 cos 11.79 0.977exp 11.5 sin 11.79o

io

t t t t )tθθ

= − − − −

The simulation without compensation gives a similar answer of:

1.000 - 1.000Exp(-11.530t)*Cos(11.787t) - 0.978Exp(-11.530t)*Sin(11.787t)

software system for controlling web-based laboratory final year … · 2004. 8. 18. · interesting...

Documents