You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 44
Next »
LCLS Control Software Meeting Minutes, September 28, 2006
Contents
Unknown macro: {maketoc}
Attendees:
Arturo Alarcon |
Dayle Kotturi (absent) |
Debbie Rogind |
Diane Fairley |
Doug Murray |
Hamid Shoaee |
Kristi Luchini (absent) |
Mike Zelazny |
Sergei Chevtsov |
Sheng Peng |
Stephanie Allison (came late) |
Stephen Norum |
Stephen Schuh |
Steve Lewis |
Till Straumann |
Ron Chestnut |
Terri Lahey |
Jingchen Zhou |
Judy Rock |
|
|
Agenda:
- EPICS Display Screen discussion. Stephen Schuh and Stephen Norum will show some recent work and template for common OPI screens.
- Proposed EPICS installation changes for LCLS.
- A Discussion of the Software Build Environment.
Minutes:
- Stephen Schuh described recent work on some display templates done by himself and Stephen Norum.
- He showed a simple start up screen, containing one list of accelerator regions and another list of subsystems.
- The discussion started with comments relating to that screen. It was suggested that other lists be added, for high-level applications and other support tools.
- Stephen said that wouldn't be a problem, but this particular screen was created only to navigate to the templates.
- He went on to show an example of their template screen.
![](/download/attachments/96436343/EDMTemplateSample.png?version=1&modificationDate=1288209388000&api=v2)
- He pointed out that the header at the top of the window and the border surrounding the area in the center belonged to a common startup file for EDM.
- Subsystem-specific EDM files would fill the area in the center. The tabs, help buttons and other navigation aids are drawn by the initial file.
- Developers need merely set up their EDM files in a standard directory using the filename used by the startup file. He pointed out the expected filename is displayed on the lower right corner of the EDM window.
- He also suggested that we used the idea of including an ellipsis (...) on each button or widget that brings up another screen.
- There was some discussion about the practicality of graphic displays in the control room.
- Ron pointed out that operators currently get things done very quickly because of the consistent position of buttons on the SCP screens.
- Hamid agreed, and said their actions were similar to touch-typing. He suggested the nice graphics might "get old" quickly.
- Doug said that a previous meeting's discussion had indicated new operators could take up to a year to learn to use the existing control system. He said this would help that situation, and nothing was stopping other displays from containing more complex non-graphic screens for experienced users.
- Stephen Schuh also suggested that he, as a recent operator, could imagine a mix of graphic and textual screens to be useful, especially for specific tasks that aren't performed often.
- Steve Lewis said the idea of Tabs was an important addition to EDM that he thought would be very useful.
- There was a brief discussion about how tabs were quite common in most modern GUI environments.
- Steve insisted that a user-programmable tool like EDM was preferable to a general programming language.
- Doug suggested that a modern programming environment with EPICS support could provide a better environment for the user if done properly; tabs and other modern widgets would be inherently available.
- Ron suggested there was no merit in talking about developing a new EDM-type tool.
- Hamid agreed, and indicated there have been many versions of display managers for EPICS over the years, which have failed.
- The discussion then turned to some EDM-specific topics.
- We discussed aspects of colors. Stephen Norum said these colors were chosen to keep the screens simple, and make colors more pronounced. Few colors were used; most of the major elements are grey.
- There were questions about new colors being put in the colors.list file.
- Doug mentioned that updating and managing the colors.list file was cumbersome because of the file format. Also, current colors are specified as 16-bit values for each of the RGB channels, and were currently written as decimal values rather than hex.
- Steve Lewis said that when the colors were originally created, he used a separate tool to create them. Doug said that would probably be the best idea for creating our own color scheme, if we wanted to do so.
- Ron mentioned that some forethought and care must be taken in setting up alarm and severity colors for EDM calc records and color rules.
- Judy said that she had recently been working on adjusting some of the custom color rules for PEP, and agreed that it requires more overall design work up front.
- Ron said the PEP rules might be too complex for our needs.
- Steve suggested that these rules might be better designed into the database. All clients would then benefit, not just the local EDM clients using those rules.
- Ron said it was a design decision that would have to be made.
- Sheng said he has previously used gencalc or calcout records and made those decisions in the database.
- We agreed to try and limit the determination of severity and alarm rules to the database whenever possible.
- We then discussed some proposed changes to the EPICS installation layout for our development work.
- Doug presented 3 issues of concern in the current build environment.
- One cannot access individual packages under site if one has a local copy of a different site package.
- Updates to new versions of EPICS can be cumbersome.
- We don't keep adequate version information on-line.
- Doug suggested a change to the RELEASE file in each package would fix the first problem.
- Jingchen said he had developed a workaround to the problem.
- Doug recommended the underlying problem be fixed, but was interested to see the workaround.
- He said that Stephanie had suggested (and started to implement) a common include file that would define the basic environment variables.
- Sheng said he was concerned that he wouldn't be able to override those variables or do other custom changes.
- Doug said that the environment variables would be defined in a single location, but could be done only if they haven't already been set.
- There was discussion regarding the version information. It was suggested that one or two versions of each package be kept on-line.
- Under the package area would be another subdirectory showing the version number. These would be checked out of the repository using the appropriate tags for CVS.
- Till argued that this would present problems when a package changed; one application might require the update, but another application destined for the same IOC might not be able to upgrade.
- Sheng said that the issue could be resolved by having the second application upgrade to the new version.
- Sheng also asked why only 1 or 2 previous versions would be maintained. It was suggested that it would be easier to maintain.
- The discussion then turned to the build strategy for the operations network.
- A recent exchange of e-mail had prompted a discussion of static versus dynamic linking of applications.
- Jingchen suggested it would be easier to maintain application servers on the production network if the applications were statically linked.
- It was pointed out that these specific production servers should be kept at the same version of OS and development tools as the development server.
- Steve mentioned that many other EPICS sites have a dedicated build server. An export of the repository would be done to a local disk on that machine, and applications built there.
- Jingchen pointed out that this was not how builds are currently done, and that builds are not typically allowed on production servers.
- It was pointed out that the build server, although on a production network, would not be running any controls application software directly. It could be used exclusively for building and as a boot server.
- Ron pointed out that keeping proper OS and tool versions on a build server and using dynamically linked libraries represents a large maintenance workload.
- Terri mentioned that we could piggyback off SCCS, which uses external vendors to build and maintain software packages.
- It was pointed out that there are a relatively small number of packages used by the EPICS software.
- Jingchen mentioned that we would need to keep a very large number of packages up-to-date. There is a very large number of packages that would be added to the Perl tool alone.
- Jingchen also mentioned that sharing everything via NFS would be preferable, to reduce the amount of maintenance work.
- Steve suggested that using rdist is a good option; it will synchronize files on different machines to keep them up to date. It's reliable, and is used at a lot of Labs.
- There was a question about having all libraries and tools on a single file server, which could represent a single point of failure in a running environment.
- Jingchen pointed out that the NFS services couldn't fail because we have redundant servers.
- It was suggested that a build server be investigated further, although there was not a clear consensus that this is the correct solution.