MCS-architecture

Document Sample
MCS-architecture Powered By Docstoc
					                                                                     db4ff6dc-a444-4aff-afc6-1f47d394a291.doc




                     MARVELS
                 System Design




TITLE



           Control System Software
          Architecture and Interfaces




Code :        MCS-1
Issue :       1.A
Date :        10-June-2009
No. of pages :         46
C/D :




                    University of Florida, Department of Astronomy
                                Gainesville, FL, USA
                   MARVELS System Design         Code: MCS-1
                                                 Issue: 1.A
                    Control System Software      Date: 10-June-2009
                   Architecture and Interfaces   Page: 2 of 35

Approval control


                        Frank Varosi
Prepared by            Senior Engineer
                   Department of Astronomy
                    University of Florida


                        Frank Varosi
Revised by             Senior Engineer
                   Department of Astronomy
                    University of Florida


                         Dr. Jian Ge
Approved by                   PI
                   Department of Astronomy
                    University of Florida

                               &

                      Dr. Nathan De Lee
                          Deputy PI
                   Department of Astronomy
                    University of Florida


                         Dr. Jian Ge
Authorized by                 PI
                   Department of Astronomy
                    University of Florida
                     MARVELS System Design              Code: MCS-1
                                                        Issue: 1.A
                      Control System Software           Date: 10-June-2009
                     Architecture and Interfaces        Page: 3 of 35

  Changes record

 Issue     Date      Section Pages                  Change description
1.A      10-06-09   All      All   First draft




  Applicable documents

   Nº                 Document title                         Code             Issue
  A1
  A2
  A3
  A4
  A5     Trouble-shooting and Maintenance
  A6
  A7

  Reference documents

   Nº                   Document title                       Code              Issue
  R1                                                                         1.A
  R2                                                                         1.A
  R3

  Configuration items

         Code                                  Description
                    MARVELS System Design                Code: MCS-1
                                                         Issue: 1.A
                     Control System Software             Date: 10-June-2009
                    Architecture and Interfaces          Page: 4 of 35

List of acronyms and abbreviations

ADC        Analog to Digital Converter
ADU        ADC Units
ASP        Array Signal Processor (main VME crate of MCE)
BPRC       BayTech Remote Power Control device
CCI        MARVELS Instrument
MCS        MARVELS Control System
MIS        MARVELS Interface Server
CORBA      Common Object Request Broker Architecture
DAC        Digital to Analog Converter
DAS        Data Acquisition Server
DC         Detector Control
DMA        Direct Memory Access
EDT-PDV    Engineering Design Team PCI Digital Video card.
FAS        Frame (Data) Acquisition Server (old name for DAS)
FOI        Fiber Optic Interface (combination of EDT-PDV and GCRI)
GCRI       Gatir Remote Camera Interface
GCS        GTC Control System
GE         Giga-bit Ethernet
GTC        Gran Telescopio de Canarias
GUI        Graphical User Interface
IR         Infrared
IDL        Interface Definition Language
MJCI       Java Control Interface (GUI of MCS)
MJDD       Java Data Display (quick-look display of data frames for users)
LCU        Local Control Unit (of MCS: rack-mounted Sun Fire V120)
LOM        Lights-Out Monitor of the LCU
M2CS       Secondary Mirror Control System
MC         Mechanism Control
MCE        Modular Camera Electronics (detector readout, A/D conversion)
MUX        Detector array readout Multiplexor (an IC contact bonded to detector)
OC         Observation Configuration
PID        Proportional (gain) Integral (reset) Derivative (rate)
PM         Pressure Monitor (using Pfeiffer 261)
TC         Temperature Control (of detector, using Lakeshore 331)
TIS        Telescope Interface Server
TM         Temperature Monitor (using Lakeshore 218)
TTL        Transistor-Transistor Logic voltages
UF         University of Florida
UFLIB      UF Library of C++ Classes, Protocols, Agents, and Servers
                                MARVELS System Design                             Code: MCS-1
                                                                                  Issue: 1.A
                                 Control System Software                          Date: 10-June-2009
                                Architecture and Interfaces                       Page: 5 of 35

LIST OF FIGURES

FIGURE 1: PHYSICAL UNITS IN MARVELS AND MCS. ................................................................... 8
FIGURE 2: SOFTWARE PACKAGES. .............................................................................................. 11
FIGURE 3: SOFTWARE DEPLOYMENT DIAGRAM ........................................................................ 12
FIGURE 4: COMMUNICATIONS BETWEEN SOFTWARE AND HARDWARE COMPONENTS. ..................... 13
FIGURE 5: TELESCOPE AND INSTRUMENT INTERFACES.............................................................. 25
FIGURE 6: MJCI - MASTER CONTROL PANEL ........................................................................... 27
FIGURE 7: MJCI - MORE OBSERVATION PARAMETERS WINDOW ............................................. 27
FIGURE 8: MJCI - DETECTOR CONTROL PANEL ........................................................................ 28
FIGURE 11: MJCI - TEMPERATURE/PRESSURE MONITOR AND CONTROL PANEL ...................... 28
FIGURE 12: MJCI - MOTOR HIGH-LEVEL CONTROL PANEL ...................................................... 29
FIGURE 15: MJCI - SYSTEM CONTROL AND MONITOR PANEL .................................................. 30
FIGURE 16: MJDD - JAVA DATA DISPLAY TOOL ...................................................................... 31
                                   MARVELS System Design                                 Code: MCS-1
                                                                                         Issue: 1.A
                                    Control System Software                              Date: 10-June-2009
                                   Architecture and Interfaces                           Page: 6 of 35

                                                             CONTENTS

1 INTRODUCTION .........................................................................................................8

2 DEFINITIONS.............................................................................................................10
2.1 UFLIB (UF INSTRUMENTS CLASS LIBRARY) .............................................................. 10
3 SOFTWARE ARCHITECTURE ..............................................................................11
3.1 PACKAGES .................................................................................................................. 11
3.2 DEPLOYMENT ............................................................................................................. 12
3.3 COMMUNICATIONS ..................................................................................................... 13
3.4 DEVICE AGENTS AND SERVERS .................................................................................. 15
  3.4.1 Motor Control Agent ........................................................................................... 15
  3.4.2 Temperature Monitor Agent................................................................................ 16
  3.4.3 Temperature Control Agent ................................................................................ 16
  3.4.4 Pressure Monitor Agent ...................................................................................... 16
  3.4.5 Detector Control Agent ....................................................................................... 18
  3.4.6 MARVELS Interface Server................................................................................. 21
  3.4.7 Data Acquisition Server ...................................................................................... 22
4 INTERFACE WITH THE HUB (SDSS CONTROL SYSTEM) ............................25
4.1 QUERY OF TELESCOPE PARAMETERS .......................................................................... 25
  4.1.1 Secondary Mirror Chop Settle Time and Stabilize Time .... Error! Bookmark not
  defined.22
  4.1.2 Environment Parameters .................................. Error! Bookmark not defined.22
  4.1.3 Telescope Parameters for FITS Header ............................................................. 25
4.2 REQUESTING TELESCOPE FOCUS AND POINTING ADJUSTMENTERROR! BOOKMARK NOT
DEFINED.23
4.3 REQUESTING TELESCOPE NOD BEAM-SWITCH .. ERROR! BOOKMARK NOT DEFINED.23
5 OBSERVING TOOLS: MJCI & MJDD ...................................................................26
5.1 TRANSACTIONS BETWEEN OBSERVING TOOLS AND DEVICE AGENTS/SERVERS .......... 26
5.2 OBSERVATION MONITOR PANEL ................................................................................. 26
5.3 JAVA CONTROL INTERFACE (MJCI) ............................................................................ 26
  5.3.1 Master Control Panel.......................................................................................... 27
  5.3.2 CCD Control Panel ............................................................................................. 28
  5.3.3 Temperature/Pressure Monitor and Temperature Control Panel ...................... 28
  5.3.4 Motor High-Level Control Panel ........................................................................ 29
  5.3.5 System Control and Monitor Panel ..................................................................... 30
5.4 JAVA DATA DISPLAY (MJDD).................................................................................... 31
6 MARVELS EQUIPMENT .........................................................................................33
6.1 FILTER WHEEL 1 ......................................................................................................... 33
6.2 FILTER WHEEL 2 ......................................................................................................... 33
6.3 SLIT WHEEL................................................................................................................ 33
6.4 MOTOR INDEXERS (DRIVERS) ..................................................................................... 33
                                 MARVELS System Design                                Code: MCS-1
                                                                                      Issue: 1.A
                                   Control System Software                            Date: 10-June-2009
                                  Architecture and Interfaces                         Page: 7 of 35

6.5 TEMPERATURE CONTROLLER AND SENSORS ............................................................... 33
6.6 TEMPERATURE SENSORS............................................................................................. 33
6.7 PRESSURE SENSOR ...................................................................................................... 34
6.8 CCD CAMERA ELECTRONICS (SI-CCD) ..................................................................... 34
6.9 TERMINAL SERVER ..................................................................................................... 34
6.10 BAYTECH REMOTE POWER CONTROL ...................................................................... 34
6.11 LOCAL CONTROL UNIT (LCU) .................................................................................. 35
                        MARVELS System Design                Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 8 of 35



1 INTRODUCTION

The MARVELS is spectrometer with interferometer, using a 4096 by 4096 CCD.
MARVELS consists of four physical units:

       (1) the Enclosure housing the CCD, optics, sensors, and mechanisms,

       (2) the Calibration Box,

       (3) the SI-CCD system,

       (4) the LCU rack housing the Mechanism Control (MC) indexers (drivers), the
       cryostat Environment Monitors (EM), and the Local Control Unit (LCU) that runs the
       control system and data transport software.

Figure 1 shows a block diagram of the physical units. Units (3) and (4) comprise the
MARVELS Control System (MCS).


Figure 1: Physical units in MARVELS and MCS.

The LCU is a Solaris/AMD rack-mounted Sun Fire X4200 computer that resides in the same
rack (enclosure) as the MC hardware.

The LCU is also connected via private Ethernet to a Terminal Server which provides serial
RS-232 lines for commanding devices such as Motor Control (MC) hardware and the MCE.
Please see Section 7.15 for more information about the Terminal Server (TS). The MCE is
connected to the TS with an optically-isolated serial I/O line. Each of the 12 motor indexers
(drivers) is directly connected to a serial port on the TS. The motor indexers are made by
Intelligent Motion Systems and are of type IMS483i. A serial I/O line is connected from the
TS to each of the following environment monitoring (EM) devices: the PMT (Hamamatsu
7464), the temperature monitors (Lakeshore 218). Please see Section 7 for more detailed
information.

The DC, MC, EM hardware, and the TS obtains its power from the BayTech Remote Power
Control (BRPC) device. The BRPC allows the power to each device outlet to be turned
on/off by commands over an Ethernet connection (using telnet port). However, the LCU
obtains its power from the UPS in the same rack.

This document describes the architecture and interfaces of the MCS. Sections 2 defines some
important concepts. Section 3 discusses the architecture and deployment of the MCS
software components. Section 4 discusses the interface between the MCS and the SDSS
Telescope Control System. Section 5 presents the GUI software for operator control of the
                       MARVELS System Design                 Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 9 of 35

CCI and quick-look display/analysis of data. Section 6 describes the configuration of the four
camera modes. Section 7 reviews the equipment of MARVELS and MCS.
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 10 of 35



2 DEFINITIONS

2.1 UFLIB (UF Instruments Class Library)

UFLib is a library of C++ and Java classes for messaging and instrument control. Messages
consist of a class hierarchy of protocol objects that have methods for sending and receiving
the the objects over sockets. The library also provides a class hierarchy for single threaded
agents and multi-threaded servers that use the socket protocol objects for messaging.
                               MARVELS System Design            Code: MCS-1
                                                                Issue: 1.A
                                Control System Software         Date: 10-June-2009
                               Architecture and Interfaces      Page: 11 of 35



3 SOFTWARE ARCHITECTURE

3.1 Packages

The software for the MARVELS Control system (MCS) consists of 3 packages:
    Observing Tools: Java Control Interface (MJCI) and Java Data Display (MJDD).
    Device Agents (for Mechanism & Detector Control) and Data Acquisition Server.
    MARVELS Interface Server (MIS) for archiving & transactions with the HUB.
Figure 2 shows a diagram of how these packages are associated.


                                 Java Control Interface       Mechanism Control
                                  (JCI )                      and Monitor Agents

      Observer                        and

                                 Java Data Di splay (JDD)                              Instrument
                                                                                       Mechanisms




    GTC Control System


                                      CanariCam Interface     Detector Control Agent
    Telescope Interface               Server ( CIS )
    Server ( TIS )                                             and Dat a Acquisition
                                                                      Server



         Component Interface         CORBA -UFLIB Interface                            Detector
                                                                                       Controller
                                                                                        (MCE)


Figure 2: Software Packages.

The Mechanism & Detector Control Agents and the Data Acquisition Server (DAS) must
execute on the LCU, and are described in Sections 3.3-3.4. The Observing Tools package
provides the GUI to the device agents called the Java Control Interface (MJCI), and the GUI
for quick-look display of data from the DAS called the Java Data Display (MJDD). The
MJCI and MJDD are described in Section 5. The MJCI and MJDD are designed for network
operation and should be run on machines other than the LCU. Together with the Device
Agents and DAS, the MJCI and MJDD allow operation of the CCI in standalone mode.
                       MARVELS System Design                    Code: MCS-1
                                                                Issue: 1.A
                        Control System Software                 Date: 10-June-2009
                       Architecture and Interfaces              Page: 12 of 35



3.2 Deployment

The deployment of the MCS software is illustrated in Figure 3. The LCU has three network
interfaces: one Gigabit Ethernet NIC with optical fiber connection to the GTC network, one
Ethernet connection with the MOC, and one for the private network local to the LCU rack
enclosure. The private network is mainly for the device agents to communicate with the
Terminal Server, thereby accessing the serial I/O devices, and to communicate with the
Baytech Remote Power Control device. The device agents, DAS, and MIS run on the LCU,
whereas the MJCI and MJDD applications should run on other processors. There is no
restriction to the number of MJCI and MJDD clients that may be running and connected to
the LCU agents and servers. Running many MJCI and MJDD clients does not create any
noticeable impact on network performance or CPU usage of agents and servers on the LCU.



        << CCI : LCU >>                                                  << CCI : MCE >>
    Data Acquisition                  Fiber Optic Interface for Data     Modular Came ra
    Server (DAS)                                                           Electronics



    Device Agents:                                                      <<Terminal Server>>
                                           <<Net Switch>>
    DC, MC, TC,                            Private Network             TCP/IP <=> Serial I/O
    TM, PM

           CanariCam
           Interface                       <<BayTech>>                  << CCI : Devices >>
           Server (CIS)                 Remote Power Control
                                                                          Motor Indexe rs

                                                                           Environment
                                                                            Monitors
                          <<Net Switch>>
  <<MOC>>
                           GTC Network
 GTC Network

                                                       <<Work-Station>>

       <<Processor>>
                                                         Java
         Telescope                                       Control
                                                         Interface
         Interface
         Server
         (TIS)                                           Java Data
                                                         Display



Figure 3: Software Deployment Diagram
                       MARVELS System Design                 Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 13 of 35



3.3 Communications
Communications between MCS software components and hardware is illustrated in Figure 4.
The diagram shows software components that execute on the LCU as blue ellipses, and all
the software and hardware components of the LCU are enclosed by the dashed blue line. The
other hardware of the CCI is shown as green rectangles and actors. The blue ellipses
containing the word “Agent” represent software components that provide communication
interfaces to hardware devices. Note that the Device Agents communicate with the hardware
through a Terminal Server that is connected to the LCU via Ethernet, creating a socket to the
particular serial port that is connected to the corresponding device.




Figure 4: Communications between software and hardware components.

The Device Agents communicate with the serial I/O devices using simple ASCII character
string command & response messages handled by the UFLib Terminal Server classes,
                       MARVELS System Design                 Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 14 of 35

whereas clients (such as MJCI) communicate with the Device Agents using UFLib protocol
object messages. The Device Agents are described in the next section.

The EDT-PDV Fiber-Optic-Interface (FOI) is a PCI card in the LCU, with Solaris device
drivers and API for DMA acquisition of data frames from the giga-bit/sec rate fiber-optic
connection with the MCE. Transport of detector readout frames co-added by the MCE
occurs between the “upper” GATIR Remote Camera Interface (GRCI) in the MCE and the
“lower” EDT-PDV-FOI in the LCU. The Data Acquisition Server (DAS, blue ellipses inside
dotted rectangle in Figure 4) is a multi-threaded process that grabs data frames from the
EDT-PDV-FOI device, and therefore must execute on the LCU. The DAS is described
further in the next section.

The orange rectangles in Figure 4 represent the Observing Tools package of custom Java
applications that provide the Graphical User Interface (GUI) for the control system. The Java
Control Interface (MJCI) communicates with the Device Agents using UFLib protocol
messages for the purpose of controlling the instrument, and the Java Data Display (MJDD)
provides quick-look display of data from the DAS. Data reduction and analysis can be
performed by existing IRAF tasks that are commonly used for T-ReCS data reduction. The
MJCI and MJDD applications should be run on machines other than the LCU, and are
described further in Section 5.

The blue ellipse with dashed border labelled the MARVELS Interface Server (MIS)
represents the software interface between the CORBA environment of the GTC Control
System and the UFLib protocol messaging of the MCS. The MIS is a Java server multi-
threaded process that executes on the LCU and handles configuration & information
transactions between the Detector Control agent and the GTC Control System, by converting
UFLib Protocol messages to CORBA transactions. The MIS invokes methods of the
Telescope Interface Server (TIS), software provided by GTC. The main purpose the MIS and
TIS is to allow the DC agent to request telescope nod beam switching and telescope
parameters. The secondary purpose of the MIS is to monitor and control the power to the
CCI devices. The TIS and MIS are described further in Section 4.
                         MARVELS System Design                  Code: MCS-1
                                                                Issue: 1.A
                          Control System Software               Date: 10-June-2009
                         Architecture and Interfaces            Page: 15 of 35



3.4 Device Agents and Servers

The Device Agents are software components based on UFLib classes. Clients (such as
MJCI) communicate with the Device Agents using UFProtocol messages, whereas Device
Agents communicate with the devices using the Terminal Server and the UFTermServ class,
which handles the serial I/O of simple ASCII character string command and response
messages. Each Device Agent is a single threaded process that repeats a standard sequence
of tasks:

   (1)   accept and greet new client socket connections,
   (2)   execute ancillary tasks, unless pending client requests have higher priority,
   (3)   handle pending client requests and reply to each client, or else:
   (4)   hibernate for a set time (e.g. one second), unless a new connection or request occurs.

One of the standard ancillary tasks of each Device Agent is to poll the hardware device for
current status. Normally the Device Agents execute on the LCU, however they could execute
on any machine that has TCP/IP access to the Terminal Server.

The Data Acquisition Server (DAS, written in C++) and the MARVELS Interface Server
(MIS, written in Java) are multi-threaded software components that must run on the LCU.
All agents and servers write a history of actions to logs files, and these files are discussed in
the document CTR/D5 – Trouble-shooting and Maintenance.

3.4.1 Motor Control Agent

The Motor Control (MC) agent provides a command and monitoring interface to the 12
motor indexers (drivers) that are each directly connected to a serial RS-232 port on the
Terminal Server (TS). The MC agent creates a TCP/IP socket connection to each of the
indexer ports (7011 – 7022) on the TS, using the class UFMultiTermServ. The MC agent
accepts and queues requests from multiple clients, formulates and sends the low-level ASCII
commands to the motor indexers, and returns the replies to clients. Each indexer drives a
motor of the CCI that moves a mechanism, such as a filter wheel or the window changer.
While motors are moving, the indexers are queried every second for step counts and status of
motion (as part of ancillary tasks, but new requests are given priority), and the step counts are
sent back to all clients (such as the MJCI) that subscribe to the status stream. Before every
motion, the MC agent checks if indexers have been power-cycled, and if so, sends the motor
operating parameters to the indexers first. The datum (home) count of each mechanism is
tracked by the MC agent, and it is reset to zero if an indexer power-cycle is detected. For
communications, MJCI creates two connections with the MC agent for each indexer: one
socket for commanding the indexer and one socket subscribing to a continuous stream of
status messages about the indexer. The MC agent performs the following actions (use cases):
     Read Motor Parameters File
     Configure Motor Indexers
     Query Motor Indexers
                         MARVELS System Design                 Code: MCS-1
                                                               Issue: 1.A
                          Control System Software              Date: 10-June-2009
                         Architecture and Interfaces           Page: 16 of 35

    Datum Mechanisms
    Move Mechanisms
    Abort Motions
A detailed description of the actions is given in CTR/D3 - Use Cases.

The file “MotorParams.dat” is read by the MC agent upon starting, and this file contains all
the parameters for the indexers motion control and all the step counts for named positions for
each mechanism. The file is located in directory “~cancam/ufcc/config” where it may be
edited, and then “make” installs the file to directory “$UFCCINSTALL/etc” where it is read
by the MC agent. The MC agent can be directed by a button on the MJCI MotorParameters
panel to re-read the file at any time, and use the new information. Please see document
CTR/D5 – Trouble-shooting and Maintenance for more information.

3.4.2 Temperature Monitor Agent

The Temperature Monitor (TM) agent communicates with the TCP/IP port number 7002 on
the Terminal Server that is connected via an RS-232 serial line to the rack-mounted
Lakeshore-218 that provides 8 channels for temperature sensors. The ancillary task of the TM
agent continually queries all channels of the Lakeshore-218 to provide status to clients, at a
default update period of 2 seconds, that is adjustable. Clients may subscribe to the status data
stream from the TM Agent, thereby receiving a continuous stream of temperature readings
from all sensors in the cryostat, as rapidly as 5 Hz.

3.4.3 Temperature Control Agent

The Temperature Control (TC) agent communicates with the TCP/IP port number 7003 on
the Terminal Server that is directly connected via an RS-232 serial line to the Lakeshore-331.
The Lakeshore-331 has two channels that connected to 2 sensors: one on the detector carrier
and one on the cold finger support of detector. The heater for temperature control is on the
cold finger. The TC agent performs multiple tasks:

   (1)   continually query the 2 channels of the Lakeshore-331,
   (2)   report temperature readings to status clients,
   (3)   configure the temperature control PID parameters of the Lakeshore-331,
   (4)   start the temperature control loop (by setting heater range and the set point),
   (5)   periodically (minute) check the heater range and power used, reporting status.

Clients may subscribe to the status data stream from the TC agent, thereby receiving a
continuous stream of temperature readings from the two sensors. The default update period
is once a second but may be selected to be as rapid as five times a second.

3.4.4 Pressure Monitor Agent

The Pressure Monitor (PM) agent communicates with the TCP/IP port number 7004 on the
Terminal Server that is directly connected via an RS-232 serial line to the rack-mounted
Pfeiffer 261 device that reads the pressure gauge in the cryostat. The PM agent continually
                         MARVELS System Design                  Code: MCS-1
                                                                Issue: 1.A
                          Control System Software               Date: 10-June-2009
                         Architecture and Interfaces            Page: 17 of 35

queries the Pfeiffer 261 to provide status to clients, at a default update period of 3 seconds,
that is adjustable. Clients may subscribe to the status data stream from the PM Agent,
thereby receiving a continuous stream of pressure readings from the sensor.
                         MARVELS System Design                 Code: MCS-1
                                                               Issue: 1.A
                          Control System Software              Date: 10-June-2009
                         Architecture and Interfaces           Page: 18 of 35


3.4.5 Detector Control Agent

As seen in Figure 4, the Detector Control (DC) agent occupies a central position in the MCS,
communicating with the MCE, the DAS, the TC agent, the MC agent, the Java Control
Interface (MJCI), and the MARVELS Interface Server (MIS). The DC agent acts as a
sequencer of many events, in particular:

   (1)   configuration of an observation,
   (2)   start of an observation,
   (3)   monitoring status,
   (4)   sequencing of nod beam-switching,
   (5)   rotating the Lyot Mask mechanism during coronographic observations,
   (6)   rotating the Half Wave Plate during polarimetric observations.

For purpose #3, the DC agent communicates with the Telescope Interface Server via the MIS,
which converts UFLib protocol messages into CORBA transactions and vice-versa.

Communication with the MCE occurs over an optically isolated RS-232 serial line from the
Terminal Server, accessed solely by the DC agent via TCP/IP port number 7008 on the TS.
The main task of the DC agent is to provide a command interface with the MCE firmware
that physically controls the detector array, allowing the selection of clocking patterns, bias
voltages, frame readout rate, etc., in addition to sequencing the data acquisition and transport.
The DC agent can configure the MCE sequencer Cycle Type (CT) parameters for the type of
detector frame readouts, co-adding, chopping, and nodding, in three ways:

        directly specify and set the CT parameters,
        specify physical parameters (e.g. frame times & frequencies) that are converted to
         CT counters by the DC agent, and then sent to the MCE, or
        specify meta-parameters (e.g. on-source time and instrument configuration) that are
         then converted to physical and CT parameters, and then sent to the MCE.

See the description of corresponding use cases in CTR/D3 for more details. The conversion
of meta-parameters to physical parameters is controlled by the file “MetaConfigDet.txt”,
located in directory “~cancam/ufcc/config” where it may be edited, and then “make” installs
the file to directory “$UFCCINSTALL/etc” where it is read by the DC agent. The DC agent
can be directed to re-read the file at any time, by the button “Read Meta-parameters File” on
the MJCI Detector panel, and then the DC agent will use the new information for
configuration. The Detector and Master panels of MJCI control and show all the above
parameters. Other transactions with the MCE include:

               setting and checking the voltage offsets of preamp channels,
               setting and checking detector bias voltages,
               powering on/off the detector bias voltages and clock signals.
                       MARVELS System Design                 Code: MCS-1
                                                             Issue: 1.A
                        Control System Software              Date: 10-June-2009
                       Architecture and Interfaces           Page: 19 of 35

These actions are normally done automatically by the MCS software or MCE firmware, but
they can be checked and set manually using special panels of the MJCI, namely the Bias and
Preamp panels.

The DC agent performs the following periodic ancillary tasks automatically:

   (1) queries the acquisition status of the DAS at least once a second,
   (2) when the MCE data transport pauses, the DC agent signals a nod beam-switch and
       then the resumption of MCE data co-adding when the nod beam-switch is complete,
   (3) during coronographic or polarimetic observations, rotates the Lyot mask or half wave
       plate, respectively, and
   (4) queries (once a minute) the TC agent for the current detector array temperature, and
       sends the value to the MCE as a safety interlock to avoid operating the detector
       outside of it’s safe and useable temperature range,
   (5) queries (once a minute) the MCE hardware status,
   (6) sends observation status to clients (MJCI) subscribed to Status Stream (see Section 5).

The DC agent also collects FITS header information from itself and the other Device Agents,
and from the Telescope Interface Server, and sends the FITS header to the DAS. The DAS is
normally configured and started by the DC agent. The following is a list of basic actions:

        (1)    Set Bias Voltages
        (2)    Set Preamp Offsets
        (3)    Check Detector Temperature
        (4)    Power On/off Detector
        (5)    Configure FOI
        (6)    Query M2CS
        (7)    Collect FITS Header
        (8)    Create Extension Header
        (9)    Queue Extension Header
        (10)   Configure DAS
        (11)   Configure MCE
        (12)   Start DAS
        (13)   Start MCE
        (14)   Resume MCE
        (15)   Query Acquisition Status
        (16)   Abort DAS
        (17)   Stop DAS
        (18)   Abort MCE
        (19)   Nod Beam-switch
        (20)   Rotate Lyot Mask
        (21)   Rotate Half Wave Plate

A description and more actions of the DC agent are given in CTR/D3 – Use Cases. The
document CTR/D4 – Operational Concepts describes in detail the methods of adjusting and
                      MARVELS System Design               Code: MCS-1
                                                          Issue: 1.A
                       Control System Software            Date: 10-June-2009
                      Architecture and Interfaces         Page: 20 of 35

configuring MCE physical parameters such as the frame readout time, and the document
CTR/D5 – Trouble-shooting and Maintenance describes the configuration control files.
                         MARVELS System Design                Code: MCS-1
                                                              Issue: 1.A
                          Control System Software             Date: 10-June-2009
                         Architecture and Interfaces          Page: 21 of 35



3.4.6 MARVELS Interface Server

The MARVELS Interface Server (MIS) is a multi-threaded Java software component running
on the LCU, that has the following purposes:

   (1)   control/monitor the BayTech Remote Power Control (BRPC) device,
   (2)   stop/start/monitor the other agents/servers,
   (3)   provide interface with TIS for MCS agents,
   (4)   provide CORBA interface to MCS.

The MIS communicates with the BRPC via the private Ethernet, since it is located in the
same rack as the LCU. The MIS can command the BRPC to turn off/on the power outlet for
each of the CCI devices, or stop/restart any of the device agents. Clients such as MJCI can
connect to the MIS via TCP/IP port 53000 to control power states and running modes of
software. The MJCI System Panel provides the GUI for such actions. The MIS and MJCI
are described further in the following sections 4 and 5. The DC agent is also a client of the
MIS in order to make transactions with the Telescope Interface Server, in particular to
perform telescope nod beam-switches. The MIS consists of the following basic threads:

        the ORB thread to handle CORBA transactions,
        a ListenThread that accepts new client socket connections on the ServerSocket,
        one clientThread per client to handle requests from each client,
        StatusMonitor thread that repeatedly performs 5 tasks:
           (1) check the LOM temperature of the LCU,
           (2) turn on/off the enclosure coolant flow valve as needed (via the BPRC),
           (3) check the running modes of agents and servers on the LCU,
           (4) check the power status of BayTech RPC power outlets,
           (5) send all this status information to subscribed status clients.

The StatusMonitor thread runs once a minute, but can be signalled to run immediately by any
client that needs status right away. The usual clients of the MIS are the DC agent and the
System panel of each MJCI. The System panel of each MJCI is also a status client and so
displays the status of device power outlets on the BPRC, and the running mode of the Device
Agents and the DAS.
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                         Control System Software               Date: 10-June-2009
                        Architecture and Interfaces            Page: 22 of 35


3.4.7 Data Acquisition Server

The Data Acquisition Server (DAS) must execute on the LCU to have direct access to the
EDT-PDV-FOI device. The DAS is a multi-threaded process, written in C++ using UFLib
classes and message protocols, and consists of six basic threads. The sole purpose of one
thread, is to listen for socket connections from clients on TCP/IP port 52000 and then create
a FrameServerThread for each client. Clients can request status, notification stream,
configure / start / abort an observation, or request the contents of any named frame buffer,
and the FrameServerThread will send the status of the action or the desired information to the
client in a UFLib protocol message. The other five threads are called:

      FrameGrabThread
      FrameProcessThread
      FrameWriteThread
      FrameStreamThread
      FrameNotifyThread

The FrameGrabThread copies frames from the EDT-PDV device’s DMA buffers into process
heap memory, as they are received from the MCE via the fiber-optic interface. Note that these
MCE output frames are actually the sum of many detector readout frames, produced by the
co-adders on the MCE. The FrameGrabThread opens and configures the EDT-PDV device at
the beginning of each observation. After each DMA event occurs, the frames are copied into
an STL list container, keeping track of relevant parameters such as the time each frame is
grabbed from the EDT-PDV device. In addition, the FrameProcessThread is signaled after
each frame is grabbed. A counter object keeps track of the number of DMA events and the
number of frames grabbed, and if the difference becomes larger than the number of DMA
buffers in the ring allocation of EDT-PDV device, the observation is aborted and an alarm
fault is indicated, since at that time old data frames not yet grabbed are getting overwritten by
new data frames. This buffer overrun would only occur at very fast save frequencies or if
there is a problem with the LCU.

The FrameProcessThread processes and accumulates frames into named buffers. Processing
consists of mapping the pixels of each frame from detector readout to image display order,
and performing the detector well sample minus clamp reference samples if multi-sample
readout mode is used. The named frame buffers are STL list containers, and the names
correspond to which part of the chop/nod sequence each frame comes from:
     on / off source frames in nod position A are called srcA / refA,
     on / off source frames in nod position B are called srcB / refB,
for a total of four current frame buffers that are populated with the acquired and processed
frames. For each of the four current frame buffers there is a corresponding accumulation
buffer into which the frames are co-added. Differences of “src” minus “ref” source buffers
are automatically computed, and results are placed in named difference frame buffers, called
difA and difB, for which there are current frames and accumulated frames. The accumulated
difference buffers of each nod beam are then added to compute the accumulated signal image
( SIG = accum(difA) + accum(difB) ) for each nod-cycle. The SIG buffers are accumulated
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                         Control System Software               Date: 10-June-2009
                        Architecture and Interfaces            Page: 23 of 35

into the accum(SIG) buffer over all nod-cycles. Frames in the buffers are locked while being
sent to clients (for display etc.), but once unlocked they are deallocated when new frames are
pushed into the buffers. Thus, up to a total of 7 frame buffers are used, with corresponding 7
accumulation buffers (see CTR/D4 Operational Concepts for an illustration). Also, after each
frame is processed it is queued to the FrameWriteThread and FrameStreamThread, and a
notification is queued to the FrameNotifyThread (see below) for sending to status clients.

The FrameWriteThread writes to FITS files on the LCU disk, (1) all the frames grabbed from
the MCE (after basic processing), and (2) the final accumulated signal image produced by the
FrameProcessThread, resulting in two FITS files for each observation. The on & off source
frames are written at the same frequency as the rate of transfer from the MCE, thus called the
save frequency (or save-time). The FITS file of all frames is written in the Multi-Extension
FITS (MEF) format (same as T-ReCS data). Each extension is the data from one nod-beam,
organized as a four dimensional array: first two dimensions of course correspond to the
horizontal and vertical axes of each frame; the third dimension is for the chop beam position
(on or off source); the fourth dimension is for the save count (during a nod beam). Each
extension has a header that contains information collected by the DC agent and sent to the
DAS for writing to the MEF file. The main header is collected again at the end of an
observation (by the DC agent) and then rewritten to the MEF file by the DAS. Normally the
FITS file directories and names are created automatically according to the year, the day of the
year, and the sequence in the day.

The FrameNotifyThread sends notifications to subscribed clients about which frame buffers
have new data available after each savesets is grabbed from the MCE and processed. The
notification messages are created and queued by the FrameProcessThread. Clients such as
the MJDD can then request data frames from their dedicated FrameServerThread based on
the notification message and user selections. Thus, each MJDD client continually waits for
notifications and then requests data from frame buffers that have been updated and also
match the display selections, thereby displaying the new data as the observation proceeds.

The FrameStreamThread is an optional feature of the DAS that allows one client (and only
one) to obtain the stream of all the processed data frames. This data stream can be used by a
Data Handling System client (e.g. DHS of Gemini) to archive all the data, or the stream
option can be used for testing the system by having a special client receive and check all the
data. If there is no client requesting the data stream, the FrameStreamThread does nothing
with the frames that are queued by the FrameProcessThread.

In summary, the DAS has at least six threads running (or waiting for a signal) all the time:
   FrameGrabThread           (grabs frames from the EDT-PDV-FOI connected to MCE),
   FrameProcessThread        (processes frames, queues writing, streaming or notification),
   FrameWriteThread          (writes all frames to MEF files, and final image to FITS file),
   FrameStreamThread         (optional feature to send all frames to one special client),
   FrameNotifyThread         (sends frame acquisition notifications to all status clients).
                         MARVELS System Design               Code: MCS-1
                                                             Issue: 1.A
                          Control System Software            Date: 10-June-2009
                         Architecture and Interfaces         Page: 24 of 35

   clientListenThread        (accepts client connections and creates FrameServerThreads),
   FrameServerThread         (one for each client),
and the DAS creates a dedicated FrameServerThread for each client, that handles requests
using methods in the five worker threads (Grab, Process, Write, Stream, and Notify). There
is no limit to the number of clients and FrameServerThreads, but connections are accepted
from only the networks that are in the allowed sub-net list that is in the clientListenThread
code (part of file FrameServerThread.cc). A sub-net can be added or removed from the list of
allowed sub-nets by sending a specific UFProtocol message to the DAS, as discussed in the
Appendix of CTR/D3 : Use Cases document, which also lists other possible transactions.

The DAS performs or is involved in the following use cases (actions):

              (1)    Configure FOI
              (2)    Configure DAS
              (3)    Collect FITS Header
              (4)    Create Extension Header
              (5)    Queue Extension Header
              (6)    Start DAS
              (7)    Abort DAS
              (8)    Stop DAS
              (9)    Acquire Data
              (10)   Process Data
              (11)   Archive Data
              (12)   Notify Data Clients
              (13)   Close FITS Files
              (14)   Query Acquisition Status
              (15)   Subscribe to Data Notification Stream
              (16)   Request Data Frames
              (17)   Subscribe to Data Stream

Please see the document CTR/D3 - Use Cases for more information.
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 25 of 35



4 INTERFACE WITH THE HUB (SDSS CONTROL SYSTEM)
The interface is based on the use of two CORBA servers, one provided by the instrument,
and the other provided by the telescope. The diagram below shows the interface between
GCS and MCS. Most of the interface is based on software, except for the TTL chopping
signal between hardware components. The Telescope Interface Server (TIS) provides the
methods needed by instruments to operate in coordination with the GCS, and this interface is
provided by GTC. The IDL of the TIS is given in Annex I of the ICD (DCI/CTRL/0054-R).
The Canaricam Interface Server (MIS) provides the methods needed by the GCS to
operate in coordination with the Canaricam instrument. The IDL of the MIS is presented in
Annex II of the ICD. A set of common of type definitions used in the GTC is provided in
order to facilitate the definition of both Telescope and Instrument interfaces. The IDL of
these types is presented in Annex III of the ICD. The FITS keywords and parameters that
shall be used in the headers of data files are documented in Annex IV of the ICD.




Figure 5: Telescope and Instrument Interfaces


4.1 Query of Telescope Parameters
The DC agent requires information from the observatory control system in order to complete
the configuration of the MCS before an observation starts, and during an observation.
Queries are performed by DC agent transactions with the MIS, which then invokes
corresponding methods of the TIS via CORBA. The MIS sends the results back to the DC
agent using UFProtocol messages.

4.1.1 Telescope Parameters for FITS Header
The DC agent requests all Telescope Parameters that are need for the FITS header from the
TIS (via the MIS), and then creates and appends the telescope FITS header information to the
instrument FITS header, forming the complete FITS header for data files. The Telescope
Parameters are obtained again at the end of each observation and rewritten to the data file, so
that both beginning and final values of parameters are recorded.
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                         Control System Software               Date: 10-June-2009
                        Architecture and Interfaces            Page: 26 of 35



5 OBSERVING TOOLS: MJCI & MJDD

5.1 Transactions Between Observing Tools and Device Agents/Servers
The transactions between Device Agents and the MJCI & MJDD are performed using the
UFLib protocol messages over TCP/IP sockets. UFProtocol classes support the following
object types: UFTimeStamp, UFStrings, UFInts, UFShorts, UFObsConfig, and
UFFrameConfig (all protocol classes inherit from UFTimeStamp). Each object has a header
and data, and methods to send and receive itself. Two type of transactions are used:
     Request for action and Response (acknowledgement),
     Status Stream of monitored values.
The Request and Response is exactly that: for every message sent, the client expects a reply.
The Status Stream transaction is for continuously monitoring sensors or mechanism positions
from the Device Agents, and is started when a client such as MJCI subscribes to the
agent/server Status Stream. The DC agent provides an observation Status Stream to MJCI
clients and the DAS provides a data Notification Stream to MJDD clients. Further
description of using the MJCI and MJDD is provided in the Operator/Engineer Manuals for
MJCI and MJDD.

5.2 Observation Monitor Panel
The bottom panel of the MJCI and MJDD, called the Observation Monitor (OM) panel, is
created by the class UFobsMonitor, and is always visible no matter which tabbed pane is
selected, as seen in all the following figures. The OM shows the current status of an
observation, and displays warnings and alarms. The OM panel is automatically updated by a
StatusMonitor thread that receives a Status Stream of messages from the DC agent (in the
MJCI) or the DAS (in the MJDD). Also shown in the OM is the observation progress bar
along with current average data ADU counts and noise statistics. The FITS file name is a
status field with information from the DAS showing the LCU file to which data is written by
the DAS.

5.3 Java Control Interface (MJCI)
The MJCI is the GUI of the MCS that allows an observer to configure, start, and monitor an
observation with MARVELS. Nine tabbed panes are provided by the MJCI (see following
figures), each providing the panel dedicated to controlling or monitoring a particular facet of
the CCI. The MJCI is also an integral part of the MCS, in that it provides some high-level
configuration logic and sets up default positions for some mechanisms depending on the
chosen camera mode. The MJCI can be executed on any machine with TCP/IP network
access to the LCU, and so should not be executed on the LCU. The MJCI communicates
directly with the Device Agents using UFProtocol transactions.

In the top menu bar of MJCI is a field for the LCU hostname that can be unlocked and
changed if needed (e.g. for testing purposes). Pressing the “Connect to LCU agents” button
would reconnect all MJCI panels to all agents running on the LCU. In addition, the Master,
Detector, Temperature, and Motor Parameters panels have fields and buttons for reconnecting
to the DC, TC, TM, PM, and MC agents. Below the menu bar are fields showing the current
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 27 of 35

status of the CCI, either IDLE, WAIT, OBSERVING, or ALARM, and status of how many
motors are moving if in the WAIT state.

The recent history of information in most of the fields in the MJCI is kept in a
UFMessageLog object for each field, that can be viewed concurrently in popup text area
windows. If the mouse pointer is moved over the text-field or label and the tool-tip displays
“Click right mouse button to view Log”, then clicking right button will display viewing
options, and selecting one will pop up a new window showing the history of that field. A
special type of panel is the “Action – Response” panel for each socket connection with an
agent, created by class UFStatusCAR. The panels display the last requested action and
response from an agent. Clicking right button on an Action-Response panel (and selecting
view mode) will show the history of requested actions and responses from the corresponding
agent.

5.3.1 Master Control Panel
Figure 6 shows the Master panel that is the normal starting point for MARVELS control,
providing a high-level interface for detector and mechanism configuration, and starting or
stopping an observation. Most of the mechanisms are automatically configured by the Master
panel methods, depending on the Camera Mode (see Section 6). The automatically
configured mechanisms are listed at the bottom left corner, and there is a checkbox for each
mechanism allowing the user to override the automatic setting.



Figure 6: MJCI - Master Control Panel

When the CONFIGURE button is pressed, the MJCI checks the “Desired” fields in the panel
and sends motion commands to the MC agent and configuration parameters to the DC agent.
The “Active” fields are automatically updated with current status of mechanisms and the
response from the DC agent. Configurations can be saved and reapplied, using features in the
center of panel (see Operator Manual for MJCI). The two filter wheels are considered as one
logical filter assembly, so there are a total of 11 logical mechanisms. The Wave Plate angle
and Lyot Mask Rotator angle are automatically controlled by the DC agent during
observations, and the Mask Rotator is not shown on the Master panel. Each sub-panel of
mechanism name, desired field (combo-box/text-field), and active value (text-field), is part of
a JCIMotorGUI object that contains a reference to the corresponding JCIMotor object for the
mechanism (see Motor Panel). The JCIMotorGUI for Filter contains both of the Filter1 and
Filter2 JCIMotor objects. The “Show Optical Path” button creates a window displaying a list
of mechanisms with positions, and the current optical path is diagrammed.




Figure 7: MJCI - More Observation Parameters Window
                        MARVELS System Design                Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 28 of 35



5.3.2 CCD Control Panel
The Detector panel provides direct control and monitoring of the physical parameters and
CT counters of the MCE sequencer. The physical parameters are sent to the DC agent when
the COMPUTE button is pressed (using a bundle of parameter-value string pairs in a
UFProtocol message), and the DC agent adjusts the values to convert them into CT counters.
The CT counters are sent to the MCE when the CONFIGURE button is pressed. An
observation can be also started and aborted from this panel. The Detector panel connects a
command socket with the DC agent that is also used by the Master, Bias, and Preamp panels.
The TEST button tests the communication connection from MJCI through DC agent to the
MCE, and the Response field will show an error “reply not received” if communication with
the MCE is not functioning. If the DC agent does not respond, that error will be displayed
and the “Connect” button will turn red. Pressing it will attempt to reconnect to DC agent.
The button “Re-connect DC agent to MCE” directs the DC agent to close & connect a new
socket to the Terminal Server port handling the MCE communications. To check the photon
efficiency of desired/active configuration press the “Efficiency ?” button, which then creates
the window shown in Figure 7. The “MCE SIM” button allows access to the four MCE
hardware simulation modes useful for debugging hardware problems. See the Engineer
Manual for MJCI, and the Use Cases document CTR/D3 for more explanation.

Figure 8: MJCI - Detector Control Panel

5.3.3 Temperature/Pressure Monitor and Temperature Control Panel

This panel provides connections to the Temperature Monitor and Control agents (TM &TC)
and the Pressure Monitor (PM) agent, receiving status streams from the agents. Fields for
temperature and pressure are automatically updated from a periodic stream of values read
from the sensors by the agents. The detector temperature can be controlled from this panel
using the Set Point and Heater Range control fields, and enabling the “Apply” buttons by
selecting the corresponding check-boxes. Normally the temperature set point and heater
range are set automatically by the DC agent based on the configuration. The heater range and
power status is updated about once a minute by the TC agent. The history of any or all
temperature sensors can be graphed (except for pressure) and saved to a file. Data from all
sensors is saved to the file so that any desired sensor can be graphed again.



Figure 9: MJCI - Temperature/Pressure Monitor and Control Panel
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 29 of 35


5.3.4 Motor High-Level Control Panel

The CCI mechanisms can be directed to move to named positions using this panel, and the
status of any motion is automatically updated. Each horizontal sub-panel corresponds to a
mechanism, and is created by an instance of the MJCIMotor object, which also stores and
displays all parameters about the mechansism. Each MJCIMotor object has a command
socket and status socket connection with the MC agent, and the status socket is monitored
continuously by a StatusMonitor thread that updates the “Indexer Status” panel on the right
side. Motion actions for each indexer are performed in separate threads so that interactive
response is maintained. Any mechanism can moved back to its home position by pressing
the “Datum” button, and any motion can be aborted by pressing the “Abort” button. Near the
bottom is a special panel for controlling the high-resolution gratings by specified the desired
central wavelength. The look of this panel can be changed by pressing the toggle button
“Names on Right”, that will change the order of columns so that check-box names will be on
right side next to status labels (switched back by pressing the button again).




Figure 10: MJCI - Motor High-Level Control Panel
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 30 of 35



5.3.5 System Control and Monitor Panel

The System Panel communicates with the MARVELS Interface Server (MIS) using
UFProtocol messages, and provides a GUI for the following actions (via the MIS):

   stopping / restarting any of the Device Agents or the DAS,
   monitoring run mode of Device Agents and DAS,
   powering off/on any of the outlets feeding power to each of the MCS devices,
   monitoring power status of the MCS devices (CCI equipment),
   setting the min & max LCU enclosure temperature thresholds for coolant flow control.

There is also a button “View agent Log files” that allow user to view the logging output files
written by agents and servers on LCU, if the LCU file system is NFS mounted. Note that the
warning messages seen in the ObsMonitor panel below are due to hardware not available.



Figure 11: MJCI - System Control and Monitor Panel
                        MARVELS System Design                 Code: MCS-1
                                                              Issue: 1.A
                         Control System Software              Date: 10-June-2009
                        Architecture and Interfaces           Page: 31 of 35




5.4 Java Data Display (MJDD)

The Java Data Display (MJDD) tool subscribes to the data notification stream from the DAS
that indicates when new data is available. When a notification is received, the MJDD will
request data frames from the buffers in the DAS that were updated, but only for the buffers
that the user has selected to be displayed. The new data frames are received and displayed by
the MJDD, according to the display options chosen by the user, which in the Figure below are
set to: DifA, DifB, SIG, and SIG-sum. The desired buffer to display in each window can be
selected from the combo-box pull-down menus, or from the “Setup Buffers” menu. Also,
any frame can be grabbed as a reference (by pressing Ref1 or Ref2 button) and then
automatically subtracted from all new frames using options in the “Buffer” pull-down menus.
Clicking the left mouse button on a buffer window will display the sub-region in the zoom
window at the selected zoom factor, as shown in Figure below.



Figure 12: MJDD - Java Data Display Tool
The zoom window also provides a smoothing option, that applies the 3x3 box-car smoothing
kernel to the data iteratively. In the limit of increasing iterations this filter approaches a
Gaussian convolution kernel of FWHM equal to the square root of the number of smoothing
iterations. Clicking the right mouse button in any window will pop-up a menu of options.
Zoom window options include:

      plot line cut profiles at any angle,
      plot histograms and statistics of regions,
      computing the centroid and full-width half-max at maximum point in data,
      plot x-y profiles through centroid,
      plot x-y projection averages of a region,
      stop all plots.

Once any of these options are turned on, they repeat the computations or plots for all future
acquired frames of data. Options selected by right clicking on a buffer window include:

      SAVE Displayed Data to FITS file,
      SAVE Ref1 to FITS file,
      SAVE Ref2 to FITS file,
      SAVE Ref3 to FITS file,
      SAVE Gain to FITS file,
      READ Ref1 from FITS file,
      READ Ref2 from FITS file,
      READ Ref3 from FITS file,
      READ Gain from FITS file,
      Show Channel Statistics,
                       MARVELS System Design                 Code: MCS-1
                                                             Issue: 1.A
                         Control System Software             Date: 10-June-2009
                        Architecture and Interfaces          Page: 32 of 35

      Pause Showing,
      Close Chan. Stats. Window.

The option “Show Channel Statistics” pops up a window that displays statistics of the stream
of data frames being displayed in the buffer window. The statistics are computed for each
channel of the detector, and include:

      Standard Deviation of pixels in a channel,
      Skew and Curtosis,
      Mean value,
      Minimum and Maximum values.

The statistics can be computed for each frame or over consecutive difference frames in time,
and the statistics can also be plotted versus channel number for easy visual study.

The MJDD also provides an interface for interaction with the Telescope Interface Server
(TIS) directly via CORBA server method invocation. Pressing the “Telescope Offset
Control” button on the menu bar pops up a new frame that allows user to request small
offsets to the telescope pointing. Other options could be added to this interface.
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                          Control System Software              Date: 10-June-2009
                         Architecture and Interfaces           Page: 33 of 35



6 MARVELS EQUIPMENT
The CCI Equipment includes all the mechanisms that need to be controlled and monitored,
devices that monitor CCI environment, and the Modular Camera Electronics (MCE). Each
mechanism has defined a logical position called “park”.


6.1 Filter Wheel 1
The first filter wheel is rotated by one stepper motor and has 13 physical positions: one is
open (no filter), and 12 positions containing filters.

6.2 Filter Wheel 2
The second filter wheel has 13 physical positions: one is open (no filter), one position
contains the pupil imaging lens doublet, and 11 positions that contain filters.

6.3 Slit Wheel
The Slit Wheel utilizes one stepper motor that will select any of the 9 pre-loaded slits, or an
open (clear) position, or a blank-off position.

6.4 Motor Indexers (Drivers)
The motor indexers are made by Intelligent Motion Systems and are of type IMS483i. The
12 indexers are housing in a large box located in the LCU enclosure, with serial connections
in the back to the Terminal Server ports #11 through #22. The indexers are wired so that
home switches are in LOW state when not contacted, and go HIGH when triggered.

6.5 Temperature Controller and Sensors
Detector temperature control and monitoring utilizes the Lakeshore-331 rack-mounted
device. The Lakeshore-331 has two sensor channels: one channel monitors the sensor on the
detector carrier and the other channel monitors the sensor on the cold-finger supporting the
detector/MUX assembly. The Temperature Controller uses a resistive heater on the cold
finger and the carrier temperature sensor in a closed loop configuration to stabilize the
operating temperature of the detector array. Based on the configured Proportional gain,
Integral reset, Derivative rate, (PID) parameters, the Lakeshore-331 continuously adjusts the
heater on the cold finger to achieve the set-point temperature. Communications with the
Lakeshore-331 is performed via serial I/O line that is connected to the Terminal Server (see
below), and handled exclusively by the Temperature Control (TC) agent. The Temperature
Panel of MJCI provides the GUI for displaying status from and working with the TC agent.

6.6 Temperature Sensors
A rack-mounted Lakeshore-218 is used to monitor the temperature from 8 sensors located on
selected components in the cryostat. Communications with the Lakeshore-218 is performed
via serial I/O line that is connected to the Terminal Server (see below), and handled
exclusively by the Temperature Monitor (TM) agent. The Temperature Panel of the MJCI
provides the GUI for displaying status from the TM agent.
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                         Control System Software               Date: 10-June-2009
                        Architecture and Interfaces            Page: 34 of 35

6.7 Pressure Sensor
The pressure sensor is used to monitor the internal cryostat pressure. The Pfeiffer-261 gauge
with rack-mounted interface is used. Communication with the Pfeiffer-261 is performed via
serial I/O line that is connected to the Terminal Server (see below), and handled exclusively
by the Pressure Monitor (TM) agent. The Temperature Panel of the MJCI also provides the
GUI for displaying status from the PM agent.

6.8 CCD Camera Electronics (SI-CCD)
The Detector Controller hardware/firmware is usually called the Modular Camera Electronics
(MCE), and is responsible for the following real-time activities:

      Clocking of detector array (CRC-774 MUX) and associated electronics
      Detector bias voltages
      Readout of all pixels in detector array (a frame)
      Amplification of the 16 analog readout channels from MUX
      Preamp channel offset voltages
      Analog to digital conversion of each channel signal
      Co-addition of frames into on/off source buffers
      Creation of on/off source TTL chop trigger
      Transport of co-added frames to the LCU

The transport of co-added frames to the LCU is accomplished by a Fiber Optic Interface
(FOI) between the.

6.9 Terminal Server
The MCS utilizes a Perle model CS9000 Terminal Server (TS) on the private network. Each
device of the CCI connected to an RS-232 serial port on the TS appears to the LCU as a
network device with a specific IP address and TCP port. This simplifies development of the
device interface control software: all that is needed is a generic socket based I/O port and
buffer handler which may then be instanced for the particular command protocol of each
device. Each of the 8 serial ports can be configured independently of the others. The TS is
self-booting and can be managed via its first serial port or via Telnet. Once the TS is
configured with an IP address and booted, it runs a TCP/IP embedded server software that
accepts connections on the standard Telnet TCP/IP port number, and each serial port is
mapped to its own TCP/IP port number. The TS accepts only one exclusive connection on
each TCP/IP port. All TCP transmissions to a TCP/IP port are sent out the associated serial
port and all serial input is transmitted back to the TCP/IP client. For a serial port configured
at 9600 bps, the worst-case round trip I/O time is less than 0.2 seconds on our LAN.
Currently the IP address of the TS is set to 192.168.111.120 and listed as “ufccperle” in the
hosts table on the LCU. The serial ports used by the Device Agents are password protected
with username “ufastro” and password the same as username.

6.10 BayTech Remote Power Control
The BayTech Remote Power Control (BRPC) device provides 8 power outlets that can be
remotely controlled to be on/off. The BRPC is connected to the CCI private Ethernet and
allows controlling and monitoring the power status of all devices plugged into the BRPC.
                        MARVELS System Design                  Code: MCS-1
                                                               Issue: 1.A
                         Control System Software               Date: 10-June-2009
                        Architecture and Interfaces            Page: 35 of 35

Communication with the BRPC is accomplished with a telnet connection, and is handled
exclusively by the MARVELS Interface Server (MIS). The System Panel of the MJCI
provides the GUI for working with the MIS and the BRPC. Simple power on/off commands
control the power for each outlet. The BRPC also has a temperature sensor that will be
monitored to determine the need for coolant flow in the enclosure. Currently the IP address
of the BRPC is set to 192.168.111.6 and listed as “ufccbaytech” in the hosts table on the
LCU.

6.11 Local Control Unit (LCU)
The Local Control Unit (LCU) is a Solaris/SPARC rack-mounted Sun Fire V120 computer
with three Ethernet interfaces. One 100 base-T Ethernet interface is connected to the CCI
private network switch (in the rack) and allows the agents (running on LCU) access to the
devices connected to the Terminal Server, and allows the MARVELS Interface Server (MIS)
to access the BRPC. The LOM temperature sensor of the LCU is monitored by the MIS to
determine the need for coolant flow in the enclosure. Currently the IP address of the LCU
private Ethernet interface is set to 192.168.111.204 and listed as “irkepler” in the hosts table
on the LCU. The second 100 base-T Ethernet interface should be connected to the MOC in
the rack. The PCI bus of the Sun Fire V120 is connected to a Netra-E1 PCI expansion
module that contains the EDT PCI-Digital-Video (PDV) card for the Fiber Optic Interface
data transport from the MCE, and the Gigabit Ethernet (3rd) interface card with fiber-optical
connectors for the GTC network.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:1/19/2012
language:
pages:35