A Brief History of XAL at SNS - What went right / wrongJ. Galambos

XAL Workshop at the 2007 EPICS / ICALEPS meeting

Knoxville TN.

XAL – The Origins

Guiding Principles:

Wanted an Accelerator Hierarchy Hide the control system from the developer A single point accelerator configuration “Online” beam model

Excuses: Had a hard deadline – beam commissioning Really did not understand much about control systems and

accelerators in the beginning – good thing we did not write detailed requirements

More-or-less right

XAL – The Origins Circa 1999 – Started worrying about “Application

Programs” Had a workshop to evaluate options

SDDS, Cdev, UAL, FORTRAN examples Database! Need an internal “champion”

2000 Evaluated the SDDS, Cdev Started populating database

2001 Started collaboration with UAL which morphed into

XAL

Notes from June 14, 2001

Accelerator Hierarchy being defined

Basic Architecture of the model

History II

2002 – wrote first few apps, virtual accelerator, scripting, commissioned the Front End at ORNL

2003: Application Framework, 10 apps, commissioned DTL1

2004: commissioned DTL – CCL, too many apps

Spring 2002: Test XAL app in control room at ORNL – MEBT at LBNL

Commissioning Schedule – Staged Approach - Useful SNS was an entirely new facility – “green-field” Staged commissioning approach with early deployment gave XAL

development time to test approaches and adjust afterwards. This was critical.

2002 2003 2004 2005 2006

DTL Tanks 1-3

Front-End

DTL Tank 1

DTL/CCLSCL

Ring

Target

What Did Not Work

Keep it pure Almost all applications have SNS specific

idiosyncrasies Some of the Node implementations have

idiosyncrasies (e.g. wire-scanner) Driven in large part by schedule Parts written by physicists (e.g. me)

Documentation apologies

What Worked

Database Absolutely recommend to any new project for all

the usual database reasons Also use it for measured data

Accelerator hierarchy / hide the control system Allows for transparent code Opened the door for neophyte physicist

programmers + generic apps

Odds & Ends – Right Choices Online model:

Need it to unravel beam observations Same model - entire accelerator – generic apps Same model - different data sources (design, machine, pv-

logger) Separate “view” than the device “view”

Virtual Accelerator Debug apps before beam time – good for neophyte real-

time programmers to learn with Java

Never want to go back to C++ GUI, Swing, database connectivity, ~ no memory leaks Speed no problem for us

What Worked The “Application GUI Framework”

A common starting point to create new apps Good for neophyte physicist programmers Good for neophyte physicist commissioners

Save/open app setup

Error logging

Toolbar for common actions

Html help

Accelerator navigating

What Worked

Accelerator Physicist Programmers Good for writing apps – 1 person responsible for

making a beam commissioning activity happen Bad for infrastructure development

Also need good software developers for this (which we were fortunate to have)

What Worked

Scripting Absolute necessity for commissioning Good for algorithm testing (and examples) Java makes this very easy (no glue code). Trivial

python / XAL interface. Good for high level studies, but you need a robust

control system (MPS) to protect equipment

Collaboration Success and Failures

XAL was born from a failed collaboration with UAL Our lack of precise requirements made

collaboration non-trivial The online model was developed at LANL,

and used during commissioning at ORNL At SNS there was a tremendous amount of

“internal collaboration” Need to trust each other and share components