1 / 13

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

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

hestia
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related