TGATS Tiling and Data Acquisition Software. Wojtek Skulski Laboratory for Laser Energetics,...

TGATS Tiling and Data Acquisition Software. Wojtek Skulski Laboratory for Laser Energetics, University of Rochester. October 7, 2005 1

TGATS tiling and data acquisition software

October 7, 2005

Wojtek Skulski

Laboratory for Laser Energetics University of Rochester

Rochester New York 14623-1299


• Programming:

Dave Hassett and Mark Wilson (LLE).

Megan Alexander, Eryk Druszkiewicz, Daniel Miner, Saba Zuberi (students).

Cuno Pfister and Wolfgang Weck (Oberon Microsystems).

Robert Campbell (BAE Systems).

Gérard Meunier (BlackBox community).

• Hardware, optics, electronics:

Joachim Bunkenburg, Larry Iwan, Terry Kessler, Charles Kellogg, Conor Kelly,

John Price, Dave Canning, Matthew Swain (LLE).

Jan Toke (Chemistry), Frank Wolfs (Physics).

Acknowledgements


Available presentations

This presentation is the third one in a series. I will highlight a

difference between engineering and scientific programming, using LLE

tiling and TGATS software as examples.

Other available presentations:

Scientific programming without a sting (BlackBox for Scientists and Engineers).

An overview and benefits of BlackBox programming.

http://www.pas.rochester.edu/~skulski/Presentations/BB_Class.ppt

Spatially Synchronous Phase Detection Unboxed.

The details of the SSPD, as implemented at LLE.

\\Hopi\Omega-EP\OMEGA-EP Presentations\General\SSPD_Unboxed.ppt


A bit of history: how the HW/SW project started

Manual control

February 2004 September 2004 April 2005

Automatic controlOne grating pair

Feb/2004 Sept/2004 Apr/2005

Automatic controlFour grating pairs(Mach-Zehnder)

May/2004

Closed loop,one TMA


Algorithm implementation application

Algorithm

Implementation

Application

Usually quite simple

E.g., SSPD is only 6 steps.

Has to deal with practical issues

E.g., noise is big issue for phase

unwrapping in SSPD.

Many months of work in the lab

Here you discover why you need rich

diagnostic tools and displays.

Model (or LOTF meas.) Science


Scientific versus engineering programming

Engineering project

Meetings and discussions

Requirements document

Developing SW to meets requirements

Working product

Deployment and maintainance

Scientific project

Meetings and discussions

Exploration

Developing SW continuously along the

way

SW is constantly evolving

Know-how

TGATSTiling


Research software is developed “on the go”

My research experience: every experiment is an exploration.

Software is often developed without rigid requirements.

As a consequence:

• Professional programmers seldom write research SW.

Physicists do.

• There is a well established method to deal with the situation.

• The same method worked at LLE (TGATS experiment).


Component Pascal is a tool for research SW

• Component Pascal (CP) software is a proper tool for research SW.

• Tiling of diffraction gratings 2 papers.

• TGATS data acquisition successful experiment.

• Waveform digitizer GUI physics outreach.

• What makes CP and BlackBox development so effective?

• Robustness and efficiency of the development environment.

• Scientific and engineering toolboxes.

• Scientist-friendly architecture.

• Most of the effort is spent on algorithms. GUI is secondary.


What makes CP and BlackBox

so effective?

Scientist-oriented tools and packages

Modular structure

Hardware interfacing

Debugging effort is dramatically reduced


The tool for tiling math: scientific computation library Chill

Over 5000 functions developed at BAE Systems for military airborne radar.

Fourier transforms.

Matrices and vectors.

Special functions.

High-precision math.

Digital filter design.

Random numbers.

Rational numbers.

Scientific plotting.

Etc.


• Before BlackBox, SW effort was often dominated by GUI.

• “Empty GUI” was created first.

• The placeholders were later filled with code.

• Examples of this approach: LabView, VB, various C++ “GUI builders”.

• Under BlackBox, GUI can be generated automatically.

• GUI can also be composed by hand.

• Code is written first, and the GUI is then created automatically.

• Work can focus almost solely on the algorithm.

• This approach is very scientist-friendly.

GUI on the fly


Old languages are not safe: C, C++, Fortran, and original Pascal.

Internal errors are not prevented by design in the old languages.

Main offenders: pointer arithmetics, typecasts, and memory leaks.

New languages eliminated most if not all internal errors.

Internal errors are prevented by design in Component Pascal, Oberon,

Java, and C#.

Debugging is dramatically reduced.

Work can focus on research and algorithm development.

Robustness of old and new programming languages


• All HW interfacing is handled via DLLs.

• DLLs are called by BlackBox.

• Several HW projects completed with BlackBox at UofR.

• CAMAC, USB, video frame-grabber card, mechanical

actuators, distance-measuring interferometer (DMI),

waveform digitizers.

• This topic is covered in depth in my other presentations.

Interfacing with hardware


1. Scientific libraries (math, vectors, etc.) Chill

2. Histogramming Chill and/or Gr

3. Graphics display Chill and/or Gr

4. Data management POM

5. User-defined extensions Data Logger

6. Interfacing with hardware DLLs

7. Networking TBD (tools built-in)

8. Database access TBD (tools built-

in)

TBD = “I have not used it yet”.

Summary of BlackBox tools


Project #1: “Get tiled!”

Project started as engineering, later evolved to research.

Initially, the goal was closed-ended.

The structure of the program

reflects the structure of the problem.


Software structure follows the problem

Far Fieldcalculations

Near Fieldcalculations

Actuatorsubsystem

Next slide shows close correspondence between the TGA hardwareand the architecture of the software. The correspondence is notexactly one-to-one, but it is close.


SW structure resembles the structure of HW

TgcGeometry

Actuator coordinates

TgcFiltersTime-domain

signal averaging

Subsystem LibMath and graphics library

Public domain, with source.

TgcUnitsNear Field processing.

Part of the structure stems directly from the problem, part from the programming considerations (e.g., the math tools).

TgcToolsMath tools specific

to this project.

TgcFarFieldsFar Field processing.

TgcCmdDisplay commands.

Legend: server client. MODULE

PicoPicomotor driver

Near FieldFar Field

Math

Actuators

GUI


These displays help understand results of SSPD.

Implementation - related diagnostics


Application – related diagnostics

These displays help understand the behavior of a TGA.


Example of implementation issue: temporal noise

Temporal noise is significant in realistic conditions, even under the hood.

-1.0

-0.5

0.0

0.5

1.0

Pis

ton

(w

ave

s)

8006004002000Iteration

Piston history. G1G2 @ working, G3G4 @ working, mirror.

Piston = 0 steps

8 steps

Fit: P = 0.55393 - 0.000512 * iteration

Blue: original piston. Green: piston minus drift

40

30

20

10

0

Fre

qu

en

cy

1.00.80.60.40.20.0Piston (waves)

0 steps 8 steps

Piston noise. G1G2 and G3G4 @ working angle.

Drift due to

lateral piston

Drift subtracted

offline.

Hee-Nee

Two TGAs + retro-mirror.


Full compressor, first time ever !

Infrared

After the algorithm and implementation are understood success!


• Requirements / specs existed SW customized for the task.

• Recording of tip, tilt, piston originated as a debugging aid.

• The recordings evolved into a powerful research tool.

• Application needs diagnostics many optional diagnostic displays.

• Easy to add new features along the design lines (e.g., some new math).

• Difficult to add new unplanned features (e.g., additional sensor recording).

• Overall.

• The OISG tiling SW is doing its job very well.

• This SW is tailored to a specific task.

• Like all BB software, it is very robust.

Main features of the tiling SW


• Let’s do TGATS.

• .. and we face a dilemma. The solution that was customized to one

task, is not easy to use in a vastly different situation.

• Why is the situation different?

• The list of sensors is open-ended. We know there will be more...

• Four recordings dozens of recordings.

• Well-defined task exploration.

From tiling to TGATS


Project #2: TGATS

A research project.

An open-ended goal.

A closed-ended program is not the right solution.

Software structure is open-ended (a framework).


TGA Discrete Sensor Locations

Cap 5 (Actuator 5)

Cap 4 (Actuator 4)

DMI 4 (Actuator 4)

Heide 1-1 (Actuator 5)

DMI 6(Actuator 6)

Cap 6(Actuator 6)

TBeam (Beam Temp)

TBK7 (Glass Temp)

TAmb ( Ambient Temp)

In addition to tiling variables, we need to acquire several new ones.

This list is open-ended !


Structure of TGATS software (simplified)

DLLs provided by the vendors

or developed by D.Hassett.

A/D and DMI interface

Utilities and calculations

Data LoggerExperiment-specific, customized script.

GUI panelsDo not contain any code.

The entire project #1

Pascal domain

Tiling softwareFF camera

NF camera

Heide interface

(M.Wilson)

Heideprobes

Object management Organizes histograms into a tree-like view on screen.

Low-level domain


Ingredients of the TGATS data acquisition software.

• Histogramming Gr Toolbox (WS).

• Graphics display Gr Toolbox (WS).

• Data management Persistent Object Manager

(WS+DM).

• Compiled DAQ script TGATS Data Logger (WS).

• Tiling software, including image acquisition and processing (WS).

Hardware interface:

• Zygo DMI interface DLL (source from Zygo, modified by DH & WS).

• National Instruments interface DLLs (DH).

• Piezo actuator control loop (DH).

• Heidenhain readout over RS-232 (MW).

TGATS data acquisition framework


Data Logger: experiment-specific script that is developed on-the-go.

Data Logger and Object Management

Object management.

Gr


TGATS SW summary

We evaluated and achieved qualification of a demanding system composed of

mechanical hardware, optics, electronics, and software.

• Complex software system was developed in short time by a small team.

• The experiment was almost continuously operated for several months with only

occasional downtime due to low-level DLLs. The downtime was seldom (if ever)

caused by high-level Pascal code, even though the SW was constantly evolving.

• The software has fulfilled its mission despite being a constantly evolving

prototype.


How TGATS software can be integrated with other systems

Other computer A

Local domain

TGATS tiling and DAQ softwareTiling, math, data acquisition

.

Lab domain

Internetcommunication

(TBD)

Other computer B


Technology transfer

Minutes of CDR – OMEGA EP Tiled Grating Assembly Control Software

MATLAB® software is considered a useful tool for these analyses and many

scientists use it. […] The System Science Group should have the responsibility of

developing these algorithms, which, once developed, should be put under revision

control by the Software Development Group.

System Science and Software Development now jointly work on the problem.

I hope that the approach presented herein will help these groups.


Robust and useful SW developed by a small programming team.

Two complementary approaches were demonstrated.

Engineering approach.

Requirements documents.

SW meets requirements, but may be difficult to evolve.

Scientific approach.

Exploration & research, loose requirements, design-as-you-go.

Needs a general framework that is easy to evolve.

With proper tools, scientific approach can yield production-quality.

Component Pascal and BlackBox are such proper tools.

Conclusions

Algorithm Implementation ApplicationSimple Demanding

TGATS Tiling and Data Acquisition Software. Wojtek Skulski Laboratory for Laser Energetics,...

Documents

Transcript of TGATS Tiling and Data Acquisition Software. Wojtek Skulski Laboratory for Laser Energetics,...