A Brief History of XAL at SNS - What went right / wrong J. 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 DTL Tanks 1-3 Front-End DTL Tank 1 DTL/CCL SCL 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