# Presentation: 823415

## synApps status and plans

*Tim Mooney*
*Beamline Controls & Data Acquisition Group*
*June 13, 2006*

## What is synApps?

- EPICS-based software for use at synchrotron beamlines
- Commissioning-level software for ~80% of a new beamline
- Basic support for common beamline devices
- Support for higher level, beamline-specific applications
- Code libraries, implementation tools, examples
- Run-time tools to help users meet unanticipated needs
- Can build software machines, feedback loops, serial support
- Support for collaborative development of beamline software
- A vehicle by which developers at one beamline can easily contribute to software running on other beamlines.
- On the web:
- www.aps.anl.gov/aod/bcda/synApps

## ...What is synApps?

- A collection of EPICS **App**lication**s **for** **use at** ****syn**chrotron beamlines
- Tools for translating user requirements into running code:
**USER**: “*I need 40 motors, two scaler banks, an MCA, a monochromator, two optical tables, four current preamplifiers, 8 serial ports, four DAC channels, three slits, a mirror, run-time calcs, scans, ..*.”
**DEVELOPER**: edit startup files to configure hardware and load databases

## Scope

- Mostly infrastructure and generic capabilities, as opposed to experiment/technique-specific programs
- E.g., things like motors, scalers, and scans, as opposed to things like EXAFS, small-angle scattering, and protein crystallography
- Why?
***Economics**** – Generic has the wider audience*
***Information & expertise**** – beamline developers have it; we don’t.*
***Control**** – Generic software allows us to contribute to user software without taking control.*
- Mostly IOC-resident code, as opposed to client-side programs
- E.g., scan software could run on workstations, but instead it runs on IOC’s
- Why?
*Access/coordination – IOC-resident code can be driven by anyone; clients generally cannot be driven by other clients.*
*Distribution/deployment – EPICS handles this for ioc-resident code.*

## ...Scope

- Some statistics:
- 19 EPICS modules
*autosave, calc, camac, ccd, dac128V, dxp, ebrick, ip, ip330, ipUnidig, love, mca, motor, optics, quadem, sscan, std, vme, xxx*
- 16 record types
*aCalcout, sCalcout, swait, transform, camac, dxp, motor, mca, table, busy, sscan, scanParm, epid, scaler, sseq, vme*
- ~156 device types (~118 hard, ~38 soft)
- ~197 EPICS databases
- ~458 MEDM display files
- ~526 c, c++, SNL source files (~281,000 lines of code)
- ~77 documentation files (~38,000 lines of documentation)

## Architecture

- Same as any other EPICS Application
- Client side
- runs on Solaris, Linux, Windows
- interfaces to C, C++, java, IDL, Python, tcl, ...
- Server side
- runs on vxWorks, Linux, Windows, Solaris
- can develop in C, C++, SNL

**transient**

**tool**

**Default**

**GUI**

**CA server interface**

**Driver**

**Driver**

**Driver**

**Driver**

**spec**

**CA client interface**

## How is synApps used?

- Copy xxx module, edit to fit beamline, boot crate
- Excerpt from xxx-module’s st.cmd file:

- dbLoadDatabase("../../dbd/iocxxx.dbd")
*...*
*# *Motors
- dbLoadTemplate("motor.substitutions")
- ...
- # Slits
- dbLoadRecords("$(OPTICS)/opticsApp/Db/2slit.db","P=xxx:,SLIT=Slit1V,mXp=m3,mXn=m4")
- dbLoadRecords("$(OPTICS)/opticsApp/Db/2slit.db","P=xxx:,SLIT=Slit1H,mXp=m5,mXn=m6")
- ...
- # Monochromator
- dbLoadRecords("$(OPTICS)/opticsApp/Db/kohzuSeq.db","P=xxx:,M_THETA=m9,M_Y=m10,
-         M_Z=m11,yOffLo=4,yOffHi=36")
- ...
- iocInit
- ...
- ### startup State Notation Language programs
- seq &kohzuCtl, "P=xxx:, M_THETA=m9, M_Y=m10, M_Z=m11, GEOM=1, logfile=kohzuCtl.log“

## Sample user displays

## synApps modules

| mca | multichannel analyzers and multichannel scalers |
| --- | --- |
| motor | stepper/servo motor |
| optics | monochromators, optical table, etc. |
| quadEM | four-channel fast analog input |
| sscan | scans, data storage |
| std | scalers, feedback, misc. |
| vme | VME hardware |
| xxx | runnable example of how everything in synApps is configured & used; typically controls a single experiment station |

| autosave | parameter save/restore; maintains continuity through reboot |
| --- | --- |
| calc | run-time expression evaluation |
| camac | CAMAC support |
| ccd | CCD support |
| dxp | XIA DSP-based x-ray detector pulse analyzer |
| ebrick
love | EPICS-brick application
Love controllers (digital and analog I/O via serial) |
| Ip*, dac*

 | Serial, analog, and digital I/O |

## Who uses synApps?

- Synchrotron beamlines
- ~20 sectors of APS
- Swiss Light Source
- NSLS (several beamlines)
- Diamond
- Australian Synchrotron
- CLS, LCLS ?
- Other EPICS sites
- Many non-synchrotron sites use a few synApps modules, notably
*motor*
*autosave*
*calc*

## Content of a synApps module

- Source code
- EPICS records
- EPICS device/driver support
- EPICS databases
- SNL and other code
- autosave-request files
- Database author figures out how to survive reboot
- MEDM-display files
- The default user-interface tool
- Documentation
- Some modules contain runnable examples

## synApps depends on software written by others

| Module | Developer Org. | Purpose |
| --- | --- | --- |
| asyn | APS Controls  & CARS-CAT | support for asynchronous message-based control |
| ipac | APS Controls | IndustryPack carrier support |
| seq | SLAC | State-Notation-Language compiler |
| genSub | Observatory Sciences | General-purpose subroutine record |
| vxStats | SNS/ORNL | vxWorks status/statistics |
| allenBradley | APS Controls | support for communicating with Allen-Bradley PLC’s |

- synApps also uses (“*contains”*? “*second sources”*?) some software written by others that is not in the form of a module
- The idea is to avoid requiring synApps users to find, configure and test software that someone else has already found, configured, and tested.

## autosave module

- Records values of selected EPICS Process Variables -- periodically, or in response to user-specified trigger
- Restores saved values when the computer restarts
- Can save/restore any scalar or array-valued PV
- Developer chooses default PV’s to be saved; user can override
- Defends saved values from incompetent file server, crash, etc.
- Recent work:
- v4.1.3 (synApps 5.2 candidate)
- reduce sensitivity to errors
- status-PV name length fixed
- Plans:
- no immediate plans

## calc module

- Evaluate expressions entered at run time
- Records
**sCalcout** – like calcout, but also supports string expressions; user can specify wait-for-completion.
**aCalcout** – like sCalcout, but for arrays instead of strings;
**swait** – like calcout, but uses recDynLink (no “PP MS” link attributes)
**transform** – like 16 calcout records that share a PV data pool
- Other code
- string/array-calc engines
- sCalcout soft device support (with wait-for-completion option)
- interpolation (lookup table), based on the genSub record

## ...calc module

- Recent work:
- v2.6.1 (synAps 5.2 candidate)
- array calc
- ESC(), TR_ESC() added to sCalc
- sCalcout record uses device support (for streamDevice)
- interp array (lookup table) modifiable via PV’s at run time
- expression help in MEDM displays
- Plans:
- Copy Andrew Johnson’s store-to-variable enhancement of the standard calc engine to string/array-calc engines.** **
- enhance aCalc with new operators/functions as needed
- Get rid of swait-record’s dependence on recDynLink

## ...calc module

- Databases, medm displays for run-time programming
- userCalc,
- userStringCalc
- userArrayCalc
- userTransform
- userAve
- lookup table

## ip module

- Originally, all IndustryPack modules
- Now, only support for message-based devices
- device support, SNL code, databases, and MEDM displays for message-based devices
- digital multimeters, current preamplifiers, temperature controllers, etc.
- deviceCmdReply
- Used to write support at run time for one command/reply message
- sCalcout to format output string
- asyn record to write/read device
- sCalcout record to parse reply
- handles messages with embedded nulls, selected checksums
- devXxStrParm device support
- to be replaced by streamDevice/asyn

## ...ip module

- Recent work:
- v2.6 (synApps 5.2 candidate)
- SR630 thermocouple scanner
- Pelco CM6700 video switch
- Plans:
- New module manager (Kurt Goetze)
- integrate streamDevice
*as new module? (not currently in module form)*
*as code within ip?*

## optics module

- Slits and mirrors
- Monochromators
- Nondispersive double-crystal
- Dispersive double crystal
- Spherical Grating
- Optical table
- Orientation matrix
- (H, K, L)     (2,,,) + constraint
- User/client can write to underlying motors
- Automated alignment for zone-plate microscope

## ...optics module

- Recent work:
- v2.5 (synApps 5.2 candidate)
- Orientation matrix
- Automated microscope alignment
- Added ionization-chamber calibration support
- Plans:
- Include SLS support for plane grating monochromator?
- general purpose alignment tools

## sscan module

- Support for user-programmable data-acquisition
**sscan** and **busy** records
- saveData
- recDynLink
- Recent work:
- number of data points limited only by IOC memory
- pipelined data storage
- can mix scalar and array detectors
- fixed some link-management bugs
- added Python code to read, write, and operate on scan-data files
- Include Dohn Arms’ (APS/XOR-7) C-code utilities for scan-data files
- Plans:
- Support 2D-array detectors

## std module

- Epid record
- Extended PID record
- Scaler record
- Controls a set of counters with a common clock, gate, and trigger
- String-sequence record (i.e., ‘seq’ for strings or numbers)
- Can choose to wait for completion after each step in sequence
- Soft-motor database
- Run-time programmable soft-motor/transform/hard-motor database
- Quick solution for driving a motor through a nonlinear transform
- Timestamp record [stolen from Stephanie Allison @ SLAC]
- needed by SNS’ vxStats; currently not available in a module
- 4-step database
- Up to four steps of (set condition; read data) with an end calculation
- Originally developed for dichroism experiments

## ...std module

- Recent work
- v2.5.2 (synApps 5.2 candidate)
- pvHistory – short-term history of PV
- String-sequence record: fixed link-management bug
- Plans:
- Convert scaler record to use asyn-based device support

## xxx module

- Prototype user directory (i.e., **deployable menu** of synApps software)
- Builds everything in synApps into a load module
- Contains command files to load/configure everything in synApps
- Contains sample top-level MEDM-display file
- Contains sample script to start up the user interface
- Contains table of recommended address/interrupt configuration.
- Recent work:
- load/config examples for new devices
- Plans:
- more support for converting applications to new version of synApps

## other directories

- Top-level documentation directory
- How to build and deploy synApps
- config directory
- Configures and builds all modules in or used by synApps
- MASTER_RELEASE – specifies all module versions
- utils directory
- changePrefix -- Global search and replace of EPICS PV prefix within a copy of the xxx module
- copyAdl -- Find all MEDM-display files buried in a file tree; copy to specified directory