Instrument Processes

The instrumentation software on the NTT is built around some very basic principles. The Observation Software (OS) only knows about the current single exposure being executed. The next or previous exposure are meaningless concepts to OS. All parallelism possible within the instrument control is handled by the OS.

The OS handles all communications between the three subsystems involved in the observation namely: ICS - Instrument Control Software, DCS - Detector Control Software and TCS - Telescope Co-ordination Software. The OS is built up from a number of sub modules described below.

Both SUSI2 and EMMI use the same structure of the software using a BASE system and configuration parameters above them. So when using SUSI2 the processes have the addendum _susiOs while when using EMMI the addendum is _emmiOs.


os0Control are the control process for the OS, which passes commands (e.g.. when sent via BOB) down to the subsystems.


Here the exposure itself is executed. The os0exposure functions signal to the DCS and ICS, the set-up commands and wait for the SET-UP to be completed before actually issuing the START command. FITS headers are accumulated here and merged into a single file.

The FITS headers are generated independently from each subsystem. The ICS writes one file, DCS another and TCS (via TIF) another. The os0ExpoControl merges the three with the image file into a single entity.


All SET-UP files are handled using the oslx facilities. The oslx can either be used as a server process or directly as a library of calls. In the NTT instrumentation we use both kinds of calls depending on what exactly we wish to be doing.


This is the master process for the ICS. This provides the interface of ICS to the OS. ICS does not have the concept of the exposure. The ICS only responds to the SET-UP command.The supervisor task provides the direct communication to the LCU.

LCU Software

The LCU software on the NTT comes in two flavours namely the devServer and lcuServer. Each of EMMI and SUSI2 has one of the these aptly named suidevServer & suilcuServer and emidevServer & emilcuServer. They behave in pretty much identical fashion. You may run the entire instrument directly from the LCU using ccseiMsg.

The devServer actually talks to the motors while the lcuServer acts as front end to that system allowing more than a single motor to be moved at a time. The motors themselves have names such as filtw (SUSI2 filter wheel) or focb (EMMI blue arm focus).

The Motor Library & sen4

SUSI2  uses the "macon controller"  which is VLT standard. Because EMMI uses CAMAC a module called sen4 has been coded that makes CAMAC look like the mac4 code that is used by the "macon controller".

Both instruments (and the adapter functions) are controlled by the motor library.


The Protocol COnverter allows the OS to talk to MIDAS or any other subsystem that does not comply to the VLT protocols.

The scan links

The scan links are automatically enabled after a reboot of the workstation is done.