| Paper |
Title |
Page |
| MOD001 |
A Generic Finite State Machine Framework for the ACNET Control System
|
28 |
| |
- L. R. Carmichael, A. Warner
Fermilab, Batavia
|
|
| |
A significant level of automation and flexibility has been added to the ACNET control system through the development of a Java-based Finite State Machine (FSM) infrastructure. These FSMs are integrated into ACNET and allow users to easily build, test and execute scripts that have full access to ACNET's functionality. In this paper, a description will be given of the FSM design and its ties to the Java-based Data Acquisition Engine (DAE) framework. Each FSM is part of a client-server model with FSM display clients using Remote Method Invocation (RMI) to communicate with DAE servers heavily coupled to ACNET. A web-based monitoring system that allows users to utilize browsers to observe persistent FSMs will also be discussed. Finally, some key implementations such as the crash recovery FSM developed for the Electron Cooling machine protection system will be presented.
|
|
|
Slides
|
|
| MOD002 |
TINE Release 4.1: Responding to the User's Needs
|
31 |
| |
- P. Duval, P. K. Bartkiewicz, S. W. Herb, M. Lomperski
DESY, Hamburg
- S. Weisse
DESY Zeuthen, Zeuthen
|
|
| |
In the period between the shutdown of the HERA collider and the commissioning of the PETRA 3 synchrotron light source the TINE* control system was upgraded and modernized to the next major release level, namely 4.0. Many of the new features and capabilities have been reported before**. As can be expected, when what was 'designed and planned' is actually put to use, various imperfections and deficiencies begin to surface, the natural 'enemy' of the developer being the 'user'. To this end there has been a slow and iterative progression toward TINE Release 4.1 which will be reported on here. Many of the embellishments involve improving data transfer efficiency (such as enforcing the use of multi-channel arrays even when the user makes single channel calls) or meeting the user's expectations of what should be possible (such as allowing variable-length TINE data types to appear within TINE data structures). In addition, TINE Central services have been more systematically integrated into the protocol.
|
|
|
|
Slides
|
|
| MOD003 |
TINE Video System: Proceedings on Redesign
|
34 |
| |
- S. Weisse, D. Melkumyan
DESY Zeuthen, Zeuthen
- P. Duval
DESY, Hamburg
|
|
| |
Funding: <have to find this out, will be filled in later>
Experience has shown that imaging software and hardware installations at accelerator facilities needs to be changed, adapted and updated on a semi-permanent basis. The past TINE-based Video System*, initiated at PITZ**, has undergone a thorough redesign after years of operation and upgrading in order to extend interoperability and cope with new challenges while still staying flexible. Emphasis was placed on flexibility, avoiding redundancies, good documentation, component-based architecture, multi-platform capability and ease of use as well as reuse. This contribution will show the current status of the redesign as well as the near and far future outlook. The main focus is put on the Java-based TINE ACOP Video Bean and its integration into jDDD and COMA, PNG file format support, core applications and services as well as universal slow control for cameras. Moreover, the Video System acts as a basis for advanced high-level software applications such as semiautomatic Emittance Measurement Wizard (EMWiz). Although the outlined Video System implementation is integrated into TINE control system***, it is modular enough so that integration into other control systems can be considered.
* S. Weisse et al., "Status of a versatile Video System at PITZ, DESY-2 and EMBL Hamburg", ICALEPCS 2007, Knoxville, TN, USA
** http://pitz.desy.de
*** http://tine.desy.de
|
|
|
|
Slides
|
|
| MOD004 |
Evolution of the FLASH DAQ System
|
37 |
| |
- T. Wilksen, A. Agababyan, G. Grygiel, O. Hensler, R. Kammering, V. Kocharyan, L. M. Petrosyan, K. Rehlich, V. Rybnikov
DESY, Hamburg
|
|
| |
The Data Acquisition System at the Free-Electron-Laser Hamburg (FLASH) has evolved since its implementation in 2005 into a reliable and versatile system used for accelerator operations and studies along with a multitude of different photon experiment users, recording about 14 TB in 2008 for experiments only. Recently the DAQ system has been successfully upgraded with new hardware to accommodate increasing demands of beamline experiments, upcoming R&D work at FLASH i.e. for the ILC, and to prepare for the upgrade of the FLASH facility this year. The design of the FLASH DAQ is based on a very scalable and extensible concept, recording all available data, processing and archiving it as well as providing an interface for the user to analyze their measurements. Several instances of the same DAQ system have been installed now in parallel to the existing ones to allow for a flexible and redundant configuration, adjusted to the needs of the different user communities. This paper describes the evolution of and experiences with the FLASH DAQ and highlights the key elements of its design to facilitate an expandable yet easily to duplicate system implementation.
|
|
|
|
Slides
|
|
| MOD005 |
Evolution of the EPICS Channel Access Protocol
|
40 |
| |
- K. Zagar, M. Sekoranja
Cosylab, Ljubljana
- L. R. Dalesio
BNL, Upton, Long Island, New York
- M. R. Kraimer
ANL, Argonne
|
|
| |
Experimental Physics and Industrial Control System (EPICS) is one of the most widely deployed control system infrastructures in large experimental physics community. At EPICS' foundation are 1) the real-time process database, which allows integrators to build the control system from reusable building blocks (e.g., device drivers) into a coherent whole without much coding or other kind of development, and 2) the Channel Access protocol, which allows the database to be distributed across several computers in a scalable way. In this contribution, we describe the objectives of the next major EPICS release (v4). In particular, we focus on the improvements of the Channel Access protocol that will allow it to support additional functionality, such as structured process variable data (pvData) and client-specified filters. We also describe how this functionality is implemented while simultaneously further improving the Channel Access' performance (no-copy get, flow control improvements, beacon traffic reduction, zero-length queues, etc.). We also discuss potential for future improvements, such as use of IP multicast and a layer for implementing remote-procedure call style of communication.
|
|
|
|
Slides
|
|
| MOD006 |
Migrating Control Servers and Applications to Virtual Machines
|
43 |
| |
- G. Wright, C. Angel, C. Finlay, E. Matias
CLS, Saskatoon, Saskatchewan
|
|
| |
At the Canadian Light Source, there are an ever-increasing number of distributed Controls applications that can run on generic networked computers. This has led to additional servers when segregation by operating system or by LAN has been required. Additional concerns of maintenance of older computer hardware, driver support for older O/S's on new hardware, and growing Virtual LAN issues have led to an adoption of moving applications to Virtual Machines. Our implementation using VMware Infrastructure provides a high reliability environment, with centralized monitoring of performance and simplified expandability. The distributed 'average' reliability hardware has been replaced by a single high-reliability system with built-in redundancies. A new virtual machine can be started in a matter of minutes from an existing pre-configured template, and can be joined to up to four VLANs with a simple software configuration.
|
|
|
|
Slides
|
|