Paper | Title | Other Keywords | Page |
---|---|---|---|
WEKA01 | The CSS Story | controls, EPICS, factory, cryogenics | 1 |
|
|||
Control System Studio (CSS) is designed to serve as an integration platform for engineering and operation of todays process controls as well as machine controls systems. Therefore CSS is not yet another replacement of existing operator interfaces (OPI) but a complete environment for the control room covering alarm management, archived data displays diagnostic tools and last not least operator interfaces. In addition we decided to use CSS as the platform for the whole engineering chain configuring EPICS based process control databases, configuring and managing the I/O, editing state notation programs, configuring role based access rights and many more. Due to the ease of use of CSS as an Eclipse based product, we decided to use the CSS core also for all our stand alone processes. This helped us to reduce the diversity of running products/ processes and simplified the management. In this presentation we will describe our experience with CSS over the last two years. How we managed the transition from old displays to new ones, how we changed our alarm/ message philosophy and last not least which lessons we learned. | |||
![]() |
Slides WEKA01 [2.926 MB] | ||
THCC02 | Controls Architecture for the Diagnostic Devices at the European XFEL | controls, diagnostics, monitoring, electron | 121 |
|
|||
The X-ray laser is an 3.4-km-long facility which runs essentially underground and comprises three sites above ground. For controlling all diagnostic devices like toroids, BPMs or BLMs, it is planned to use the new MTCA.4 crate standard instead of VME. ATCA is an emerging standard from the Telecom Industry and adapted with the PICMG MTCA.4 branch for physics usage. The communication on the backplane utilizes the high speed serial PCIe communication plus precise clock lines and SATA interface. The MTCA.4 hardware supports hot-plug mechanism and remote monitoring and control via IPMI over Ethernet. Some of the diagnostics will be connected to 16Bit ADCs with up to 125Mhz sampling rate from Struck company or to an internal DESY development call DAMC2. The software architecture is based on the DOOCS control system known from the FLASH accelerator. The raw data from the ADCs will be read via DMA transfer by one server process. Then this raw data will distributed locally on the CPU using a message passing system based on the ØMQ project. The receiving server processes are calculating these data into engineering units then. Everything works in an event driven way. | |||
![]() |
Slides THCC02 [2.499 MB] | ||
THPD06 | FLogbook: From Concept to Realization | controls, synchrotron, synchrotron-radiation, radiation | 148 |
|
|||
Indus-1 and Indus-2, the Synchrotron Radiation Source (SRS) facilities at RRCAT Indore are national facilities and being operated on round the clock basis to provide synchrotron radiations to users as well as carrying out machine studies. Both of these accelerators are widely distributed systems and employ many sub systems for their operation. These sub-systems are also made up of heterogeneous type of hardware and software modules. To keep the whole system up and running, the faults & failures encountered during machine operations are attended at site and all observations and rectifications information are to be recorded electronically by the crew members. FLogbook has been conceived and developed to meet such needs. This web based software operates in the Intranet environment over a three tier architecture. It mainly uses JavaServer Pages (JSP), JavaBeans and SQL databases for designing its building blocks. Using relational database, the package supports logging, e-mailing, searching & commenting the faults of various sub systems. This paper explains the salient features of FLogbook and also briefly describes the architectural design of the complete package. | |||
![]() |
Poster THPD06 [0.555 MB] | ||
THPD13 | SocketCAN Device Support for EPICS IOCs | EPICS, controls, diagnostics, status | 163 |
|
|||
Funding: Supported by DFG through CRC 634. A large number of devices used at the S-DALINAC are controlled by IOCs running on standard personal computers via CAN bus (Controller Area Network). CAN interface controllers for PCs are commercially available from different manufacturers but although they all share the same basic functionality, most of them have a vendor-specific API. Moreover, traditional CAN drivers can usually be accessed by only one process at a time which avoids the use of sniffer programs for debugging. In contrast to that the SocketCAN network stack [1], included in recent Linux kernels, provides access to the CAN bus via network devices (BSD sockets) which can be accessed by multiple applications at the same time via a vendor independent interface. A set of open source CAN drivers provides access to controllers of different vendors. This contribution describes an EPICS device support that makes use of the SocketCAN framework and thereby is independent from the API of a specific vendor. The device support has been used successfully in a production environment at the S-DALINAC since almost two years. [1] http://developer.berlios.de/projects/socketcan/ |
|||
![]() |
Poster THPD13 [1.748 MB] | ||