Sie sind auf Seite 1von 141

Best Project of the Year at PRL (8.

25/10)
- Review Panel, 16 Apr ‘09

Project Report
On
24 CHANNEL DATA ACQUISITION SYSTEM
(DAS) USING USB 2.0 & REAL TIME
MONITORING SYSTEM OVER INTRANET
FOR SIMS
Project Guide:
Mr. Chandresh Parekh Dr. Kuljeet Kaur Marhas
HOD Mr. M.P. Deomurari
Electronics & Communication Dept Ion Probe Laboratory
Government Engineering College, Planetary Sciences Division
Gandhinagar Physical Research Laboratory
Ahmedabad
Physical Research Laboratory

Submitted by
Sunil S Pillai
Department of Electronics & Communications
Government Engineering College, Sector-28,
Gandhinagar

Jan-May’09

GEC, Gandhinagar i Sunil S Pillai


Physical Research Laboratory

CERTIFICATE

This is to certify that Shree Pillai Sunil Sasidharan of course


B.E. (EC) SEM 8th Roll No 10540 has satisfactorily
completed his project work at

PHYSICAL RESEARCH LABORATORY, AHMEDABAD


And Submitted the Project Report on

24 CHANNEL DATA ACQUISITION SYSTEM (DAS)


USING USB 2.0 & REAL TIME MONITORING
SYSTEM OVER INTRANET FOR SIMS

as a partial fulfillment of the requirement for the award of


Bachelor of Engineering (BE) degree in Electronics and
communication by Gujarat University, Ahmedebad, during the
academic year 2008-09

Date of Submission ___________


Examining Faculty Head of Department

_______________ _________________

GEC, Gandhinagar ii Sunil S Pillai


Physical Research Laboratory

Table of Contents

Abstract … … … … … … … … … iii

Acknowledgement … … … … … … … iv

List of Tables … … … … … … … v

List of Figures … … … … … … … vi

1. About Physical Research Laboratory … … … 1


1.1 About Physical Research Laboratory… … … 2
1.2About Planetary Science Division … … … 3
1.3About Ion Probe Laboratory … … … … 4
1.4About SIMS … … … … … … 4

2. Introduction … … … … … … … 11
2.1 Objectives … … … … … … … 12
2.2 Modular Approach … … … … … 13
2.3 Project Management … … … … … 15

3. System … … … … … … … … 17
3.1Overview … … … … … … … 18
3.2 Hardware Board … … … … … … 20
3.3 Ion Probe Server … … … … … … 21

4. Hardware … … … … … … … … 27
4.1 Overview … … … … … … … 28
4.2 PIC18F4550 … … … … … … 28
4.3 Circuit Diagram … … … … … … 32

5. Firmware … … … … … … … … 33
5.1 Overview … … … … … … … 34
5.2 File Description … … … … … … 34
5.3 Program Execution … … … … … …

5.4 List of Files… … … … … … … 39


5.5 Conclusion … … … …. … … 39

6. Data Logger … … … … … … … 41
6.1 Overview … … … … … … … 42

6.2 SIMS Monitoring System … … … … 42


6.3 Snapshot … … … … … … … 47
6.4 Conclusion … … … … … … … 48

7. Database … … … … … … … … 49

GEC, Gandhinagar iii Sunil S Pillai


Physical Research Laboratory

7.1 Overview … … … … … … … 50
7.2 The Ion Probe Database … … … … 50
7.3 Snapshot … … … … … … … 55

7.4 Conclusion … … … … … … … 57

8. Dashboard Web Service … … … … … 58


8.1 Overview … … … … … … … 58
8.2 Dashboard … … … … … … … 58
8.3 Login Page … … … … … … … 63
8.4 Dashboard Page … … … … … … 64
8.5 Snapshoot … … … … … … … 71
8.6 Conclusion … … … … … … … 74

9. Future Work … … … … … … … 75

10. Bibliography … … … … … … 77

11. Appendix A : Firmware Code … … … … … 79

12.Appendix B : Data Logger Code … … … … 92

13.Appendix C : Dashboard Code … … … … 104

14.Appendix D : Datasheet… … … … … … 117

GEC, Gandhinagar iv Sunil S Pillai


Physical Research Laboratory

ABSTRACT

The project is intended to provide real time monitoring of the status of Secondary
Ion Mass Spectrometer (Cameca’s IMS-4F) at Ion Probe laboratory. 17 Parameters were
identified for obtaining status information of the Instrument viz, Duoplasmatron Primary
Beam ON/OFF, Duoplasmatron Vacuum, Vacuum generated by two Rotary Pumps,
Vacuum generated by two Ion Pumps, Speeds of 4 Turbo Pumps, Chiller Water Level &
Temperature, Water Flow, Coolant Level & Flow and Lab Temperature & Humidity.

A data acquisition Board has been realized for acquiring all the intended
parameters. The system is based on PIC18f4550 microcontroller from Microchip Inc.
Provision has been made for acquiring 8 analog values & 16 digital values. However, this
capacity can further be extended by cascading appropriate multiplexers. The acquired
values are sent to PC through USB.

A data logging application running on the PC receives the data from the USB via
appropriate drivers. After validation, the Data is parsed & displayed for diagnosis
purpose. Simultaneously data is logged into MS Access Database with time stamp. The
PC has been turned into a local Server which hosts the Intranet Service. The Data is
visualized onto a dashboard which is then streamed live over PRL LAN.

So user can log in to SIMS Monitoring Site from any pc on PRL LAN & view the
status data in form of the gauges & indicators displayed on dashboard. The dashboard
also has a chart panel. This can be used to analyze the status data for any given period.

For dashboard Development, Dundas Data Visualization Software has been used.
The web service has been developed using Visual Studio 2005 (ASP.NET) in C#
language. The stand alone Data Logging application has been developed using Visual
Studio 2005 in VB language.

Microchip’s Mplab IDE v8.20 has been used for firmware development. The USB
stack has been implemented using Microchip USB framework MCPFSUSB v2.4. PicKit
v2.40 has been used for loading the microcontroller. The hardware used for loading the
firmware was the Sunrom Technology’s PICEX2000 loader. Experimental work was
done on the PIC18F4550 evaluation board by Sunrom Technology Inc.

This project was implemented at the Ion Probe Laboratory of Planetary Sciences
Division of Physical Research Laboratory, Ahmedabad. The system was accomplished by
me under the supervision of Dr. Kuljeet Kaur Marhas & Mr. M.P.Deomurari in a period
of four months i.e. from Jan’09-Apr’09. The project was adjudged as the “Best Trainee
Project of the Year-2009” with a score of 8.25 / 10 by a 5 member review panel.

GEC, Gandhinagar v Sunil S Pillai


Physical Research Laboratory

ACKNOWLEDGEMENT

Before we get into the thick of the thing, I would like to pen down a few words
for the people who made this possible.

First & foremost am thankful to Almighty GOD, for providing me all that I have,
for putting me in a good place & for guiding my efforts.

I would like to begin with Mrs. Neeta Mehta ma’am & Asst. Prof Chandresh R
Parekh of our college for nominating me for a project work at PRL. On similar Lines, am
thankful to Prof. A.K. Singhvi, Dean-Academics, PRL & his team for providing an
opportunity to work at PRL.

My utmost gratitude goes to my guide, Dr. Kuljeet Kaur Marhas. Her affectionate
& conducive nature could be accounted for as one of the major catalyst in the project
achieving its goals. Ma’am, the project owes itself to your vision, for without such a
requirement, it won’t be able to bag the title of “Best Trainee Project of the Year-2009”
at the review.

M.P.Deomurari Sir’s deep knowledge in electronics was quite helpful in the work
related to sensors. His detailed step by step approach is worth appreciation. I would like
to take this platform to express my heart felt gratitude towards Ritesh Mishra (PhD
student at Ion Probe Lab).

I am grateful to my sister Ms. Soumya Pillai (Software Executive-RISL) for


lending her technical expertise to the development of dashboard & web service. T.A.
Rajesh Sir (SPA-SC, PRL)’s experience in front end development came quite handy in
evolving the SIMS Monitoring System’s data logger.

The support lent by Mr. Dipak Panda, Mr. Pranav Adharyu (PGSDN-PRL), Mr.
Mannan & Lakhanji cannot go unmentioned. I would also like to mention Mr. Mathiyas
Crachiolli’s efforts in helping us to locate the points in the SIMS electronics from where
signals could be tapped for monitoring.

I would like to express sincere thanks to all the fellow trainees at PRL and to all
those who had participated in field trials of dashboard web service. Thanking you all for
taking out your valuable time.

Last but not least, I would like to remember all of those who directly or indirectly
made my stay at PRL, a smooth and pleasant affair.

Thanking You All.

Sunil S Pillai

GEC, Gandhinagar vi Sunil S Pillai


Physical Research Laboratory

LIST OF TABLES

Table 5.1 USB Device Stack Files … … … … … … 34


Table 5.2 CDC Device Driver Stack Files … … … … … 35
Table 5.3 USB Stack Functions … … … … … … 36
Table 5.4 USB Device Stack Macros … … … … … 36
Table 5.5 usb_function_cdc.h Functions … … … … … 37

Table 6.1 Parameters & their Associated Tables … … … … 46

Table 7.1 Duodetails Table Structure … … … … … 51


Table 7.2 Duomain Table Structure … … … … … 51
Table 7.3 Galden Flow Table Structure … … … … … 52
Table 7.4 Galden Level Table Structure … … … … … 52
Table 7.5 Lab Humidity Table Structure … … … … … 52
Table 7.6 Lab Temperature Table Structure … … … … 53
Table 7.7 Login Table Structure … … … … … … 53
Table 7.8 Pump Pressure Table Structure … … … … … 53
Table 7.9 Pump Speed Table Structure … … … … … 54
Table 7.10 Water Flow Table Structure … … … … … 54
Table 7.11 Water Level Table Structure … … … … … 54
Table 7.12 Lab Temperature Table Structure … … … … 55

GEC, Gandhinagar vii Sunil S Pillai


Physical Research Laboratory

LIST OF FIGURES

Fig 1.1 Cameca IMS 4f Geometry … … … … … … 5


Fig 1.2 Duoplasmatron Structure … … … … … … 5
Fig 1.3 Primary Column … … … … … … … 6
Fig 1.4 Sample Chamber … … … … … … … 7
Fig 1.5 Electrostatic sector … … … … … … … 8
Fig 1.6 Entrance & Exit slits… … … … … … … 9
Fig 1.7 Quadrupole Mass Analyzer… … … … … … 10
Fig 1.8 Ion detectors … … … … … … … … 10

Fig 2.1 Modular System Diagram … … … … … … 12

Fig 3.1 Data Flow diagram of the System … … … … … 19

Fig 4.1 Oscillator Block Diagram … … … … … … 29


Fig 4.2 USB Block Diagram … … … … … … 31
Fig 5.1 Program Flow … … … … … … … 38

Fig 6.1 Data flow diagram of Data logger … … … … … 41

GEC, Gandhinagar viii Sunil S Pillai


Physical Research Laboratory About Physical Research Laboratory

Chapter 1
About Physical Research Laboratory

GEC, Gandhinagar 0 Sunil S Pillai


Physical Research Laboratory About Physical Research Laboratory

1.1 About Physical Research Laboratory


Known as the cradle of Space Sciences in India, the Physical Research
Laboratory (PRL) was founded in 1947 by Dr. Vikram Sarabhai. As a unit of the
Department of Space, Government of India, PRL carries out fundamental research in
select areas of Physics, Space & Atmospheric Sciences, Astronomy, Astrophysics &
Solar Physics, and Planetary & Geosciences.

The Laboratory was formally established on November 11, 1947, in the M. G.


Science College, Ahmedabad, with support from the Karmkshetra Educational
Foundation and the Ahmedabad Education Society. The initial focus was research on
Cosmic Rays and the properties of the Upper Atmosphere. Research in Theoretical
Physics and Radio Physics were added later with grants from the Atomic Energy
Commission.

The main campus at Navrangpura was inaugurated by Pt. Jawaharlal Nehru in


1954. In 1979 Infrared Telescope become operational at Mt. Abu. Udaipur Solar
Observatory became a part of PRL in 1980. PRL got an extension campus at Thaltej in
1990.
PRL recently conceptualized & implemented India’s first mission to moon,
Chandrayaan-1. Prof. J.N. Goswami was the principal scientist of this 400 crore maiden
mission of Govt. of India. PRL also developed a HEX (High Energy x-ray spectrometer)
payload for this mission

ACADEMIC DIVISIONS
 Astronomy And Astrophysics
 Planetary sciences Division
 Geosciences Division
 Space and Atmospheric Sciences
 Planetary Science & Exploration Program
 Theoretical Physics & Complex Systems
 Udaipur Solar Observatory

Fields of Research:

 Astronomy & Astrophysics  Solar Physics


 Quantum Optics & Quantum Information  Gravitation & Cosmology
 Space & Atmospheric Sciences  Particle Physics
 Nuclear, Atomic & Molecular Physics  Nonlinear Dynamics
 Planetary Sciences & Exploration  Earth Sciences

GEC, Gandhinagar 1 Sunil S Pillai


1.2 About Planetary Science Division

Research Programmes of this Division aim to understand the origin and evolution
of the Solar System, physical and chemical processes occurring on the Earth surface
reservoirs through analysis of isotopic, chemical and luminescence signatures

Research Programmes
1. Pre-Solar and Early Solar system processes;
2. Chemical and Isotopic studies on meteorites;
3. Catastrophic events in Earth's history;
4. Spatial and Temporal evolution of various landforms of India;
5. Paleoclimate, Paleomonsoon and Desertification on various time scales;
6. Chemical Weathering and Climate;
7. Ocean Circulation and Gas Exchange;
8. Aerosol Chemistry and Deposition;
9. Trace gases in the atmosphere;
10. Space based experiments;
11. Planetary Exploration: Chandrayaan-1 and beyond.

Facilities

Existing:

1. Thermal Ionization Mass Spectrometer (TIMS) ;


2. Liquid Scintillation Counter (LSC);
3. Alpha, Beta and Gamma detectors;
4. Secondary Ion Mass Spectrometer;
5. Stable Isotope Mass Spectrometer;
6. Gas Chromatography-Mass Spectrometery (GCMS);
7. Noble Gas Mass Spectrometer;
8. Ion Chromatograph;
9. Inductively Coupled Plasma- Atomic Emission Spectrometry (ICPAES);
10. CN-Analyzer;
11. Thermo-Optical EC-OC Analyzer;
12. SO2 Analyzer;
13. Atomic Absorption Spectrophotometry (Flame & GF).
14. Thermoluminescence (TL) & Optically Stimulated Luminescence (OSL) dating
systems;

New Additions (Along with PLANEX):


1. Multi-collector Noble gas mass spectrometer,
2. Nano SIMS,
3. Electron Probe Mass Analyzer (EPMA,)
4. Inductively Coupled Pulse Mass Spectrometer (ICP-MS )
5. XRF
Current Research
 Study of  short-lived nuclides (26Al, 41Ca, 36Cl, 53Mn) in the early Solar System
objects to infer the time scales for the formation of the Sun and some of the first
solar system objects, and what they can tell about the origin of the Solar System.

 Study of radiogenic and stable isotopic anomalies and trace element abundances
in Calcium-Aluminum-Inclusions (CAIs)in meteorites to understand the
formation and evolution of the CAIs that are considered to be some of the first
Solar System solids.
 Study of nitrogen and noble gases in different types of meteorites to delineate the
various nitrogen and noble gas components present in the early Solar System

1.3 About Ion Probe Laboratory

The Ion Probe Laboratory was set up in 1990. The Lab is chaired by Prof J.N.
Goswami who also happens to be the director of PRL. The lab houses the Cameca’s IMS
4f Instrument, popularly referred to as SIMS (Secondary Ion Mass Spectrometer). The
working group comprises of Prof. J. N. Goswami, Dr. Kuljeet Kaur Marhas & M.P.
deomurari. The lab web page can be accessed at www.prl.res.in\~ionprobe

1.4 About SIMS

The IMS 4f is an ion mass spectrometer capable of achieving very fine resolutions.
As any other mass spectrometer it gives the ratios of masses of different isotopes in the
sample. At ionprobe, SIMS is used to analyze meteoritic samples. After the sample is
mounted in the sample chamber, a primary ion beam is generated by the Duoplasmatron.
This beam travels through primary column where different lenses & deflectors are used
to control & manipulate the beam. When the beam of ions strikes the sample, it results in
a sputtering. This secondary beam then travels through the secondary column. The
secondary beam is controlled & manipulated with electromagnetic lenses & various slits.
At the end of the secondary column the beam is detected & analyzed with help of
electron multiplier, a Faraday cup, and two ion image detectors.

The detail of following major parts of SIMS is mentioned below.


1. Primary Ion Sources
2. Primary Ion Column
3. Secondary Ion Extraction and Transfer
4. Ion Energy Analyzers
5. Mass Analyzers
6. Secondary Ion Detectors
1.4.1 SIMS Primary Ion Sources

The Duoplasmatron can operate with virtually any gas, but oxygen is the most
common because oxygen implantation into the sample surface enhances ionization
efficiency for electropositive elements. Before this oxygen enhancement effect was
discovered, argon was commonly used. The oxygen plasma within the Duoplasmatron
source contains both O- and O2+, and either can be extracted.

1.4.2 SIMS Primary Ion Column


Primary ions are extracted from the sources and passed to the sample through the
primary ion column. The column usually contains a primary beam mass filter that
transmits only ions with a specified mass-to-charge (m/z) ratio.
This mass filter eliminates impurity species in the beam. For example, Cr, Fe, and
Ni ions sputter from stainless steel surfaces within a duoplasmatron. Without a primary
beam mass filter, these metal contaminants deposit onto the sample surface, raising the
detection limits for stainless steel elements.

In the figure above, the electromagnetically active components are shown in blue.
The ion beam trajectories (indicated in red) are greatly exaggerated in the lateral
directions. The electrostatic lenses and the apertures control the intensity and width of the
primary ion beam. Several aperture diameters are usually available at each aperture
location. The primary beam intensity can be reduced by defocusing the ion beam onto the
back of the first aperture (nearest the magnet). A narrow beam (at the sample) results
from defocusing the ion beam (with the middle lens) onto the back of the second
aperture, and then adjusting the last lens to transfer the image of the cross-over from
behind the aperture onto the sample.

DUOPLASMATRON
Cathode
Intermediate electrode
CESIUM SOURCE Coil
Anode
Extraction lens
Deflector 2
PBMF
Extraction lens
Deflector 2

Lens 2
Mass selection aperture
Deflector 1

Lens 1
Primary beam aperture
Stigmator
Faraday Cup
Deflector
Lens 3
Sample

Electrostatic deflectors steer the primary beam in a raster pattern onto the sample.
A finely focused and rastered primary ion beam delivers uniform primary beam intensity
to an area on the sample. This leads to flat bottom sputter craters. The best depth
resolution in a depth profile results when the secondary ions are sampled from the flat
bottom of such a crater without contributions from the crater edges. Other deflectors (not
shown) are located near the apertures. They help tune the primary beam through the
middle of the electrostatic lenses.

1.4.3 Secondary Ion Extraction and Transfer

Secondary ions are extracted from the sample as they are produced. If large mass
spectrometer components are held at ground potential, the sample must be held at high
voltage, the accelerating potential. The secondary ions accelerate toward the ground plate
of an electrostatic lens. This first lens is called the immersion or ion extraction lens. The
second (transfer lens) focuses the ion beam onto the mass spectrometer entrance slits or
aperture. This two lens system constitutes an ion microscope. The secondary ions could
be projected onto an image detector for viewing the sample surface. Different transfer
lenses produce different magnifications.

In the figure above, the electromagnetically active components are shown in blue.
The ion beam trajectories (indicated in red) are greatly exaggerated in the lateral
directions.

The field aperture is located


approximately at the point where the
ion beam image comes into focus.
The entrance aperture is sometimes
called a contrast diaphragm. Smaller
aperture diameters intercept ions
with off-axis energy components.
This reduces image aberrations but
unfortunately it also reduces
secondary ion intensity.

Ions that arise from off the


secondary ion optical axis contribute
to lower mass resolution. These off-
axis ions arise because the primary beam raster pattern sputters an area rather than the
single point where the axis intercepts the sample. The dynamic emittance deflectors
adjust the secondary ion beam back on-axis. The deflectors operate in synchrony with the
primary beam raster generator to provide continuous adjustment.

1.4.4 Ion Energy Analyzers

Electrostatic energy analyzers bend lower energy ions more strongly than higher energy
ions. The sputtering process produces a range of ion energies. An energy slit can be set to
intercept the high energy ions (shown in green).

In the figure above, the electromagnetically active components are shown in blue. The
ion beam trajectories (indicated in red) are greatly exaggerated in the lateral directions.
Voltage offset is a strategy for enhancing monatomic ions over multiatomic. The
monoatomic ions have higher energy distributions. If the accelerating voltage is lowered
(offset), more of the atomic ions still have enough energy to pass through the energy slits.
In a typical SIMS experiment, the accelerating voltage is 4.5 kV, and the offset is 50 V.
The inner jaw of the slits intercepts most (low energy) multiatomic ions. Both monatomic
and multiatomic ion intensities are reduced in a voltage offset measurement, but
multiatomic ions relatively more than monoatomic.

The inner and outer sector electrodes have voltages of opposite polarity. Their
magnitude is about 10% of the ion accelerating voltage. The ion image comes into focus,
producing a virtual image inside the electrostatic sector behind the field aperture. The
active surfaces of the electrostatic sector are spherical. This geometry transfers the image
to the mass analyzer with minimal distortion. The spectrometer lens adjusts the ion beam
focus (cross over) to meet the input requirements of the mass analyzer.

1.4.5 Mass Analyzers

Dynamic SIMS instruments use two kinds of mass analyzers, magnetic sector and
quadrupole. Magnetic sector instruments are most common. As the ion beam passes

through the magnetic field, the particles are acted on by a force at right angles, both to the
direction of motion and to the direction of the magnetic field.
The following equation shows the relationship between the magnetic field (B), the ion
accerating voltage (V), the mass-to-charge ratio (m/q), and the radius of ion curvature (r)
in the magnetic field. In atomic units, m/q becomes m/z where z is the number of charges
on the ion.

Magnetic sector mass analyzer is shown in blue. The ion beam trajectories
(indicated in red) are greatly exaggerated in the lateral directions.

Modern mass spectrometers use non-normal pole faces for entrance and exit of
the ion beam to the magnetic sector. The fringings fields in this configuration compress
the ion beam in the vertical direction (in and out of the screen) as it passes through the
sector. Fewer ions strike metal surfaces and the ion beam focuses better at the exit slit
with non-normal pole faces. The entrance and exit slits can be arranged at ion beam
crossovers for the cleanest separation (highest mass resolution) between ions with similar
m/z values. The green part of the beam represents ions with higher m/z values that do not
pass through the spectrometer. 

The combination of a magnetic and an electrostatic sector produces a double


focusing instrument. A magnetic analyzer, by itself, introduces chromatic aberrations into
an ion beam with dispersed ion energies. These aberrations reduce mass resolution. In a
series arrangement of one electrostatic and one magnetic sector, the energy dispersion of
the electrostatic sector can just compensate the energy dispersion of the magnet. The
system will have the mass dispersive properties of the magnet, except that it will produce
higher mass resolution. The spectrometer lens adjusts the cross-over from the
electrostatic sector to the location required for the magnetic sector.

Quadrupole mass analyzers were invented in 1953. Many kinds of analysis, including
SIMS, employ quadrupoles. Ideally, the rods have hyperbolic shapes, but this geometry
can be approximated with closely spaced circular rods. In a typical quadrupole
spectrometer, the rods are 1 cm in diameter and 20 cm long. In the diagram, ions enter
from the left at a relatively low energy (~25 eV). Since SIMS ions can have a wider
energy range than 25 eV, electrostatic sectors usually precede the quadrupole.
Alternating and direct voltages on the rods cause the ions to oscillate after
entering the quadrupole. For a given set of voltages, Ions with a single mass-to-charge
ratio undergo stable oscillation and traverse through the rods. All other ions have unstable
oscillations and strike the rods. The alternating frequency and the ratio between the
alternating and direct voltages remain constant. Scanning the voltages scans the mass
spectrum.

1.4.6 Secondary Ion Detectors

The most widely used SIMS instruments have as many as four detectors. These
include an ion counting electron multiplier, a Faraday cup, and two ion image detectors.
The following figure shows the arrangement of detectors. The ion counting electron
multipliers are the most sensitive detectors. They must be protected from intense ion
beams. The Faraday cup detector moves on a
solenoid to cover the electron multiplier when
the incoming ion signal is too high. High energy
neutral species form by charge exchange when
an ion beam strikes a surface. These neutrals
contribute noise to the ion signal. If an
electrostatic sector precedes the electron
multiplier, the neutrals can be eliminated from
the ion signal. Quadruple mass analyzers also
use electrostatic sectors or deflectors to minimize
the contributions of high energy neutral species
to the ion signal. The ion beam passes through a
small hole in the electrostatic sector when the
sector is deactivated. This path leads to dual micro channel plate and resistive anode
encoder image detectors. The projector lenses bring an image of the sample into focus on
the image detectors.

Electromagnetically active components are shown in blue. The ion beam


trajectories (indicated in red) are greatly exaggerated in the lateral directions. In
particular, the image detectors are smaller and the path through the electrostatic analyzer
is narrower. The ions pass through a much smaller hole in the sector.
2. INTRODUCTION
Physical Research Laboratory Introduction

2.1 OBJECTIVES

 To provide an integrated station to monitor all the Parameters of IMS 4f at a


single place.

 To monitor various Sub Systems of Mass Spectrometer and provide an Audio-


Visual Alarm.

 To remotely record various parameters & store them for later retrieval &
processing.

 To present the data in a User Friendly manner so as to improve the Operational


Efficiency of the unit and help in Fast Troubleshooting in times of Subsystem
failures.

The Following 17 parameters spread across 5 subsystems were required to be


monitored

Sub Systems

1. Duoplasmatron
a. To monitor the status of Arc (On/Off)
b. To monitor and record the Beam current.

2. Galden
a. To monitor the flow of Galden
b. To monitor the level of Galden in the Sump

3. Pumps
a. To monitor the pressure(Vacuum) of rotary pump
b. To monitor the rpm of four Turbo Pumps catering to:
i. Duoplasmatron
ii. Primary Column
iii. Sample Chamber
iv. Sample Changing Chamber
c. To monitor the pressure of two Ion Pumps.

4. Water Chiller
a. To monitor water flow through the system
b. To monitor water level in the chiller unit.
c. To monitor water temperature in the chiller unit

5. Lab
a. To monitor the temperature of Lab
b. To monitor the Humidity of the Lab.
Physical Research Laboratory Introduction

2.2 MODULAR APPROACH


The approach was to develop a highly modular System to achieve the fore stated
objectives. The desired system was divided into four modules
1) Transducer & Transmitter Module
2) Data Collection Module
3) Data Storage Module
4) Display & Alerter Module

Display
Transducers Data Data
&
& Collection Storage
Alerter
Transmitters System Solution
Systems

2.1 Modular System Diagram

A modular system had imminent advantage of allowing simultaneous


development, effective troubleshooting & minimal interdependence. This also allowed
each module to be developed using different technology platforms. For effective
integration of the system all that was required was to build effective interfaces between
the modules. This led to an increase in overall efficiency of the system.

To monitor the target parameters a standard master slave approach was chosen.
Hereby a central data acquisition board was to be built. All the sensors & transducers
would be on the respective slave boards at an optimum location with respect to their
target parameters. The central DAQ board would have the responsibility to collate the
data from these boards.

2.2.1 Transducer & Transmitter Module

 This module comprises of different slave sensor boards designed to measure one
or many of the target parameters.

 The slave sensor boards would be located as close as possible or at an optimum


distance from the target parameter.

 The measuring principle applied should be such so as to cause minimum


interference with the SIMS viz electric, magnetic or noise fields. Also it should
not impact, degrade or change the parameter being measured

 The slave sensor boards should include signal processing so as to maintain the
desired characteristics of signal till it reaches the Central DAQ collector board.
Physical Research Laboratory Introduction

 The slave sensor boards should transmit data continuously or when requested by
the DAQ collector board with minimum latency.

 The slave sensor boards should provide power to all its on board electronics &
should not draw any power (or minimal power (current) if absolutely required)
from the SIMS machine.

 The slave sensor boards should ensure adequate isolation between:


1) itself & the SIMS machine
2) itself & the DAQ board

2.2.2 Data Collection Module

 This module consists of a central DAQ board.

 It has the responsibility to periodically gather the data from the slave boards.

 It should provide for attaching more number of slave boards as may be required in
the future i.e. port expansion capability.

 It should do the required processing like A-to-D conversion & present the data in
a format acceptable to the storage solution

 It should provide for a low BER, low latency, high speed, high bandwidth method
of transmission to data storage system

 It should (if required) provide for adequate isolation between:

1) itself & the slave boards (input ports)


2) itself & the data storage system (output port)

 A microcontroller based platform was chosen to develop a custom DAQ board.

 USB 2.0 was chosen as the interface between DAQ & data storage system due to
its several advantages like plug & play, high compatibility, high bandwidth, high
speed, low BER et al.

2.2.3 Data Storage Module

 It should provide for adequate storage space.

 The data should be easily accessible.


Physical Research Laboratory Introduction

 It should be easy to retrieve the data & transport it to other physical systems.

 Data storing should not be interrupted while the data is being accessed.

 Considering the huge space requirement & the easy availability of computers,
data storage solution is usually implemented on a pc.

 This provides for several advantages like no need to physically replace the
EEPROMS /chips, storage space in excess of GBs, all standard data transport
mechanisms available et al.

 Advanced data management softwares could be utilized on PCs for efficient &
orderly maintenance of data.

 PC based data storage systems are highly user friendly.

2.2.4 Display & Alerter Module

 It should display the data in a meaningful & easy to interpret.

 It should provide for charts & other analytic tools to aid in speedy & complete
extraction of information.

 It should display data in real time.

 It should provide for remote viewing of the data.

 Use of data visualization package was deemed to be required for a graphical


display of data.

 For remote viewing it was decided to utilize the services offered by state-of-art
LAN network of PRL.

2.3 PROJECT MANAGEMENT

Detailed deliberations with departmental Engineers led to a conclusion that the


project was too big to be realized in a five month span. Hence it was decided to divide the
project into phases & implement at least one of the phase, the remaining to be completed
at a later schedule.
Physical Research Laboratory Introduction

An important factor in deciding the phasing of project was the SIMS. The SIMS machine
is operated continuously day & night. Even when it is not analyzing the pumps and most
of other subsystems have to be kept running to maintain the operating conditions. For
e.g. Sims operates at close to 10-9 torr. Once the vacuum is lost it takes close to two days
for the pumps to reclaim the vacuum. This meant that SIMS electronics was not available
for analysis & sensor development. The SIMS has the state-of-the-art electronics of the
90’s. It comprises of over 140 boards housed in four panels spanning 5 meters. This led
to division of the project into two phases.
1) Phase-1 Development of Backbone System.
2) Phase-2 Development of Sensor Systems.

2.3.1 BACKBONE SYSTEM

 It comprises of the three modules of the system: Data Collection, data storage &
data display.

 It involved the entire data flow from the DAQ board to USB interface to data
Storage on the PC & thereafter to the Display service over the LAN.

 It was expected to be completed in the five months duration.

 It is meant to provide interfaces for integration of the slave board as & when they
are developed.

2.3.1 SENSOR SYSTEMS

 It comprises of the transducer & transmitter module.

 It is to be developed when SIMS could be made available for development work.

 All sensor systems are expected to be completed in 2 years time.

 As & when a sensor board is developed it is to be connected to the DAQ board &
integrated with the whole system.
Physical Research Laboratory System

Chapter 3

SYSTEM
Physical Research Laboratory System

3.1 OVERVIEW

This chapter provides a bird’s eye view of the complete system. Physically the
system consists of three components:
1) The sensor boards (to be implemented in 2nd phase)
2) The DAQ board (referred to herein as the hardware board)
3) The server PC with applications running on it.

The target parameters are sensed by the mechanisms on the Sensor boards. The
data from all sensor boards is collected by the central hardware board. This data could be
in form of analog or digital TTL signals. The central board provides for 8 analog
channels & 16 Digital channels.

The PIC 18f4550 on the Central DAQ Board does all the processing work. It also
implements the USB Protocol framework. The packetised data is now ready to be sent to
the server PC via USB cable. At PC device drivers take care of interfacing with the
board.

Hereafter a Front end Logging Application, The SIMS Monitoring System takes
on. It validates the received data, decodes it and logs it into a MS ACCESS database. It
also applies a Smart sense for effective data logging.

The ionprobe.mdb database stores the received data. It is organized in form of 12


tables. Each table is dedicated to a single or a group of parameters. The datasets are
appended in form of rows at the end of tables.

A dashboard website has been developed for allowing remote viewing of the data.
Being an Intranet application, user can log into this SIMS Monitoring Site using any
system connected to the PRL LAN. A PC at the ionprobe lab has been turned into a local
server for hosting this web application. The current URL of the SIMS Monitoring Site is
http://172.16.13.153/dashboard_prl/login.aspx.

User authentication is done in the login page. The dashboard page displays the
current status data with the help of gauges & charts. The site automatically refreshes
every 40 seconds

The Site also provides a chart panel. The data can be analyzed remotely using the
charts. Graphs can be generated of any parameter for any given time interval. Three
charts can be viewed simultaneously.

The hardware, firmware, data logger, database & dashboard website are discussed
in comprehensive detail in separate chapters.
Physical Research Laboratory System

PC, ION PROBE LAB LOCAL SERVER

Data Logger Database Data Visualization


VB.NET MS Access Dundas

USB 2.0
MCHPCDC Web Service
Driver ASP.NET IIS

rd
Orcad
oa USB SIE
B
PRL
8 Analog
LAN
e
Channels Sensor
ar
MPLAB IDE Boards
w MCHPFSUSBv2.4 16 Digital
d MCCC18 Channels IMS 4F
PICKIT2
ar
PIC 18f4550 User
H
Browser

Fig 3.1 Data Flow diagram of the System

Note: 1) Italics denote the software platforms used


2) Sensor boards on IMS 4f will be implemented in the next phase of the project.
Physical Research Laboratory System

3.2 HARDWARE BOARD

The hardware board is a 24 channel data Acquisition board based around the PIC
18f4550 microcontroller from Microchip Inc. The PIC 18f4550 is a 40 pin DIP package.
The PIC 18f4550 collects data one by one from all 24 channels, processes them &
converts them in a format suitable for transmission over the USB cable to the PC.

The board provides for 8 analog input channels & 16 digital input channels. To
conserve microcontroller pins, multiplexers have been used. 74LS150 is a 16-to-1 digital
multiplexer catering to the digital input channels. Analog channels are obtained by using
DG408 8-to-1 Analog multiplexer. PIC 18f4550 has an onchip 10-bit ADC. The
microcontroller also sports a 5 pin ICSP port for programming. A mini USB port is
provided for connecting the USB cable.

The PIC has to first poll through the 16 digital channels acquiring the state of
each digital channel. Thereafter it polls through the 8 analog channels performing an
ADC conversion on each channel using the internal ADC engine. Then a suitable format
is decided upon to transmit the data via the USB.

The PIC 18f4550 provides a Serial Interface Engine (SIE) for serial transmission
of data. It also features an inbuilt USB transceiver capable of full speed USB
transmission. The USB framework is coded into the microcontroller.

A 1.5m USB cable connects the board to the PC. USB is operated in
Communications Device Class (CDC) mode at a full speed of 12Mbps. The CDC driver
MCHPCDC is provided by Microchip. The USB provides true Plug & Play capabilities in
that it can be attached or detached without rebooting the server. The use of USB lends
several other advantages to the system detailed in Chapter 4 on Hardware.

The onchip USB engine then takes the data from its input buffer & dumps them
on to PC as soon as the protocol allows for it. The data can also be explicitly sent to the
USB using the custom functions available in the Microchip Application libraries. At PC
the data is then decoded, processed & stored for further operations. Since USB is a
bidirectional bus, the PIC Microcontroller can also receive data & commands from the
PC

The PIC also allows for an external USB transceiver to be used. However using
external transceiver option requires 6 pins of the microcontroller to be dedicated for USB
Transmission. The use of Internal Transceiver dictates dedicating only two pins for
transmission purposes. The external transceiver option is handy when application
demands isolation between PC & hardware board.

The board houses a 20MHz crystal. However full speed USB operation requires a
stable clock of 48MHz. This is obtained from the 20MHz input using pre & post scalers
with a PLL. The microcontroller runs at a frequency of 20MHz.
Physical Research Laboratory System

3.3 ION PROBE LOCAL SERVER

A PC has been earmarked for this system. It runs the Internet Information Server
(IIS) along with all the software applications of this system. Mainly three pieces of
system software are residing on the PC:
1) Data Logger (Windows Console Application)
2) Database (MS ACCESS)
3) Dashboard Web Service (Visual Studio 2005 –ASP.NET)

The data from the hardware board is received via the USB. Microsoft Windows
has built in support for the USB. On attaching the USB cable from hardware board to the
pc, Windows automatically tries to find the appropriate driver, MCHPCDC in our case, &
installs it. The MCHPCDC driver provides for an Application Programming Interface
(API). It emulates a virtual com port & pools all USB data to this Virtual Serial Port. The
data logger application then accesses this com port to obtain the data.

3.3.1 DATALOGGER

Once the data has been sent to the PC, we need a utility on the PC to receive this
data. Usually a device driver takes care of the lower level details of the protocol. The
front end application has to interface with the driver API. The MCHPCDC driver creates
a Virtual Com port for the Front end Applications

Visual Studio provides for a MSCOMM class that makes working with Com ports
easy. The SIMS Monitoring System data logger is a Windows Console application
created with Visual Studio 2005 in VB language. Set in Black background, the data
logger has a user friendly interface.

It has a drop down listbox containing the list of available com ports. Once the
appropriate com port has been chosen, clicking on the Connect button takes the program
to the main loop.

The data logger tries to open the selected Com Port. On successful connection the
application reads from the Serial Port Buffer. Now this speed with which the Front end
Application reads the buffer determines the Actual rate of data transmission. This is so
because the buffer has a limited capacity, hence until the last data is read, new data is not
loaded into buffer. To avoid any loss of data, the microcontroller always waits for the last
transaction to be complete before sending in new data.

The received data string is displayed in a text box at the bottom. The data is then
checked for validation. On validation, the received string is decoded to extract
meaningful information. The parameter values so extracted are then displayed in
Physical Research Laboratory System

appropriate textboxes. Simultaneously they are logged with a timestamp into their
respective tables in the database.

The speed of data logger is influenced by the capacity of the system on which it is
running. On a P4 system running at 2.4GHz with 1GB RAM, with no other process
active, the SIMS monitoring System could log 12 records every second. However at
normal load on PC, the logging rate was found to be averaging at 6 insertions per second.

3.3.2 MICROSOFT ACCESS DATABASE

The database implemented in MS ACCESS stores the acquired values. These


values are retrieved by the Dashboard Web service. The ionprobe.mdb located in the
dashboard_prl folder is the database file of the system.

The database is arranged in form of tables. Each new dataset is appended as a new
row at the end of the table. As such ACCESS does not put on a limit on the number of
rows in a table. In practice using a long integer as a primary key puts a limit of 2 31 rows.
With an average logging speed of 6 rows per second, it would take 11.5 years (or 139
months) to exhaust a table of 231 rows.

The database has the following 12 tables.

1) DuoDetails : stores the on/off details of particular Duoplasmatron.

2) Duomain : stores the records of all Duoplasmatrons used

3) Galden Flow : stores the status of flow of Galden through the instrument.

4) Galden Level : stores the level of Galden in the sump.

5) Lab Humidity : stores the humidity levels of the lab

6) Lab Temperature : stores the temperature levels of the lab.

7) Login : stores userids, passwords & usernames for login purposes.

8) Pump Pressure : stores the pressure values of various pumps

9) Pump Speed : stores the speed values of various pumps.

10) Water Flow : stores the status of flow of water through the instrument

11) Water Level : stores the level of water in the Chiller.

12) Water Temp : stores the temperature of the water


Physical Research Laboratory System

The details of the fields of the tables & their formats are covered in
comprehensive detail in Chapter 7 on Database.

3.3.3 DASHBOARD WEB SERVICE

To allow for remote viewing of data, a web service has been created. A pc in the
ion probe lab has been deemed as a local server running the Internet Information Server
(IIS). The SIMS Monitoring Site (http://172.16.13.153/dashboard_prl/login.aspx) has
been custom developed for the purpose of displaying Data Acquisition results. The site
uses xhtml & is developed using Visual Studio.NET 2005 (ASP.NET) in C# (C Sharp)
language.

The site has been developed as a dashboard website. A Dashboard Website offers
a central access to all the Data in one Single Pane. Dundas Data Visualization Inc’s
Dundas Gauge & Chart Controls for ASP.NET have been used to provide data
visualization.

The SIMS monitoring site has only two pages:


1) Login page
2) Dashboard page.

The login page is the startup page. It provides for authentication of the user. It
prompts the user to enter the Employee ID & password. This is then matched with entries
in login table of the ionprobe database. On successful authentication the login page is
closed & dashboard page is opened in a new window in full screen mode. This is to
maximize the screen size available for the dashboard.

The dashboard page has two panels, a Gauge Panel & a Chart panel. The page
automatically refreshes after a predefined time interval. Currently the refresh interval is
set to 40 seconds.

These panels can be accessed by two tabs at the top:


1) Main tab for Gauge panel
2) Details tab for Chart Panel
The main tab displays the current status of the machine. It displays in real time the
values of 17 parameters. To do so, it utilizes a number of Gauges & other numeric &
state indicators. The page has two text rows at the top followed by two rows of gauges.
The name of the logged-in user is displayed at the right end in the first row (for
e.g. “Welcome Dr. Kuljeet Kaur”). The second row is meant to provide one line status of
the whole machine. It will indicate if any of the subsystems require attention. If
everything is ok it will declare SIMS to be in good health.
Physical Research Laboratory System

The details of the different gauges on the main tab of dashboard page are as
follows.
1) Duoplasmatron Vacuum Gauge
It displays the vacuum at Duoplasmatron in units of torr in form of a
circular gauge with numeric indicator displaying the value up to two decimal
digits.

2) Tc1 Rotary Vacuum Gauge


It displays the vacuum generated by rotary pump in primary column in
form of a circular gauge in units of torr with numeric indicator displaying the
value up to two decimal digits.

3) Tc2 Sample Chamber Vacuum Gauge


It displays the vacuum generated by rotary pump at the sample chamber in
form of a circular gauge in units of torr with numeric indicator displaying the
value up to two decimal digits.

4) Entry Slit Arm Ion Pump Pressure Gauge


It displays the vacuum generated by ion pump at the entry slit arm in form
of a circular gauge in units of torr with numeric indicator displaying the value
up to two decimal digits.

5) Exit Slit Ion Pump Pressure Gauge


It displays the vacuum generated by ion pump at the exit slit arm in form
of a circular gauge in units of torr with numeric indicator displaying the value
up to two decimal digits.

6) Galden Flow Gauge


It displays the flow of Galden in the instrument in form of a linear gauge
with a numeric Indicator displaying the text ‘LOW’ or ‘OK’ as per the case.

7) Galden Level Gauge


It displays the level of Galden in the Sump in form of a linear gauge with a
numeric Indicator displaying the text ‘LOW’ or ‘OK’ as per the case

8) Duoplasmatron Hour Gauge.


It displays the number of the hours Duoplasmatron has been put on in
form of a circular gauge with a 3 digit numeric indicator displaying the exact
value.
Physical Research Laboratory System

9) Duoplasmatron Turbo Pump Speed Gauge


It displays the speed of turbo pump serving the Duoplasmatron in units of
rpm in form of a circular gauge with a 5 digit numeric indicator displaying the
exact value.

10) Primary Column Turbo Pump Speed Gauge


It displays the speed of turbo pump serving the Primary Column in units
of rpm in form of a circular gauge with a 5 digit numeric indicator displaying
the exact value.

11) Sample Chamber Turbo Pump Speed Gauge


It displays the speed of turbo pump serving the Sample Chamber in units
of rpm in form of a circular gauge with a 5 digit numeric indicator displaying
the exact value.

12) Sample Changing Chamber Turbo Pump Speed Gauge


It displays the speed of turbo pump serving the Sample Changing
Chamber in units of rpm in form of a circular gauge with a 5 digit numeric
indicator displaying the exact value.

13) Water Temperature Gauge


It displays the temperature of Water in the chiller in units of oC in form of
a linear gauge with a 3 digit numeric indicator displaying the exact value up to
1 decimal place.

14) Lab Temperature Gauge


It displays the temperature of Lab in the chiller in units of oC in form of a
linear gauge with a 3 digit numeric indicator displaying the exact value up to 1
decimal place.

15) Lab Humidity Gauge


It displays the relative humidity of lab in the chiller in units of percentage
in form of a linear gauge with a 3 digit numeric indicator displaying the exact
value up to 1 decimal place.

16) Water Flow Gauge


It displays the flow of Water in the instrument in form of a linear gauge
with a numeric indicator displaying the text ‘LOW’ or ‘OK’ as per the case

17) Water Level Gauge


It displays the level of water in the Chiller in form of a linear gauge with a
numeric indicator displaying the text ‘LOW’ or ‘OK’ as per the case
Physical Research Laboratory System

The details tab provides for 3 integrated chart containers. These can be used to
analyze the data of any parameter for any given time interval.
Since each chart can display more than one parameter, a drop down box has been
provided for parameter selection. Upon selecting a parameter, the page automatically
reloads to display the selected parameter data. The parameters available in each Chart
container are as shown below:

1) Pump Chart Container


 Rotary1
 Rotary2
 Turbo1
 Turbo2
 Turbo3
 Turbo4
 Ion1
 Ion2

2) Duoplasmatron Chart Container


 All the Duoplasmatrons used so far

3) Temperature/ Humidity Chart Container


 Water Temperature
 Lab temperature
 Lab humidity

The values are plotted against the timestamp. The y-axis automatically takes a
range suitable to accommodate all the data points to be displayed. The X-axis (date &
Time) can be zoomed in or out by selecting appropriate time interval.
Using Java Script a calendar has been built providing the facility of date picker.
The User can select the Start date & End date using this date picker. All the charts on the
page will then display the data for the selected period. The default end date is the current
date & default start date is one month in the past from the current date.
More information on the exact implementation of dashboard is available in the
chapter 6 on dashboard.
Physical Research Laboratory System
Physical Research Laboratory Hardware

Chapter 4

HARDWARE
Physical Research Laboratory Hardware

4.1 OVERVIEW
The implemented hardware portion is the DAQ board. The ICs used in developing
this board are:
i. PIC 18f4550
ii. 74LS150
iii. DG408
The use of optoisolators should be considered for isolating the input channels
from the board. It provides for 16 channels to be connected. It has a 5 pin ICSP port for
programming. It carries an AB type USB port for connecting to PC. The input channels
are implemented using multiplexers. The 74LS150 is a 16-to-1 Digital multiplexer. The
four select lines are connected to Pins 19-22. The input from 74ls150 is received at Pin
33(Port B.0). The DG408 is a 8-to-1 Analog Multiplexer. The three select lines are
connected to Pins 27-29. The analog input from DG408 is connected to ADC channel 0,
(pin 2).

4.2 PIC 18F4550


The PIC 18f4550 is a 8-bit microcontroller from Microchip Inc packaged in a
40pin DIP.
Universal Serial Bus Features:
 USB V2.0 Compliant
 Low Speed (1.5 Mb/s) and Full Speed (12 Mb/s)
 Supports up to 32 Endpoints (16 bidirectional)
 1-Kbyte Dual Access RAM for USB
 On-Chip USB Transceiver with On-Chip Voltage Regulator

Regular Features:

 Operating Frequency DC – 48 MHz

 Program Memory (Bytes) 32768;

 Program Memory (Instructions): 16384

 Data SRAM Memory (Bytes) 2048:

 Data EEPROM Memory (Bytes) 256

 Instruction Set: 75 Instructions; 83 with Extended Instruction Set

 20 Interrupt Sources

 I/O Ports :Ports A, B, C, D, E

 4 Timers
Physical Research Laboratory Hardware

 10-Bit Analog-to-Digital Module :13 Input Channels

 2 Capture/Compare/PWM Modules

 Serial Communications: MSSP, Enhanced USART

 Streaming Parallel Port (SPP)

 2 Comparators
Physical Research Laboratory Hardware

4.2.1 Oscillator Settings

Full speed USB operation requires a stable clock of 48 MHz. A 20 MHz crystal is
connected to pins 13 & 14 of the PIC 18F4550. This input is given to the on chip PLL via
a Prescaler. The PLL requires an input of 4 MHz & gives an OUTPUT of 96 MHz. hence
the prescaler is used to divide the 20 MHz input by 5. A postscaler then divides the PLL
output by two to give 48 MHz to USB engine.

Fig 4.1 Oscillator Block Diagram


Physical Research Laboratory Hardware

The microcontroller core can be driven at desired frequency using any of the following
sources:
 The Primary Oscillator, Connected to pins 13 & 14
 The PLL output,
 The Secondary Oscillator, Connected to pins 15& 16.
 The Internal RC oscillator.
The microcontroller core runs at 20MHz, while the USB module runs at 48MHz.

4.2.2 ADC Settings

The 18F4550 has 13 channel 10bit ADC. The module has five registers:
 A/D Result High Register (ADRESH)
 A/D Result Low Register (ADRESL)
 A/D Control Register 0 (ADCON0): controls the operation of the A/D module.
 A/D Control Register 1 (ADCON1): configures the functions of the port pins.
 A/D Control Register 2 (ADCON2): configures the A/D clock source,
programmed acquisition time and justification.

The analog reference voltage is software selectable to either the device’s positive and
negative supply voltage (VDD and VSS) or the voltage level on the RA3/AN3/VREF+
and RA2/AN2/VREF-/CVREF pins.
The following steps should be followed to perform an A/D conversion:
1. Configure the A/D module:
 Configure analog pins, voltage reference and digital I/O (ADCON1)
 Select A/D input channel (ADCON0)
 Select A/D acquisition time (ADCON2)
 Select A/D conversion clock (ADCON2)
 Turn on A/D module (ADCON0)
2. Configure A/D interrupt (if desired):
 Clear ADIF bit
 Set ADIE bit
 Set GIE bit
3. Wait the required acquisition time (if required).
4. Start conversion:
 Set GO/DONE bit (ADCON0 register)
5. Wait for A/D conversion to complete, by either:
 Polling for the GO/DONE bit to be cleared
OR
 Waiting for the A/D interrupt
6. Read A/D Result registers (ADRESH:ADRESL);clear bit ADIF, if required.
7. For next conversion, go to step 1 or step 2, as required. The A/D conversion time per
bit is defined as TAD. A minimum wait of 3 TAD is required before the next acquisition
starts.
Physical Research Laboratory Hardware

4.2.3 USB Settings


The SIE can be interfaced directly to the USB, utilizing the internal transceiver, or
it can be connected through an external transceiver. An internal 3.3V regulator is also
available to power the internal transceiver in 5V applications.

The operation of the USB module is configured and managed through three
control registers. In addition, a total of 22 registers are used to manage the actual USB
transactions. The registers are:
 USB Control register (UCON): controls the module behavior during transfers.
 USB Configuration register (UCFG): configures the module’s associated internal
and/or external hardware
 USB Transfer Status register (USTAT): reports the transaction status within the
SIE
 USB Device Address register (UADDR): contains the unique USB address that
the peripheral will decode when active.
 Frame Number registers (UFRMH:UFRML): contain the 11-bit frame number.
 Endpoint Enable registers 0 through 15 (UEPn) independent control register for
each endpoint

Fig 4.2 USB Block Diagram


Physical Research Laboratory Hardware

4.3 Circuit Diagram


Physical Research Laboratory Hardware

Chapter 5

FIRMWARE
5.1 OVERVIEW

The firmware has been developed using Microchip’s MPLAB IDE v8.20. The
coding has been done in C language. Microchip’s C18 Compiler was used for compiling
the project. The USB framework has been coded onto the microcontroller. The
Microchip’s USB Framework v2.4 – MCHPFSUSBv2.4 has been utilized for this
purpose. Microchip’s latest Application Libraries came handy in developing the code.
MPLAB produces two main files:
1) The Microchip Workspace File(.mcw)
2) The Microchip Project File (.mcp)
5.2 USB DEVICE STACK
This section lists the files required for use with the device stack. These files
should be included in any project using the USB device stack
Name  Description 
usb_device.c  This file contains functions, macros, definitions, variables, datatypes,
etc. that are required for usage with the MCHPFSUSB device stack.
This file should be included in projects that use the device stack.
This file is located in the "<Install Directory>\Microchip\USB"
directory. 
usb.h  This is file usb.h. 
usb_ch9.h  This file defines data structures, constants, and macros that are used to
to support the USB Device Framework protocol described in Chapter
9 of the USB 2.0 specification. 
usb_common.h  This file defines data types, constants, and macros that are common to
multiple layers of the Microchip USB Firmware Stack. 
usb_device.h  This file, with its associated C source file, provides the main
substance of the USB device side stack. These files will receive,
transmit, and process various USB commands as well as take action
when required for various events that occur on the bus. 
usb_hal.h  This file abstracts the hardware interface. 
usb_hal_pic18.h  This file abstracts the hardware interface. The USB stack firmware
can be compiled to work on different USB microcontrollers, such as
PIC18 and PIC24. The USB related special function registers and bit
names are generally very similar between the device families, but
small differences in naming exist. 
usb_config.h  usb_config.h is a file used to configure the MCHPFSUSB stack. This
file provides compile time selection of options provided by the stack.
This file defines constants needed by the stack and various function
drivers. 
HardwareProfile.h  HardwareProfile.h is a file used to define hardware specific
definitions that are required by the MCHPFSUSB stack. This file
should be modified to match the application hardware. 
Table 5.1 USB Device Stack Files
Physical Research Laboratory Firmware

This section lists the files required for use with the CDC Device Driver stack.

Name  Description 
usb_function_cdc.h  This file contains all of functions, macros, definitions, variables,
datatypes, etc. that are required for usage with the CDC function
driver. This file should be included in projects that use the CDC
function driver. This file should also be included into the
usb_descriptors.c file and any other user file that requires access to
the CDC interface.

This file is located in the "<Install


Directory>\Microchip\Include\USB" directory. 
usb_function_cdc.c  This file contains all of functions, macros, definitions, variables,
datatypes, etc. that are required for usage with the CDC function
driver. This file should be included in projects that use the CDC
function driver.

This file is located in the "<Install Directory>\Microchip\USB\CDC


Device Driver" directory. 
Table 5.2 CDC Device Driver Stack Files

The table below describes the various Functions from the USB Stack files.

Name  Description 
USBDeviceInit  This function initializes the device stack it in the default
state. The USB module will be completely reset including all
of the internal variables, registers, and interrupt flags. 
USBDeviceTasks  This function is the main state machine of the USB device
side stack. This function should be called periodically to
receive and transmit packets through the stack. This function
should be called preferably once every 100us during the
enumeration process. After the enumeration process this
function still needs to be called periodically to respond to
various situations on the bus but is more relaxed in its time
requirements. This function should also be called at least as
fast as the OUT data expected from the PC. 
USBEnableEndpoint  This function will enable the specified endpoint with the
specified options 
USBCBInitEP  This function is called whenever the device receives a
SET_CONFIGURATION request. 
USBCBSuspend  Call back that is invoked when a USB suspend is detected. 
USBCBWakeFromSuspend  This call back is invoked when a wakeup from USB suspend
is detected. 
USBCBCheckOtherReq  This function is called whenever a request comes over
endpoint 0 (the control endpoint) that the stack does not
Physical Research Laboratory Firmware

know how to handle. 


USBCBSendResume  This function should be called to initiate a remote wakeup.
(optional) 
USBCBErrorHandler  This callback is called whenever a USB error occurs.
(optional) 
USBCBStdSetDscHandler  This callback is called when a SET_DESCRIPTOR request
is received (optional) 
USBCB_SOF_Handler  This callback is called when a SOF packet is received by the
host. (optional) 
USBCBEP0DataReceived  This function is called whenever a EP0 data packet is
received. (optional) 
Table 5.3 USB Stack Functions

The Table below describes the various Macros available from the USB
Device Stack Files.

Name  Description 
USBGetDeviceState  This function will return the current state of the
device on the USB. This function should return
CONFIGURED_STATE before an application tries
to send information on the bus. 
USBGetRemoteWakeupStat This function indicates if remote wakeup has been
us  enabled by the host. Devices that support remote
wakeup should use this function to determine if it
should send a remote wakeup. 
USBIsDeviceSuspended  This function indicates if this device is currently
suspended. When a device is suspended it will not be
able to transfer data over the bus. 
USBHandleBusy  Checks to see if the input handle is busy 
USBHandleGetAddr  Retrieves the address of the destination buffer of the
input handle 
USBHandleGetLength  Retrieves the length of the destination buffer of the
input handle 
Table 5.4 USB Device Stack Macros

These are the functions used for sending & receiving data defined in the
usb_function_cdc.h File

Name  Description 
CDCInitEP  This function initializes the CDC function driver. This function
should be called after the SET_CONFIGURATION command. 
CDCTxService  CDCTxService handles device-to-host transaction(s). This
function should be called once per Main Program loop after the
device reaches the configured state. 
getsUSBUSART  getsUSBUSART copies a string of BYTEs received through USB
Physical Research Laboratory Firmware

CDC Bulk OUT endpoint to a user's specified location. It is a


non-blocking function. It does not wait for data if there is no
data available. Instead it returns '0' to notify the caller that
there is no data available. 
putrsUSBUSART  putrsUSBUSART writes a string of data to the USB including
the null character. Use this version, 'putrs', to transfer data
literals and data located in program memory. 
putsUSBUSART  putsUSBUSART writes a string of data to the USB including
the null character. Use this version, 'puts', to transfer data from
a RAM buffer. 
putUSBUSART  putUSBUSART writes an array of data to the USB. Use this
version, is capable of transfering 0x00 (what is typically a
NULL character in any of the string transfer functions). 
Table 5.5 usb_function_cdc.h Functions

5.3 PROGRAM EXECUTION

The C18 compiler starts off at C018i.c File. The entry point being
void_entry (void) function. This makes a call to _startup function coded in asm.
This Initializes the stack pointer & loads the table pointers. Then it calls the _init
function. If user defined __init is not found, the one in clib.lib will be used

Now the execution jumps to void main (void) function in Main.c. It is the
main Program loop. It does all the work by calling three functions.
1. InitializeSystem()
2. UsbDeviceAttach()
3. ProcessIO()

Application Specific Tasks can be added here or in ProcessIO() function.


The first function encountered in main() is InitializeSystem(). This function
initializes the whole system. It has two functions:
1. Userinit:
User can put in here the initialization code. It calls
mInitAllLed() which initializes the leds.

2. UsbDeviceInit
Usb device initialization code resides here. It does the
following :
1 Clears all USB error flags & USB interrupts.
2 Resets all of the Ping Pong buffers
3 Clears all of the endpoint control registers: for this jump
is made to memset.asm file.
4 Clears all of the BDT entries
5 Initializes EP0 as a Ctrl EP
6 Flushes any pending transactions
7 Clears all of the internal pipe information
8 Makes sure packet processing is enabled
Physical Research Laboratory Firmware

9 Gets ready for the first packet

The UsbDeviceAttach() Function takes care of device attach & detach


procedures. It does the following
1 Masks all USB interrupts
2 Enables module & attach to bus
3 Enables/sets things like: pull ups, full/low-speed mode,
set the ping pong mode, and set internal transceiver

_entry()
c018i.c

_startup
()
c018i.c

_init() Main()
clib.libc main.c

InitialiseSystem() UsbDeviceAttach() ProcessIO()


main.c Usb_device.c main.c

UserInit() USBDeviceInit(
main.c ) BlinkUsbStatus
Usb_device.c ()
main.c

mInitAllLEDs() Memset()
main.c memset.asm

Fig 5.1 Program Flow


Physical Research Laboratory Firmware

The ProcessIO processes the input –output. It sends data to the USB as
well as includes the code for receiving data. Application specific user tasks are
also included in this function. It includes code for polling through the channels,
Code for ADC, code for forming the packet to be sent & finally the code for
sending the data.

5.4 LIST OF FILES

The following list mentions the library files required for this project.

5.4.1 SOURCE FILES


1. c018i.c (/MCC18/src/traditional/startup/c018i.c)
2. memset.asm (/MCC18/src/traditional/stdclib/memset.asm)
3. main.c (Project Directory)
4. usb_descriptors.c (Project Directory)
5. usb_device.c (/Microchip/USB)
6. usb_function_cdc.c (/Microchip/USB/CDC Device Driver)

5.4.2HEADER FILES
1. GenericTypeDefs.h (/Microchip/Include)
2. Compiler.h (/Microchip/Include)
3. usb_config.h (Project Directory)
4. usb_device.h (/Microchip/Include/USB)
5. usb.h (/Microchip/Include/USB)
6. usb_function_cdc.h (/Microchip/Include/USB)
7. HardwareProfile.h (Project Directory)
8. HardwareProfile-p18f4550.h (Project Directory)
9. usb_ch9.h (/Microchip/Include/USB)
10. usb_common.h (/Microchip/Include/USB)
11. usb_hal.h (/Microchip/Include/USB)
12. usb_hal_pic18.h (/Microchip/Include/USB)
13. adc.h (/MCC18/h)
14. p18f4550.h (/MCC18/h)

5.5 CONCLUSION
The Firmware with implementation of USB Device Stack is a significant
achievement of this project. The understanding of USB protocol was crucial in
this work. The USB 2.0 specification & CDC specification was worked out in the
framework. The Microchip’s Demos & other Software support have been very
crucial in the development.

The project now offers a standard transmission interface. Other


functionalities can now be added to the firmware.
Physical Research Laboratory Firmware

Chapter 6

DATALOGGER
6.1 OVERVIEW

Any microcontroller-PC interface system requires a Front End at PC for receiving


the data. The problem of developing a front end for a USB interface is a grave one. This
is so because the front end has to deal with driver level details & there is not much
expertise easily available in this field. Customizing a driver to meet the front end needs is
a clumsy process often requiring months of development work. So the onus is on the
front end to get things done out of the driver API. However the CDC driver turns the
USB interface into a COM port Interface thereby making this front end development a bit
easier a bit easier.

This chapter deals with the implementation details of the SIMS Monitoring
System’s Front end cum data logging application. A snapshot of the user interface is
provided in section 6.3 of this chapter for reference.

6.2 SIMS MONITORING SYSTEM

Sims Monitoring System is the front end Data logger custom developed for this
application. It is a windows Console application developed using Visual Studio 2005 in
VB language. The entire code Sims.vb is included at the end as Appendix B. It is
developed as a Front end cum data Logging application. The flow of data through the
application can be graphically described as below.

MCHPCDC
API Data Reader Data Validater

Data Processor Packet Splitter

Data Displayer Smart Sense Data Logger

6.1 Data flow diagram of Data logger


Physical Research Laboratory Data Logger

For understanding the functioning of the application, it can be divided into six
sequential functional modules:
1) Data Reader
2) Data Validater
3) Packet Splitter
4) Data Processor
5) Data Displayer
6) Smart Sense
7) Data Logger

This modular approach provides for a highly efficient system. Each module interacts
with its immediate neighbors only. This helps in tracking & debugging of errors. The user
interface of SIMS Monitoring System is shown as a snapshot at the end of this chapter.

6.2.1 Data Reader

The user interface provides for a list of com ports available with the system. The
function to update this list is called every millisecond with help of timer. The user has to
select the com port with which our DAQ hardware is associated. This can be known from
the device manager. Once the desired com port has been selected, clicking on the connect
button will start the whole process.

The data is read from the serial port buffer. The read data is then stored in a text
box with id txtdatareceived. The read data can be seen in the multi line textbox at the
bottom of the user interface. Hereafter, all code access only this text box & all
manipulation are done on the text of this textbox.

While accessing the serial port, a Catch expression is always used. This is so
because the device may be disconnected at any time. Reading a port with no connected
device could result in an exception. In such a case, the connection to serial port is closed.

6.2.2 Data Validater

It is necessary to ensure that correct & complete data as been received. Sometimes
due to certain uncontrolled factors, some abnormalities may be introduced in the system.
To protect the data from such corruption some sort of the validation is necessary

Validation is implemented by fixing a data format for the data being transmitted.
This is done in the form of predefined length of data string that is to be sent, unique start-
of-frame & end-of-frame indicators.

For developing phase-1, a length of 214 was fixed. The ‘<’ symbol was used for
start-of-frame identifier & ‘>’ was used for the end-of-frame indicator. Any arbitrary
Physical Research Laboratory Data Logger

protocol could be developed on similar lines. The basic idea is fixing a format at the
sending end & telling the receiving end what to expect.

Firstly, the length of the string received in the txtdatareceived textbox is extracted.
If this value matches the predefined data length, then complete string is received & next
validation test will now be performed. The txtdatastatus textbox is updated with a
message “Packet Size Verified” to indicate this. If there is a mismatch in the size values
then “Packet Size Corrupted” is displayed in the status box. The validation process is
stopped at the first violation; the data is then discarded without performing any further
operations.

On successful packet size validation the start-of-frame is checked. The first


character of the string is extracted using the Substring function. It is then compared with
the assigned start-of-frame symbol. On positive match, status text box is updated with
“Start of Frame Verified” else “Start of Frame Corrupted” is displayed & data discarded.

Same process is repeated with end-of-frame symbol. If required the process can
be repeated for the data delimiters embedded in the frame at known intervals. If a data
string successfully completes all validation tests it is then processed further.

6.2.3 Packet splitter

The data string sent from the hardware board carries status data of all the
parameters, in our case of 24 parameters. At the front end this data has to be extracted &
separated for further processing.

At the transmission end we know the exact space given to each parameter in the
frame to be transmitted. This information is used at the front end for extraction. For
development purpose the string formed at the microcontroller for transmission was of the
following format.
<D16:1010101010101010, ADC01:0000001010101010, ADC02:0000001010101010,
ADC03:0000001010101010, ADC04:0000001010101010, ADC05:0000001010101010,
ADC06:0000001010101010, ADC07:0000001010101010, ADC08:0000001010101010>

The 16 characters after the ‘D16:’ are the status indicators of the 16 digital
channels. The data of each channel is extracted using substring function. The extracted
data could be directly used for processing or saved to a variable. Similarly the 16
characters preceded by ‘ADC1’ represent the 16 bit ADC result of Analog Channel 1.
This is followed by the data of channel 2 & so on till the 8th Analog channel.

The full implementation of this functionality is only possible after the


implementation of Phase-2. As only then it will be known which encoding is used at
transmission end. Accordingly changes should be made in this module.
Physical Research Laboratory Data Logger

6.2.4 Data Processor

To get the most out of the system the data is transmitted in most efficient way.
For e.g. to transmit the status of Duoplasmatron, instead of sending “ON” & “OFF”,
sending a 1 or 0 would be more efficient. This applies to all digital channels. Similarly
analog channels would be transmitted as their binary or hex values.

However after data has been received, they have to be decoded back to their
original state. Sometimes they have to be changed to a format suitable for displaying or to
a format that matches the table structure of the database into which they are to be logged.

For all digital channels after the status character is extracted, an if-else statement
is employed to generate the appropriate value. For analog channels appropriate decoding
code should be added. The desired value is generally of the form required to be
displayed.

The full implementation of this functionality is only possible after the


implementation of Phase-2. As only then it will be known which encoding is used at
transmission end.

6.2.5 Data Displayer

The data processor renders the parameter values which are ready to be displayed.
This display feature can serve as an aid in troubleshooting. The user interface provides
for 18 text boxes to display the parameter values. The text boxes are arranged into 6
Group boxes as shown below:

13) Duoplasmatron
 Vacuum
 Primary beam on off
 Last changed on

14) Vacuum
 Ion Pump
• Entry Slit arm
• Exit Slit arm
 Rotary pump
• Rotary
• Sample Chamber

15) Turbo Pump Speed


 Duoplasmatron
 Primary column
 Sample chamber
 Sample changing chamber
Physical Research Laboratory Data Logger

16) Coolant
 Galden Flow
 Galden Level

17) Lab
 Lab Temperature
 Lab Humidity

18) Water Chiller


 Water Level
 Water Temperature
 Water Flow

In addition to these, the front end also displays the current system time. This is
very important for troubleshooting as System time is the time with which the timestamp
is made. It also has a status textbox which displays the status of the current process.
These text boxes are read only so the user cannot inadvertently type on it & corrupt the
data. It provides a text box for typing in the commands which could be send back to the
microcontroller.

The displayed data is then used for data logging purposes. Such an approach
provides for a highly modular system

6.2.6 Smart Sense

The system has displayed an average logging speed of 6 records per second.
Maintaining such high speed can be justified for sake of better resolution. However many
parameters do not change so fast & after acquiring a state maintain their state for several
minutes. For e.g. the Duoplasmatron could remain switched on for hours. All the while
logging 6 times per second that Duoplasmatron is on is a waste of resource.

Hence smart sense feature was developed. Here the value of parameter is
compared with its last known value. The database is updated only if there has been a
change in the value, else it is discarded. This allows for judicious use of memory resource
& also provides for manageable database size.

The smart sense feature is not employed for all parameters. This is so because
many of the acquired parameters continue to operate in optimum condition. Any change
in their value would be an abnormality.

The exact implementation of smart sense can only be done after implementation
of phase-2. However smart sense is suggested for use with Duoplasmatron ON/OFF.
Physical Research Laboratory Data Logger

6.2.7 Data Logger

It does the actual work of inserting the acquired values into the ionprobe database.
This feature utilizes the System.OleDb class. The ion probe database is stored in the
dashboard_prl folder. Each target parameter has a table associated to it. The new data is
appended as a record at the end of table. The following table shows the association of
parameters to the tables.

Sr. No. Parameter Table Name


1 Duoplasmatron hours duodetails
2 Duoplasmatron vacuum Pump Pressure
3 Rotary pump pressure Pump Pressure
4 Sample chamber pump Pressure Pump Pressure
5 Entry Slit Ion pump Pressure Pump Pressure
6 Exit Slit Ion pump Pressure Pump Pressure
7 Duoplasmatron Turbo Pump Speed Pump Speed
8 Primary column Turbo Pump Speed Pump Speed
9 Sample Chamber Turbo Pump Speed Pump Speed
10 Sample Changing Chamber Turbo Pump Speed Pump Speed
11 Water Flow Water Flow
12 Water Level Water Level
13 Water Temperature Water Temp
14 Galden Flow Galden Flow
15 Galden Level Galden Level
16 Lab Temperature Lab Temperature
17 Lab Humidity Lab Humidity

Table 6.1 Parameters & their Associated Tables

A connection is made to the database. The connection string specifies all the
required values for making this connection. The connection is opened. Then INSERT
INTO statements is used to insert the parameter values to their associated tables.

A value must be specified for all the required columns. The format of data being
logged must match with table structure of table into which it is being inserted otherwise
an exception will occur.

The data to be inserted is retrieved from the text boxes used to display the parameter
values. The required additional values are generated to match the table structure. The
timestamp is generated using the system date & time.
Physical Research Laboratory Data Logger

During experiments, a maximum data logging rate of 12 logs per second was
achieved. The average logging rate hovers around 6 insertions per second.

6.3 SNAPSHOT Of SIMS MONITORING SYSTEM


Physical Research Laboratory Data Logger

6.4 CONCLUSION

Overall, the SIMS Monitoring System is successful in achieving all its objectives.
It is also versatile enough to be adapted for future requirements. The technology platform
used, Visual studio 2005, has a lot many tools that can be utilized for making this
application more user friendly, efficient & feature rich. Before we wind up the chapter, a
few key concerns deserve attention.

The SIMS Monitoring System application has to be kept running continuously for
the period for which data logging is required else the data is lost. The application needs to
be added to the start up folder so that it stats every time the system boots. However, if
due to some reason the application exits, then it must alert the system administrator. A
small data backup of few hours could also be provided at the hardware board.

The speed of data logger puts an upper limit on speed of data acquisition. This is
so because the microcontroller waits for the last transaction to be complete before
sending in new data. Once a data string is read, the SIMS Monitoring System will
validate it, split it, process it, display it & then finally log it. Only after this it will go &
read the next data from the Serial port Buffer. To avoid loss of data during this period,
the microcontroller is kept waiting & sends in new data only after the previous data has
been read. Hence the SIMS Monitoring System’s code needs to be optimized for fast
execution.

The speed of the application is influenced by a number of external factors. One


among them is the health of the PC system on which it is running. Currently the system
used is a 2.4 GHz P4 with 1 GB of RAM. If the load on the PC increases, the application
thread may get slowed down. This will affect the logging rate hence the actual acquired
rate.
Physical Research Laboratory Database

Chapter 7

DATABASE
Physical Research Laboratory Database

7.1 OVERVIEW

Data Acquisition applications usually have data logging feature. There is not
much use of a state-of-art data acquisition system, if the acquired data cannot be made
available at a later time. Data logging provides for further processing & analyses of the
data. Depending on the speed of data acquisition & nature & number of the parameters
being acquired, the volume of data could be enormous. This becomes even more involved
as most data acquisition systems log data continuously & they have to be designed to
keep doing so for years. This calls in for effective data management.

The desired characteristics of a data storage system to be used in conjunction with


a data acquisition system are:

1) It should have a minimal impact on the speed of data acquisition. In other words,
it should be able to save data at the acquired rate or at the closest fastest speed
possible.

2) The data format should be such that it is portable among the standard data
processing platforms or efficient utilities should be available to do the required
conversion for exporting.

3) It should have minimum possible space requirement.

4) It should be able to provide fast retrieval of required data.

5) It should support all standard features like sorting, copying, encryption,


compression etc

6) It should be able to provide data backup capabilities.

7) It should have a user friendly interface with minimum amount of learning/


training needed by the user.

Several state-of-art database management systems are available today like Oracle,
SQL, Sybase et al. After qualitative considerations, MS ACCESS was found to be the
best candidate. It was also compatible with the data logger built on .Net platform. The
web service which used Dundas controls for displaying data could also retrieve data from
ACCESS using the System.OleDB class.

7.2 THE IONPROBE DATABASE

The ionprobe.mdb located in the dashboard_prl folder is the database file of the
system. The database is arranged in form of tables. Each table is dedicated to either a
single or a group of similar parameters. The data is appended in the form of a new row at
the end of the table. The incoming data should match the number & data type of columns
in the table otherwise data will not be inserted. This has to be ensured by the data Logger.
Physical Research Laboratory Database

The details of the tables & the format in which they store data are described below. The
database has the following 12 tables.

1) DuoDetails 7) Login
2) Duomain 8) Pump Pressure
3) Galden Flow 9) Pump Speed
4) Galden Level 10) Water Flow
5) Lab Humidity 11) Water Level
6) Lab Temperature 12) Water Temp

7.2.1 DUODETAILS
 It stores the details of the on/off of particular Duoplasmatron.
 It has four columns:
o ID: It stores the Id of Duoplasmatron
o Start Date: It holds the timestamp at which current observation started.
o End Date: It holds the timestamp at which current observation stopped.
o Status: It stores the status of flow of Galden
o 0: if OFF
o 1 : If ON

Table 7.1 DUODETAILS TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 ID Text Valid Values: duo1, duo2…
2 Start Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 End Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
4 Status Number Valid values: ‘0’ or ‘1’

7.2.2 DUOMAIN
 It stores the details of all Duoplasmatrons.
 It has four columns:
o ID: It stores the Id of Duoplasmatron.
o Start Date: It holds the timestamp at which current observation started.
o End Date: It holds the timestamp at which current observation stopped.
o Total Time: It holds the total number of hours the Duoplasmatron was
on.

Table 7.2 DUOMAIN TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 ID Text Valid Values: duo1, duo2…
2 Start Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 End Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
4 Total time Number
Physical Research Laboratory Database

7.2.3 GALDEN FLOW


 It stores the data related to the flow of Galden (coolant) through the instrument.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Galden_Flow: It stores the status of flow of Galden
o LOW: If below predetermined flow rate
o OK : If equal to or above predetermined flow rate

Table 7.3 GALDEN FLOW TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Galden_Flow Text Valid values: ‘LOW’ or ‘OK’

7.2.4 GALDEN LEVEL


 It stores the data related to the level of Galden (coolant) in the sump.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Galden_level: It stores the status of level of Galden
o LOW: If below predetermined level
o OK : If equal to or above predetermined level

Table 7.4 GALDEN LEVEL TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Galden_Level Text Valid values: ‘LOW’ or ‘OK’

7.2.5 LAB HUMIDITY


 It stores the data related to the relative humidity in the lab.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Lab_humidity: It stores the relative humidity in the lab.
o Valid Values: 0-100.

Table 7.5 LAB HUMIDITY TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Lab_humidity Number Long Integer. Valid values 0~100
Physical Research Laboratory Database

7.2.6 LAB TEMPERATURE


 It stores the temperature in the lab.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Lab_ temperature: It stores the temperature in the lab.
o Valid Values: 0-100.

Table 7.6 LAB TEMPERATURE TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Lab_temperature Number Long Integer. Valid values 0~100

7.2.7 LOGIN
 It stores the authentication details to be verified at the time of Login.
 It has three columns:
o UserID: It stores the Employee ID.
o Password: It stores the password.
o Name: It stores the user name to be displayed on dashboard page

Table 7.7 LOGIN TABLE STRUCTURE


Sr. no. Field Name Data Type Remarks
1 UserID Text Used for login
2 Password Text Used for login
3 Name Text Displayed on the dashboard page

7.2.8 PUMP PRESSURE


 It stores the data related to the pressure of the 5 pumps.
 It has three columns:
o PumpId: It stores the pump ID.
 Valid Values: Ion1. Ion2, rotary1, rotary2, duo
o Date_time: It holds the timestamp of the moment of data entry.
o Pressure: It stores pressure of the pump.

Table 7.8 PUMP PRESSURE TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 PumpId Text Valid Values: Ion1. Ion2, rotary1, rotary2, duo
2 Date_time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 Pressure Number Long Integer.
Physical Research Laboratory Database

7.2.9 PUMP SPEED


 It stores the data related to the speed of the 4 Turbo pumps.
 It has three columns:
o PumpId: It stores the pump ID.
 Valid Values: turbo1, turbo2, turbo3, turbo4.
o Date_time: It holds the timestamp of the moment of data entry.
o Pressure: It stores the speed of the pump.

Table 7.9 PUMP SPEED TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 PumpId Text Valid Values: turbo1, turbo2, turbo3, turbo4
2 Date_time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 Speed Number Long Integer.

7.2.10 WATER FLOW


 It stores the data related to the flow of water (coolant) through the instrument.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Water_Flow: It stores the status of flow of water
o LOW: If below predetermined flow rate
o OK : If equal to or above predetermined flow rate

Table 7.10 WATER FLOW TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Water_Flow Text Valid values: ‘LOW’ or ‘OK’

7.2.11 WATER LEVEL


 It stores the data related to the level of water in the chiller.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Water_level: It stores the status of level of water
o LOW: If below predetermined level
o OK : If equal to or above predetermined level

Table 7.11 WATER LEVEL TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
Physical Research Laboratory Database

2 Water_Level Text Valid values: ‘LOW’ or ‘OK’

7.2.12 WATER TEMPERATURE


 It stores the temperature of water in the lab.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Water _ temperature: It stores the temperature in the lab.
o Valid Values: 0-100.

Table 7.12 LAB TEMPERATURE TABLE STRUCTURE


Sr. no. Field Name Data Type Format
1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Water _temperature Number Long Integer. Valid values 0~100

7.3 SNAPSHOTS

7.3.1 ION PROBE DATABASE


Physical Research Laboratory Database

7.3.2 GALDEN FLOW TABLE


Physical Research Laboratory Database

7.4 Conclusion

Overall, the ionprobe.mdb database satisfies all of its required specifications.


Being implemented on a standard Microsoft Office platform, it provides for all the
standard features as well as the portability. The tables can be sorted, queried and reports
be generated. The data can also be exported to Microsoft Excel for advanced
mathematical manipulation or generation of charts. As we wind up this chapter, lets
discuss some key points to be kept in mind while operating the database.

The login table is used for authentication at the time of startup. If the database is
opened at the server machine, then login table becomes inaccessible to the web service. If
a user tries to login at this time at a remote browser, an exception will occur. However
after login the database can be viewed at the server. This will not interfere with the
logging activity or the refresh of the webpage at the remote browser.

The limit on the number of rows in a table comes from the use of long integer as a
primary key. In such a case a maximum of 231 rows can be accommodated. With an
insertion rate of 6 rows per second, it would require11.5 years of continuous logging to
exhaust such a table. However it is not advisable to build up such a huge table. A backup
policy should be devised to prevent building up of data in a single file.

The ionprobe.mdb is located in the dashboard_prl folder. If the database is


relocated then the new path should be updated at all places that access the database. This
could be a cumbersome process as database is accessed by data logger & dashboard web
service on quite a large number of occasions. If absolutely required, it is suggested to
make a copy of the database at desired location.
Physical Research Laboratory Dashboard Web Service

Chapter 8

DASHBOARD WEB SERVICE


Physical Research Laboratory Dashboard Web Service

8.1 Sims Monitoring Site Overview

A website has been developed in xhtml for allowing for remote viewing of status data
over the Intranet. The site has been developed using Visual Studio 2005 in C# language.

The site has two pages: (a) login page & (b) dashboard page. On startup it displays
the Login Page. It does the job of authenticating the user. After successful login the
window is closed & dashboard page is opened in a new window in Full screen mode. The
dashboard page displays the current status of SIMS with the help of various gauges.

8.2 DASHBOARD

To provide an effective display & interpretation of data, the concept of dashboard was
used. Dashboard web sites analogous to the dashboards on automotive vehicles provide
the information about complete state of system on a single screen. In one look, a fair idea
about the current state of the system can be obtained. Dashboards don’t carry a large
number of links nor do they have multiple pages, however they may provide links to
external websites. They have drill down feature to carry the extra data which could not be
accommodated on a single page.

Several dashboard generating tools are available in the market. However I chose
to create a custom dashboard so as to have full control over all its features without any
limitation. To display data in an easy to interpret form, the need of data visualization
software was realized. I selected the best data visualization service available for Visual
Studio, the Dundas Gauge & Chart Control from Dundas Data Visualization Inc.

Dundas Gauge for ASP.NET is a fully managed ASP.NET control that lets
developers add Gauges to their applications, and attain a new level of data
visualization with a minimal amount of effort.

Dundas Gauge for ASP.NET includes a full assortment of Gauge types, including
circular gauges, linear gauges, angular gauges, and thermometer gauges all of which have
been designed to help you add a new dimension of data visualization, and analysis to
your ASP.NET applications. With customization abilities, and full integration into Visual
Studio 2005, one can get the exact look and feel one needs for all applications.

Dundas Gauge for ASP.NET includes more than just incredibly attractive
Gauges. Advanced data manipulation abilities let you get the most out of your data, with
a minimum amount of effort. For example, historical data which is easily stored enables
both playback and display of calculated values such as minimums, maximums,
and averages. You can display your data in real-time, and customize the scales, needles,
alarms, labels, and markers you use to get the exact Gauge you want for your specific
visual analysis.

Dundas Chart for ASP.NET is the perfect solution for developers looking to add
advanced, feature rich, visually appealing charts to their ASP.NET applications. It
Physical Research Laboratory Dashboard Web Service

consists of the charting web control, numerous sample applications and solutions, and
extensive documentation to guide you every step of the way.

The Chart control is an easy to use ASP.NET web-server control that lets you add
robust charting abilities to your applications with a minimum amount of effort. The
control has been created using C#, which means that it is a fully-managed .NET
component, and it has been specifically designed for use with Microsoft's Visual
Studio .NET.

Dundas Chart for ASP.NET is available in two editions including the Professional
edition, and Enterprise edition. Both editions are feature rich and easy to use.

The following is a list of features for Dundas Gauge for ASP.NET. This feature
list is organized by its major components, starting with the root Gauge Container object,
and proceeding through all of its functional elements. 

Features of the Gauge Container

The Gauge container is the root object used to contain and display any number of
Gauges, or indicators. This root object can support each Gauge having one or more
Pointers (e.g. a Needle), Scales, and Ranges. The Gauge container is as powerful, as it is
flexible. These are the features of this component, and its elements:

 Full Visual Studio 2005 Integration.


 Full Smart-Tag capability.
 Improved data binding using an object, web service, or database.
 Design-time cloning of Gauge elements.
 Selection of any Gauge element using a new Selected property.
 Multiple gauges, state indicators, and numeric indicators.
 Linear and circular gauges are both supported.
 Supports numerous rendering image types (e.g. Bmp, Jpeg, Png, Emf, Svg,
Flash).
 Can be displayed as a Windows Forms control using Internet Explorer's Smart
Client functionality.
 Custom images can be displayed.
 Data playback is possible via the data history mechanism.
 Pre-defined frames, with various styles are available.
 Serialization support for the saving and loading of appearance properties, values,
and historical data.
 Ability to save image snapshots.
 Ability to manipulate and synchronize data playback for all scales.
 Statistical functions, via calculated values.
Physical Research Laboratory Dashboard Web Service

Gauges

 Linear and circular gauges are both supported.


 Angular gauges are available as a variant of circular gauges.
 Pre-defined frames, with various styles are available.
 Multiple pointers, scales and ranges are supported.
 Shadows and gradient colors.
 Automatic positioning within the Gauge container.
 Circular gauges have an adjustable pivot point.
 Linear gauges can have vertical, horizontal, or automatically calculated
orientation.
 Statistical functions are available via calculated values.

Scales

 Ability to specify a range of values.


 Supports both linear and circular axes.
 Circular scales include:
o Clockwise and counter-clockwise rotation.
o The ability to specify start angle and end angle.
o The ability to set center coordinates and radius of scale.
o The ability to have a circular scale projected onto a straight horizontal, or
vertical line.
 Logarithmic scales, with customizable base.
 Multiple pointers.
 Custom markers.
 Maximum and minimum pins.

Pointers

 Can be shown as needles, markers, or bars.


 Multiple pointers per scale can be used.
 Optional dampening of movement.
 Snapping to values supported.
 Customized images can be used as Pointers.

Knobs

 Primarily associated with interactivity to create intuitive controls.


 Similar features as the pointer.
 Used for circular Gauges.
 Can be used to complement, or replace pointers.
Physical Research Laboratory Dashboard Web Service

Ranges

 Associated with scales, and used to highlight a specific area of a scale's range.
 Various color and styles are available.

Numeric Indicators

 Several styles to choose from including mechanical, 7-segment, and 14-segment


indicators.
 Format values with ease.
 Can be automatically sized.
 Can have associated ranges.
 Optional snapping and dampening behaviors.
 Automatically fitted text.

State Indicators

 Several styles to choose from including circular or rectangular LED.


 Can have multiple states, each with a start and end value. This helps to
determine if the indicator is On or Off.
 Can be automatically sized.
 Automatically fitted text.

Frames

 Pre-defined assortment of attractive frames, which can be used for both the
Gauge container and all of its gauges.
 Frames can be either circular or rectangular.

Miscellaneous

 Gradient color support.


 Hatching supported.  
 Images
o Can be associated with various Gauge components (e.g. container,
Gauge objects, etc.).
o Transparency support (0-100%).
o Can be positioned anywhere within a container.
 Labels
o Can be associated with various Gauge components (e.g. container,
Gauge objects, etc.).
o Text can be automatically fitted.
o Can be positioned anywhere within a container.
Physical Research Laboratory Dashboard Web Service

8.3 Login Page

The login.aspx page has been displayed in the snapshot section of this chapter. It
is a classic PRL style webpage with blue background. It carries the photographs of the
ionprobe lab & the IMS 4f Instrument. It also mentions the working group of the lab. It
asks the user to enter the Employee ID & Password. These two textboxes are then
matched with the records of login table in ionprobe database.

The ionprobe database is located in dashboard_prl folder. The login table has
three fields: User id, Password & User name. Upon having a positive match, the
associated user name is retrieved. The current window/tab is then closed & dashboard
page is called. While calling the page, the retrieved user name is also passed on.

The dashboard page queries its header to obtain the user name. The retrieved user
name is displayed at the top right corner of dashboard page. The login has to be done
only once, at every refresh the session information is maintained. A user can logout by
simply closing the window.

If authentication fails then the login page is reloaded with an “Invalid user id”
message. The user can retry any number of times. The login.aspx.cs file is included in the
Appendix C.

Authentication details can be managed by adding, deleting or updating the records


of the login table of ionprobe database.
Physical Research Laboratory Dashboard Web Service

8.4 Dashboard Page


The dashboard page always opens in a full screen mode. The screen area houses
two rows at the top followed by a panel window. The top row is akin to a title bar. At the
right end it displays the user name with which current session was logged into. The user
name is supplied by the login page after retrieving it from the login table of database on
successful authentication.

The Dashboard page has two panels:


1) Gauge panel accessed through ‘Main’ tab
2) Chart panel accessed through ‘Details’ tab
By default, the gauge panel is displayed at the startup as well as at subsequent page
refreshes.

8.4.1 GAUGE PANEL

The gauge panel displays 17 gauges. These are encapsulated in 8 Gauge


containers. The gauge panel has arranged the Gauge Containers in two rows. The
brackets indicate the container id with which they are referred to in the code.

The first row houses:


1) Duoplasmatron Vacuum Gauge Container (dgcduovacuum)
2) Rotary & Sample Chamber Vacuum Gauge Container (dgcrotarysample)
3) Ion Pump Vacuum Gauge Container (dgcIon)
4) Galden Gauge Container (dgcgalden)

The second row incorporates:


1) Duoplasmatron Hour Gauge Container (dgcPlasmatron)
2) Turbo Pump Gauge Container (dgcturbo)
3) Temperature & Humidity Gauge Container (dgcchillerlabTemphumid)
4) Chiller gauge Container (dgcchiller)

8.4.1.1 Duoplasmatron Vacuum Gauge Container (dgcduovacuum)

This gauge container houses the Duoplasmatron vacuum gauge. It displays the
current vacuum maintained at the Duoplasmatron in the units of torr.
o
Gauge Name : duovacuum
o
Gauge type : Circular
o
Sweep Angle : 240o
o
Pointer : needle
o
Numeric Indicator : 4 digit with 2 decimal places
: 1 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 2. Red, Green
o
State Indicator : Rounded Rectangular Led
Physical Research Laboratory Dashboard Web Service

8.4.1.2 Rotary & Sample Chamber Vacuum Gauge Container (dgcrotarysample)

This gauge container houses two circular gauges. They display the current
vacuum maintained by the rotary pumps in the units of torr.

Rotary Pump Pressure Gauge


o
Gauge Name : Rotary1
o
Gauge type : Circular
o
Sweep Angle : 240o
o
Pointer : needle
o
Numeric Indicator : 3 digit with 2 decimal places
: 1 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 3. Red, Green, Yellow
o
State Indicator : Rounded Led

Sample Chamber Pressure Gauge


o
Gauge Name : Rotary2
o
Gauge type : Circular
o
Sweep Angle : 240o
o
Pointer : needle
o
Numeric Indicator : 3 digit with 2 decimal places
: 1 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 3. Red, Green, Yellow
o
State Indicator : Rounded Led

8.4.1.3 Ion Pump Vacuum Gauge Container (dgcIon)

This gauge container houses two circular gauges. They display the current
vacuum maintained by the ion pumps in the units of torr. The second gauge is stacked
just below the first one.

Entry Slit Arm Ion Pump Pressure Gauge


o
Gauge Name : Ion1
o
Gauge type : Circular
o
Sweep Angle : 180o
o
Pointer : needle
o
Numeric Indicator : 3 digit with 2 decimal places
: 1 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 3. Red, Green, Yellow
o
State Indicator : Rounded Rectangular Led
Physical Research Laboratory Dashboard Web Service

Exit Slit Arm Ion Pump Pressure Gauge


o
Gauge Name : Ion2
o
Gauge type : Circular
o
Sweep Angle : 180o
o
Pointer : needle
o
Numeric Indicator : 3 digit with 2 decimal places
: 1 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 3. Red, Green, Yellow
o
State Indicator : Rounded Rectangular Led

8.4.1.4 Galden Gauge Container (dgcgalden)

This gauge container houses two linear gauges. The first one displays the level of
Galden in the sump. The second one displays the flow of Galden through the instrument.

Galden level Gauge


o
Gauge Name : galdenlevel
o
Gauge type : Linear
o
Pointer : Bar
o
Numeric Indicator : 2 digit without decimal places
o
Numeric Indicator Style : Mechanical

Galden Flow Gauge


o
Gauge Name : galdenflow
o
Gauge type : Linear
o
Pointer : Bar
o
Numeric Indicator : 2 digit without decimal places
o
Numeric Indicator Style : Mechanical

8.4.1.5 Duoplasmatron Vacuum Gauge Container (dgcduovacuum)

This gauge container houses the Duoplasmatron Hour gauge. It displays the
number of hours Duoplasmatron has been on. The circular scale shows a range of 0-450
hours. After the 350 hours the range is marked as red, also the state indicator text displays
an alert.
o
Gauge Name : duohours
o
Gauge type : Circular
o
Sweep Angle : 105o
o
Pointer : needle
o
Numeric Indicator : 3 digit without decimal places
o
Numeric Indicator Style : 14 Segment
Physical Research Laboratory Dashboard Web Service

o
Ranges : 2. Lime, Red
o
State Indicator : Text

8.4.1.6 Turbo Pump Gauge Container (dgcturbo)

This gauge container houses four circular gauges. They display the speed of the
turbo pumps in units of rpm. They are arranged in two rows at four corners. Their
prominent numeric indicators fall in a column of four rows at the center. The big state
indicators are housed adjacent to pointer cap. Each gauge carries its label just below
itself.

Duoplasmatron Turbo Pump Gauge


o
Gauge Name : turbo1
o
Gauge type : Circular
o
Sweep Angle : 90o
o
Pointer : needle
o
Numeric Indicator : 5 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
State Indicator : Rounded Led

Primary Column Turbo Pump Gauge


o
Gauge Name : turbo2
o
Gauge type : Circular
o
Sweep Angle : 90o
o
Pointer : needle
o
Numeric Indicator : 5 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
State Indicator : Rounded Led

Sample Chamber Turbo Pump Gauge


o
Gauge Name : turbo3
o
Gauge type : Circular
o
Sweep Angle : 90o
o
Pointer : needle
o
Numeric Indicator : 5 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
State Indicator : Rounded Led

Sample Changing Chamber Turbo Pump Gauge


o
Gauge Name : turbo4
o
Gauge type : Circular
o
Sweep Angle : 90o
o
Pointer : needle
Physical Research Laboratory Dashboard Web Service

o
Numeric Indicator : 5 digit without decimal place
o
Numeric Indicator Style : 14 Segment
o
State Indicator : Rounded Led

8.4.1.4 Temperature & Humidity Gauge Container (dgcchillerlabTemphumid)

This gauge container houses three linear gauges. The first one displays the
temperature of water flowing through the instrument in units of oC. The second one
displays the temperature of lab in units of oC. The third gauge displays the relative
humidity present in the lab in units of percentage. The three gauges are stacked side by
side in vertical orientation.

Water Temperature Gauge


o Gauge Name : Chiller
o
Gauge type : Linear
o
Pointer : Thermometer
o
Numeric Indicator : 3 digit with 1 decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 4. White, Lime, Orange, Red
o
State indicator : 2, Rounded Led
The scale ranges from 5 oC to 45 oC. The ranges have been distributed as
o Too Cold (White) : 0 oC to 10 oC
o Ok (Lime) : 10 oC to 20 oC
o Warning (Orange) : 20 oC to 30 oC
o High (Red) : 30 oC to 45 oC

Lab Temperature Gauge


o Gauge Name : labtemp
o
Gauge type : Linear
o
Pointer : Thermometer
o
Numeric Indicator : 3 digit with 1 decimal place
o
Numeric Indicator Style : 14 Segment
o
Ranges : 4. White, Lime, Orange, Red
o
State indicator : 2, Rounded Led
o o
The scale ranges from 5 C to 45 C. The ranges have been distributed as
o Too Cold (White) : 0 oC to 10 oC
o Ok (Lime) : 10 oC to 25 oC
o Warning (Orange) : 25 oC to 35 oC
o High (Red) : 35 oC to 45 oC

Lab Humidity Gauge


o
Gauge Name : labhumid
Physical Research Laboratory Dashboard Web Service

o
Gauge type : Linear
o
Pointer : Bar
o
Numeric Indicator : 3 digit with 1 decimal place
o
Numeric Indicator Style : 14 Segment

8.4.1.8 Chiller gauge Container (dgcchiller)

This gauge container houses two linear gauges. The first one displays the level of
water in the chiller. The second one displays the flow of water through the instrument.

Water level Gauge


o
Gauge Name : waterlevel
o
Gauge type : Linear
o
Pointer : Bar
o
Numeric Indicator : 3 digit without decimal places
o
Numeric Indicator Style : Mechanical

Water Flow Gauge


o
Gauge Name : waterflow
o
Gauge type : Linear
o
Pointer : Bar
o
Numeric Indicator : 3 digit without decimal places
o
Numeric Indicator Style : Mechanical

8.4.2 CHART PANEL

The chart panel provides for generation of chart based on the logged data. In a
way it provides for remote analyses of the data. The charts are drawn with time on x-axis
& status data on y-axis. Graphs can be generated for any of the parameter for any given
time interval. Dundas Chart control for ASP.NET 2005 is utilized for providing this
capability.
The panel provides for 3 chart containers:
1) Pump Chart Container
2) Duoplasmatron Chart Container
3) Temperature/Humidity Chart Container

Each chart container has a drop down box for selecting the parameter to be
plotted. As soon as the selected index of the drop down box, the plot is updated.

8.4.2.1 Pump Chart Container


It allows following parameters to be plotted.
 Rotary1
Physical Research Laboratory Dashboard Web Service

It plots the pressure (Vacuum) maintained by the rotary pump in units of


torr against time.
 Rotary2
It plots the pressure (Vacuum) maintained by the pump at sample chamber
in units of torr against time.
 Turbo1
It plots the speed of the turbo pump serving the duoplasmatron in units of
rpm against time.
 Turbo2
It plots the speed of the turbo pump serving the primary column in units of
rpm against time.
 Turbo3
It plots the speed of the turbo pump serving the sample chamber in units of
rpm against time.
 Turbo4
It plots the speed of the turbo pump serving the sample changing chamber
in units of rpm against time.
 Ion1
It plots the pressure (Vacuum) maintained by the ion pump at entry slit
arm in units of torr against time.
 Ion2
It plots the pressure (Vacuum) maintained by the ion pump at exit slit arm
in units of torr against time.

8.4.2.2 Duoplasmatron Chart Container


It allows the on/off duration of the duoplasmatrons to be plotted against the time.
The ids of all the duoplasmatrons used so far are displayed in the drop down box.

8.4.2.3 Temperature/Humidity Chart Container


It allows following parameters to be plotted
 Water temperature
It plots the temperature of water in the chiller in the units of oC against time.

 Lab temperature
It plots the temperature of lab in the chiller in the units of oC against time.

 Lab humidity
It plots the relative humidity of the lab in the units of percentage against time.
Physical Research Laboratory Dashboard Web Service

The y-axis ranges automatically to include all the data points of the selected
interval. The x-axis range is customizable. The time interval on the x-axis is controlled by
the two text boxes with labels Start date & End Date. A Java Script based date picker is
provided for date selection. Clicking on fetch button will update all the plots to the new
interval. This feature can be intuitively used for having a Zoom feature along the x-axis.
Physical Research Laboratory Dashboard Web Service

8.5 Snapshots
8.5.1 Login Page
Physical Research Laboratory Dashboard Web Service

8.5.2 Dashboard Page – Gauge Panel


Physical Research Laboratory Dashboard Web Service

8.5.3 Dashboard Page – Chart Panel


Physical Research Laboratory Dashboard Web Service

8.6 Conclusion

The dashboard site has been online since mid February. It has been through 3
design cycles. Each time the number & features of the gauges were increased. The SIMS
Monitoring site has successfully met all objectives & is now ready for phase 2 to be
completed when the whole system will become live.

During the four month period, the site has been logged into from various different
systems using different browsers. The site was found to be giving best performance with
internet explorer 6.0 or higher. There were some problems with Mozilla’s Firefox
browser while displaying the dashboard page. Pop-up blockers should be turned off to
enable opening of dashboard page. Since almost all browsers allow for customizing of
pop-up settings for individual sites, this is not much of a problem.

The site being quite graphic heavy takes some time to load in heavy traffic
networks. But normally the latency is not annoying. The C# code of both login &
dashboard page are included at the end in Appendix C.
Physical Research Laboratory Future Work

Chapter 9

FUTURE WORK
Physical Research Laboratory Future Work

The most prominent work would be the completion of phase 2 & integration of
the whole system so as to meet all the stated objectives. However while working on the
Phase-1 of the system, following enhancements were desired.

9.1 HARDWARE

 Isolation between the hardware & the PC by use of external transceiver could be
thought of.

 Backup of few hours for data storage in form of On Board memory chips could be
added. This backup can be used at times when PC is shutdown or in maintenance
mode.

 The hardware should be able to sense the PC state through the bus activity on the
USB & should switch to the local memory backup when the PC is powered down
or USB cable is disconnected. On reconnection it should dump the backup
memory on to pc.

9.2 FIRMWARE

 USB boot loader code can be added. This will allow reprogramming of the chip
without using ICSP.

9.2 DATA LOGGER

 A provision to take backup of data with configurable settings (like time of


backup, auto scheduler, location & name of the backup file et al) could be added.

 Auto reconnection capability to com port could be provided. Currently if due to


an exception the connection to the serial port is reset/lost, the connect button has
to be manually clicked to restart the logging process.

9.4 DASHBOARD
 A utility to save the generated charts can be added.

 A utility to fire e-mails & SMS to predefined configurable authorities in case of


predefined configurable events can be added.
Physical Research Laboratory Future Work

Chapter 10

BIBILOGRAPHY
Physical Research Laboratory Bibliography

Following Documents were referred to during the project

 UNIVERSAL SERIAL BUS SPECIFICATION REVISION 2.0

 UNIVERSAL SERIAL BUS CLASS DEFINITIONS FOR


COMMUNICATIONS DEVICES REVISION 1.2

 MPLAB® C18 C COMPILER LIBRARIES

 PIC 18F4550 DATASHEET

 THE PIC MICROCONTROLLER, YOUR PERSONAL INTRODUCTORY


COURSE, 3RD ED.

 USB COMPLETE

 MAKING PIC MICROCONTROLLER- INSTRUMENTS &


CONTROLLERS

The following websites have come in handy during development


 www.microchip.com
 www.microchipc.com
 www.pic18f.com
 www.embedded.com
 www.lvr.com/hidpage.htm
 www.ccsinfo.com
 www.microsoft.com/msdn
 www.support.dundas.com
Physical Research Laboratory Bibliography

APPENDIX- A

FIRMWARE CODE
Physical Research Laboratory Firmware Code

/********************************************************************
FileName: main.c
Dependencies: See INCLUDES section
Complier: Microchip C18 (for PIC18) or C30 (for PIC24)
Company: Microchip Technology, Inc.
**************************************************************************/

/** INCLUDES *******************************************************/


#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "usb_config.h"
#include "./USB/usb_device.h"
#include "./USB/usb.h"
#include "./USB/usb_function_cdc.h"

#include "HardwareProfile.h"

/** CONFIGURATION **************************************************/

#pragma config PLLDIV = 5 // (20 MHz crystal)


#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2 // Clock source from 96MHz PLL/2
#pragma config FOSC = HSPLL_HS
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = OFF
#pragma config BOR = ON
#pragma config BORV = 3
#pragma config VREGEN = ON //USB Voltage Regulator
#pragma config WDT = OFF
#pragma config WDTPS = 32768
#pragma config MCLRE = ON
#pragma config LPT1OSC = OFF
#pragma config PBADEN = OFF
#pragma config STVREN = ON
#pragma config LVP = OFF
#pragma config XINST = OFF // Extended Instruction Set
#pragma config CP0 = OFF
#pragma config CP1 = OFF
#pragma config CPB = OFF
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
#pragma config WRTB = OFF // Boot Block Write Protection
#pragma config WRTC = OFF
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
#pragma config EBTRB = OFF

/** I N C L U D E S ********************************************************/

#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "usb_config.h"
#include "USB\usb_device.h"
Physical Research Laboratory Firmware Code

#include "USB\usb.h"
#include "adc.h"
#include "delays.h"
#include "HardwareProfile.h"

/** V A R I A B L E S ******************************************************/
#pragma udata
char USB_In_Buffer[64];
char USB_Out_Buffer[64];

BOOL stringPrinted;

/** P R I V A T E P R O T O T Y P E S ***************************************/
static void InitializeSystem(void);
void ProcessIO(void);
void USBDeviceTasks(void);
void YourHighPriorityISRCode();
void YourLowPriorityISRCode();
void BlinkUSBStatus(void);
void UserInit(void);

/** DECLARATIONS ***************************************************/


#pragma code

/*************************************************************************
* Function: void main(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: Main program entry point.
**************************************************************************/

void main(void)
{
InitializeSystem();

#if defined(USB_INTERRUPT)
USBDeviceAttach();
#endif

while(1)
{
#if defined(USB_POLLING)
// Check bus status and service USB interrupts.
USBDeviceTasks();
/*
Interrupt or polling method. If using polling, must call this function periodically. This
function will take care of processing and responding to SETUP transactions (such as during
the enumeration process when you first plug in). USB hosts require that USB devices
should accept and process SETUP packets in a timely fashion. Therefore, when using
Physical Research Laboratory Firmware Code

polling, this function should be called frequently (such as once about every 100
microseconds) at anytime that a SETUP packet might reasonably be expected to be sent by
the host to your device. In most cases, them USBDeviceTasks() function does not take very
long to execute (~50 instruction cycles) before it returns.
*/
#endif

// Application-specific tasks.
// Application related code may be added here, or in the ProcessIO() function.

ProcessIO();

}//end while
}//end main

/********************************************************************
* Function: static void InitializeSystem(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: InitializeSystem is a centralize initialization routine. All required USB initialization
routines are called from here. User application initialization routine should also be called from
here.
*******************************************************************/
static void InitializeSystem(void)
{

ADCON1 |= 0x0F; // Default all pins to digital

#if defined(USE_USB_BUS_SENSE_IO)
tris_usb_bus_sense = INPUT_PIN; // See HardwareProfile.h
#endif

#if defined(USE_SELF_POWER_SENSE_IO)
tris_self_power = INPUT_PIN; // See HardwareProfile.h
#endif

UserInit();

USBDeviceInit(); //usb_device.c. Initializes USB module SFRs and firmware


//variables to known states.
} //end InitializeSystem

/***************************************************************************
Physical Research Laboratory Firmware Code

* Function: void UserInit(void)


*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This routine should take care of all of the demo code initialization that is
required.
**************************************************************************/
void UserInit(void)
{
//Initialize all of the LED pins

mInitAllLEDs();
} //end UserInit

/********************************************************************
* Function: void ProcessIO(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is a place holder for other user routines. It is a mixture of both USB
and non-USB tasks.
*******************************************************************/
void ProcessIO(void)
{

BYTE numBytesRead;

//Blink the LEDs according to the USB device status

BlinkUSBStatus();

// User Application USB tasks

/*
Put in code here for adc conversion & reading the channels. Sample ADC handling code for
channel 0 (AD0) is shown here.

OpenADC(ADC_FOSC_32 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 &


ADC_INT_OFF, 14);

int res;
Delay10TCYx( 5 ); // Delay for 50TCY
ConvertADC(); // Start conversion
while( BusyADC() ); // Wait for completion
res = ReadADC(); // Read result
Physical Research Laboratory Firmware Code

CloseADC(); // Disable A/D converter

After obtaining the values of all digital & analog channels, a packet is to be formed for
transmission by combining them all.

The packet should begin and end with a ‘<’ sign. A ‘,’ should be used for delimiting the fields. The
sample packet was used for testing purpose.

*/

if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;

if(mUSBUSARTIsTxTrfReady())
{
putrsUSBUSART("<D16:1010101010101010, ADC01:0000001010101010,
ADC02:0000001010101010, ADC03:0000001010101010, ADC04:0000001010101010,
ADC05:0000001010101010, ADC06:0000001010101010, ADC07:0000001010101010,
ADC08:0000001010101010>");
}

if(mUSBUSARTIsTxTrfReady())
{
numBytesRead = getsUSBUSART(USB_Out_Buffer,64);
if(numBytesRead != 0)
{
BYTE i;
for(i=0;i<numBytesRead;i++)
{
/* Put in here code for manipulating the output from pc.
The output from pc is received in USB_Out_Buffer.
The use of a switch statement can be made to respond to predefined
commands. For e.g.

switch(USB_Out_Buffer[i])
{
case 0x0A:
case 0x0D:
USB_In_Buffer[i] = USB_Out_Buffer[i];
break;

default:
USB_In_Buffer[i] = USB_Out_Buffer[i] + 1;
break;
}
*/
}
putUSBUSART(USB_In_Buffer,numBytesRead);
}
}
CDCTxService();
} //end ProcessIO

/********************************************************************
* Function: void BlinkUSBStatus(void)
*
* PreCondition: None
*
Physical Research Laboratory Firmware Code

* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: BlinkUSBStatus turns on and off LEDs corresponding to the USB device state.
*
* Note: mLED macros can be found in HardwareProfile.h USBDeviceState is declared and
updated in usb_device.c.
*******************************************************************/
void BlinkUSBStatus(void)
{
static WORD led_count=0;

if(led_count == 0)led_count = 10000U;


led_count--;

#define mLED_Both_Off() {mLED_1_Off();mLED_2_Off();}


#define mLED_Both_On() {mLED_1_On();mLED_2_On();}
#define mLED_Only_1_On() {mLED_1_On();mLED_2_Off();}
#define mLED_Only_2_On() {mLED_1_Off();mLED_2_On();}

if(USBSuspendControl == 1)
{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_On();
}
else
{
mLED_2_Off();
}
} //end if
}
else
{
if(USBDeviceState == DETACHED_STATE)
{
mLED_Both_Off();
}
else if(USBDeviceState == ATTACHED_STATE)
{
mLED_Both_On();
}
else if(USBDeviceState == POWERED_STATE)
{
mLED_Only_1_On();
}
else if(USBDeviceState == DEFAULT_STATE)
{
mLED_Only_2_On();
}
else if(USBDeviceState == ADDRESS_STATE)
Physical Research Laboratory Firmware Code

{
if(led_count == 0)
{
mLED_1_Toggle();
mLED_2_Off();
} //end if
}
else if(USBDeviceState == CONFIGURED_STATE)
{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_Off();
}
else
{
mLED_2_On();
}
} //end if
} //end if(...)
} //end if(UCONbits.SUSPND...)

} //end BlinkUSBStatus

// *************************************************************************
// ************** USB Callback Functions ***********************************
// ************************************************************************
/*
The USB firmware stack will call the callback functions USBCBxxx() in response to certain USB
related events. For example, if the host PC is powering down, it will stop sending out Start of
Frame (SOF) packets to your device. In response to this, all USB devices are supposed to decrease
their power consumption from the USB Vbus to <2.5mA each. The USB module detects this
condition (which according to the USB specifications is 3+ms of no bus activity/SOF packets) and
then calls the USBCBSuspend() function. You should modify these callback functions to take
appropriate actions for each of these conditions. For example, in the USBCBSuspend(), you may
wish to add code that will decrease power consumption from Vbus to <2.5mA (such as by clock
switching, turning off LEDs, putting the microcontroller to sleep, etc.). Then, in the
USBCBWakeFromSuspend() function, you may then wish to add code that undoes the power
saving things done in the USBCBSuspend() function.

The USBCBSendResume() function is special, in that the USB stack will not function. This
function is meant to be called from the application firmware instead. See the additional
comments near the function.
*/

/***************************************************************************
* Function: void USBCBSuspend(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
Physical Research Laboratory Firmware Code

* Side Effects: None


*
* Overview: Call back that is invoked when a USB suspend is detected
**************************************************************************/
void USBCBSuspend(void)
{
// Example power saving code. Insert appropriate code here for the desired application behavior.
// If the microcontroller will be put to sleep, a process similar to that shown below may be used:

//ConfigureIOPinsForLowPower();
//SaveStateOfAllInterruptEnableBits();
//DisableAllInterruptEnableBits();
//EnableOnlyTheInterruptsWhichWillBeUsedToWakeTheMicro();
//should enable at least USBActivityIF as a wake source
//Sleep();
//RestoreStateOfAllPreviouslySavedInterruptEnableBits();
//Preferrably, this should be done in the USBCBWakeFromSuspend() function
//RestoreIOPinsToNormal();
//Preferrably, this should be done in the USBCBWakeFromSuspend() function

//IMPORTANT NOTE: Do not clear the USBActivityIF (ACTVIF) bit here. This bit is cleared
//inside the usb_device.c file. Clearing USBActivityIF here will cause things to not work as
//intended.

/***************************************************************************
* Function: void _USB1Interrupt(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called when the USB interrupt bit is set. In this example the
interrupt is only used when the device goes to sleep when it receives a USB suspend command
**************************************************************************/
#if 0
void __attribute__ ((interrupt)) _USB1Interrupt(void)
{
#if !defined(self_powered)
if(U1OTGIRbits.ACTVIF)
{
IEC5bits.USB1IE = 0;
U1OTGIEbits.ACTVIE = 0;
IFS5bits.USB1IF = 0;
//USBClearInterruptFlag(USBActivityIFReg,USBActivityIFBitNum);
USBClearInterruptFlag(USBIdleIFReg,USBIdleIFBitNum);
//USBSuspendControl = 0;
}
#endif
}
#endif
Physical Research Laboratory Firmware Code

/***************************************************************************
* Function: void USBCBWakeFromSuspend(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The host may put USB peripheral devices in low power suspend mode (by
"sending" 3+ms of idle). Once in suspend mode, the host may wake the device back up by
sending non-idle state signalling.
*
* This call back is invoked when a wakeup from USB suspend is detected.
*****************************************************************************/
void USBCBWakeFromSuspend(void)
{
// If clock switching or other power savings measures were taken when executing the
//USBCBSuspend() function, now would be a good time to switch back to normal full
//power run mode conditions. The host allows a few milliseconds of wakeup time,
after //which the device must be fully back to normal, and capable of receiving and
processing //USB packets. In order to do this, the USB module must receive proper
clocking (IE: //48MHz clock must be available to SIE for full speed USB operation).
}

/********************************************************************
* Function: void USBCB_SOF_Handler(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The USB host sends out a SOF packet to full-speed devices every 1 ms. This
interrupt may be useful for isochronous pipes. End designers should implement callback routine
as necessary.
********************************************************************/
void USBCB_SOF_Handler(void)
{
// No need to clear UIRbits.SOFIF to 0 here.
// Callback caller is already doing that.
}

/*******************************************************************
* Function: void USBCBErrorHandler(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
Physical Research Laboratory Firmware Code

* Side Effects: None


*
* Overview: The purpose of this callback is mainly for debugging during development. Check
UEIR to see which error causes the interrupt.
*******************************************************************/
void USBCBErrorHandler(void)
{
// No need to clear UEIR to 0 here.
// Callback caller is already doing that.
// Typically, user firmware does not need to do anything special. if a USB error
occurs. //For example, if the host sends an OUT packet to your device, but the packet
gets //corrupted (ex: because of a bad connection, or the user unplugs the USB cable
during //the transmission) this will typically set one or more USB error interrupt flags.
Nothing //specific needs to be done however, since the SIE will automatically send a
"NAK" //packet to the host. In response to this, the host will normally retry to send the
packet //again, and no data loss occurs. The system will typically recover automatically,
without //the need for application firmware intervention.
// Nevertheless, this callback function is provided, such as for debugging purposes.
}

/*******************************************************************
* Function: void USBCBCheckOtherReq(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: When SETUP packets arrive from the host, some firmware must process the
request and respond appropriately to fulfill the request. Some of the SETUP packets will be for
standard USB "chapter 9" (as in, fulfilling chapter 9 of the official USB specifications) requests,
while others may be specific to the USB device class that is being implemented. For example, a
HID class device needs to be able to respond to "GET REPORT" type of requests. This is not a
standard USB chapter 9 request, and therefore not handled by usb_device.c. Instead this request
should be handled by class specific firmware, such as that contained in usb_function_hid.c.
*******************************************************************/
void USBCBCheckOtherReq(void)
{
USBCheckCDCRequest();
}//end

/*******************************************************************
* Function: void USBCBStdSetDscHandler(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
Physical Research Laboratory Firmware Code

* Overview: The USBCBStdSetDscHandler() callback function is called when a SETUP,


bRequest: SET_DESCRIPTOR request arrives. Typically SET_DESCRIPTOR requests are not
used in most applications, and it is optional to support this type of request.
* *******************************************************************/
void USBCBStdSetDscHandler(void)
{
// Must claim session ownership if supporting this request
} //end

/*******************************************************************
* Function: void USBCBInitEP(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called when the device becomes initialized, which occurs after
the host sends a SET_CONFIGURATION (wValue not = 0) request. This callback function should
initialize the endpoints for the device's usage according to the current configuration.
*******************************************************************/
void USBCBInitEP(void)
{
CDCInitEP();
}

/********************************************************************
* Function: void USBCBSendResume(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The USB specifications allow some types of USB peripheral devices to wake up a
host PC (such as if it is in a low power suspend to RAM state). This can be a very useful feature in
some USB applications, such as an Infrared remote control receiver. If a user presses the "power"
button on a remote control, it is nice that the IR receiver can detect this signalling, and then send
a USB "command" to the PC to wake up.
*
The USBCBSendResume() "callback" function is used to send this special USB signalling which
wakes up the PC. This function may be called by application firmware to wake up the PC. This
function should only be called when:
1. The USB driver used on the host PC supports the remote wakeup capability.
2. The USB configuration descriptor indicates the device is remote wakeup capable in the
bmAttributes field.
3. The USB host PC is currently sleeping and has previously sent your device a SET FEATURE
setup packet which "armed" the remote wakeup capability.
*
*This callback should send a RESUME signal that has the period of 1-15ms.
Physical Research Laboratory Firmware Code

********************************************************************/
void USBCBSendResume(void)
{
static WORD delay_count;

USBResumeControl = 1; // Start RESUME signaling

delay_count = 1800U; // Set RESUME line for 1-13 ms


do
{
delay_count--;
}while(delay_count);
USBResumeControl = 0;
}

/*******************************************************************
* Function: void USBCBEP0DataReceived(void)
*
* PreCondition: ENABLE_EP0_DATA_RECEIVED_CALLBACK must be defined already (in
usb_config.h)
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called whenever a EP0 data packet is received. This gives the
user (and thus the various class examples a way to get data that is received via the control
endpoint. This function needs to be used in conjunction with the USBCBCheckOtherReq()
function since the USBCBCheckOtherReq() function is the apps method for getting the initial
control transfer before the data arrives.
*******************************************************************/
#if defined(ENABLE_EP0_DATA_RECEIVED_CALLBACK)
void USBCBEP0DataReceived(void)
{
}
#endif

/*******************************************************************
* Function: BOOL USER_USB_CALLBACK_EVENT_HANDLER(
* USB_EVENT event, void *pdata, WORD size)
*
* Precondition: None
*
* Input: USB_EVENT event - the type of event
* void *pdata - pointer to the event data
* WORD size - size of the event data
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called from the USB stack to notify a user application that a USB
event occurred. This callback is in interrupt context when the USB_INTERRUPT option is
selected.
Physical Research Laboratory Firmware Code

*******************************************************************/
BOOL USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void *pdata, WORD
size)
{
switch(event)
{
case EVENT_CONFIGURED:
USBCBInitEP();
break;
case EVENT_SET_DESCRIPTOR:
USBCBStdSetDscHandler();
break;
case EVENT_EP0_REQUEST:
USBCBCheckOtherReq();
break;
case EVENT_SOF:
USBCB_SOF_Handler();
break;
case EVENT_SUSPEND:
USBCBSuspend();
break;
case EVENT_RESUME:
USBCBWakeFromSuspend();
break;
case EVENT_BUS_ERROR:
USBCBErrorHandler();
break;
case EVENT_TRANSFER:
Nop();
break;
default:
break;
}
return TRUE;
}

/** EOF main.c *************************************************/


Physical Research Laboratory Data Logger Code

APPENDIX B
DATA LOGGER
Physical Research Laboratory Data Logger Code

SIMS.VB
'Here are some useful articles when creating new PC applications for COM
ports:
'(links valid as of April 1, 2009)
'
'"SerialPort Class"
'http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx
'
'"SerialPort Members"
'http://msdn.microsoft.com/en-
us/library/system.io.ports.serialport_members.aspx
'
'"SerialPort.DataReceived Event"
'http://msdn.microsoft.com/en-
us/library/system.io.ports.serialport.datareceived.aspx
'
'"How to: Make Thread-Safe Calls to Windows Forms Controls"
'http://msdn.microsoft.com/en-us/library/ms171728(VS.80).aspx
'
'"Visual Basic Developer Center"
'http://msdn.microsoft.com/en-us/vbasic/default.aspx?pull=/library/en-
us/vbcon/html/vboriintroductiontovisualbasic70forvisualbasicveterans.asp

Imports System.IO.Ports
Imports System.Data.OleDb

Public Class Form1

'Create a delegate function for this thread that will take


' in a string and will write it to the txtDataReceived textbox
Delegate Sub SetTextCallback(ByVal [text] As String)

'**********************************************************************
' Function:
' private void UpdateCOMPortList()
'
' Summary:
' This function updates the COM ports listbox.
'
' Description:
' This function updates the COM ports listbox.This function is
launched periodically based on its Interval attribute (set in the form
editor under the properties window).
'
' Precondition:
' None
'
' Parameters:
' None
'
' Return Values
' None
'
' Remarks:
' None
Physical Research Laboratory Data Logger Code

'*********************************************************************
Private Sub UpdateCOMPortList()
Dim s As String
Dim i As Integer
Dim foundDifference As Boolean

i = 0
foundDifference = False
'If the number of COM ports is different than the last time we
' checked, then we know that the COM ports have changed and we
' don't need to verify each entry.

If lstCOMPorts.Items.Count = SerialPort.GetPortNames().Length
Then
'Search the entire SerialPort object. Look at COM port name
' returned and see if it already exists in the list.
For Each s In SerialPort.GetPortNames()
'If any of the names have changed then we needto update list
If lstCOMPorts.Items(i).Equals(s) = False Then
foundDifference = True
End If
i = i + 1
Next s
Else
foundDifference = True
End If

'If nothing has changed, exit the function.


If foundDifference = False Then
Exit Sub
End If

'If something has changed, then clear the list


lstCOMPorts.Items.Clear()

'Add all of the current COM ports to the list


For Each s In SerialPort.GetPortNames()
lstCOMPorts.Items.Add(s)
Next s
'Set the listbox to point to the first entry in the list
lstCOMPorts.SelectedIndex = 0
End Sub

'**********************************************************************
' Function:
' private void DataSplitter()
'
' Summary:
' This function breaks up the incoming data, validates it &
logs it into the appropriate textboxes.
'
' Description:
'
' Precondition:
Physical Research Laboratory Data Logger Code

It has been assumed that Data will be transmitted in the following


format. If there is achange in this format then appropriate change
should be made in the code here.
'Data Packet<D16:1010101010101010,ADC01:0000001010101010,
ADC02:0000001010101010, ADC03:0000001010101010,
ADC04:0000001010101010, ADC05:0000001010101010,
ADC06:0000001010101010, ADC07:0000001010101010,
ADC08:0000001010101010>
'Length 214
'
' Parameters:
' None
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************

Private Sub DataSplitter()


Dim DataValidated As Boolean

If (txtDataReceived.Text.Length = 214) Then


DataValidated = True
txtdatastatus.AppendText("Packet Size Verified")
Else
txtdatastatus.Text = "Packet Size Corrupted"
DataValidated = False
Return
End If

If (txtDataReceived.Text.Substring(1, 1).Equals("<") = True)


Then
DataValidated = True
txtdatastatus.AppendText("Start of packet Verified")
Else
txtdatastatus.Text = "Start of packet Corrupted"
DataValidated = False
Return
End If

If (txtDataReceived.Text.Substring(214, 1).Equals(">") = True)


Then
DataValidated = True
txtdatastatus.AppendText("End of packet Verified")
Else
txtdatastatus.Text = "End of packet Corrupted"
DataValidated = False
Return
End If

If (DataValidated = True) Then


txtduovacuum.Text = "9.25"
Physical Research Laboratory Data Logger Code

' Include the data processing code here. A example of processing a


Digital channel is shown below.

If (txtDataReceived.Text.Substring(1, 1).Equals("1") = True)


Then
txtduoprim.Text = "ON"
ElseIf (txtDataReceived.Text.Substring(1, 1).Equals("0") =
True) Then
txtduoprim.Text = "OFF"
Else
txtduoprim.Text = "Err"
End If
txtDataReceived.Text.Substring(12, 10)
= "6.23" 'txtDataReceived.Text.Substring(23, 10)
= "4.45" 'txtDataReceived.Text.Substring(34, 10)
= "15"
' Similarly add code for processing other channels . analog channels can
also be taken care of by providing appropriate conversion code. This
will depend on the format in which the data is transmitted hence is left
to be decided in the Phase-2.

The processsed value could be stored in a variable or directly entered


to their respective text boxes.
txtion1.Text txtrotrot.Text
txtion2.Text txtrotsc.Text
txtwatertemp.Text txtturboduo.Text
txtlabtemp.Text txtturboprim.Text
txtlabhum.Text txtturbosc.Text
txtduochngd.Text txtturboscr.Text
txtgaldenlevel.Text txtgaldenflow.Text
txtwaterflow.Text txtwaterlevel.Text

Call data logging function to log these values to the database.

DataLogging()

End If '(DataValidated = True)


End Sub

'**********************************************************************
' Function:
' private void Datalogging()
'
' Summary:
' This function logs the data from the textboxes to their
appropriate tables in the MS ACCESS database.
'
' Description:
'
' Precondition:
' None
' Parameters:
' None
'
' Return Values
' None
'
Physical Research Laboratory Data Logger Code

' Remarks:
' None
'*********************************************************************

Private Sub DataLogging()


Dim cn As OleDbConnection
Dim ds As DataSet
Dim da As OleDbDataAdapter

cn = New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\\Dashboard_prl\\Database\\ionprobe.mdb; Persist Security
Info=False;")
cn.Open()

txtdatastatus.Text = "Database Opened"

da = New OleDbDataAdapter("INSERT INTO GaldenFlow


(date_time,Galden_Flow) VALUES(#" & System.DateTime.Now & "# ,'" &
txtgaldenflow.Text & "')", cn)
ds = New DataSet()
da.Fill(ds, "galdenf")

'On Similar basis data can be inserted of the remaining parameter


values.
txtdatastatus.Text = "Data Inserted"
cn.Close()
End Sub

'**********************************************************************
' Function:
' private void timer1_Tick(object sender, EventArgs e)
'
' Summary:
' This function updates the COM ports listbox.
'
' Description:
' This function updates the COM ports listbox. This function
is launched periodically based on its Interval attribute (set in the
form editor under the properties window).
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' EventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
Physical Research Laboratory Data Logger Code

'Update the COM ports list so that we can detect


' new COM ports that have been added.
UpdateCOMPortList()
txtsystime.Text = Convert.ToString(System.DateTime.Now())
End Sub

'*********************************************************************
' Function:
' private void btnConnect_Click(object sender, EventArgs e)
'
' Summary:
' This function opens the COM port.
'
' Description:
' This function opens the COM port. This function is launched
when the btnConnect button is clicked. In addition to opening the COM
port, this function will also change the Enable attribute of several of
the form objects to disable the user from opening a new COM port.
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' EventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'********************************************************************/
Private Sub btnConnect_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnConnect.Click
Try
'Get the port name from the application list box.
' the PortName attribute is a string name of the COM
' port (e.g. - "COM1").
SerialPort1.PortName =
lstCOMPorts.Items(lstCOMPorts.SelectedIndex).ToString()

'Open the COM port.


SerialPort1.Open()

'Change the state of the application objects


btnConnect.Enabled = False
lstCOMPorts.Enabled = False
btnClose.Enabled = True

'Clear the textbox and print that we are connected.


' txtDataReceived.Clear()
' txtDataReceived.AppendText("Connected." + vbCrLf)
txtdatastatus().Clear()
txtdatastatus.AppendText("Connected." + vbCrLf)

Catch ex As Exception
Physical Research Laboratory Data Logger Code

'If there was an exception, then close the handle to


' the device and assume that the device was removed
btnClose_Click(Me, e)

End Try
End Sub

'**********************************************************************
' Function:
' private void btnClose_Click(object sender, EventArgs e)
'
' Summary:
' This function closes the COM port.
'
' Description:
' This function closes the COM port. This function is
launched when the btnClose button is clicked. This function can also be
called directly from other functions. In addition to closing the COM
port, this function will also change the Enable attribute of several of
the form objects to enable the user to open a new COM port.
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' EventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'********************************************************************/
Private Sub btnClose_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnClose.Click
'Reset the state of the application objects
btnClose.Enabled = False
btnConnect.Enabled = True
lstCOMPorts.Enabled = True

'This section of code will try to close the COM port.


' Please note that it is important to use a try/catch
' statement when closing the COM port. If a USB virtual
' COM port is removed and the PC software tries to close
' the COM port before it detects its removal then
' an exeception is thrown. If the execption is not in a
' try/catch statement this could result in the application
' crashing.
Try

'Dispose the In and Out buffers;


SerialPort1.DiscardOutBuffer()
'txtdatastatus.Text = "OUT Buffer Discarded"
SerialPort1.DiscardInBuffer()
'txtdatastatus.Text = "In Buffer Discarded"
Physical Research Laboratory Data Logger Code

'Close the COM port


SerialPort1.Close()
'If there was an exeception then there isn't much we can
' do. The port is no longer available.
Catch ex As Exception

End Try
End Sub

'*********************************************************************
' Function:
' private void serialPort1_DataReceived( object sender,
'
SerialDataReceivedEventArgs e)
'
' Summary:
' This function prints any data received on the COM port.
'
' Description:
' This function is called when the data is received on the COM
port. This function attempts to write that data to the txtDataReceived
textbox. If an exception occurs the btnClose_Click() function is called
in order to close the COM port that caused the exception.
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' SerialDataReceivedEventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'*****************************************************************/
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object,
ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles
SerialPort1.DataReceived
'The ReadExisting() function will read all of the data that
' is currently available in the COM port buffer. In this
' example we are sending all of the available COM port data
' to the SetText() function.
'
' NOTE: the <SerialPort>_DataReceived() function is launched
' in a seperate thread from the rest of the application. A
' delegate function is required in order to properly access
' any managed objects inside of the other thread. Since we
' will be writing to a textBox (a managed object) the delegate
' function is required. Please see the SetText() function for
'more information about delegate functions and how to use them.
Try
SetText(SerialPort1.ReadExisting())
Physical Research Laboratory Data Logger Code

Catch ex As Exception
'If there was an exception, then close the handle to
' the device and assume that the device was removed
btnClose_Click(Me, e)
End Try
End Sub
'*********************************************************************
' Function:
' private void SetText(string text)
'
' Summary:
'This function prints the input text to the txtDataReceived textbox.
'
' Description:
' This function prints the input text to the txtDataReceived
textbox. If the calling thread is the same as the thread that owns the
textbox, then the AppendText() method is called directly. If a thread
other than the main thread calls this function, then an instance of the
delegate function is created so that the function runs again in the main
thread.
'
' Precondition:
' None
'
' Parameters:
' string text - Text that needs to be printed to the textbox
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub SetText(ByVal [text] As String)
'InvokeRequired required compares the thread ID of the
' calling thread to the thread ID of the creating thread.
' If these threads are different, it returns true. We can
' use this attribute to determine if we can append text
' directly to the textbox or if we must launch an a delegate
' function instance to write to the textbox.
If txtDataReceived.InvokeRequired Then
'InvokeRequired returned TRUE meaning that this function
' was called from a thread different than the current
' thread. We must launch a deleage function.

'Create an instance of the SetTextCallback delegate and


' assign the delegate function to be this function. This
' effectively causes this same SetText() function to be
' called within the main thread instead of the second
' thread.
Dim d As New SetTextCallback(AddressOf SetText)

'Invoke the new delegate sending the same text to the


' delegate that was passed into this function from the
' other thread.
Invoke(d, New Object() {[text]})
Physical Research Laboratory Data Logger Code

Else
'If this function was called from the same thread that
' holds the required objects then just add the text.
txtDataReceived.AppendText(text)
DataLogging()
DataSplitter()

End If
End Sub

'**********************************************************************
' Function:
' private void btnSendData_Click(object sender, EventArgs e)
'
' Summary:
' This function will attempt to send the contents of txtData
over the COM port
'
' Description:
' This function is called when the btnSendData button is
clicked. It will attempt to send the contents of txtData over the COM
port. If the attempt is unsuccessful this function will call the
btnClose_Click() in order to
' close the COM port that just failed.
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' EventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub btnSendData_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnSendData.Click
Try
'Write the data in the text box to the open serial port
SerialPort1.Write(txtData.Text)
Catch ex As Exception
'If there was an exception, then close the handle to
' the device and assume that the device was removed
btnClose_Click(Me, e)
End Try
End Sub
Physical Research Laboratory Dashboard Code

APPENDIX C
DASHBOARD
Physical Research Laboratory Dashboard Code

LOGIN.ASPX.CS
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Data.OleDb;

public partial class login : System.Web.UI.Page


{
OleDbConnection cn;
OleDbCommand cmd;
OleDbDataAdapter da;
DataSet ds;
protected void Page_Load(object sender, EventArgs e)
{
this.btnSubmit.Click += new EventHandler(btnSubmit_Click);
}
void btnSubmit_Click(object sender, EventArgs e)
{
if (this.TextBox1.Text.ToString() != "" &&
this.TextBox2.Text.ToString() != "")
{
cn = new
OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" +
Server.MapPath("Database\\ionprobe.mdb" ) +";Persist Security
Info=False");
da = new OleDbDataAdapter("select name from login where
userid='" + this.TextBox1.Text.ToString() +"' and password='" +
this.TextBox2.Text.ToString() +"'",cn);
ds = new DataSet();
da.Fill(ds,"test");
if (ds.Tables["test"].Rows.Count != 0)
{
string strScript;
strScript = "<script language=javascript>";
strScript += "OpenNewWindow('dashboard.aspx?user_name="
+ ds.Tables["test"].Rows[0][0].ToString()
+"','PRLDashboard','status=1,scroll=no,location=no,resizable=1');";
strScript += "</script>\n";
ClientScript.RegisterClientScriptBlock(typeof(Page),
"new_window", strScript);
//Response.Redirect("dashboard.aspx");
}
else
{
Response.Write("invalid user id");
}
}
}
}
Physical Research Laboratory Dashboard Code

DASHBOARD.ASPX.CS
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using Dundas.Charting.WebControl;
using Dundas.Gauges.WebControl;
using System.Data.OleDb;

public partial class dashboard : System.Web.UI.Page


{
OleDbConnection cn;
OleDbCommand cmd;
OleDbDataAdapter da;
DataSet ds;

protected void Page_Load(object sender, EventArgs e)


{
this.btnMain.Click += new EventHandler(btnMain_Click);
this.btnDetail.Click += new EventHandler(btnDetail_Click);
this.ddlPump.SelectedIndexChanged += new
EventHandler(ddlPump_SelectedIndexChanged);
this.ddlTemp.SelectedIndexChanged += new
EventHandler(ddlTemp_SelectedIndexChanged);
this.ddlPlasma.SelectedIndexChanged += new
EventHandler(ddlPlasma_SelectedIndexChanged);
this.btnFetch.Click += new EventHandler(btnFetch_Click);
this.pnl1.Style.Clear();
this.pnl1.Style.Add("Display", "None");
if (!this.IsPostBack)
{
this.loginid.Text
=Request.QueryString["user_name"].ToString();
this.btnMain_Click(null, null);
}
}

void btnFetch_Click(object sender, EventArgs e)


{
this.pump();
this.duo();
this.temp();
}

void ddlPlasma_SelectedIndexChanged(object sender, EventArgs e)


{
this.duo();
}
Physical Research Laboratory Dashboard Code

void ddlTemp_SelectedIndexChanged(object sender, EventArgs e)


{
this.temp();
}

void ddlPump_SelectedIndexChanged(object sender, EventArgs e)


{
this.pump();
}

private void last_level()


{
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();

da = new OleDbDataAdapter("select max(date_time) from


Galdenlevel where Galden_level='Low'", cn);
ds = new DataSet();
da.Fill(ds, "galden");
if (ds.Tables["galden"].Rows.Count != 0)
{
this.lblFreonlast.Text = ds.Tables["Galden"].Rows[0]
[0].ToString().Trim();
}

da = new OleDbDataAdapter("select max(date_time) from waterlevel


where water_level='Low'", cn);
ds = new DataSet();
da.Fill(ds, "waterl");
if (ds.Tables["waterl"].Rows.Count != 0)
{
this.lblWaterllast.Text = ds.Tables["waterl"].Rows[0]
[0].ToString().Trim();
}

da = new OleDbDataAdapter("select max(date_time) from waterflow


where water_flow='Low'", cn);
ds = new DataSet();
da.Fill(ds, "waterf");
if (ds.Tables["waterf"].Rows.Count != 0)
{
this.lblWaterflast.Text = ds.Tables["waterf"].Rows[0]
[0].ToString().Trim();
}

cn.Close();
}

private void pump()


{
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();
Physical Research Laboratory Dashboard Code

da = new OleDbDataAdapter("select date,pressure from


pumppressure where pumpid='" +
this.ddlPump.SelectedItem.Value.ToString().Trim() + "' and (date between
#" + this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
ds = new DataSet();
da.Fill(ds, "pump");
if (ds.Tables["pump"].Rows.Count != 0)
{
dcPump.Series[0].ValueMemberX =
ds.Tables["pump"].Columns["date"].ColumnName;
dcPump.Series[0].ValueMembersY =
ds.Tables["pump"].Columns["pressure"].ColumnName;
dcPump.DataSource = ds.Tables["pump"];
dcPump.DataBind();
}
cn.Close();
}

private void duo()


{
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();
da = new OleDbDataAdapter("select startdate,status from
duodetails where id='" +
this.ddlPlasma.SelectedItem.Value.ToString().Trim() + "' and (startdate
between #" + this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
ds = new DataSet();
da.Fill(ds, "duo1");
if (ds.Tables["duo1"].Rows.Count != 0)
{
dcPlasma.Series[0].ValueMemberX =
ds.Tables["duo1"].Columns["startdate"].ColumnName;
dcPlasma.Series[0].ValueMembersY =
ds.Tables["duo1"].Columns["status"].ColumnName;
dcPlasma.DataSource = ds.Tables["duo1"];
dcPlasma.DataBind();
}
cn.Close();
}

private void temp()


{
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();
if (this.ddlTemp.SelectedItem.Value == "WaterTemp")
{
da = new OleDbDataAdapter("select
date_time,water_temperature from watertemp where (date_time between #" +
this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
}
Physical Research Laboratory Dashboard Code

else if (this.ddlTemp.SelectedItem.Value == "LabTemp")


{
da = new OleDbDataAdapter("select date_time,lab_temperature
from labtemp where (date_time between #" +
this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
}
else if (this.ddlTemp.SelectedItem.Value == "LabHumidity")
{
da = new OleDbDataAdapter("select date_time,lab_humidity
from labhumidity where (date_time between #" +
this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
}

ds = new DataSet();
da.Fill(ds, "temp_humid");
if (ds.Tables["temp_humid"].Rows.Count != 0)
{
dcTemp.Series[0].ValueMemberX =
ds.Tables["temp_humid"].Columns[0].ColumnName;
dcTemp.Series[0].ValueMembersY =
ds.Tables["temp_humid"].Columns[1].ColumnName;
dcTemp.DataSource = ds.Tables["temp_humid"];
dcTemp.DataBind();
}
cn.Close();
}

void btnDetail_Click(object sender, EventArgs e)


{
this.DirSearch();
this.pnlDetail.Visible = true;
this.pnlGeneral.Visible = false;
this.btnMain.CssClass = "TableHeaderClick";
this.btnDetail.CssClass = "ButtonHeader";
this.txtFrom.Text=
Convert.ToDateTime(System.DateTime.Now.AddDays(-30)).ToString("dd MMM
yyyy");
this.txtTo.Text=
Convert.ToDateTime(System.DateTime.Now).ToString("dd MMM yyyy");
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();
da = new OleDbDataAdapter("select distinct id from duomain",
cn);
ds = new DataSet();
da.Fill(ds, "plasma");
if (ds.Tables["plasma"].Rows.Count != 0)
{

this.ddlPlasma.Items.Clear();
this.ddlPlasma.DataSource = ds.Tables["plasma"];
this.ddlPlasma.DataValueField = "id";
this.ddlPlasma.DataTextField = "id";
this.ddlPlasma.DataBind();
Physical Research Laboratory Dashboard Code

}
da = new OleDbDataAdapter("select id from duomain where enddate
is null", cn);
ds = new DataSet();
da.Fill(ds, "plasmac");
if (ds.Tables["plasmac"].Rows.Count != 0)
{
this.ddlPlasma.SelectedIndex = -1;

this.ddlPlasma.Items.FindByValue(ds.Tables["plasmac"].Rows[0]
[0].ToString().Trim()).Selected = true;
}
cn.Close();
this.pump();
this.duo();
this.temp();
this.last_level();

void btnMain_Click(object sender, EventArgs e)


{
this.DirSearch();
this.pnlDetail.Visible = false;
this.pnlGeneral.Visible = true;
this.btnMain.CssClass = "ButtonHeader";
this.btnDetail.CssClass = "TableHeaderClick";
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist Security
Info=False");
cn.Open();
da = new OleDbDataAdapter("select total_time from duomain where
enddate is null", cn);
ds = new DataSet();
da.Fill(ds, "plasma");
if (ds.Tables["plasma"].Rows.Count != 0)

{ dgcPlamatron.CircularGauges["duohours"].Pointers["Default"]
.Value = Convert.ToDouble(ds.Tables["plasma"].Rows[0][0].ToString());

dgcPlamatron.NumericIndicators["NumericIndicator1"].Value =
dgcPlamatron.CircularGauges["duohours"].Pointers["Default"].Value;
}

da = new OleDbDataAdapter("select max(date),pumpid,pressure from


pumppressure group by date,pumpid,pressure", cn);
ds = new DataSet();
da.Fill(ds, "pump1");
if (ds.Tables["pump1"].Rows.Count != 0)
{
for (int i = 0; i < ds.Tables["pump1"].Rows.Count; i++)
{
if (ds.Tables["pump1"].Rows[i][1].ToString() == "ion1")

{ dgcIon.CircularGauges["Ion1"].Pointers["Default"].V
alue = Convert.ToDouble(ds.Tables["pump1"].Rows[i][2].ToString());
Physical Research Laboratory Dashboard Code

dgcIon.NumericIndicators["NumericIndicator1"].Value =
dgcIon.CircularGauges["Ion1"].Pointers["Default"].Value;
}

if (ds.Tables["pump1"].Rows[i][1].ToString() == "ion2")

{ dgcIon.CircularGauges["Ion2"].Pointers["Default"].V
alue = Convert.ToDouble(ds.Tables["pump1"].Rows[i][2].ToString());

dgcIon.NumericIndicators["NumericIndicator2"].Value =
dgcIon.CircularGauges["Ion2"].Pointers["Default"].Value;
}

if (ds.Tables["pump1"].Rows[i][1].ToString() ==
"rotary1")

{ dgcrotarysample.CircularGauges["Rotary1"].Pointers[
"Default"].Value = Convert.ToDouble(ds.Tables["pump1"].Rows[i]
[2].ToString());

dgcrotarysample.NumericIndicators["NumericIndicator1"].Value =
dgcrotarysample.CircularGauges["Rotary1"].Pointers["Default"].Value;
}

if (ds.Tables["pump1"].Rows[i][1].ToString() ==
"rotary2")

{ dgcrotarysample.CircularGauges["Rotary2"].Pointers[
"Default"].Value = Convert.ToDouble(ds.Tables["pump1"].Rows[i]
[2].ToString());

dgcrotarysample.NumericIndicators["NumericIndicator2"].Value =
dgcrotarysample.CircularGauges["Rotary2"].Pointers["Default"].Value;
}

if (ds.Tables["pump1"].Rows[i][1].ToString() == "duo")

{ dgcduovacuum.CircularGauges["duovacuum"].Pointers["
Default"].Value = Convert.ToDouble(ds.Tables["pump1"].Rows[i]
[2].ToString());

dgcduovacuum.NumericIndicators["duovacuum1"].Value =
dgcduovacuum.CircularGauges["duovacuum"].Pointers["Default"].Value;
}
}
}

da = new OleDbDataAdapter("select max(date),pumpid,speed from


pumpspeed group by date,pumpid,speed", cn);
ds = new DataSet();
da.Fill(ds, "pump2");
if (ds.Tables["pump2"].Rows.Count != 0)
{
for (int i = 0; i < ds.Tables["pump2"].Rows.Count; i++)
Physical Research Laboratory Dashboard Code

{
if (ds.Tables["pump2"].Rows[i][1].ToString() ==
"turbo1")

{ dgcturbo.CircularGauges["Turbo1"].Pointers["Default
"].Value = Convert.ToDouble(ds.Tables["pump2"].Rows[i][2].ToString());

dgcturbo.NumericIndicators["C DUO"].Value =
dgcturbo.CircularGauges["Turbo1"].Pointers["Default"].Value;
}

if (ds.Tables["pump2"].Rows[i][1].ToString() ==
"turbo2")

{ dgcturbo.CircularGauges["Turbo2"].Pointers["Default
"].Value = Convert.ToDouble(ds.Tables["pump2"].Rows[i][2].ToString());

dgcturbo.NumericIndicators["C Prim"].Value =
dgcturbo.CircularGauges["Turbo2"].Pointers["Default"].Value;
}

if (ds.Tables["pump2"].Rows[i][1].ToString() ==
"turbo3")

{ dgcturbo.CircularGauges["Turbo3"].Pointers["Default
"].Value = Convert.ToDouble(ds.Tables["pump2"].Rows[i][2].ToString());

dgcturbo.NumericIndicators["C SC"].Value =
dgcturbo.CircularGauges["Turbo3"].Pointers["Default"].Value;
}

if (ds.Tables["pump2"].Rows[i][1].ToString() ==
"turbo4")

{ dgcturbo.CircularGauges["Turbo4"].Pointers["Default
"].Value = Convert.ToDouble(ds.Tables["pump2"].Rows[i][2].ToString());

dgcturbo.NumericIndicators["C SCR"].Value =
dgcturbo.CircularGauges["Turbo4"].Pointers["Default"].Value;
}
}
}
da = new OleDbDataAdapter("select
max(date_time),water_temperature from watertemp group by
date_time,water_temperature", cn);
ds = new DataSet();
da.Fill(ds, "water_temp");
if (ds.Tables["water_temp"].Rows.Count != 0)

{ dgcchillerlabTemphumid.LinearGauges["Chiller"].Pointers["De
fault"].Value = Convert.ToDouble(ds.Tables["water_temp"].Rows[0]
[1].ToString());

dgcchillerlabTemphumid.NumericIndicators["NumericIndicator1"].Value =
Physical Research Laboratory Dashboard Code

dgcchillerlabTemphumid.LinearGauges["Chiller"].Pointers["Default"].Value
;
}

da = new OleDbDataAdapter("select max(date_time),lab_temperature


from labtemp group by date_time,lab_temperature", cn);
ds = new DataSet();
da.Fill(ds, "lab_temp");
if (ds.Tables["lab_temp"].Rows.Count != 0)

{ dgcchillerlabTemphumid.LinearGauges["labtemp"].Pointers["De
fault"].Value = Convert.ToDouble(ds.Tables["lab_temp"].Rows[0]
[1].ToString());

dgcchillerlabTemphumid.NumericIndicators["NumericIndicator2"].Value =
dgcchillerlabTemphumid.LinearGauges["labtemp"].Pointers["Default"].Value
;
}
//--------------- Lab Humidity------------------ Lab Humidity--------
da = new OleDbDataAdapter("select max(date_time),lab_humidity
from labhumidity group by date_time,lab_humidity", cn);
ds = new DataSet();
da.Fill(ds, "lab_humid");
if (ds.Tables["lab_humid"].Rows.Count != 0)

{ dgcchillerlabTemphumid.LinearGauges["labhumid"].Pointers["D
efault"].Value = Convert.ToDouble(ds.Tables["lab_humid"].Rows[0]
[1].ToString());

dgcchillerlabTemphumid.NumericIndicators["NumericIndicator3"].Value =
dgcchillerlabTemphumid.LinearGauges["labhumid"].Pointers["Default"].Valu
e;
}
//------------------ Water Level------------------ Water Level--------

da = new OleDbDataAdapter("select max(date_time),water_level_value


from waterlevel group by date_time,water_level_value", cn);
ds = new DataSet();
da.Fill(ds, "waterl");
if (ds.Tables["waterl"].Rows.Count != 0)

{ dgcchiller.LinearGauges["waterlevel"].Pointers["Default"].Va
lue = Convert.ToDouble(ds.Tables["waterl"].Rows[0][1].ToString());

dgcchiller.NumericIndicators["waterlevel"].Style =
NumericIndicatorStyle.Mechanical;
if ((ds.Tables["waterl"].Rows[0][1].ToString()) == "1")
{
dgcchiller.NumericIndicators["waterlevel"].FormatString
= "LOW";
}
else
{
Physical Research Laboratory Dashboard Code

dgcchiller.NumericIndicators["waterlevel"].FormatString
= "OK";
}
}
cn.Close();
}

}
Physical Research Laboratory Datasheets

APPENDIX D

DATASHEETS
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets
Physical Research Laboratory Datasheets