OUAHAB Karim Rigaku Americas Corporation – Houston (USA)
Summer 2007
Internship report
Align Optics Module for StructureStudio™
Internship Report
Summer 2007
General Purpose General Purpose ........................................................................................................................................... 2 I.
Introduction .......................................................................................................................................... 5 A.
Rigaku Americas Corporation ........................................................................................................... 5
B.
The Internship ................................................................................................................................... 5
C.
The Team........................................................................................................................................... 6
II.
Project Ambits ....................................................................................................................................... 7 A.
Project requirements ........................................................................................................................ 7
B.
The limits ........................................................................................................................................... 7
III.
Presentation of the hardware ........................................................................................................... 8
A.
The Optics ......................................................................................................................................... 8
B.
The motors ........................................................................................................................................ 9
C.
The pin diode .................................................................................................................................... 9
IV.
Development environment ............................................................................................................. 10
A.
The Java language ........................................................................................................................... 10
B.
StructureStudio ............................................................................................................................... 11
C.
Used Software ................................................................................................................................. 12
The Software I.
The User interface............................................................................................................................... 13 A.
Presentation of the UML ................................................................................................................. 13
B.
The MVC Pattern ............................................................................................................................. 14
C.
Implementation .............................................................................................................................. 15
D.
Customized Swing components ...................................................................................................... 15 1.
The Strip Chart ............................................................................................................................ 16
2.
The Confirm Button..................................................................................................................... 17
3.
The Curve Panel .......................................................................................................................... 18
4.
The curves global panel .............................................................................................................. 19
5.
The Instruments Picture Label .................................................................................................... 20
6.
The JThumbnailPanel .................................................................................................................. 21 Page 2
Internship Report E. II.
Summer 2007
The Design ....................................................................................................................................... 21 Interaction with the instruments ........................................................................................................ 22
A.
Presentation of the server .............................................................................................................. 22
B.
The TCL commands system ............................................................................................................. 22
C.
Connection to the server ................................................................................................................ 23
D.
Developments and implementation of the commands .................................................................. 24
III.
A Packages overview ....................................................................................................................... 26
IV.
Important objects ........................................................................................................................... 28
A.
The hardware package and the motor objects ............................................................................... 28 1.
The hardware package object ..................................................................................................... 28
2.
The Hardware Design Configuration object ................................................................................ 29
3.
The motor object ........................................................................................................................ 29
B.
The logic object ............................................................................................................................... 30
C.
The profile object ............................................................................................................................ 31
V.
1.
FWHM computing ....................................................................................................................... 32
2.
Integrated intensity computing .................................................................................................. 33
Implementation of the logic ............................................................................................................... 34 A.
The idea........................................................................................................................................... 34
B.
The scan of the axis – threads usage .............................................................................................. 34
C.
The motors issue: required changes ............................................................................................... 35
D.
Connection to the UI ....................................................................................................................... 36
VI.
Implementation of the data acquisition panel ............................................................................... 37
A.
The profiles listener ........................................................................................................................ 38
B.
The curves view............................................................................................................................... 39
C.
Starting a new scan and using the results....................................................................................... 39 1.
Starting a new scan ..................................................................................................................... 39
2.
Using the results ......................................................................................................................... 40
D.
The profiles history ......................................................................................................................... 41
E.
The profiles information panel ....................................................................................................... 43
VII.
Implementation of the Manual Control panel ................................................................................ 44
A.
The instruments picture.................................................................................................................. 45
B.
Motors control ................................................................................................................................ 46 Page 3
Internship Report
Summer 2007
C.
Shutter control ................................................................................................................................ 47
D.
The Intensity scrolling chart and the real time intensity label ....................................................... 48
VIII.
Tests ................................................................................................................................................ 49
IX.
Conclusion ....................................................................................................................................... 50
Page 4
Internship Report
Summer 2007
General Purpose I.
Introduction A.
R
Rigaku Americas Corporation
igaku was created in Japan in 1951, “Rigaku” means physical science in Japanese. It quickly expands its offices around the world: in the United Kingdom’s, and in a few states in the USA. It is now a leader in the fields of protein and small molecule X-ray crystallography, general Xray diffraction, X-ray spectrometry, semiconductor metrology, automation, cryogenics and X-
ray optics. Rigaku employs more than 1000 over the world. The Houston Rigaku offices where the internship took place develops instruments, software and provides to its clients fully integrated solutions, supplying scientists of universities and industrials.
B.
The Internship
As a student of the French engineering school ENSEEIHT, located in Toulouse, I had to make a technical internship abroad. I always wanted to have an experience in the USA, and Rigaku Americas Corporation offered me an 11 weeks summer internship, with a purpose that perfectly fits my skills in computer sciences and applied mathematics, but also my background in physics and chemistry. I worked in the software team and had a very close relationship with engineers and scientists from different areas: chemistry, electronics, robotics, physic. Moreover I was very interested y dealing with managers.
Page 5
Internship Report C.
Summer 2007 The Team
I worked with a part of the software team on the project: Colin Acheson and Bill Barnet were responsible for the development of the instruments server.
Thom Hendrixson was the manager of the project at the software level.
And I also worked with a part of the Automation department, especially: Jim Pflugrath war supervising the project as a specialist of the instruments and bring his large experience in this domain.
Kris Tesh, as a Product Manager close from the clients, helped us to develop software that fit the expectation of the future customers.
Joseph D. Ferrara was the manager of the whole project, he supervised the coordination of the team and indicated the way to follow.
Page 6
Internship Report
Summer 2007
Some other employees were directly or indirectly involved in the project, for instance the persons in charge of the laboratories helped us to use the instruments and also gave their valuable opinion about our work.
II.
Project Ambits A.
Project requirements
When scientists need to analyze a specific molecule, they are used to employ an X-Ray beam: the behavior of the beam over the sample gives a lot of information. But the beam must be perfectly align with the sample and ensure that the intensity of the ray on the sample is maximized. To align the optics, a set of mirrors is used to focus the beam before sending the beam over a collimator. Those mirrors were moved with high precision screws. This manual procedure could be long and displeasing for the user. This is why Rigaku decided to develop a software to automate the alignment of the optics with the help of picomotors driving the screws. The goal of my internship was to design such a software.
B.
The limits
The main limit was the last of my stay: 11 weeks. It defined the deadline of the project. Another important factor was the price of the hardware used; we tried to minimize it, in order to offer an interesting package to the customers.
Page 7
Internship Report III.
Summer 2007
Presentation of the hardware A.
The Optics
The X-ray generated produces an electrons beam, which hits a rotating anode. Depending on the material (Cu, Mo, Cr…) used to generate the beam, the wave length will vary. The aim of the optics is to harvest, monochromatize and focus the beam to get a straight beam under control at the exit of the collimator. The focusing system is ensured by a set of mirrors. They will be controlled by the Align optics Module.
The optics and the generator:
The generator provides the required power to incur the X-ray beam
Page 8
Internship Report
B.
Summer 2007
The motors
The motors used to drive the optics are New Focus Intelligent Picomotors. Those very high precision motors are connected to the server by an Ethernet connection and could be driven with a hand terminal. The motors are mounted on this part of the optics (where the screws are):
C.
The pin diode
To compute the intensity, our first idea was to use a CMOS camera in front of the beam. The result could have been very nice on screen, but too many problems appeared with the camera: -
-
It was very hard to find the beam on the image by an algorithm, because of the shadows and lens effects due to the collimator. And it is unacceptable to have such errors in the intensity computing. The computing of the images and their management would have considerably increased the time required for the alignment.
So we decided to use a pin diode, which is the standard instrument for this usage. For the development, Rigaku bought a National Instrument Digital Pin diode with a USB 2.0 interface Page 9
Internship Report IV.
Summer 2007
Development environment A.
The Java language
The application will be a module for an existing Rigaku Application: StructureStudio, developed with Java, the object oriented language of Sun Microsystems. I particularly appreciate this language: during my studies I developed a lot of application with Java.
As an Engineer, I had to keep in mind the five golden rules for a Java Program: 1. 2. 3. 4. 5.
It should use the object-oriented programming methodology. It should allow the same program to be executed on multiple operating systems. It should contain built-in support for using computer networks. It should be designed to execute code from remote sources securely. It should be easy to use by selecting what were considered the good parts of other objectoriented languages.
One of the main advantages of Java is its platform independence: it means that a program written in the Java language can run similarly on any supported hardware/operating-system platform. One should be able to write a program once, compile it once, and run it anywhere: the application could be run on Windows, Linux, UNIX, Solaris… as soon as the user installed the Java virtual machine, which is now incontrovertible.
Page 10
Internship Report B.
Summer 2007 StructureStudio
StructureStudio is a highly modular program for collecting and processing single crystal diffraction data. StructureStudio can be enhanced to support computer control of Rigaku X-ray generators . The user interface follows the control panel paradigm and is highly configurable, so for most tasks it is possible to layout a single panel with all the views necessary to perform the necessary functions and monitor the progress. This eliminates the need to constantly switch back and forth between windows. The project is a standalone module for StructureStudio, which means that the software can be connected with other modules of StructureStudio, but no other modules are required to run the application. StructureStudio ™:
Page 11
Internship Report C.
Summer 2007 Used Software
For the development, I principally used two different software: -
Eclipse 3.3: The most appreciated IDE (Integrated Development Environment) of the majority of the Java developers: it’s powerful, flexible, reliable and free. Also the community is very large and provides a lot of useful plug-ins.
-
NetBeans 5.5: The Sun IDE software was really helpful for the development of the user interface: it is supple, and light. The inspector tool and the layout manager allowed a fast development of the GUI, that could be long and hard with Java.
Moreover other software were used, notably: -
CVS for the team synchronizing. (An Eclipse’s plug-in was used) Paint.NET for the design.
The Operating System used by the software team is Microsoft Windows XP SP2, but the tests were run both on Windows XP and Linux (Redhat 9.0).
Page 12
Internship Report
Summer 2007
The Software I.
The User interface
The user interface of a software is always an important part of the development of the software, it must be flexible, pleasant, and … fashionable: user interfaces styles quickly changes in time. The user interface is the only part of the software that could be appreciated by the user. In the case of professional software, designed for a very specific public, developers have to be very careful about the interface, as the user already has habits about this kind of software. Moreover trying to implements creative new feature could make the difference with the competition products. My first step was to talk with the people of Rigaku who use StructureStudio (as the project is a module for it) and other Rigaku software. I also had a close look to StructureStudio itself, as the module has to integrate well in the existing design. We will come back later on the content of the user interface.
A.
Presentation of the UML
The best way to describe a complex oriented object structure is the UML language (the Unified Modeling Language). Sun Microsystems gives the following definition: “In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.”
Several UML diagram will describes the structure of the program in this report to illustrate the objects and their relations.
Page 13
Internship Report B.
Summer 2007 The MVC Pattern
In Java, a powerful ways to develop a GUI is the Sun API “Swing”, the descendant of AWT. Swing offers a lot of components and is very flexible, but it could be very long and fastidious to implement when the interface becomes heavy. This is why I decided to implements the Model – Views – Controllers (MVC) design pattern recommended by the Sun developers. It decouples presentation from data and from operation on that data. The controller is actually collapsed into a delegate object and is not truly separated from view, or is not a separate class; this is why MVC in Swing is sometimes called "separable model architecture." Note that the MVC pattern is not specific to Java, it could be used in any Object Oriented environment. The MVC pattern
In fact, Sun describes the M-VC model, not the MVC. The difference is that in the M-VC pattern, the views and the controllers may be mixed in common classes to simplify the code.
Page 14
Internship Report
Summer 2007
Benefit or the MVC pattern: As my work may be improved and pressed on in the future by other Rigaku developers, the flexibility was definitely required. The MVC pattern is long to install but allows easy adding or removing of features, without modifying the core or the software (the model, which here will be the logic of the alignment and the management of the hardware). Moreover, during the development itself I had to often change the UI, and the efficiency of the MVC pattern allowed me to do those changes. See also: http://java.sun.com/products/jfc/tsc/articles/architecture/
C.
Implementation
The main view of the MVC model is the global interface of the module, designed in the JAlignOpticsControl class and displayed by the top level module manager of StructureStudio. A set of listeners controls the views and are connected to the classes that describe the hardware and the logic, which is the model of the pattern. So basically a component can be added to the user interface in the JAlignOpticsControl class, then this component can get a listener in an existing class or in a new one, and this listener will be connected _ if required _ to the logic. Example: The progress bar in the scans tab is built in the JAlignOpticsControl class. The ProfilesListener class knows this component, but also knows all the profiles built by logic, and when the advancement of a profile will change, the model will prevent the listener about this change, and the listener will change the progress bar status with the last received information.
D.
Customized Swing components
Even if the Swing API offers a large set of components, sometimes it is necessary to develop your own for specific applications. I developed very general components to be sure that they could be reused by the Rigaku developers for other projects: I did not make components specifically for this project. And this should be always the case for an application that may be modified or include as a part of a bigger application.
Page 15
Internship Report
Summer 2007 1.
The Strip Chart
An important thing to remember during the development of a user interface is the movement. The user will be quickly bored with a static interface which only displays classic components as buttons. Using colors, icons, pictures and movement makes the interface dynamic and keep the focus of the user. The Strip Chart is a component that can display in real time the evolution of a value. I developed this component not only for the specific use of the module but also for any other king of use: the module will display the real intensity provided by the pin diode, but a developer can also implements this components to display the evolution of any other parameter: a position, a temperature etc… Basically the component is a Java abstract class called JStripChart, so an implementation is required. The developer only have to implement a method called “getValue()” to periodically indicate to the strip chart the new value to display. The implementation for the module is the JIntensityStripChart class which provides the intensity value to the component:
The component is fully customizable, the developer can change: -
The scrolling speed The refresh time The colors (of the curve, the background and the grid)
On the UI, at the left of the strip chart, the user can read the real time value of the beam intensity. The strip chart auto-resizes itself with the maximum read value (This functionality could be turned off). The strip chart uses a dedicated thread to avoid blocking the UI and a Java Timer for the refreshing of the curve. Moreover 2 useful functions are available for the developer: -
start(): start the scrolling stop(): stop the scrolling
Note that this component is an extension of the JLabel Swing component and so it is fully compatible with the Swing API.
Page 16
Internship Report
Summer 2007 2.
The Confirm Button
The JConfirmButton class is an extension of the JButton component; it simply pops up a menu to confirm the action when the user clicks on the button. This component is useful for critical action, for instance this component is used when the user wants to open the shutter:
The button is fully customizable (as a JButton is). The text and the icons of the popup menu can be changed at any time, as the events associated to the popup menu.
Page 17
Internship Report
Summer 2007 3.
The Curve Panel
The curve panel is an extension of the JLabel Swing component. It has been designed for the displaying of intensity profiles. The particularity of this object is its direct relationship with an IntensityProfile object. The profile will provide in real time the new characteristics, and the curve panel will be in charge to display them.
This component includes a lot of functionalities: -
An integrated popup menu. A printer interface (using Printable and Pageable Java interfaces). It could be opened in a new window to enlarge the view. The colors could be changed in real time (using a JColorChooser). The both axis are auto scaled. An indicator of the position and the intensity follows the mouse on the curve. The maximum is displayed in real time. The component can build at any time a thumbnail image that could be used by other classes. The component can be cloned (using Cloneable interface). The component adapts its border if it is selected or not on the user interface. The name of the profile is displayed and can be changed in real time. Keyboard shortcuts (associated with the popup menu). …
Page 18
Internship Report
Summer 2007 4.
The curves global panel
The JCurvesDisplayPanel is an extension of the JScrollPane Swing component. Its aim is to display few Curves in a scrollable panel, and to allow a dynamic change of its content by the user. The idea is to manage a JPanel designed with a GridLayout inside the JScrollPane to display the curves: each case of the GridLayout will contain a JCurvePanel. The size of the layout depends of how many curves are present. The maximum column number is 2, the rows are unlimited. The panel will automatically resize its child components to make them fit the screen, and a vertical scrollbar will be added when necessary.
Note that the JCurvesDisplayPanel can contain any kind of components, even if it has been especially designed to contain JCurvePanel. For specific disposition of the components (i.e. note in a table), the layout of the container panel may be changed (I would recommend a GridBagLayout).
Page 19
Internship Report
Summer 2007 5.
The Instruments Picture Label
The JInstrumentsDraw is an extension of a JLabel designed for the drawing of hardware on a picture, using the Java2D libraries. It directly uses the hardware classes to display the items on screen.
The user can drag the labels, select and move a motor by clicking on it. As we will see later, this component is fully customizable. An issue encountered with this component is the refresh time, which was pretty long at the beginning but I could reduce this time by using a double buffering drawing strategy: The image is computed with a buffer in the memory, and when then buffer is ready, it will be painted on the component. Most of the design options are note contained by this component but in the displayed items classes, for instance each motor class describes the way it will be displayed on the instruments picture. A JPopup menu is associated with the component, this menu allows drawing options such as the visibility of the components on screen.
Page 20
Internship Report
Summer 2007 6.
The JThumbnailPanel
The JThumnailPanel is an extension of the JPanel Swing component. This panel is dedicated for the displaying of an Image. Usually an IntensityProfile object provides an Image object to the JThumbnail panel. This component is used in the “data Acquisition” panel.
The component includes a useful method called setEmptyThumbnail() that will fill the panel with a default image when there is not thumbnail to display. This panel is not responsible for the creation of the image, it simply displays it (for an intensity profile, the associated JCurvePanel object is responsible for the creation of the thumbnail).
E.
The Design
The design of the application includes all the pictures and the icons used. The icons are located in the images directory of the “Jframework” project, one of the core project of StructureStudio. I created most of the icons required with Paint.NET, and added them into this directory it includes the toolbars and popup menu icons, but also the icons of the manual control panel. The textures used for the motors label have been also created with Paint.NET, and, as the instruments picture, those images are located in the images directory of the Align Optics Module project, because those images are specific of the module (the icons may be used by other modules, this is why they have been placed in the common images directory). To modify the design, it is fairly simple: just edit the images or change the path to the images in the concerned directory.
Page 21
Internship Report II.
Summer 2007
Interaction with the instruments A.
Presentation of the server
Bill Barnet and Colin Acheson developed for this project an extension of an existing instruments server which commands the hardware at the low level, this server was developed with the C++ language. A set of new commands have been added to drive the specific hardware required for the alignment: -
The picomotors The pin diode In this part we will see how this server was used by the software.
B.
The TCL commands system
StructureStudio includes a commands system called TCL (Tool Command Language). Java classed exists to parse those commands, and the TCL system must be used to make the commands recognized by the server. Typically, a TCL command has the following syntax: Command [option [option …]] [SendReply = 0 | 1]
Where Command is the name of a command (e.g., MoveMotor) and option is one or more options for the command. All of the options listed for a command must be specified on the same line as the command. Options have the form: keyword = value
Moreover, the module uses a TCL interpreter that allows the user to directly send TCL commands or scripts to the server. This interpreter is a part of StructureStudio so I did not have to develop one, I just used the existing one and connected the module to it:
Page 22
Internship Report
Summer 2007 The available commands are described in the AlignOpticsServer documentation.
C.
Connection to the server
The connection to the instruments server is made threw a socket. The AlignOpticsClient class extends the existing class SocketDataclient which itself extends the DataClientClass. Those super classes ensure the synchronization of the communication and the state of the connection. UML diagram of those relations
To connect to the server, 3 parameters are required: -
The server address (usually ‘localhost’ if the server and the client are on the same computer) The server port (usually 8050 with the instruments server) The client name
Those parameters can be set in the clientConfig.txt file located in the Align Optics Module “config” directory. This file will be loaded at the start and the module will use it to establish the connection. Note that the file also contains the timeout accepted for the requests. When the connection is made, the servers listens to the client and parses the received TCL commands, executes them and sends back answers if the client is expecting some.
Page 23
Internship Report
Summer 2007
An issue encountered was the fact that the server disconnects the client at the first connection (due to a server convention). So I had to listen to the server and automate the reconnection to the socket when needed (i.e. only at the first disconnection). I was able to perform this by configuring the module as a DataClientListener of the client.
D.
Developments and implementation of the commands
As recommended by the team, I took the existing “CameraMan” project as an example to write all the classes responsible of the commands. I worked on the command system at the very beginning of the project, because having a reliable and fast communication system with the server was necessary. I had to become friendly with the TCL command system of StructureStudio. UML Diagram of the complete Command System
Page 24
Internship Report
Summer 2007
As we can see the AlignOptics class is at the center of the diagram: it is the core of the system. The module has an AlignOpticsThread which is a thread used to run and execute the commands. The module will ensure that the AlignOpticsClient uses the same thread: the AlignOpticsClient is responsible for the management of the socket for the connection and send TCL requests or messages through the pipe. The creation of the commands is made by the AlignOpticsImpl class which implements the AlignOptics class where all the headers of the required methods are defined. Moreover, each command is encapsulated is an AlignOpticsTask instance which will run a dedicated thread for the command and append it into a queue. The AlignOpticsCommand class is responsible to call the module for a new command. The commands queue is managed by the TCL synchronization system and ensures that all the commands will be run in the creation order. Eventually, the system follows this: -
The logic asks the AlignOpticsCommand class for a command, passing the options of the command as parameters. The module asks the AlignOpticsImpl to create the corresponding TCL command The AlignopticsImpl send the command through the AlignOpticsImpl with an AlignOpticsThread, encapsulated in an AlignOpticsTask instance. This is synchronized by the AlignOpticsModule as the client and the module has the same thread.
Notes about the CommandFactory class: To automate the commands creation, I have created a dedicated class called CommandFactory (located in the “logic” package). This class contains a getNewCommand() method which will return an AlignOpticsCommand instance connected to the client and the module. This class will be useful for the logic to create new commands at any time, with the confidence that the command will be synchronized with the TCL system.
Page 25
Internship Report III.
Summer 2007
A Packages overview
We will describe in this section the classes of the project with the UML language. A package is a set of classes which could be assigned as a folder in the project structure. On the following UML diagram, you will find at the top the main classes of the module which are contained in the root package. At the bottom appear the following Packages: -
Swing: all the views components, including the customized components. Logics: all the classes relative to the logic of the alignment. Listeners: all the listeners required by the MVC pattern. Interfaces: the important java interfaces of the project, used by the root package. Hardware: all the classes that describes the hardware components. DragNDrop: all the classes required for the implementation of the drag and drop function on the user interface Utils: utilitarian classes that could be use by any java project.
Sum total, the whole module contains around 50 different Java classes, which is a reasonable figure for this kind of application. Before I wrote any line of code, I made few UML diagrams to get in mind where I was going. The UML allows an engineer to get a large view of what he’s doing, having this hindsight is necessary to get a consistent structure in an Oriented Object program. Moreover, the conception _ on paper _ of the user interface (the swing package) was also a part of the specifications, before the development. During the development, I constantly modified the diagram to adapt to the new functionalities and the required changes.
Page 26
Internship Report
Summer 2007
Root classes:
The Packages:
Page 27
Internship Report IV.
Summer 2007
Important objects A.
The hardware package and the motor objects 1.
The hardware package object
The HardwarePackage class describes all the hardware used by the module. If some instruments are added, they should be (if necessary) known by this class. For instance all the motors are stored in a Vector in this class, but the pin diode is not, as it is not necessary (we only use the pin diode to compute the beam intensity). This class contains important information, as the maximum time allowed to let the shutter open. But a very important feature of this class is the usage of the instruments.xml file. By using the Java XMLEncoder and XMLDecoder classes, the hardware object is saved in a XML (eXtensible Markup Language) java object. That means two things. First of all it is very easy to modify some properties by editing the XML file, as an example, since a motor is a part of the hardware, all the motors will be saved in the XML file, and so their names can be changed by editing the file. Secondly, as the file is encoded with the XMLEncoder, any other Java program (especially other StructureStudio modules) can use the xml file to read the content of the hardware. The XML file is located in the ‘config’ directory of the module and is load at the start of the module, and save at the end. Why should we save it? if a user change the position of a motor label on screen, it will be save in this file and the configuration will be the same the next time someone launches the module. The HardwarePackage class contains a saveXML() method which automates the saving and a createXMLExample() which will generate for the developer a new customized XML file. A problem encountered with the Java Encoder 1.5 is that it is quite impossible to encode an enumeration. This is now solved with the last Java release. But I was unable to use an enumeration for the motor type, which would have been better. As soon as StructureStudio moves to the java 6.0 compiler, this functionality should be added.
See Also: The Java documentation for XMLEncoder and XMLDecoder.
Page 28
Internship Report
Summer 2007 2.
The Hardware Design Configuration object
Each item of contained in the HardwarePackage could use an instance of the HardwareDesignConfiguration class. This class describes some properties for the displaying of the item on the UI, especially on the instruments picture. For instance each motor own an instance of this class and describes inside it the textures for their labels, their positions on the instruments picture etc… HardwareDesignConfiguration instances will be saved in the instruments XML file as it is a part of the hardware description. 3.
The motor object
The motor object is an important class: each motor will be represented by an instance of this class, which contains all the information about its features: -
Name Type (InBeam, CrossBeam, Bragg1, Bragg2, Vertical or Slit) Minimum, Maximum, Current and Home position Speed Acceleration Visibility on the UI
As we have seen before each motor also have an instance of the HardwareDesignConfiguration class. The logic ensures that the properties of the motors are correctly modified during the execution of the application. Note that some motor properties are not saved in the instruments XML file: those properties are recovered from the instruments server and then set in the object. (e.g.: the motor position, the motor acceleration). The Hardware, HardwareDesignConfiguration and Motor classes constitute the Hardware package:
Page 29
Internship Report B.
Summer 2007 The logic object
If one object might be more important than any other, it would be the AlignmentLogic class. My idea was to create a system that allows the development of many logics, as the hardware could evolve, as the ideas of the scientists to align the optics. In fact, the AlignmentLogic is an abstract class. It contains all the method to send the commands and contains 3 abstract methods: -
Initialize() Run() Abort()
“Abstract” means that a logic class will be an extension of the AlignmentLogic class, and in this extension will be defined the 3 abstract methods: -
Initialize() is called when the module is launched and typically retrieves information about the instruments from the server. Run() is called when the auto alignment procedure is launched. Abort() is called when the auto alignment procedure is aborted.
So I developed an extension of the AlignmentLogic class called DefaultLogic, but if a developer wants a new logic, he doesn’t have to rewrite the whole core, he just have to implements 3 methods, and inside those methods he can call the methods defined in the AlignmentLogic class, such as “scanAxis” , “moveMotor” etc.. The AlignmentLogic class also contains interesting parameters that can be used by the logic, including: -
The computing time (time needed to align the optics) The listeners of the logic A flag indicating the state of the shutter A flag indicating the state of the procedure (if it is running or not) The current intensity of the beam
Note that those parameters could directly act on the user interface via the MVC pattern, so it is strongly recommended to correctly set the flags and the values when a new logic is written.
Page 30
Internship Report C.
Summer 2007 The profile object
A profile represents the result of a scan: for every position of the scan, the profile associates the corresponding intensity. This object is one of the most complex and one of the longest (in terms of code) of the project. First of all, it is an extension of the TreeMap Java object. This structure, Red-Black tree based, allows easy iterations and most of all it ensures that the contained keys will be sorted. The TreeMap will contain a set of key/value pairs, in a pair the key is a motor position and the value is intensity. So basically a profile can be used like a TreeMap: keys and values can be added or remove from anywhere at any time. A profile is defined by a start position, a stop position and a name (optional). The profile object will update in real time: -
The minimum intensity The maximum intensity The average intensity The integrated intensity (if asked) The full width at half maximum (if asked) Moreover a profile is directly linked to:
-
The concerned motor. A JCurvePanel if the profile should be displayed on the UI (e.g. a profile used by the auto alignment logic should not)
When a new point is added to the profile, a new line is added to the JCurvePanel, which will automatically update itself by adding the line, rescaling if necessary etc… Moreover, each profile contains a “smooth” flag, which indicates whether or not the curve should be smoothed. Due to the real time drawing necessity, I used a fairly simple smoothing method: The points are taken 3 by 3, and the middle point receives the average intensity of the 3 points. This method works very well as the intensity profiles are continuous functions and was recommended to me by Jim Pflugrath. The profile object also contains other flags: -
A flag indicating if the scan is completed A flag indicating if the curve is selected on screen
It also contains a variable indicating the advancement of the scan, useful for the progress bar of the user interface. Note that all those parameters are set automatically but you can modify them
Page 31
Internship Report
Summer 2007
externally if required (but this is not recommended). And if the Profile or the JCurvePanel class must be modified, the bidirectional relation between those two classes should never be forgotten. 1.
FWHM computing
The FWHM (Full Width at Half Maximum) is given by the difference between the two extreme values of the independent variable at which the dependent variable is equal to half of its maximum value.
The IntensityProfile class contains a method called updateFWHM() for the computing. It will get the maximum of the curve and try to find 2 lines that intercept the half maximum line. Usually profiles have a Gaussian look, but if not, the FWHM cannot be computed: the 0 value is returned. This method will also set 2 attributes of the JCurvePanel class associated to the profile: fwmhX1 and fwhmX2. Those points can be used to quickly display the FWHM on the curve. At the moment this displaying is done on the thumbnail picture. The FWHM is a good indicator of the quality of the profile: a low FWHM indicate that the maximum is well localized: Between two profiles with the same maximum, the profile with the lower FWHM will be chosen.
Page 32
Internship Report
Summer 2007 2.
Integrated intensity computing
The Integrated intensity is also a good indicator for the quality of a profile. The integrated intensity is the area below the curve:
The area is the sum of the pair triangle/rectangle contained below each line of the curve. A simply iteration over the curve returns the integrated intensity with a very good accuracy. As the JDK does not contain any area computing method I had to make my own.
In crystallography, the integrated intensity gives precious information about the structure of the analyzed crystals.
Page 33
Internship Report V.
Summer 2007
Implementation of the logic A.
The idea
The idea of the logic is to follow the human procedure. Kris Tech showed me in the laboratory how they used to align the optics manually: He tuned the axis by following a specific sequence and with the help of an analog pin diode. The observations showed that by following this sequence and setting the mirrors where the intensity peak is, the alignment of the optics could be done in an efficient way. So the module follows a sequence of scans describes in the strategy.txt file (located in the “config” directory of the module). After each scan the concerned motor is set at the position where the maximum was reached on the profile.
B.
The scan of the axis – threads usage
The AlignmentLogic class provides a very useful method named scanAxis: this method needs two parameters: a profile and a step size for the scan. This method will get the motor of the profile and fill the profile object by scanning an axis with the MoveMotor and GetIntensity commands. A particularity of this method is that it is run in a thread: it allows a real time update of the user interface, and as a scan could be very long, the software will continue to run even if the scan is not finished yet. The returned thread allows the developer to synchronize the scans in the run() method of the logic: so each scan can wait for the preceding scan to end before starting, which will be always the case, except if for some reason few motors have to be moved at the same time. Basically the logic will: 1) Load the strategy file. (so the file can be changed without reloading the module) 2) Build the corresponding profiles. 3) Start to scan one by one the axis of the sequence using a thread synchronization and for each set the motor position where the max intensity peak was found. 4) End.
Page 34
Internship Report C.
Summer 2007 The motors issue: required changes
Here comes the biggest problem encountered during the project. The motors used to drive the optics do not include encoders. That means that there is no way to know the position of any motor at any time. I was not aware of this at the beginning as project, especially because the instruments server was supposed to provide commands as GetMotorPosition. In fact even the pulse counting depends of the position of the motor and also of the direction of the movement. This is why we had to completely revise the logic of the alignment: the idea was to align the optics only with the intensity value, as a human does when he manually aligns the optics. The default logic overrides the “scanAxis” method of the AlignmentLogic class, and implements an algorithm originally purposed by Joseph D. Ferrara. The logic still works as described in the previous part, but used this scan method for each axis defined in the strategy (for the visibility, the algorithm have been simplified): for i from 1 to repeatTimes: |
I1=getIntensity(), moveMotor(stepSize),I2=getIntensity()
|
computeSlope(i1,i2,stepSize)
|
if slope
