LCLS Control Software Meeting Minutes, September 7, 2006

Attendees:

Agenda:

• The goal of this meeting is to understand what the users expect to see in the Control Room for commissioning later this year, and also in the longer term. The agenda addressed several points:
  • A Startup Screen; will there be one? Who can do it, what will it provide?
  • Standards for screen layouts.
    • Will MATLab, XAL, EDM and all other screens types adhere?
  • Standard colours.
  • Types of users.
    • User access control from EPICS.
  • How can we provide Knob access?

Minutes:

1. The first issue of a startup screen was discussed.
   1. It was agreed that a common startup screen for EDM based displays would be best.
   2. Patrick mentioned that EDM displays could be started from the existing SCP displays, which would be useful since they will also be heavily used.
   3. Till said that operators often add their own screens, and having a launch screen with the ability to add single buttons for new displays might be useful. Steve Lewis agreed.
   4. Till also suggested that in light of the schedule crunch, it might be useful to let the operators help out in that respect.
   5. It was generally agreed that we should offer something, even as a starting point for operators.
   6. He also suggested that a Graphic Designer might be hired to do some of this work.
   7. The question was raised about the type of display; should it be a graphical or textual interface. Patrick suggested a graphical interface would be best, and there was general agreement.
2. The discussion turned to address standard screen layouts and components.
   1. Some sample screens were presented as a starting point for the discussion.
   2. It was agreed that some standard buttons be maintained, such as DONE, HELP or PRINT. It was also pointed out that a DONE button might be of limited value since most X11 window managers supply a Close button on the top window bar.
   3. The samples also contained some "tabs" at the top, which allow switching to similar displays, such as LINAC Sector maps or related subsystem diagrams. It was pointed out that these Tabs were simply parts of an underlying image, over which invisible buttons had been placed.
   4. Stephen Norum pointed out that this effect could also have been done using real buttons. Doug felt that the tab images looked more professional.
   5. Diane suggested that a Java based program might be used, since it directly allows Tabs and other GUI control elements to be used. Steve mentioned that having a generic software tool which allows data sources to be redefined dynamically is more important in a working Control System environment.
   6. Mike Stanek and Patrick noted that there was no indication of delays when a button was pressed, such as an hourglass cursor. Doug said it was because of the software delays came from network latency over the wireless network and proxy connections.
   7. Paul mentioned that numeric values on the displays should have engineering units of measure whenever possible.
   8. It was suggested that the sample screens be made available as a template for other screens.
   9. Stephen Schuh, Arturo and Stephanie had some important comments about existing SLAC Control Room screens:
      1. They have the Application title on the top left corner of the Window frame.
      2. The HELP and PRINT buttons are on the top right of the screen.
      3. He suggested that better navigation controls be implemented. For instance, there is a "return to top" button available for all windows, regardless of where they exist in the hierarchy.
      4. The PRINT button, although common to most applications is quite problematic.
      5. It was also mentioned that while certain colours are intended to show a communication problem (typically, white), there should be colours set aside to indicate other problems. Stephanie has successfully used Magenta as an indicator of device-specific problems on other projects.
   10. Mike Zelazny said there are alternatives to EDM for control system client software. Platforms such as XAL, MATLab and others were mentioned, but it was agreed that there was no time to change all applications, regardless of the development tool, to a common look for the commissioning schedule.
   11. There was some discussion about the need for hierarchical displays of both geographic (i.e. map style diagrams) and functional (i.e. subsystem oriented diagrams relating to RF, Vacuum, Magnets, etc) access. Maps of the accelerator areas and maps of accelerator functions are typically found to be useful.
   12. Mike also pointed out that all software, even those intended for technicians and field engineers, should be made available in the control room.
       1. He also pointed out that the operators usually work in low light conditions in the control room.
       2. Stephanie wondered if the simple white screens shown as examples might be too bright in the subdued environment.
3. We then discussed aspects of User identification and security.
   1. It was pointed out that two different mechanisms exist for user access; the EPICS database fields but also an internal Channel Access facility.
   2. Mike Stanek mentioned that access restrictions are seldom used. There was an example of an internal klystron setting, which is typically locked, but most other elements were openly available.
   3. Arturo said that the MPS would have secure access implemented in EPICS records.
   4. Mike asked if gateways would honor the access features for EPICS records. Steve confirmed that they could.
   5. We discussed the need for group accounts as opposed to individual accounts for operator access.
      1. Mike Stanek said that it might be useful to have an expert mode with a password access for other specific purposes. For instance, there is typically no need for an operator to change calibration limits on most devices.
      2. Steve suggested we start with a minimal set of elements having access restrictions. There should always be some mechanism to bypass the restrictions.
      3. Mike also pointed out that it is preferable to have some kind of group account for accelerator control. An operator might be working on a particular study which will take many hours to complete, and will not want to log off the system while it runs.
      4. Kristi pointed out that it might be difficult to implement a system using group accounts in the current security environment.
   6. Steve Lewis spoke about the use of coloured backgrounds to indicate different subsystem control screens (i.e. vacuum, RF, magnets, etc.) versus different levels of user expertise.
   7. There was some concern about having background colour indicate subsystem usage, and it was suggested that a simple gray colour with minimal colouring of control elements be investigated.
4. The last agenda topic was relating to Knobs, or dynamically assignable dials, which can be assigned to arbitrary controllable elements to effect changes.
   1. It was agreed that such Knob controls are useful.
   2. Patrick said that EPICS PVs are "knobable" from the SCP based systems today.
   3. Stephanie said this shouldn't be a problem for our PVs, as long as we adhere to some minor constraints, as described in the current Naming Scheme. Also, the new EPICS feature of having more than 4 character field names within a record is not supported. It was felt not to be a problem.
5. One final point of concern was that there might not be outside Internet access from the private IOC control network. There are plans for such access from the "DMZ" area, where the operator displays and servers reside.