The Insertion Device Control System of BESSY II

Götz Pfeiffer

     Table of Contents

   1. Introduction    1

   2. Overview over major components of IDCS    3

   3. External Interfaces    5

   4. Internal Interfaces    6

   5. Existing Software-Components used by IDCS    6

   6. Design-Outline of the IDCS software components    10

  1   Introduction

This document describes the major components and interfaces of IDCS, the Insertion Device Control System at BESSY II. IDCS is a system of hard- and software-components that controls the movement of wigglers and undulators at BESSY II. These wigglers and undulators are also named Insertion Devices.

  1.1   a Brief introduction to Insertion Devices

Wigglers and undulators are magnetic structures that are used to create radiation when the electron beam passes between them. These structures consist of 2 parts above and below the electron beam that can be moved against each other. This vertical movement changes the characteristic of the radiation that is created.

Extracted pic [1]

In the BESSY II installation, the magnetic structures consist of (this is a simplified description) 4 large bars. 2 of them are in one line above and 2 are below the electron beam. Each end of each bar can be moved up or down. The movement of 2 ends that are in one vertical line is mechanically coupled. Overall there are 4 motors that can be driven to move the bars (plans exist for Insertion Devices with 4 additional motors instead of the mechanical coupling).

The major task of the Insertion Device Control System is to control the movement of these magnetic structures. Three different kinds of movement have to be supported in the long run, the first kind will be implemented first:

At all times, the position of the magnetic structures has to be monitored. Two systems need this information, the machine control system and the monochromator control system. The position is given in form of the size of the vertical gap between each pair of magnetic structures ("magnetic gap"). During movement, this information has to be provided about 50 times a second for the monochromator control system and about 10 times a second for the machine control system.

Each time the magnetic structures are moved, several security checks have to be made in order to avoid damage to the Insertion Device:

  2   Overview over major components of IDCS

  2.1   Hardware-Components

IDCS consists of 2 major hardware components, the ID-IOC and the MOCON device. Note that the magnetic structures, the motors, the position measurement system and the power electronic equipment of the motors are not part of IDCS, but are part of the Insertion Device (ID) itself.

Extracted pic [2]

  2.1.1   The ID-IOC:

This is a VME-BUS based computer that is part of the Machine Control System. The Machine Control System has many more IOC's that are also VME-BUS based computers, but the ID-IOC is used solely to control a single Insertion Device. Each IOC has an ethernet-interface which connects it to the rest of the control system. It also has 4 interfaces for the CAN bus, which is a real-time bus used at BESSY II. The CAN-BUS connects the IOC to:

The ID-IOC has also a direct connection to the position measurement system. This system, that is also connected to the MOCON, measures the magnetic gap with high accuracy. With it's direct connection, the ID-IOC can control the motor movement independently from the MOCON device. Additionally the ID-IOC can gather the current gap-values during motor movements at a high rate.

  2.1.2   The MOCON:

This is the motor-control unit that is used to inferface the motors. It is programmable in a kind of BASIC-dialect and has a CAN-BUS interface. The position measurement system is directly connected to the MOCON's built-in motor steering unit.

  2.2   Software-Components

IDCS consists of 2 major software components, MOSERV and IDCP. In order to simplify the development of these, 2 further components are needed, MOSIM and MOTEST. These 4 software modules can be used in 4 different configurations. 3 of them are needed only in the test phase.

Extracted pic [3]

  2.2.1   IDCP

IDCP is the Insertion Device Control Program. This is the program that runs on the IOC. The program receives commands via the CAN-BUS from the MC-IOC. It informs the Machine Control System of the movement, calculates gap-values from given energy values (the MC-IOC provides only the energy of the wanted radiation) and transmits the needed movement-parameters to the MOCON-unit. During movement, it receives the current gap-values from the MOCON unit, checks and compares them with it's own gap-values and sends them to the Collector-IOC and the MC-IOC. IDCP uses EPICS, which is a software-packet that runs on all IOC's and forms (together with System-Operator workstations) the control system of the storage ring. EPICS is too complex to describe it here in detail. Put into a few words, it is a distributed real-time data-base. Each process-variable is part of that data-base. All data-base variables are stored in structures called Records. Records can interact with each other on one IOC and across the (TCP/IP-) network with other IOC's. They can also be read, displayed and modified from the Operator-Workstations. A program that uses EPICS is not simply written in a programming language but it is essentially a set of record-specifications and connections between them. Parts of such a program can be ordinary C-Code (with the EPICS-Sequencer) but this is avoided when possible in order to keep a clean and straight-forward approach.

  2.2.2   MOSERV

MOSERV is the Motor-Control Server Program. It runs on the MOCON-unit. Since the MOCON-Unit can only be programmed in a simple (BASIC-like) programming language which is based on a slow interpreter, no complex tasks are performed by MOSERV. MOSERV will essentially receive parameters from the CAN-BUS and start the motor-movement when an appropriate command is received via the CAN-Bus. It will also send the current gap-positions during this movement as fast as possible via the CAN-Bus to the ID-IOC.

  2.2.3   MOSIM (a Test-Program)

This is a portable C-program that is used to simulate the MOCON-Unit. It will run on a dedicated test-IOC, a HP-743 VME-Bus Computer or a PC and print out all motor-movements that would have been performed by the MOCON-unit. This program is needed for the development of IDCP since the MOCON-unit is physically connected to an Insertion-Device and cannot be moved. It will also prevent Insertion-Device structures of being damaged during testing of IDCP.

  2.2.4   MOTEST (a Test-Program)

In order for MOSIM to be useful, it has to be proved at that MOSIM behaves in every way like the real MOSERV-program (except for the simulation of the motor-movement itself). MOTEST will run on a dedicated test-IOC, a HP-743 VME-Bus Computer or a PC.

It is a simple, interactive test program that will be used to test all commands the MOSERV program knows. A protocol of such a test of MOSIM will be compared with a protocol of a test of MOSIM. When all test-results are identical, it can be assumed that MOSERV and MOSIM behave the same and MOSIM can be used to develop and test IDCP.

MOTEST will also be used to provide the Insertion-Device group with a first program that can be used to move the Insertion Devices for measurement purposes.

  3   External Interfaces

  3.1   The MC-IOC Interface

The ID-IOC has a CAN-Bus connection to the MC-IOC. The LowCAL protocol will be used on this connection. LowCAL is a CAN-protocol and is part of MultiCAN. MultiCAN is a set of software-components that add CAN-Bus support to EPICS. MultiCAN consists of GPS (Generic Protocol Support), LowCAL (subset of the CAL-Protocol), SCI (Simple CAN Interface) and VCAN (VME-CAN2 Driver). These components are also explained in Section 5 on page 6.

  3.2   The Machine Control System Interface

The ID-IOC has 2 connections to parts of the Machine Control System. First there is the connection via EPICS to the System Operator Workstations. Since EPICS provides all necessary functions for that connection, no additional work has to be done on side of the ID-IOC. The 2nd connection is the CAN-Bus connection to the Collector-IOC. This IOC gathers all gap-values from all ID-IOC's in the storage ring. It is currently planned that this connection will use the LowCAL protocol in order to actively read gap-values from each ID-IOC.

  3.3   The Motor-Interface

This interface is only mentioned here only for completeness. It is already realized within the MOCON-unit which provides all commands that are necessary for controlling the motors of the Insertion Device.

  3.4   The Measurement System Interfaces

The measurement system provides analog signals that are used to measure the magnetic gaps at a very high precision. These signals are fed into the MOCON and also into the ID-IOC. By this both, the ID-IOC and the MOCON can monitor the current positions and the ID-IOC can provide gap-values to other parts of the control system independently from the MOCON device.

  4   Internal Interfaces

The IDCS consists of 2 hardware components, each equipped with a single software component. The hardware-components, the ID-IOC and the MOCON are connected via the CAN-Bus. The software-components, IDCP and MOSERV will communicate via the CAN-Bus, using the LowCAL protocol. LowCAL introduces Multiplex-Variables which are a way to transport up to 127 different variables just with 2 CAN-objects. This is important, since the MOCON-unit only supports up to 3 CAN-objects. LowCAL will be used to implement a number of parameter-variables in MOSERV which can be read or written by the IDCP. There will be also a command-variable in MOSERV which is used to start or stop the motor-movement. Several (currently planned: only two) variables within the IDCP will be used by MOSERV to write back status-messages and gap-values.

  5    Existing Software-Components used by IDCS

IDCS is based on a number of existing software-components that are partly bought by BESSY GmbH and partly developments of BESSY GmbH. These components are listed in the following paragraphs. The following picture shows the hierarchy of libraries on the ID-IOC:

Extracted pic [4]

  5.1   Programming Languages

The following programming languages are used:

  5.2   Operating Systems

The following operating systems are used:

  5.3   Drivers

Note that "driver"does not just mean a program that accesses hardware directly but a program the complies to certain standards of the operating system for device-drivers. The only driver used in that meaning is the VCAN-driver:

  5.3.1   VCAN

VCAN is a portable driver for the VME-CAN2 card, which is a CAN-Interface card for the VME-BUS. This driver was developed by Götz Pfeiffer at BESSY and is available in a HP-RT and a VxWorks-Version. HP-RT is a operating system for a HP-743 VME-Bus computer that is used for CAN-driver development.This driver is also used by all other IOC's that are part of the Machine Control System.

Status: completed

  5.4   Libraries

This is a list of libraries that is used in IDCS, some of that libraries were developed for the BESSY II Machine Control System.

  5.4.1   SCI

This is a library that gives access to the CAN-Bus in a hardware-independent way. It is optimized for being used by EPICS but is still generic enough to be useful for all kinds of CAN applications. SCI always transfers raw-data (1 to 8 bytes at a time, this is a CAN-bus limitation) via the CAN bus and makes no assumptions about the content of the data. The design of SCI was developed by Ingo Müller, Bernhard Kuner and Götz Pfeiffer (documentation is available). SCI is used in the IDCS project for the test-programs MOSIM and MOTEST and (via the EPICS-system) by IDCP. SCI exists in 4 implementations:

Status of all SCI-versions: completed

  5.4.2   GPS

This is a library that connects SCI with the EPICS device-support. GPS supports a arbitrary number of protocols. In general, protocols do not just transfer 1 to 8 bytes of raw data over the CAN bus. They support certain data-types, like integer or short-integer, they may acknowledge received data or make it possible to transmit complex data-structures that are larger than 8 bytes. GPS is used indirectly by IDCP, since IDCP is based on EPICS and all CAN-bus data transfers within EPICS use GPS. The design of GPS was developed by Jens Bergl, Ralph Lange and Götz Pfeiffer at BESSY. Implementation and Tests were done by Ralph Lange at BESSY.

Status: beta-test

  5.4.3   LowCAL:

This is a protocol that interacts with MultiCAN. LowCAL implements a subset of CAL, which is one of several protocol norms for the CAN-bus. LowCAL supports several different types of variables. A variable is a data-structure of a certain type whose data is transmitted over the CAN bus in a defined way. LowCAL supports byte, short-integer and long-integer types. It also supports arrays of these that must not be longer than 8 bytes. Additionally, it supports multiplex-variables, which are arrays of a variable of one type. Each element of such an array can be transmitted separately over the CAN bus. Acknowledge of received data is also possible. LowCAL is used by IDCP via the LowCAL device-support in EPICS. It was developed and implemented by Ralph Lange at BESSY.

Status: completed

  5.4.4   GPS Device Support

The MultiCAN device support is not a separate library but a large number of modifications and additions that were made to EPICS. EPICS had to be changed in order to support CAN-bus connections. The MultiCAN device support is used by IDCP, since IDCP is based on epics. The MultiCAN device support was developed and implemented by Jens Bergl at BESSY.

Status: beta-test

  5.4.5   EPICS

EPICS is the Experimental Physics Industrial Control System. It is a software-system that runs on the IO-Controllers (IOC's) and operator interface workstations (OPI's). The IOC's are VME-Bus based computers with a 680xx CPU and the operating system VxWorks, the OPI's are in general UNIX-Workstations. EPICS implements a distributed real-time data base on the IOC's that is controlled via the operator workstations. The BESSY II Machine Control System will be based on EPICS. EPICS is essential for IDCP since IDCP will be "programmed in EPICS". An EPICS-program is usually not written in a traditional programming language, but is instead a set of so called records, which are represented as entries in the real-time data bank. A record in general hold one value (a process variable) and is connected via hardware-links to hardware (e.g. the CAN bus) or to other records. Much like electronic components form a circuit, records that are interconnected form a part of the control system.

Status: completed (this is no in-house development)

  5.4.6   CALMVP

This library implements the CAL-multiplex variable protocol (see also LowCAL) with a few restrictions but is much smaller and simpler than LowCAL. It is based on SCI and available for VxWorks, HP-RT and DOS. It was developed by Götz Pfeiffer at BESSY.

This library will only be used for the programs MOTEST and MOSIM, not in the final installation of IDCS.

Status: beta-test

  6   Design-Outline of the IDCS software components

  6.1   Outline of MOTEST

Note that this test-program is not used in the final installation of IDCS.

MOTEST is used to simulate the IDCP in order to test the MOSERV program. Apart from this goal, MOTEST is held as simply as possible. MOTEST is programmed in C and runs on VxWorks, HP-RT and DOS.

MOTEST is a simple, screen oriented interactive program that allows the test of all functions of the MOSERV program. MOSERV is mainly intended to run on a PC, so it does not have a direct interface to the position measurement system. All communication is performed via the CAN-bus.

Status: alpha-test (a first incomplete version has been tested)

  6.2   Outline of MOSIM

Note that this test-program is not used in the final installation of IDCS.

MOSIM is used to simulate MOSERV in order to test the IDCP. Apart from this, MOSIM is held as simply as possible, it runs VxWorks, HP-RT and DOS.

MOSIM us screen oriented and receives all commands from it's CAN bus interface. MOSIM prints the current position of the (simulated) motors during their movement.

Status: alpha-test (a first incomplete version has been tested)

  6.3   Outline of MOSERV

MOSERV will be programmed in the MOCON-language, a kind of basic. Due to this and to the fact that one line of code executes in about 5 milliseconds (quite slow) this program will be held as simple as possible. However, 2 LowCAL conform variables have to be implemented. Since MOCON is totally different from the ID-IOC, the program code from LowCAL cannot be used. A strong limitation is that only 2 8-byte CAN objects or 3 5-byte CAN objects can be set up. In order to transmit more than 3 parameters over the can bus, a kind of multiplexing has to be implemented. The solution is the use of multiplex variables with the LowCAL protocol. MOSERV will have one Read/Write Mulitplex Server-variable for movement parameters and commands and a Write-Only Multiplex Client variable for it's status and the gap-values that are actively sent back to the ID-IOC.

Status: alpha-test (a first incomplete version has been tested)

  6.4   Outline of IDCP

Basically, IDCP will represent certain parameters of the Insertion Device movement in several records and will have one command-record to give the MOCON the start- or stop command. The parameters will be transmitted to the MOCON via the LowCAL protocol. Note that Big-Endian format will be used to transmit integers, this is not quite CAL conform, but it is the native format of the MOCON. IDCP will also receive parameters and commands from the MC-IOC in the same way via LowCAL. If later development of IDCP shows, that certain tasks can not be performed by programming records, the sequencer will be used. The sequencer is a separate task and also a part of EPICS. It is used to write programs that represent a state machine and provides an easy way to access records.

Status: design-phase

Generated by fmtoweb written by Peter G. Martin <> Last modified: 26 Feb 1997