(Original Author: Diane Fairley)

This page is a working area for the High Level Applications Development for LCLS. It contains an overview of issues to be resolved, and a list of questions and concerns to be addressed in the planning stages for LCLS physics applications development. Decisions made, as well as supporting information, will be recorded here as planning progresses.

Still need research into:

Can and should we provide SLC History Data to LCLS? Effort Reqd?
Can and should we provide SLC model data to LCLS? Effort Reqd?
Making the XAL online model work for LCLS. Effort Reqd?
Making existing SNS XAL Applications work for LCLS. Effort Reqd?
Can and should we use Matlab, SSRL toolbox? Effort Reqd?
List of New applications we need to develop.
Priority order for all development - from Patrick once we have enough details from above

I would like to make infrastructure recommendations to Patrick on:

What is the accepted set of application development tools for LCLS?
Where will shared applications and files be stored?
Will LCLS support applications run on local desktop?
What application delivery/update method will be used by LCLS?

GENERAL TOPICS and DETAILED QUESTIONS:

  1. What are the interfaces to the High Level Applications?
    1. Real time interface
      1. Data acquisition (BPMs, GADCs) provided by
        1. Channel Access,
        2. Java Channel Access,
        3. SCP via slc-aware IOC (BPMS, GADCs, toroids only, no wire scan data from SLC)
        4. (Greg) Aida will also do BPMs.
      2. Real-time Control, Setpoints, access via:
        1. Channel access,
        2. Java channel access
        3. SCP via Slc-aware IOC (BPMs, GADCs, toroids, magnets only - wire scanning not done by SLC)
        4. (Greg)Aida will also do magnets.
        5. (Steph) may want to add (limited to CAMAC-controlled) magnet control via SLCCAS as well.
          1. be sure that SLCCAS communications from XAL CA clients goes through a CA Gateway to limit client connections to SLC
    2. History Data from archives
      1. EPICS archives
        1. available through the EPICS channel archiver
          1. retrieval speed issues with the archiver - XAL PVLogger has been used by SNS as an alternative
      2. SLC History
        1. Is it useful to new applications?
          1. is there data that only SLC stores? RF? Patrick/Ron/Greg?
        2. Is it available to new applications?
          1. Aida? What effort required? Greg? (Greg: no effort, Aida already can retrieve both SLC and Archiver history data).
          2. (Steph)Change SLCCAS to store SLC-only data to Epics archiver
    3. Online Model
      1. XAL
        1. how it works with Hi Level Apps See Paul Chu's talk - need an SNS contact?
        2. Needs additional elements: solenoid, acceleration, anything else?
        3. Any other development required to make it work for LCLS? (Greg: see comment)
      2. SLC - TBD Mark Woodley January?
        1. Can SLC model outputs be made available to new applications? Aida? Greg/Ron C.? (Greg: SLC model data is now available to new applications anywhere through Aida - already done).
          1. is this useful? (Greg: I think so, since we're going to be dependent on SLC modeling apps in the short term, including commissioning I think, LCLS operations are going to at the very least want to construct ad-hoc analysis in matlab using the model the machine is being optimized with. So they'll need to access the SLC model through matlab which on unix - Aida now provides this access). I'd say this at least is completely done and can be reliably integrated into LCLS's commissioning planning).
          2. how much effort reqd? (Greg: For SLC model access itself, none).
  1. What are the existing Applications?
    1. Existing SNS applications
      1. What has already been developed? - See Paul Chu's talk
      2. Wire scans, profile monitors and emittance applications are not supported by SLC, does XAL have emittance apps?
        1. (Patrick)IOCs will conduct wire scans, collect images from profile monitors (epics only)
        2. (Patrick)IOCs will calculate size/error (from wire scan data / images) and provide size/error data via PVs
      3. Assume SNS apps run on all platforms (java)
      4. Are they useful for LCLS?
      5. How much effort reqd to make them useful?
      6. How does SNS deliver updates/new versions?
    2. Matlab
      1. See SSRL accelerator toolbox - get a demo from SSRL, Greg coordinate?
        1. is it applicable to LCLS?
        2. what applications can we use?
        3. how much effort reqd to make them useful?
      2. Will we have new applications developed on Matlab entirely?
      3. How does SSRL use Matlab
        1. Run on local desktop? Via xterm from shared space?
          1. (Steph)SSRL uses Matlab locally on Windows only and shares source and data on windows network drives
          2. (Steph)the SSRL toolbox may have been ported to Linux- contact: Greg Portman LBL/ALS
        2. How is SSRL toolbox maintained? shared? Updated?
        3. all sources / data shared on network drives, no CVS
    3. SCP applications
      1. Anything using model and BPM.TORO, GADC data.
      2. No wire scans, profile monitors or related emittance apps are available from SLC
      3. Available as a backup
    4. New Java development
      1. Which apps require fully new development?
  1. Application Development Tools
    1. What's available
      1. Eclipse
        1. GRAPHICAL gui builder - couldn't find one for eclipse, is there one?
      2. JBuilder?- has a GRAPHICAL gui builder
        1. can it import/use Eclipse libraries?
      3. Matlab
      4. Good ole emacs or vi
    2. SWT/JFace vs AWT/Swing
      1. Which way will industry go?
      2. Epics community now using Eclipse with Epics Office
      3. Non-trivial effort to translate AWT/Swing to SWT/JFace (Viji)
      4. Ask XAL guys if interested in having a SWT/Jface version of XAL
  1. LCLS Infrastructure
    1. What platforms do we support for running high level apps?
    2. Do we support running apps from the local desktop?
      1. Linux
      2. Mac
      3. Windows??
    3. If so, how do we deliver updates and new versions
    4. Main Window - Application Launcher - need to modernize
      1. Epics not great - too many windows piled on screen,
      2. SCP is better, but can be hard to navigate
      3. What does XAL provide
        1. simple main window with drop-down menu
        2. Any version update delivery support?
      4. What does Eclipse provide?
        1. Application View can be created?
        2. delivery solution?
          1. Has it actually been tried with a SLAC application - can we prototype/demo it? Greg
    5. Networks, Shared space, and Security
      1. Storing shared applications
      2. Shared Access to XAL xml files
      3. Don't even know what to ask, Steph????
      4. (Steph input from here)
      5. Will we need to keep XAL and Matlab apps developed by people outside the controls group under CVS control?
      6. Data files written by XAL and Matlab apps will need to be kept on shared drives and will need backup. How much space?
      7. Data files written on private network will need to be made available (read-only) to SLAC public side
      8. We will want to run some XAL nad Matlab apps (that do no control) on the SLAC public side using files from the private side (XML, data, what else?) plus read-only access to production PVs through the public CA gateway.
      9. Some XAL, and possibly Matlab scripts, will need to run standalone. That is, they start at server bootup time and stay up. We will need the ability to restart these and to add new ondes to the autostartup list.
      10. Will need access to printer queues around SLAC for XAL and Matlab printout requests. Is there a way to pre-define printers for the user to choose?
      11. How many Matlab licenses will we need to get? What Matlab features do we need? Who buys and installs Matlab?
      12. We need to install Till's LavCA package in lcls/epics/extensions
    6. Web servers
      1. doesn't the epics java archiver need one?
      2. Does SNS use java webstart for delivery of applications?
      3. Could LCLS?
  • No labels

6 Comments

  1. Greg White

    Re 1.2.2.1 In general history is only useful to the history browser application.

  2. Greg White

    I talked to Tom Pelaia on Friday, he said he looked into converting XAL to SWT/JFace when I mentioned it to him last summer. He concluded it would not be big deal, XAL makes a clean MVC separation, and I got the impression he was pretty keen, but he emphasised that he can't right now because they need more models and apps at SNS.

    I also talked to Andy Goetz. He's keen to collaborate on apps based on the Eclipse Rich Client Platform (RPC).

    My feeling after looking at XAL code is that in general whichever we do, XAL as it is, or XAL integrated into SWT/Jface (only) or fully integrated into Eclipse's RPC, we will need programmers willing to undertake GUI MVC programming in a significant way.

  3. Greg White

    > (Steph) An alternative to using the SLC history data is to make sure every data
    > point that LCLS needs from the old SLC control system is available to
    > LCLS via the SLC CA server (SLCCAS on MCC) so that it is stored in the
    > EPICS archive.
    >
    > If there is data that only SLC stores and it's not available via SLCCAS,
    > then we should consider changing SLCCAS to provide it.
    Bear in mind that Aida already gets all SLC and EPICS archiver history
    seamlessly (you don't have to know which it came from), so I reckon a
    simpler addition would be to the archive browser to access SLC history
    through Aida. I'd like to see effort spent in making the archive browser
    more responsive too, it's really pretty awful when run from Solaris onto the
    Linux desktop (by which I mean completely unusable). It's better if run on
    the linux desktop itself - in which case it's usable but not great.

  4. Greg White

    > (Steph) It's also possible to change SLCCAS so that it can do limited control
    > (ie, trim of CAMAC-controlled magnets), in addition to providing
    > readbacks. This is important when we want to use XAL steering in the
    > LINAC where some magnets are still CAMAC-controlled.
    I'm also adding magnet control to Aida at PEP accelerator physics request
    now. This has the advantage that it will coordinate and synchronize magnet
    control when a number are involved. That is very important for bumps, where
    you can't have one magnet go to its setpoint unsynchronized with another
    because then the beam would see a non-closed bump. Having said that, it's
    probably a good idea to add camac controlled magnets to SLCCAS too.

  5. Diane Fairley

    Further comments by Stephanie:

    somewhat-related items:
    Will any XAL or Matlab app send messages to cmlog? Sure would be nice
    Will any XAL or Matlab app send messages to elog?
    Is there a way for users to save their current XAL setup so they can go back to pre-defined menu options, etc, later on?

    1. Greg White

      The Err facility, which we wrote for Aida, allows any C++, matlab, or Java app to send messages to cmlog. in matlab its as simple as this:

      Err err = Err("my matlab app"); % instantiate an Err object

      err.log('hi there');

      The Err facility also allows you to defined messages, like in VMS. Eg

      err.log(UnableToProcess('thing I can not process'),'when thinking');