A Brief History of XAL at SNS - What went right / wrong

1. A Brief History of XAL at SNS - What went right / wrong J. Galambos XAL Workshop at the 2007 EPICS / ICALEPS meeting Knoxville TN.

2. 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

3. 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

4. Accelerator Hierarchy being defined Basic Architecture of the model Notes from June 14, 2001

5. History II Spring 2002: Test XAL app in control room at ORNL – MEBT at LBNL • 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

6. 2003 2002 2004 2006 2005 Front-End DTL/CCL SCL DTL Tank 1 Ring DTL Tanks 1-3 Target 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.

7. 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

8. 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

9. 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

10. Save/open app setup Error logging Html help Toolbar for common actions Accelerator navigating What Worked • The “Application GUI Framework” • A common starting point to create new apps • Good for neophyte physicist programmers • Good for neophyte physicist commissioners

11. 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)

12. 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

13. 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