EPICS Developments at the Australian Synchrotron Contributors: Richard Farnsworth, Andrew C Starritt (Controls Team) Chris Myers & Mike DeSilva (Versi) Presented by Nicholas Hobbs Epics to MySQL The “Flange” for control system to internet applications

Epics to MySQL As have most other facilities, we developed an application we called the Facility Status Monitor (FSM*). Originally intended it to be a stand alone application that would be used throughout the facility and beamlines. It shows beam current, lifetime, operating status and messages, shutter status and a few other variables Proved quite popular Needed a web version * Not to be confused with the Flying Spaghetti Monster

Internal Facility Status Monitor

What we did and didn’t want (Requirements) The FSM should use the “corporate” colour scheme and contain a summary of all that an Accelerator Physicist, Operator or Beamline Scientist wants to know at any instant in time We did not want to distribute a video signal around the facility We wanted to publish data on the Web, internally and externally We wanted the ability to build arbitrary web applications in the future

Introducing the “FLANGE” First we took the original program, “cut the head off” and made it talk to an SQL database It was a good first start, but not very general

Introducing the “FLANGE” First we took the original program, “cut the head off” and made it talk to an SQL database It was a good first start, but not very general Enter the FLANGE. A Flange is a mechanical device for joining two differing pipes or similar together. Our FLANGE uses channel access one end and writes EPICS data, and metadata such as enumeration type, connection state, update times, element count, data type, alarm severity, precision, engineering units and high/low operating range to a mySQL database

Introducing the “FLANGE” First we took the original program, “cut the head off” and made it talk to an SQL database It was a good first start, but not very general Enter the FLANGE. A Flange is a mechanical device for joining two differing pipes or similar together. Our FLANGE uses channel access one end and writes EPICS data, and metadata such as enumeration type, connection state, update times, element count, data type, alarm severity, precision, engineering units and high/low operating range to a mySQL database Everything we do with the flange is from a parameter file It runs natively on windows, but is now in production under WINE It uses a subset of our GUI framework

The Database The Flange writes to a MySQL database It supports arbitrary amounts of historical data – often at lower resolutions than the EPICs archiver (we use the SNS maintained archiver) * It reads from an EPICS gateway (for the usual throttling security and load reasons) *

The Database The Flange writes to a MySQL database It supports arbitrary amounts of historical data – often at lower resolutions than the EPICs archiver (we use the SNS maintained archiver) * It reads from an EPICS gateway (for the usual throttling, security and load reasons) We have 1551 PV’s at the moment (We have tested up to 20,000) Including some very special functions  Historical backfill for Shutters with data for 8 days  Historical data for FSM graphs for 1 day  Specials for images and BMP to Jpegs conversions etc *

AJAX and Php We then access the MySQL database with AJAX (Asynchronous JavaScript and XML) to create web applications. What does it look like?

Web view of the Facility Status Monitor

Other things it can do - 1 We can pass anything through to MySQL – within limits Have tried 20,000 PV’s, but it takes a hit – so we have slightly “paralleled” it. Using a four core machine, we made it possible to run four instances of the FLANGE writing to a single SQL database and reading from a single Channel access archive and gateway. This spreads the load over the four cores and allows time lags to be introduced, thus spreading the load. Performance was very good on our web servers.

Other things it can do - 2 Image processing: It can take an array from EPICS waveform derived from a camera image and uses it to convert to a JPG to be stored in the SQL database This is how we get the beam image.

Other things it can do - 3 EDM to PHP applications We have a script that converts EDM screens to AJAX applications using the My-SQL database for data. It runs in multiple ways: It can run in real-time on the EDM directly, or can pre-process This allows many of our Scientists to monitor status from home

Converted EDM GUI from Protein Crystallography Beamline

Converted EDM GUI from the Linear Accelerator

Other things it can do - 4 Because we are using AJAX, we don’t have to be limited to ordinary web pages. For example we have mobile phone friendly pages (WML)

Database Schema for My SQL database

Web page generated from Scratch

Australian Synchrotron Thank you for your attention A paper is available with more information.

For more information and software: Richard Farnsworth Andrew Starritt ftp://ftp.synchrotron.org.au/pub/EPICS09/