Document Number 3390AS0001: Software Specification and ... · 1.3 21 Oct 2002 Post-completion...

SALTICAM Software Specification and Design Document 1

Doc No. 3390AS0001 Issue 2.2

1

Southern African Large TelescopeSALTICAM

Document Number 3390AS0001:Software Specification

and

Design Document

Darragh O’DonoghueLuis BalonaDeon BesterDave CarterGeoff EvansWillie Koorts

James O’ConnorFaranah OsmanChantal Petersen

Stan van der Merwe

Issue 2.330 May 2003



2

Issue History

Number And File Name Person Issue Date Change HistoryDOD 1.0 10 Aug 2002 VI FDR version

1.1 16 Sep 2002 Post-VI FDR development1.2 27 Sep 2002 Completed1.3 21 Oct 2002 Post-completion update!

3390AS0001 SALTICAMSoftware Specification Issue1.4.doc

1.4 22 Oct 2002 Further updates before softwarePDR.

3390AS0001 SALTICAMSoftware Specification and DesignIssue 1.5.doc

1.5 12 Feb 2003 Combination of specification anddesign documents

3390AS0001 SALTICAMSoftware Specification Issue andDesign Issue 1.6.doc

1.6 29 Mar 2003 Further development


1.7 15 Apr 2003 SALTICAM KER, MMI almostfinished. Progress with CON


1.8 05 May 2003 Revisions of SALTICAM KER,MMI almost finished. Progresswith SDSU


2.0 11 May 2003 Major new issue after decision tohave mouse running on theSALTICAM PC.


2.1 13 May 2003 Further major revamp afterdiscussions with Luis and Deon.


2.2 27 May 2003 Further major revision afterdesign is carried forward by Luisand Deon on their own.


2.3 30 May 2003 Clean-up after comments backfrom Deon.

TABLE OF CONTENTS

1 Scope.............................................................................................................................................62 Referenced Documents...........................................................................................................63 Customer Furnished Equipment and Responsibilities..............................................74 Functional Requirements: General.................................................................................104.1 The Concept of Programs............................................................................................................105 Functional Requirements: SALTICAM CON ............................................................125.1 Program/Exposure Initiation/Termination...............................................................................125.2 Image Display and Interaction Using The Mouse....................................................................125.3 Data Storage .................................................................................................................................125.4 Offsetting and Closed Loop Guiding........................................................................................125.5 Communication With Precision Time Source..........................................................................125.6 Communication With SALTICAM KER.................................................................................12



3

5.7 Communication With SALTICAM PCI...................................................................................135.8 Communication With SALTICAM SDSU...............................................................................135.9 Communication With The Science Database...........................................................................135.10 Communication With SOMMI/SAMMI ...................................................................................146 Functional Requirements: SALTICAM KER.............................................................156.1 Communication With The TCS.................................................................................................156.2 Communication With SALTICAM CON.................................................................................157 Functional Requirements: SALTICAM MMI............................................................178 Functional Requirements: SALTICAM SDSU (including PCI and Subsystem

Controller) ...................................................................................................................................188.1 The SDSU-PCI :...........................................................................................................................188.2 The SDSU Controller:.................................................................................................................188.3 The Subsystems Controller:.......................................................................................................189 Technical Requirements......................................................................................................209.1 Software Architecture..................................................................................................................209.2 Software Interfaces.......................................................................................................................209.3 Modes (States) and Events .........................................................................................................219.4 Software Capabilities..................................................................................................................249.4.1 Communication...............................................................................................................................249.4.2 Initialisation ....................................................................................................................................249.4.3 Command Interpretation and Generation ........................................................................................249.4.4 Status Reporting .............................................................................................................................249.5 Operating System.........................................................................................................................249.6 Resource Allocation.....................................................................................................................2410 Generic Software Requirements ......................................................................................2511 Software Testing.....................................................................................................................2611.1 Verification cross-reference matrix............................................................................................2611.2 Detailed Test Requirements .......................................................................................................2611.2.1 Interface Test ..................................................................................................................................2711.2.2 Initialisation ....................................................................................................................................2711.2.3 Command Interpretation and Generation ........................................................................................2711.2.4 Status Reporting .............................................................................................................................2712 Software Design: SALTICAM KER & SALTICAM CON....................................2812.1 Mode Command Vocabulary .....................................................................................................2812.2 Top Level Status ..........................................................................................................................3112.3 Sub-Commands and Sub-Status in PROGRAM Mode..........................................................3112.3.1 Activity On Entering PROGRAM Mode........................................................................................3312.3.2 Activity On Starting An Exposure...................................................................................................3412.3.3 Definition of Windows...................................................................................................................3512.3.4 Definition of Programs...................................................................................................................3612.3.5 Target Information..........................................................................................................................3812.3.6 Telescope Information ....................................................................................................................3912.3.7 Status of Program Execution ..........................................................................................................3912.4 Instrument Parameter Status......................................................................................................4012.5 Sub-Commands and Sub-Status in INITIAL Mode................................................................4112.5.1 Initialization Operations..................................................................................................................4212.6 Image Data....................................................................................................................................4312.7 SPARE Mode................................................................................................................................4312.8 INPUT Mode.................................................................................................................................4312.9 Data Clusters/Structures, Software ICD...................................................................................4812.10 Code Structure of SALTICAM KER.........................................................................................4512.11 Communications Between SALTICAM KER and SALTICAM CON..................................4812.12 Image Interaction By SALTICAM CON...................................................................................46



4

13 Software Design: SALTICAM MMI...............................................................................5013.1 SALTICAM MMI: Mode Commands and Status....................................................................5013.2 SALTICAM MMI: PROGRAM/INITIAL/INPUT Mode Sub-Commands and Sub-Status5013.3 SALTICAM MMI: Front Panel..................................................................................................5014 Software Design: SALTICAM SDSU .............................................................................5214.1 SDSU-PCI:....................................................................................................................................5214.2 SDSU Controller: ........................................................................................................................5214.3 Subsystem Controller..................................................................................................................55



5

ACRONYMS AND ABBREVIATIONSAC Acquisition Camera (SALTICAM mode)ACSI Acquisition Camera and Science Imager (SALTICAM configuration)ATP Acceptance Test ProcedureATR Acceptance Test ReportBITE Built-in Test EquipmentCDR Critical Design ReviewCOTS Commercial off the shelfDSS Data Socket Server (LabVIEW)ELS Event Logger SoftwareHET Hobby-Eberly TelescopeI/O Input/Output (Device)ICD Interface Control DossierMMI Man-Machine InterfaceMTBF Mean Time Between FailuresMTTR Mean Time to RepairOPT Operational Planning ToolPC Personal ComputerPDR Preliminary Design ReviewPFIS Prime Focus Imaging SpectrographPI Principal Investigator (Astronomer)PIPT PI Planning ToolPLC Programmable-Logic ControllerSA SALT AstronomerSALT Southern African Large TelescopeSAMMI SA Machine InterfaceSC Software Component (e.g. part fo the TCSS)SDB Science DatabaseSDD Software Design DocumentSDP Software Development PlanSI Software Item (the TCSS is a Software Item) OR

Scientific Imager (SALTICAM mode) (context will define which ismeant)

SO SALT OperatorSOMMI SO Machine InterfaceSRS Software Requirement SpecificationSTARCAT Object CatalogueSW SoftwareTBC To Be ConfirmedTBD To Be DeterminedTCS Telescope Control SystemTCSS TCS ServerVI Virtual Instrument (Labview function) OR

Verification Instrument (SALTICAM mode) (context will define whichis meant)



6

1 ScopeThis document specifies the requirements for SALTICAM Software. It will also provide the design of thesoftware.

According to the Software Development Plan (3390BP0001 SALTICAM Software Development Plan Issue1.0), the software will comprise:

• SALTICAM Kernel Software (designated SALTICAM KER).• SALTICAM MMI Software (designated SALTICAM MMI). This is the interface to

SALTICAM for development and maintenance via the SALTICAM PC keyboard. It will be similarto SALTICAM SOMMI and SALTICAM SAMMI. It may also function as SALTICAM SAMMI.

• SALTICAM Control Software (designated SALTICAM CON). This is the software that will:v Control all the hardware.v Contain the master copy of all the instrument parameters.

• SALTICAM PCI Card Software (designated SALTICAM PCI). This is software that issupplied by Astronomical Research Cameras (ARC) with their SDSU II CCD controllers. It runs inthe DSP processor on the PCI interface card supplied with ARC CCD controllers. If Real Time Linuxis used, the functionality of the PCI driver within the Real Time Linux operating system environmentwill be emulated by SAAO developed software.

• SALTICAM SDSU II Control Software (designated SALTICAM SDSU), including thesoftware in the subsytem controller. This is software that is initially supplied by ARC with theirSDSU II CCD controllers. The supplied software will be used as a prototype for an SAAO developedequivalent, tailored for the SALTICAM application.

In addition, there are two further items of software which are the responsibility of the SALT Project:

• SALT Operator SALTICAM MMI Software (designated SALTICAM SOMMI). This is the mainoperator interface to SALTICAM in Verification Instrument (VI) or Acquisition Camera (AC) modes.

• SALT Astronomer SALTICAM MMI Software (designated SALTICAM SAMMI). This is themain astronomer interface to SALTICAM in Science Imager (SI) mode. It is possible thatSALTICAM MMI will function in the same machine as SALTICAM SAMMI, or be identical to ora subset of SALTICAM SAMMI.

The relationships of these software items to each other are shown in Fig. 1.

The main purpose of the software suite is to:

• Interact with the MMIs (SALTICAM SOMMI/SAMMI/MMI) to enable them to control theSALTICAM hardware to obtain images of the focal plane of SALT.

• Display the images on the SALTICAM PC monitor near the SO or SA. The SOMMI/SAMMI/MMIshould be able to control this display, as well as interact with it (placement of markers etc.).

• Store the images on the SALTICAM PC disc in FITS format.• Enable the use of simple algorithms to make quantitative measurements on the displayed image.• Interact with the TCSS to obtain telescope status information and adjust the pointing of the telescope

either to place targets in the entrance apertures of the scientific instruments or perform closed loopguiding.

• Monitor the safety of the instrument and preventing unsafe or inappropriate operation.

2 Referenced DocumentsThe following documents are referenced in this specification and are applicable to the extent specified herein.



7

1000AA0030 SALT Safety Analysis1000AB0044 SALT Labview Coding Standard1000AD0005 SALT Computer Architecture1000AS0040 SALT Operational Requirements3300AS0001 SALTICAM Specification3390BP0001 SALTICAM Software Development Plan1700AS0001 TCS Specification1000AS0049 SALT Data Interface Control Dossier

3 Customer Furnished Equipment and ResponsibilitiesSALTICAM will have its own fully functioning MMI, which may be used not only to enable the human operatorto control the instrument, but also for development and maintenance purposes. In normal operation, the MMI shallbe via SALTICAM SOMMI or SAMMI. It is possible that the SALTICAM MMI will be used by the SAMMIfor controlling the instrument in SI mode. SALTICAM SOMMI and SAMMI are the responsibility of theCustomer.



8

SALTICAM PC

SCL

6,7:NamedPipes

5

4:Mouseclicks

SO Workstation

1,2

3: Full image,markers

SALTICAM PC MonitorMonitor

* * * *

SALTICAMMouse

SDSU IIPCI

SubsystemController

SDSU IIController

SALTICAMCONTROL

SALTICAMKERNEL

PrecisionTime Source

Commands & Status:11,12

SALTICAMMMI

Compressed image: 13

DSS Commandsand Status: 9,10

SA WorkstationSALTICAM SAMMI

SAMMI DataChannel (e.g.

TCP/IP)

SALTICAM SOMMI

SOMMI DataChannel (e.g.

TCP/IP)

TCS Server

TCS

TCS Data SocketServer

Data ProcessorScience Database

Data ReductionPC

Sciencedata

8Language Legend:

LabVIEW

C

DSP Asm



9

Figure 1. SALTICAM Modules From The Software Perspective



10

4 Functional Requirements: GeneralThe main purpose of the software is to control the acquisition of images by the SALTICAM hardware, displaythem on the SALTICAM PC monitor, allow the user to perform image manipulation via the SALTICAM mouse,perform closed-loop guiding (autoguiding), and carry out miscellaneous other instructions. User control of thesoftware will be exerted in two ways:

i) via an MMI running on SOMMI, SAMMI, or SALTICAM itself (the SALTICAM MMI softwareshown in Fig. 1).

ii) via the mouse running on the SALTICAM PC.

In the former case, the software will be controlled, in a “slave” mode, by one of the MMIs running on SOMMI,SAMMI or the SALTICAM PC itself (SALTICAM MMI). Multiple MMIs can run at the same time but, ofcourse, only one will have control.

If SOMMI or SAMMI is the controlling MMI, it will exert its control by sending SALT Command Language(SCL) commands to the TCS which will, in turn, translate the information into suitable clusters and publish themon the Data Socket Server (DSS) on the TCS machine.

If SALTICAM MMI is in control, it will send the same cluster information to KER directly.

In the former case, this architecture will require a LabVIEW application (SALTICAM KER) running in theSALTICAM PC to subscribe to the TCS DSS. SALTICAM KER will translate the information and send it toSALTICAM CON.

4.1 The Concept of Programs

The concept of a “program” is an important one for SALTICAM instrument control. All images are obtained in“program” mode. The sequence of operations to be carried in the acquisition of images will be predefined inspecific “programs”. For example, a sequence of images through 3 different filters with different exposure timesetc. can be defined. As another example, a “faint star acquisition” can be defined in which a single image througha clear filter is required, with other camera parameters set so as to optimise the detectability of objects at the limitof the telescope. Such a program would be used to relieve the SALT Operator from fiddling with the numerousparameters available when trying to acquire faint targets. Other “programs” could be defined for obtaining biasimages, dark images, repeated short exposures (“video camera” mode) etc.

On the other hand, users can set all individual camera parameters (see items 1-16 in the list below). The “Snap”program uses the current values of all the individual camera parameters to obtain the next image. In addition,programs can be placed in repeat mode (item 10 in the list below).

In this manner, flexibility of operation as well as ease of routine use are assured. This catering for “opposite endsof the operational spectrum” is sufficiently important that it assumes the position of a requirement of the software,as opposed to a design feature.

The programs will be transmitted to SALTICAM CON via SALTICAM KER from the controlling MMI.

A program will comprise the following information:

1. The “program” name.2. Whether or not autoguiding is required.3. Whether or not the shutter should be open during the execution.4. Whether or not the acquired images should be written to disk.



11

5. The row prebin factor.6. The column prebin factor.7. The readout speed.8. The gain used in conversion from measured electrons to analog to digital units (ADUs).9. The position of the frame transfer mask.10. The number of times to repeat the filter sequence.11. The number of different exposures in a sequence.12. For each exposure: the exposure time.13. For each exposure: the filter number.14. For each exposure: the filter name.15. The number of windows on the detector.16. For each window, a definition of the window position and size.



12

5 Functional Requirements: SALTICAM CONSALTICAM CON will be the “central control room” of the instrument. For this reason, we consider its functionalrequirements first.

5.1 Program/Exposure Initiation/Termination

After receiving instructions to do so from SALTICAM KER, SALTICAM CON initiates the start of the nextprogram or stops or aborts a currently executing program.

5.2 Image Display and Interaction Using The Mouse

SALTICAM CON will display images obtained by the instrument with adequate resolution on a large monitor inthe SALT Control Room. This monitor will be the SALTICAM PC Monitor (as indicated in Fig. 1). Control ofbrightness and contrast shall be part of the display algorithms. Displaying the orientation on the image is required.

SALTICAM CON will also manage interaction with the displayed image to place marks/boxes/windows on thedisplay, select objects on the display, overlay catalogues on the display etc. The nature of what is displayed willbe controlled by the controlling MMI. Status return is via the appearance of the display.

The following simple image processing algorithms are also required:

i. A read out of pixel position, RA and Dec of a mouse-type pointer.ii. Fitting of Gaussian functions to point sources.iii. 2-d line plots of image brightness in any direction across the image.iv. Simple aperture photometry to estimate magnitudes of objects.v. Simple image processing function such as background subtraction, smoothing or median filtering.

Results of these operations will be reported either directly to SALTICAM KER or via the SALTICAM PC display.

The user input to the interaction with the image will take place using the SALTICAM PC Mouse.

5.3 Data Storage

SALTICAM CON will also control and manage data storage (in FITS format) on the SALTICAM PC’s disk. (Itis necessary that SALTICAM CON carry out this task as opposed to SALTICAM KER or SALTICAM MMIas in very high speed mode, minimum latency is required).

5.4 Offsetting and Closed Loop Guiding

SALTICAM CON will also perform any calculations required for (i) positioning a target in the entrance apertureof any instrument; (ii) closed loop guiding. These calculations will return the telescope pointing offsets toSALTICAM KER for onward transmission to the TCS.

5.5 Communication With Precision Time Source

SALTICAM CON shall obtain data from the Precision Time Source in order to ensure that the SALTICAMcomputer keeps Universal Time to 1 millisec accuracy or better at all times by providing suitably coded GPS-referenced time to the SALTICAM computer.

5.6 Communication With SALTICAM KER

SALTICAM CON shall exchange data with SALTICAM KER in order to:



13

• Receive commands from SALTICAM KER, program definitions and any other parameters and returnas status the current SALTICAM hardware parameters.

• Receive commands from SALTICAM KER to initiate the next program or terminate the currentprogram. Reporting of the outcome of the command is also required.

• Receive information from SALTICAM KER about whether or not the data is to be stored on disk (inFITS format).

• Receive target pointing data such as target name, RA, Dec, Epoch etc from SALTICAM KER forinclusion in the FITS header of the stored data.

• Receive telescope pointing data such as telescope RA, Dec, Epoch, HA, Altitude, Azimuth, Trackerposition etc from SALTICAM KER for inclusion in the FITS header of the stored data.

• Receive commands from SALTICAM KER to (i) perform calculations for offsetting a target into theentrance aperture of any scientific instrument; or (ii) initiate/stop closed loop guiding. Once initiated,centroids of one or more guide objects will be calculated and pointing corrections deduced for returnto SALTICAM KER for onward transmission to the TCSS. In high time resolution mode, guide starcentroiding may be achieved from the scientific images. The outcome of the command must bereported back to SALTICAM KER.

SALTICAM CON will send any additional status required back to SALTICAM KER.

5.7 Communication With SALTICAM PCI

SALTICAM CON shall communicate with SALTICAM PCI in order to verify that the interface is functioningproperly.

5.8 Communication With SALTICAM SDSU

SALTICAM CON shall communicate with SALTICAM SDSU in order to effect all hardware control via bi-directional communication. Control & status, and CCD Read out data - data rate (on internal optical fibre) up to250 Mbits/sec (equates to 3.9 Mpixels/second, theoretical maximum speed). Image size up to 17.6 Mpixels, butusually 4.2 Mpixels.

SALTICAM CON shall issue commands to SALTICAM SDSU in order to:

• Request controller status• Download CCD-specific control/executable code• Filter selection and positioning• Set full frame, frame transfer or slot mode• Frame Transfer mask in/out• Set pre-bin factor• Set window/s if any• Set gain factor & readout speed• Start/stop exposure• Open/close shutter• Shift image to store area• Read out CCD data• Focus control• Various test functions such as charge pumping, noise testing etc.

5.9 Communication With The Science Database

At low priority, so as to avoid interference with SALTICAM’s normal operations, SALTICAM CON will transmitone or more images to the Data Processor computer. SALTICAM images may be as large as 17.6 M pixels (of2 bytes/pixel) but will usually be no larger than 4.2 M pixels. Data rates to be determined by the data reduction



14

requirements.

Science program information including finding charts etc. may be retrieved from the science database for use inthe execution of science programs. The details of this remain to be worked out.

5.10 Communication With SOMMI/SAMMI

SALTICAM CON will also transmit, on request, compressed images (no larger than 500 x 500 pixels) to theSOMMI or SAMMI machine using a mutually agreed protocol.



15

6 Functional Requirements: SALTICAM KERSALTICAM KER will primarily be used to relay control and status information between SALTICAM CONrunning in the SALTICAM PC, and MMIs running on other computers, as mentioned at the start of Section 5 andillustrated in Fig. 1. This information comprises commands and associated parameters to control the camera, initiateclosed-loop guiding if necessary, initiate the acquisition, readout and storage of images etc.

6.1 Communication With The TCS

SALTICAM KER will exchange data with the TCS residing in the TCSS machine. Data exchange shall be via theData Socket Server (DSS) in the TCS machine.

SALTICAM KER will subscribe to the TCS DSS to obtain commands, program definitions and any additionalinformation in order to:

• Initiate the next program or terminate the current program. Reporting of the outcome of the commandis also required.

• Decide whether or not the data is to be stored on disk (in FITS format).• Receive target pointing data such as target name, RA, Dec, Epoch etc for inclusion in the FITS header

of the stored data.• Receive telescope pointing data such as telescope RA, Dec, Epoch, HA, Altitude, Azimuth, Tracker

position etc for inclusion in the FITS header of the stored data.• (i) Perform calculations for offsetting a target into the entrance aperture of any scientific instrument;

or (ii) initiate/stop closed loop guiding. Once initiated, centroids of one or more guide objects will becalculated and pointing corrections deduced for return to the TCS. In high time resolution mode, guidestar centroiding may be achieved from the scientific images.

• Define what marks/overlays etc. are to appear on the SALTICAM display.

SALTICAM KER will transmit all relevant status required back to the TCS DSS.

In addition, SALTICAM KER will send pointing commands to the TCS DSS in order to:

• Place objects in the entrance apertures of the scientific instruments• Function as guiding corrections during closed loop guiding

6.2 Communication With SALTICAM CON

SALTICAM KER shall exchange data with SALTICAM CON in order to:

• Initiate/terminate the next program/exposure or terminate the current program/exposure. Reportingof the outcome of the command is also required.

• Specify whether or not the data is to be stored on disk (in FITS format).• Supply target pointing data such as target name, RA, Dec, Epoch etc for inclusion in the FITS header

of the stored data.• Supply telescope pointing data such as telescope RA, Dec, Epoch, HA, Altitude, Azimuth, Tracker

position etc for inclusion in the FITS header of the stored data.• Request CON to (i) perform calculations for offsetting a target into the entrance aperture of any

scientific instrument; or (ii) initiate/stop closed loop guiding. Once initiated, centroids of one or moreguide objects will be calculated and pointing corrections deduced for return to SALTICAM KER foronward transmission to the TCSS. In high time resolution mode, guide star centroiding may beachieved from the scientific images.




16

SALTICAM KER will receive all relevant status required for sending back to the TCS.



17

7 Functional Requirements: SALTICAM MMIThe SALTICAM MMI will be used to provide a user interface running on the SALTICAM PC to control theinstrument and assist in the development and maintenance of SALTICAM software. It will exert control bycommunicating directly with SALTICAM KER.

In normal operational mode, and upon initiation of all software units, it is assumed that MMI control will residewith SALTICAM MMI.

If SALTICAM MMI is in MMI control, then it will communicate with the TCS DSS in order to instructSALTICAM KER to:

• Initiate the next program or terminate the current program. Reporting of the outcome of the commandis also required.

• Specify whether or not the data is to be stored on disk (in FITS format).• Supply target pointing data such as target name, RA, Dec, Epoch etc for inclusion in the FITS header

of the stored data.• Supply telescope pointing data such as telescope RA, Dec, Epoch, HA, Altitude, Azimuth, Tracker

position etc for inclusion in the FITS header of the stored data.• Instruct CON to (i) perform calculations for offsetting a target into the entrance aperture of any

scientific instrument; or (ii) initiate/stop closed loop guiding. Once initiated, centroids of one or moreguide objects will be calculated and pointing corrections deduced for writing to the TCS DSS. In hightime resolution mode, guide star centroiding may be achieved from the scientific images.


SALTICAM MMI will subscribe to all status information published on the TCS DSS. A suitable selection willbe displayed on its application screen.



18

8 Functional Requirements: SALTICAM SDSU (including PCI and SubsystemController)

Note that SALTICAM SDSU includes the SDSU II controller as well as the PCI and Subsystem Controller blocksin Figure 1.

8.1 The SDSU-PCI :

Shall exchange data with SALTICAM CON and SDSU II Controller in order to:

• Pass bi-directional messages between SALTICAM CON and SDSU Controller• Pass image data from SDSU Controller to SALTICAM CON in a manner that is optimised for maximum data

rate.• Shall provide status to SALTICAM CON reflecting the process of command-and-reply between SALTICAM

CON and SDSU Controller.

8.2 The SDSU Controller:

Shall exchange data with SALTICAM CON via SDSU-PCI in order to:

• Respond to commands from SALTICAM CON to execute the expose-and-readout process in the variousmodes as defined.

• Provide status to SALTICAM CON of the detector system internal variables.• Pass commands and status to and from the Subsystems Controller.• Control the shutter directly via hardware in the Subsystems Controller.

In addition the SDSU Controller shall:

• Control the temperature of the CCD array.• Perform exposure timing accurate to 1ms.

8.3 The Subsystems Controller:

Shall exchange data with SALTICAM CON via SDSU Controller in order to:

• Respond to and execute commands from SALTICAM CON, and provide appropriate status. • Control the following SALTICAM units:

o Filter mechanismo Focus Mechanismo Frame transfer Masko Ion Pump

• Provide hardware to control the shutter.

Readout Mode Readout Speed Prebin Window CommentsFull frame Fast or slow X by Y Yes Exposure defined by shutter

Frame transfer Fast X by Y Yes Exposure defined by frame transfer.Frame transfer mask in FT position

Slot mode Fast X by Y Yes Exposure defined by frame transfer.Frame transfer mask in slot position



19

Frame transfer mask in slot positionDriftscan Fast or slow X No Exposure defined by drift rate &

length of CCD (61.5 mm). CCDmust be aligned with edge (4102

pix) in E-W direction.



20

9 Technical Requirements9.1 Software Architecture

Fig. 1 shows the major software blocks of SALTICAM along with the external and internal interfaces.Fig. 1 also shows the languages to be used in the different software blocks.

9.2 Software Interfaces

Table 1 provides details of each of the interface shown in Fig. 1. This data indicated here is for informationonly. The most current data will be identified in the SALT Data ICD, referenced in Section 2.

Table 1: SALTICAM Software Interfaces

Number Interfacingapplications

Description

1,2 CON ´ SDSU Section 5.8 (and 5.7): Communication between CON andthe SDSU through the PCI card.

3 CON Æ Display Section 5.2: Image display by CON.4 Mouse Æ CON Section 5.2: Input to CON from SALTICAM Mouse.5 Time Æ CON Section 5.5: Input to CON from Precision time source.

6,7 CON ´ KER Section 5.6: CON/KER commands/status exchange.8 CON ´ D-Base Section 5.9: Transmission of stored image data to the

science data base. Retrieval of science programsinformation from the science data base.

9,10 KER ´ TCS Section 6.1: KER communication with the TCS via TCSDSS.

11, 12 SALTICAM MMI´ KER

Section 7: Commands and status clusters betweenSALTICAM MMI and SALTICAM KER (at least atpresent).

13 CON ÆSOMMI/SAMMI

Section 5.10: Compressed image from CON toSOMMI/SAMMI.

14 SOMMI, SAMMIÆ TCS

Section 5.1: SALT Command Language fromSOMMI/SAMMI to the TCS. This is not a part of theSALTICAM software suite.



21

9.3 Modes (States) and Events

Figure 2. System Modes

Fig. 2 illustrates the different modes of SALTICAM. See Table 2 for a description of these modes. Table 3describes the mode transitions.

For the remainder of this document, the word “mode” and the word “state” shall be used interchangeably.

PROGRAMMODE

109

INPUTMODE

SPAREMODE

11 13

12

MAINTENANCEMODE

SHUTDOWN OFFINITIAL

READY IN

VIMode

MAJOR FAULT

4

6

7

14

DEAD210

ACMode

SIMode

5

3

8



22

Table 2: SALTICAM Modes

Mode Description Further DescriptionDead Power to Salticam Computer, CCD and

Subsystem Controller, and Cryotigercompressor is switched off.

Off Power to Salticam Computer is switchedoff; power to CCD and SubsystemController, and Cryotiger compressor isswitched on.

CCD Controller, SubsystemController and CryotigerCompressor switched on.These systems shouldnormally always be leftswitched on.

Initialise (orInitial)

Power to Salticam Computer, CCD andSubsystem Controller, and CryotigerCompressor is switched on. In this statethe Salticam Computer is running and thecontrolling application is executing.

SALTICAM computerswitched on. Boot-up scriptshave been executed. Ready toinitialise.

Shutdown Just about to place all subsystems in a safestate before quitting the applications.

Ready in VI,AC or SImodes

All subsystems powered up and initialised:• Detector controller active with default

(VI, AC, SI mode) setup• Detectors at set point temperature• Shutter closed.• Filter unit to default position.• Frame Transfer Mask out of beam.

Controller code down-loaded.MMI selected. All softwaremodules now running. Systemhealth has been checked.

MaintenanceMode

As for VI/AC/SI modes, except that fullinstrument parameters available for MMI.It’s just a more general version of the other“READY” modes.

Under SO control.

ProgramMode

Executing a pre-defined sequence ofexposures (including a single exposure).Program is downloaded to Salticamcomputer from controlling entity.

Can be aborted.

Spare Mode Spare mode in case it’s needed. Used to be IMAGPROC modebefore the SALTICAM mousewas allowed as a pointingdevice

Input Mode Instrument parameters being updated byoperator interaction with MMI.

See those listed in Section 4:“Functional Requirements forSALTICAM CON.

Major Fault Serious errors, which affect the capabilityof the instrument to perform as designed,will place Salticam in this mode. Sensorreadings and status reporting will continueas far as possible. Error reporting must besufficient to guide the SO to the source ofthe problem.



23

Table 3: SALTICAM Mode Transitions

EVENT

From Mode To Mode SENSOR/INPUT

01

DEADOFF

OFFDEAD

Button – Cryotiger CompressorButton – CCD ControllerButton – Subsystem Controller

2 OFF INITIAL Button – Salticam Computer orbootup script

3 SHUTDOWN OFF Button – Salticam Computer orapplication command

4 INITIAL READY On successful power up andauto/operator initialisation sequence

5 READY SHUTDOWN Software/operator initiated shutdownsequence

6, 13 READYPROGRAM

SPARE

MAJOR FAULT Serious error conditions. For example:• Problem with subsystems: e.g.

Filters, Shutter, Frame Transfer Mask.

• Problem with detector temperature• Problem with controller over-

temperature• Problem with fibre data comms.Operator initiated – on detectingproblems

7 MAJOR FAULT READY Serious error recovery – Operatorinitiated

8 MAJOR FAULT OFF Operator initiated: unable to recoverfrom Major Fault mode.

9 READY INPUT ÆREADY

Operator initiated: parameter update.System returns to READY mode.

10 READY PROGRAM Performing a pre-defined sequence ofimages. Operator initiated.

11 READY IMAGEPROCESSING

Post-processing of a pre-obtainedimage from Program modes

12 MAINTENANCEPROGRAM

SPARE

READYREADYREADY

Operator initiated: mode over.Program finished/abortedOperator initiated: mode over.

14 MAJOR FAULT INITIAL Serious error conditions not resolved.Start again further back.



24

9.4 Software Capabilities

9.4.1 Communicationa. SALTICAM SW shall communicate with the other SALT subsystems, using the methods described in

Fig. 1 and the Functional Requirements sections, as amended by the SALT Data ICD.b. The variables communicated shall be defined using the cluster data types identified in the SALT Data

ICD.c. The standard “SALT Communication Module” shall be used to perform LabVIEW Data Socket

communication, at a rate commensurate with the requirements of the applicable data.d. Exceptions to the above shall only be allowed with approval of the SALT Systems Engineer.

9.4.2 Initialisation

a. The SALTICAM PC and SW shall initialise to a safe, known mode. Communication with the SDSUcontroller and subsystem controller shall be established and all hardware shall be placed in a safe,“ready” mode.

b. The SW shall monitor the status of each subsystem’s initialisation and shall only complete initialisationwhen all the subsystems are known to be ready, unless this process is aborted via an operator command.

c. No hardware movement or CCD operations shall be allowed without operator intervention.

9.4.3 Command Interpretation and Generation

a. All commands to/from the TCSS or the Data Processor shall be text-based. These commands will definethe required action and appropriate parameters associated with the action.

b. SALTICAM SW shall interpret the commands and change modes and/or initiate the appropriate action,only if appropriate (see c.)

c. SALTICAM SW shall only initiate actions or change modes, if it is appropriate in terms of safety orallowable instrumental operation. A set of “operating rules” shall define this operation, incorporatingthe actual modes of the instrument.

d. Changing modes shall be implemented using a state machine, following a matrix of present modes,required modes, conditions to be met and actions to be performed.

e. When SALTICAM is placed in maintenance mode, the above requirements can be overridden.f. It shall be possible to operate the instrument in an expanded fashion in Maintenance mode.

9.4.4 Status Reporting

a. SALTICAM SW shall report all status information to the TCS.

9.5 Operating System

SALTICAM SW shall run the Linux or Real Time Linux operating system.

9.6 Resource Allocation

The TCS software shall be capable of performing its function on a PC with the following specifications:- 2GHz Pentium- 256MB memory- 800 x 600 resolution (local MMI)



25

10 Generic Software RequirementsSALTICAM Software shall comply with the requirements specified in the SALTICAM Software DevelopmentPlan and the Labview Coding Standard, as referenced in section 2.



26

11 Software Testing11.1 Verification cross-reference matrix

The software specified herein must be verified for compliance with this specification, as indicated in the tablebelow. Where appropriate, detailed test methods have been defined in the next section.

Spec.Para.

Requirement Test Level[Note 1]

Test Method[Note 2]

Test Detail(see 10.2)

1 Scope N/A2 Referenced Documents N/A3 Customer Furnished Equipment and

ResponsibilitiesN/A

4 Functional Requirements: CON4.1 Program/Exposure Initiation/Termination R4.2 Image Display and Interaction R4.3 Data Storage R4.4 Offsetting and Closed Loop Guiding R4.5-4.8 Communications with Precision Time

Source, KER, PCI and SDSUR

5 Functional Requirements: KER5.1 Communication with SOMMI R5.2 Communication with SAMMI R5.3 Communication with MMI R5.4 Communication with the TCS R5.5 Communication with the Database R5.6 Communication with CON R6 Functional Requirements: MMI R7 Functional Requirements: SDSU R8 Technical Requirements8.1 Software Architecture N/A8.2 Software Interfaces SI/TCS/S T 10.2.18.4 Software Capabilities8.4.1 Communication SI/S T 10.2.18.4.2 Initialisation SI/S T 10.2.28.4.3 Command Interpretation and Generation SI/TCS/S T 10.2.38.4.4 Status Reporting SI/TCS T 10.2.48.5 Operating System SI D8.6 Resource Allocation SI D9 Generic Software Requirements SI RNote 1: Test Level defines the level of integration at which this particular requirement will be verified.This could be SC - Software Component (parts of this software on their own), SI - Software Item (thisspec’s software on its own), TCS (this software integrated with other parts of the TCS), S - System (thissoftware working with the whole telescope).Note 2: Test method could be R- Review, D – demonstrate (not quantitative or precise), T – Test (mostcomprehensive).

11.2 Detailed Test Requirements



27

11.2.1 Interface Test

The interface and communication capability will be tested by the following process:• Check that the correct communication modules are implemented (according to the ICD).• Using the TCSS, check that communication is established with the TCS.• Using the actual subsystems, check that data is correctly passed and interpreted.

11.2.2 Initialisation

This will be verified by starting up the system and verifying that:• All software units are communicating with each other and functioning correctly.• All hardware is safe and in the initialisation position.• All health checks are working.

11.2.3 Command Interpretation and Generation

All commands will be executed and shown to be working.

11.2.4 Status Reporting

All status requests will be generated and the responses checked. Timeouts will also be checked.



28

12 Software Design: SALTICAM KER & SALTICAM CONThis design will be a joint description for the controlling MMI, SALTICAM KER and SALTICAM CON as itmakes most sense to consider them together because these software items have to work closely.

The overall structure of the software is that of “command from the controlling entity” and “status back to thecontrolling entity”. The controlling entity will never be expected to receive commands and take action (althougha sub-status return by SALTICAM CON may “inspire” the controlling entity towards its next action (!), it is notobligatory). The controlling entity will be an MMI: one of SALTICAM MMI, SOMMI or SAMMI (or copiesthereof). The term MMI will refer to any one of these MMIs. Usually that MMI will also have “control” of theinstrument and this should be obvious from the context.

If either SOMMI/SAMMI is the controlling MMI, the implementation of communications will be via the DataSocket Server (DSS) on the TCS machine. The controlling MMI will send SALT Command Language (SCL)commands to the TCS which will translate and publish appropriate cluster information on its DSS. SALTICAMKER will then subscribe to this cluster information.

If SALTICAM MMI is the controlling MMI, it will send cluster information to SALTICAM KER directly.

To comply with SALT Project team preferences:

• Communications between the controlling MMI and SALTICAM KER will be via a Mode Command anda return (top-level) Status.

• The Mode Commands will not be “event” commands but “state” commands. The controlling MMI willissue commands to SALTICAM KER which, if valid, instruct the instrument to “move into” that mode.A specific Mode Command implies that the MMI expects the instrument to remain in, or move into thatmode.

The Mode Commands will be issued repeatedly at 5 Hz. In return, SALTICAM CON will transmit a Status viaSALTICAM KER to the MMI of the actual mode that the instrument is in. Status will also be transmitted at 5 Hz.

Sub-Commands and Sub-Status associated with the instrument in one of its valid Modes will be operated in thesame way as the top-level Command and Status just mentioned.

If the controlling MMI is SOMMI or SAMMI, then these communications will take place via the TCS DSS; ifSALTICAM MMI is the controlling MMI, then the communications will take place directly via communicationsfrom SALTICAM MMI to SALTICAM KER.

SALTICAM CON will manage the details of the hardware control and exposures. It will essentially receive andcarry out commands from the controlling MMI via SALTICAM KER, forwarding commands to the arraycontroller or sub-system controller as appropriate. It will be written in C using the Xforms library and have its ownXforms MMI which is not part of the specification but part of the design, so that the software can be developed,maintained and upgraded easily.

SALTICAM KER will be a LabVIEW application, communicating with SALTICAM CON via named pipesand subscribing to information on the TCS Data Socket Server or directly from its own MMI.

12.1 Mode Command Vocabulary

The primary means of controlling the instrument will be via the Mode Command. Each Command will comprisea string of up to 8 characters which will be sent by the controlling MMI via SALTICAM KER to SALTICAMCON. Refer to Figure 2 for a schematic of the different instrument Modes. Valid Commands have the same name



29

as the Modes. (Some slight variation on this is allowed: thus Major Fault mode is known as MFAULT andInitialise mode is called INITIAL). The Command set is:

Table 4: Mode Command Vocabulary

Command ValidStartingMode

ValidEndingMode

Description

READY-VIREADY-ACREADY-SI

INITIAL READY-VIREADY-ACREADY-SI

Initialise the instrument placing it in VI, AC or SImodes as appropriate. The operations carried outsuccessfully to reach the new mode include:• Detector controller code has been

downloaded. Default setup (VI, AC, SImode) is active.

• Detectors at set point temperature.• Shutter initialised and closed.• Filter unit to default position.• Frame Transfer Mask out of beam.After successfully reaching the new mode, allsubsystems are powered up and initialised andthe instrument is ready for operation.


READY-AC/READY-SI/READY-VI asappropriate


Switch instrument to one of the other modes,taking all action that is necessary to effect this.

READY-MM READY-AC/READY-SI/READY-VI

READY-MM Switch instrument to Maintenance mode.

INPUT READY-AC/READY-SI/READY-VI

INPUT Switch instrument to Input mode allowingparameter adjustment or other instrument inputdata to be supplied.

SPARE READY-AC/READY-SI/READY-VI

SPARE Switch instrument to spare mode allowing asyet undefined operations.

SHUTDOWN READY-AC/READY-SI/READY-VI

SHUTDOWN Switch instrument to Shutdown Mode andplace the various subsystems in a safecondition: filter unit to default position, frametransfer mask out of beam, shutter closed.



30

OFF SHUTDOWN OFF Stop program SALTICAM CON and KER butleave the SDSU controlling the detectortemperature and ion pump. Simply switchingoff the SALTICAM computer should beallowed to achieve the same thing.

READY-ACREADY-SIREADY-VI

MFAULT READY-ACREADY-SIREADY-VI

Attempt to go back to one of the READYmodes after being in MAJOR FAULT mode(hereafter called MFAULT mode), carrying outsuitable checks to ensure that all is now well.Stay in MFAULT mode if the checks still fail.

INITIAL MFAULT INITIAL Attempt to go back to INITIAL mode afterbeing in MFAULT mode, performing suitablebut less stringent checks to ensure that all isnow well. Stay in MFAULT mode if the checksstill fail.

OFF MFAULT OFF Stop program SALTICAM CON and KERafter being in MFAULT mode, but placing thevarious subsystems in a safe condition: filterunit to the default position, frame transfer maskout of the way, shutter closed. Leave the SDSUcontrolling the detector temperature and ionpump.

PROGRAM READY-AC/READY-SI/READY-VI

PROGRAM Start the next program.

(see ProgramSub-Commands)

PROGRAM READY-AC/READY-SI/READY-VI

When the instrument is in PROGRAM mode,it is possible to return it to one of the READYmodes by issuing the STOP or ABORTcommand. However, these commands are readas part of the Program Sub-Commands (seebelow) not the top level Mode commands listedin this table. See below.

READY-AC/READY-SI/READY-VI

READY-MM READY-AC/READY-SI/READY-VI

Leave MAINTENANCE mode, returning toone of the other READY modes.


INPUT READY-AC/READY-SI/READY-VI

Leave INPUT mode, returning to one of theREADY modes



31


SPARE READY-AC/READY-SI/READY-VI

Leave SPARE mode, returning to one of theREADY modes.

MFAULT READY-AC/READY-SI/READY-VI/PROGRAM/SPARE/READY-MM

MFAULT Place the instrument in MFAULT mode. Notethat transition to this mode can also begenerated by hardware conditions duringexecution.

SAVE READY-AC/READY-SI/READY-VI/READY-MM

READY-AC/READY-SI/READY-VI/READY-MM

Save the last image acquired to disk. This isneeded if the Program that acquired the imagedid not write the image to disk, but the userlater wants this to take place.

RECALL READY-AC/READY-SI/READY-VI/READY-MM


Read a previously stored image from theSALTICAM Computer’s disk. This is toinspect or make measurements on a previouslystored image.

DEF-PROG READY-AC/READY-SI/READY-VI/READY-MM


Retrieve the centroid of the last “clicked-on”point source from SALTICAM CON andassume this is the desired projected position inthe focal plane of the next target to be observed.

ACQ-PROG READY-AC/READY-SI/READY-VI/READY-MM


Retrieve the centroid of the last “clicked-on”point source from SALTICAM CON andassume this is the next target to be observed.

The PROGRAM command implies that an associated Program must be read as the first operation. See below fordefinitions of Program Sub-Commands, Sub-Status and other related information.

12.2 Top Level Status

As mentioned already, SALTICAM KER will return top-level Status as its current Mode via an 8 ASCII bytestring. SALTICAM KER will obtain the top-level Status from SALTICAM CON, which will be the controller ofthat status. The valid statuses are obviously one of the possibilities from column 3 of Table 4.

In principle, it would be more logical to describe the INITIAL mode now. However, PROGRAM mode willillustrate more of the design so we turn immediately to this.

12.3 Sub-Commands and Sub-Status in PROGRAM Mode

PROGRAM mode and the initiation of a program to obtain one or more exposures is entered when the controllingMMI sends the Mode command PROGRAM to SALTICAM CON via SALTICAM KER. In addition, theprevious mode command must have been one of the READY commands.

SALTICAM CON detects the Mode command PROGRAM from SALTICAM-KER and responds by settingits top level status to PROGRAM which it sends back repeatedly to the controlling MMI via SALTICAMKER.



32

In PROGRAM mode, the MMI may issue one of the so-called Sub-Commands described below and listed inTable 5:

• The CONTINUE sub-command (indicating no operation is required);• The PAUSE sub-command to pause the current exposure by shutting the shutter;• The RESUME sub-command to resume the current exposure by opening the shutter;• The STOP-RPT command indicating that PROGRAM mode should be terminated after the current

program cycle;• The STOP command indicating that PROGRAM mode should be terminated after the current exposure

(which runs to its normal exposure time), regardless of how many additional exposures are left in thecurrent program cycle;

• The TERMINAT command indicating that the current exposure should be terminated immediately, butthat the data should be read out, stored on disk if necessary and displayed as normal;

• The ABORT command indicating that the current exposure should be terminated immediately, the datashould not be read out and the display should not be changed.

A potential issue is that SALTICAM has, at times, to operate in high time resolution mode. SALTICAM CON maynot then have much time for communications. When operating in high time resolution, the instrument willobviously be in PROGRAM Mode. In this Mode, Sub-Command and return Sub-Status will comprise no morethan 8 ASCII bytes each, so it is likely that such minimal communications will not impact excessively.

Table 5: Sub-Command Specification for PROGRAM Mode

PROGRAMMode Sub-Command

ValidStartingMode

ValidEndingMode

Description

CONTINUE PROGRAM PROGRAM Continue with current operations.PAUSE PROGRAM PROGRAM Pause the current exposure by shutting the

shutter.RESUME PROGRAM PROGRAM Resume the current exposure by shutting the

shutter.STOP-RPT PROGRAM PROGRAM Stop the currently executing program at the

end of the current set of exposures.STOP PROGRAM PROGRAM Stop the currently executing program at the

end of the current exposure which is assumedto run to its normal exposure time.

TERMINAT PROGRAM PROGRAM Stop the currently executing exposure andprogram immediately. The data arenevertheless read out, stored on disk ifnecessary, and displayed as normal.

ABORT PROGRAM PROGRAM Abort the current exposure in the currentlyexecuting program immediately. Do not readout the data, change the display or save anydata to disk.

The valid Sub-Status returned to the MMI in PROGRAM mode will be one of:

Table 6: Sub-Status Specification in PROGRAM Mode



33

PROGRAMMode Sub-Status

Description

IDLE The instrument is neither preparing, nor exposing, norreading out, nor storing on disk. It’s just plain idle.

PREPARE Setting up for the next exposure by moving the FTmask and filter to the correct place, purging the CCDand opening the shutter.

EXPOSING Obtaining the next exposure.PAUSED Pausing the current exposure.READOUT Reading out the current exposure.TODISK Writing the data to disk.ABORTING (Transiently) Aborting current exposure.READINFO Indicating a desire to read target or telescope info from

the TCS DSS.FINISHED This status indicates that the current program has

finished and signals to the controlling MMI that it isready to be commanded back to the appropriateREADY mode.

As mentioned above, an important “flag” that the software needs and should share is the TIMECRIT flag. Thisis set by SALTICAM CON when it requires minimalist interaction with SALTICAM KER and the controllingMMI, because it is so busy. Reasons for its busyness include:

• Reading out the detector and displaying the data. This is a very CPU intensive activity.• Performing very short exposures. This is also a very CPU intensive activity.

The exact circumstances when the TIMECRIT flag will be set will require appraisal of the performance of thesystem.

In TIMECRIT mode, SALTICAM KER will also have to have minimalist contact with the TCS DSSin order to avoid consuming the resources of the SALTICAM PC. The TIMECRIT flag will have its owncluster (as mentioned in Table 20).

12.3.1 Activity On Entering PROGRAM Mode

SALTICAM CON will enter PROGRAM mode when it detects the mode command PROGRAM, and providedthat the previous mode command was one of the READY commands. SALTICAM CON will immediately set itssub-status to IDLE.

The controlling MMI will immediately send the program to be executed (Table 7) via SALTICAM KER toSALTICAM CON. Both the latter software items, knowing that this is about to take place, will take appropriateaction:

• in the case of SALTICAM KER: accepting the program from the controlling MMI and writing it to theappropriate named pipe;

• in the case of SALTICAM CON: reading it from the appropriate named pipe.

SALTICAM CON decodes each program descriptor (see below for details of communication over named pipes)and value to fill a C structure called Pr containing the entities in Table 7 below. It verifies that the values of the



34

elements are within the specified ranges. Unspecified parameters retain the values they had previously, or uponstartup of the program.

12.3.2 Activity On Starting An Exposure

Having received the program to be executed:

• SALTICAM CON will set its sub-status to READINFO. This will signify to the controlling MMI andthe TCS that target and telescope information are required (Tables 10 and 11). The controlling MMIshould send the target information. SALTICAM KER should accept the target information andsubscribe to the telescope information on the TCS DSS, passing both along to SALTICAM CON vianamed pipe. SALTICAM CON will verify that the target and telescope information is within theacceptable parameter range.

• SALTICAM CON will set the hardware up (filter and frame transfer mask) setting its sub-status toPREPARE (see Table 6) to indicate that it is doing this.

• SALTICAM CON will also wipe the CCD clean by executing a “CCD prepare” sequence, maintainingits sub-status as PREPARE (see Table 6).

• SALTICAM CON begins the exposure and sets the sub-status to EXPOSING (see Table 6).

• At the end of the exposure, SALTICAM CON sets the sub-status to READOUT (see Table 6). Thisis the beginning of the readout phase which is extremely CPU intensive. TIMECRIT flag to be sethere? SALTICAM-KER must not expect to see much activity from SALTICAM CON, but shouldbegin a timeout sequence to ensure that SALTICAM CON is still alive after a sufficiently long duration.

• On completion of READOUT, SALTICAM CON will store the data on its local disk. During this brieftime, SALTICAM CON will set its sub-status to TODISK. If disk storage is not specified this step willbe skipped.

• SALTICAM CON will then display the data on its display. Appopriate marks, boxes, slits, overlayswill also be shown at this point.

• If closed loop guiding is required, SALTICAM CON will perform the appropriate calculations andreturn them to the TCS server via named pipe to SALTICAM KER.

• If the exposure counter is less than the number of different exposures in the program (i.e. Pr.Nexp <Pr.Numb_exp), SALTICAM CON will immediately start a new exposure by setting its sub-status toREADINFO. This is necessary so it can solicit the telescope pointing for the next exposure.

If there are no more exposures, SALTICAM CON will set its sub-status to FINISHED (see Table 6).This can then be used by the controlling MMI as the signal to move the instrument back to theappropriate READY mode.



35

While the exposure sequence is proceeding, SALTICAM KER may send any of the sub-commands from Table5. The sub-status, as described above, is returned to the controlling MMI via SALTICAM KER at 5 Hz.

12.3.3 Definition of Windows

This subsection is intended to define windowing for the SALTICAM CCDs. We need to discuss this beforedealing with so-called Programs which specify how exposures are to be obtained. For this purpose, the two CCDsare to be viewed as one detector with a co-ordinate system which extends in the row and column directions fromthe origin in the top left hand corner. This is illustrated in Figure 3. Each CCD has 2048 by 4096 pixels so thedetector co-ordinate systems extends from (1,1) in the top left corner to (4096,4096) in the bottom right corner.The first co-ordinate in the pairs mentioned refers to the row direction, the second to the column direction. Notethat the small gap between the CCDs is to be ignored: the pixel in the top right corner of the left CCD has co-ordinates (1,2048) and the pixel in the top left hand corner of the right CCD has co-ordinates (1,2049), despite thefact that there is a physical gap in the detector. The following table therefore defines the parameters for a set ofwindows:

Table: Definition of Windows

Item Name Units ValidRange

DataType

Description

Nwindows 0 – 10 16-bit integer Number of windowsWin(1,1) 0 – 4096 16-bit integer Row of top left corner of

window 1Win(1,2) 0 – 4096 16-bit integer Col of top left corner of

window 1

Figure 3: SALTICAM Windowing Co-ordinates

Origin: (1,1)

4096Rows

4096 Cols

Row 1

Row 4096

Col 1 Col 4096



36

window 1Win(1,3) 0 – 4096 16-bit integer Number of rows in window 1Win(1,4) 0 – 4096 16-bit integer Number of columns in

window 1…………. …… …………. ………….Win(10,1) 0 – 4096 16-bit integer Row of top left corner of

window 10Win(10,2) 0 – 4096 16-bit integer Col of top left corner of

window 10Win(10,3) 0 – 4096 16-bit integer Number of rows in window

10Win(10,4) 0 – 4096 16-bit integer Number of columns in

window 10

Notes:a. I am aware that LabVIEW indices for arrays run from 0, not 1. It still seems that starting the

window counter from 1 is more intuitive.b. A value of 0 indicates that that particular window is undefined.c. Any prebinning is applied after windowing;

12.3.4 Definition of Programs

All image acquisition will be achieved by the execution of a so-called program. The simplest program is the“SNAP” program: it uses all the “current” camera parameters. The “current” camera parameters are a set ofparameters that are associated with the MMI (see design in the next chapter). Executing the “SNAP” programwill obtain one or more exposures using all “current” camera parameters. This provides for maximum “on-the-spot” flexibility. On the other hand, science users can set up pre-defined programs for their observations. Such“custom” programs will be known by a number in the range 0001-9999. (The string representation of the numberwill be used: 0001 to 9999 so the leading zeroes are important).

A program will comprise a set of parameters needed to fully define an exposure or sequence of exposures. Up to40 exposures through different filters are allowed (repeat mode enables any number of exposures through the samefilter). A feature of the scheme will be the need to define only the parameters that the user wishes. All otherparameters will use the existing value of that parameter at the time the program is initiated. The SNAP programuses only the current values of the camera parameters. The parameters associated with each program are (a fulldefinition of the windows was presented in the last subsection):

Table 7: Definition of Programs


DataType

Description S/C

Pr_Name <=10 chars String Name of the program.Possibilities are presetnames such as SNAP |DARK | BIAS etc. aswell as one of thenumbers 0001-9999 (butstored as a left-justifiedstring). The predefinedprogram SNAP uses allexisting parameters of thecamera. It is thus themeans to take a single“snapshot” exposure.

C



37

camera. It is thus themeans to take a single“snapshot” exposure.

Pr_Autoguide TRUE |FALSE

Boolean Whether or notautoguiding is requiredwith this program

Pr_Shutter OPENSHUT

String Whether the shutter isopen or shut during theexposure (Usually OPENbut with dark exposures itis SHUT!).

C

Pr_Disk TRUE |FALSE

Boolean Whether or not data is tobe stored on disk or not

C

Pr_PB_Rows 1 – 9 16-bitinteger

Row prebin factor for theprogram

C

Pr_PB_Cols 1 – 9 16-bitinteger

Column prebin factor forthe program

C

Pr_Readout_Speed FAST |SLOW |NONE

String Readout speed for theprogram. Option NONEimplies no readout (mainly for diagnostics)

C

Pr_Gain BRIGHT |FAINT

String Gain for the program C

Pr_FT_Mask NONE |HALF |SLOT

String Frame transfer maskposition for the program

C

Pr_Numb_Rpts >=0 32-bitinteger

Number of cycles of thefilter sequence. 0 impliesRepeat mode in whichcase the Program Sub-Command is needed toterminate it.

C

Pr_Numb_Exp 1-40 16-bitinteger

Number of differentexposures in the program.

C

Pr_Nexp 1-40 16-bitinteger

Exposure number withinthe program

C

Pr_Exptime(1) Sec 0.0 –100,000.0

Floating pt. Exposure time of the firstexposure in the program

C

Pr_Filter(1) 1 – 8 16-bitinteger

Filter number of the firstexposure

C

Pr_Filter_Name(1) <=10 chars String Filter name of the firstexposure

C

…………. …… …………. ………….Pr_Exptime(40) Sec 0.0 –

100,000.0Floating pt. Exposure time of the 40th

exposureC

Pr_Filter(40) 1 – 8 16-bitinteger

Filter number of the 40th

exposureC

Pr_Filter_Name(40) <=10 chars String Filter name of the 40th

exposureC

Pr_Nwindows 0 – 10 16-bitinteger

Number of windows forthe program

C

Pr_Win(1,1) 0 – 4096 16-bitinteger

Row of top left corner ofwindow 1

C



38

integer window 1Pr_Win(1,2) 0 – 4096 16-bit

integerCol of top left corner ofwindow 1

C


Number of rows inwindow 1

C


Number of columns inwindow 1

C

…………. …… …………. ………….Pr_Win(10,1) 0 – 4096 16-bit

integerRow of top left corner ofwindow 10

C


Col of top left corner ofwindow 10

C


Number of rows inwindow 10

C


Number of columns inwindow 10

C

Note: I am aware that LabVIEW arrays have indices running from 0, not 1. I think that index 0 is not very intuitivehere but this is open for discussion.

The implication of the instrument moving into PROGRAM mode is that it must read the details of the programas defined in Table 7 above and start executing it. The program will be contained in a separate LabVIEW cluster.No program definitions will be accessible on the SALTICAM PC’s (SDET’s) disk to SALTICAM CON.SALTICAM MMI may store programs on SDET.

In the above table, the rightmost column contains the single character “S” or “C” standing for SALTICAM orControl. This refers to whether the parameter is set by SALTICAM (S) or the controller (C) of the instrument (oneof SALTICAM MMI, SOMMI or SAMMI). This convention applies to the rest of the tables in this document withan S/C column.

12.3.5 Target Information

When the instrument moves into PROGRAM Mode, SALTICAM CON requires information about the target forinclusion in the FITS header for every data file. This information is provided to SALTICAM KER from the TCSDSS (or directly from SALTICAM MMI if it is the controlling MMI) when SALTICAM CON sets thePROGRAM mode sub-status to READINFO. This triggers the controlling MMI to send this information. Thespecific target information is shown in this table:

Table 10: Target Information


DataType

Description S/C

Object_Name <=20 chars String Name of the Target CRA_Target 10 chars e.g. 13:47:11.2 Right Ascension of the

target. Two digits for thehours is compulsory

C

Dec_Target 9 chars e.g. -00:48:23 Declination of the target.The sign is compulsory asare two digits for thedegrees.

C

Epoch Years 1800.0 – 2100.0 Floating pt. Epoch of the Target RAand Dec

C



39

Tr_Rho_Target Degrees -115.0o –+115.0o

Floating pt. Tracker Rho angle at startof exposure

C

Proper_Motion Arcsec/yr

0.0-200 million Floating pt. Proper motion of the target C

Position_Angle Degrees 0.0 – 360.0 Floating pt. Proper motion positionangle: N to E

C

12.3.6 Telescope Information

Information about where the telescope is actually pointing at the start of the exposure is required by SALTICAMCON for the FITS header. It is expected that this information will be supplied by the TCS through its DSS.

Table 11: Telescope Information


DataType

Description S/C

RA_Telescope 10 chars e.g. 13:47:11.2 Right Ascension of thetelescope. Two digits forthe hours is compulsory

C

Dec_Telescope 9 chars e.g. -00:48:23 Declination of thetelescope. The sign iscompulsory as are twodigits for the degrees

C

Epoch Years 1800.0 –2100.0

Floating pt. Epoch of the telescope RAand Dec

C

HA _Hr 9 chars e.g. -00:48:23 Hour angle of thetelescope. Two digits forthe hours as well as thesign are both compulsory.

C

Altitude Degrees +25.0o –+50.0o

Floating pt. Telescope altitude C

Azimuth Degrees 0.0o –+360.0o

Floating pt. Telescope azimuth C

Tracker_Tip Degrees -10.0o –+10.0o

Floating pt. Tracker tip angle C

Tracker_Tilt Degrees -10.0o –+10.0o

Floating pt. Tracker tilt angle C

Tracker_X mm -10000.0 –+10000.0

Floating pt. Tracker X C

Tracker_Y mm -10000.0 –+10000.0

Floating pt. Tracker Y C

Tracker_Z mm +10000.0 –+15000.0

Floating pt. Tracker Z C

Tracker_Rho Degrees -115.0o –+115.0o

Floating pt. Tracker Rho angle C

Only telescope pointing information at the start of each exposure will be available as it is impossible to get thisinformation when a very rapid sequence of exposures is being undertaken.

12.3.7 Status of Program Execution



40

It is necessary to provide status showing progress in executing the current program. Table 8 lists the parametersfor this status information. In Table 8, Pr_AGuide_Ex is the autoguiding indicator. This indicates whether softwareis, in fact, carrying out autoguiding: at the end of each exposure, the centroid of the guide star is determined anda command to the TCS sent to update the pointing of the telescope.

Table 8: Status of Program Execution


DataType

Description S/C

Pr_Name_Ex <=10 chars String Name of the programbeing executed.

S

Pr_Disk_Ex TRUE |FALSE

Boolean Whether or not data is tobe stored on disk or notin the program beingexecuted

S

Pr_AGuide_Ex TRUE |FALSE

Boolean Whether or notautoguiding is takingplace in the programbeing executed

S

Pr_Numb_Rpts_Ex >=0 32-bitinteger

Number of cycles of thefilter sequence. 0 impliesRepeat mode in whichcase the Program Sub-Command STOP isneeded to terminate it.

S

Pr_Nrpt_Ex >=0 32-bitinteger

Repeat number within theprogram being executed.

S

Pr_Numb_Exp_Ex 1-40 16-bitinteger

Number of differentexposures in the programbeing executed.

S

Pr_Nexp_Ex 1-40 16-bitinteger

Exposure number withinthe program beingexecuted

S

Pr_Exptime_Ex Sec 0.0 –100,000.0

Floating pt. Exposure time of thisexposure in the programbeing executed

SC

Pr_Filter_Ex 1 – 8 16-bitinteger

Filter number of thisexposure in the programbeing executed

S

Pr_Filter_Name_Ex <=10 chars String Filter name of thisexposure in the programbeing executed

S

12.4 Instrument Parameter Status

In all modes, except PROGRAM mode with the TIMECRIT flag set, SALTICAM CON will return as status thefollowing set of parameters to the controlling MMI via SALTICAM KER.

Table 9: Instrument Status



41


DataType

Description S/C

Shutter OPEN | SHUT String Indicates whether shutter isopen/shut

S

PB_Rows 1 – 9 16-bit integer Row prebin factor for thecurrent exposure

S

PB_Cols 1 – 9 16-bit integer Column prebin factor forthe current exposure

S

Readout_Speed FAST | SLOW String Readout speed for thecurrent exposure

S

Gain BRIGHT |FAINT

String Gain for the currentexposure

S

FT_Mask NONE | HALF |SLOT

String Frame transfer maskposition for the currentexposure

S

CCD_Temp oC 0.0 – 350.0 Floating pt. CCD cold plate temperature SCold_Box_Temp oC 0.0 – 350.0 Floating pt. Payload cooler box

temperatureS

WindowparametersNwindows 0 – 10 16-bit integer Number of windows in the

current exposureS

Win(1,1) 0 – 4096 16-bit integer Row of top left corner ofwindow 1 in the currentexposure

S

Win(1,2) 0 – 4096 16-bit integer Col of top left corner ofwindow 1 in the currentexposure

S

Win(1,3) 0 – 4096 16-bit integer Number of rows in window1 in the current exposure

S

Win(1,4) 0 – 4096 16-bit integer Number of columns inwindow 1 in the currentexposure

S

…………. …… …………. ………….Win(10,1) 0 – 4096 16-bit integer Row of top left corner of

window 10 in the currentexposure

S

Win(10,2) 0 – 4096 16-bit integer Col of top left corner ofwindow 10 in the currentexposure

S

Win(10,3) 0 – 4096 16-bit integer Number of rows in window10 in the current exposure

S

Win(10,4) 0 – 4096 16-bit integer Number of columns inwindow 10 in the currentexposure

S

12.5 Sub-Commands and Sub-Status in INITIAL Mode

In INITIAL mode, the MMI may issue one of the so-called Sub-Commands listed in Table 12:



42

• The CONTINUE sub-command (indicating no operation is required);• The FILTERS sub-command to initialise the filters;• The SHUTTER sub-command to initialise the shutter;• The FTMASK sub-command to initialise the FT mask;• The CCDCONT sub-command to initialise the CCD controller;• The INITALL sub-command to initialise all the above sub-systems;• The ABORT sub-command indicating that the current operation should be terminated immediately;

The INITALL command is used in normal operation. The other commands are used to test specific systems.

Table 12: Sub-Command Specification in INITIAL Mode

INITIAL ModeSub-Command

ValidStartingMode

ValidEndingMode

Description

CONTINUE INITIAL INITIAL Do nothing.FILTERS INITIAL INITIAL Initialise the filters.SHUTTER INITIAL INITIAL Initialise the shutter.FTMASK INITIAL INITIAL Initialise the FT mask.CCDCONT INITIAL INITIAL Initialise the CCD controller.INITALL INITIAL INITIAL Initialise all the hardware.ABORT INITIAL INITIAL Abort the current initialisation operation.

The valid Sub-Status returned to the MMI in INITIAL mode will be one of:

Table 13: Sub-Status Specification in INITIAL Mode

PROGRAMMode Sub-Status

Description

IDLE The instrument is idle.FILTERS Initialising the filters.SHUTTER Initialising the shutter.FTMASK Initialising the FT mask.CCDCONT Initialising the CCD controllerFINISHED Initialising finished, ready to be commanded back to

the appropriate READY mode.

12.5.1 Initialization Operations

On startup, SALTICAM CON carries out the following sequence (even before the INITIAL command has beenissued by SALTICAM KER):

i) Checks if the precision time module is present - if not, it displays a non-fatal error message.ii) Checks if the Digital Sky Survey server is responding - if not, it displays a non-fatal error message.iii) Starts the pipeline server and checks if there is a pipeline client listening. If not, it displays a non-

fatal error message.



43

iv) Opens the named pipes. If an error occurs in opening the named pipes, it displays an error and willnot write or read to the named pipes any more. This error IS fatal as there can be no communicationwith SALTICAM-KER.

In what follows, it is assumed that the named pipes are working.

v) Sets the mode to "INITIAL" and sends this string 5 times per second to SALTICAM-KER forrelaying on to the controlling MMI.

vi) Waits in a loop for messages from SALTICAM-KER.

It will respond to buttons on the SALTICAM CON interface.

When the controlling MMI sends the INITIAL mode sub-command INITALL (via SALTICAM-KER ofcourse), SALTICAM CON responds by initialising the instrument:

i) Exercises the filters and move the filter unit to the reference position.ii) Exercises the shutter by opening and closing it.iii) Exercises the frame transfer mask and places it in its initial position.iv) Checks communications with the SDSU controller.v) Loads SDSU software to the SDSU controller.vi) Opens the SDSU device driver.vii) Allocates the image buffer.viii) Defines noticeboards.ix) Tests the controller.

An error message may occur during any of these steps, which would be fatal. At present, these are simplydisplayed as informative error messages. If no error messages occur, SALTICAM CON sets the sub-status toFINISHED (and waits for it to be commanded to READY-VI).

12.6 Image Data

At the end of each exposure, SALTICAM CON will send a compressed image of no more than 500 x 500 pixelsto SOMMI or SAMMI for display. This will be done by converting the image, including any marks/boxes/slitsor overlays, to a jpeg file and transmitting it to SOMMI/SAMMI via data socket.

12.7 SPARE Mode

This mode is just a place marker at the moment.

12.8 INPUT Mode

In INPUT Mode, the MMI is expected to issue, through the INPUT Mode Sub-Command, commands as yetunspecified. The details are to be worked out with the SALT System Engineer and other interested parties. Sub-Status will be returned via HOW???. (AND HOW THEN WILL THE END OF INPUT MODE BE



44

SIGNALLED TO THE CALLING SOFTWARE?).

Table 14: Sub-Command Specification in INPUT Mode

INPUT ModeSub-Command

ValidStartingMode

ValidEndingMode

Description

INPUT INPUT Command 1INPUT INPUT Command 2INPUT INPUT …INPUT INPUT Command nINPUT READY-AC/

READY-SI/READY-VI/READY-MM

End INPUT Mode



45

Figure 3. SALTICAM KER Generic Code Structure

12.9 Code Structure of SALTICAM KER

The primary purpose of SALTICAM KER is to provide communications between the MMI and the rest of thesoftware suite. So its code structure is very simple. The general structure will comprise threads as shown in Fig.3.

The top thread refers to the handling of the top level Mode commands (Table 4) while the second thread refers tothe Sub-Commands (Table 5 or 12) associated with PROGRAM or INPUT Modes. The bottom thread refers tothe information coming back from CON via the named pipe (see next section).

InitializationGet andwrite top

level statusto DSS

Read toplevel

commandfrom DSS

Mode change?Pass

commandto CON

Select Sub-Modeand set flag

NO

YES

Mode end?

NO

YESSub-mode Flag

set?

Get andwrite Sub-status to

DSS

Read Sub-commandfrom DSS

Pass Sub-commandto CON

Unset Sub-modeflag

NO

YES

NO

YESData from

CON?

Read datafromCON

Update globalvariables such as

Status, Sub-status,Instrumentparameters



46

Every cycle of the main loop, SALTICAM KER will:

• Read the Mode Command from the data socket server and write top level Status to the data socket serverusing the clusters defined later in Table 20. Except in PROGRAM Mode and with the TIMECRIT flagset, it will write the Instrument Status to the data socket server.

• When the instrument is in PROGRAM, INITIAL or INPUT Modes, SALTICAM KER will read the Sub-Command from the data socket server and write the Sub-Status (as appropriate) to the data socket server.

When moving into PROGRAM Mode, the code must read the Program cluster, SC_Program. The targetinformation cluster, SC_Target (see Table 10) and the telescope pointing cluster, SC_Telescope (see Table 11),must be supplied by the controlling MMI when the sub-status is set to READINFO by SALTICAM CON.

12.10 Image Interaction By SALTICAM CON

Using the SALTICAM PC Mouse, commands to interact with the display are possible. The functionality to beprovided includes:

• Adjust display LUT to change brightness and contrast.• Background subtract, smooth or median filter the displayed image.• Place boxes, markers, windows or overlay catalogues on the display.• Re-display the original image.• Move pointer over display and give readout of pixel position or RA/Dec, pixel value.• Fit Gaussian function to a point source.• 2-d line plot of image brightness.• Aperture photometry to estimate magnitude of an object.

The parameters associated with this part of the program to adjust brightness and contrast, and to backgroundsubtract, smooth or median filter the displayed image should carry over from one exposure to the next so they arenot reset for every exposure. It may be desired to carry out some of the computational actions on every image thatcomes in. Therefore some means must be found to “turn on/off” fitting of Gaussians, 2-d line plots or aperturephotometry to every image.

The numerical results of Gaussian fitting and aperture photometry will be shown on the display and/or returnedto the calling entity by means of the cluster/structure shown in Table 17.

Table 17: Image Analysis Information


DataType

Description S/C



C




C

Actions using buttons on the SALTICAM CON interface are invisible to SALTICAM-KER. For example,zooming and panning are invisible to KER.

12.10.1 Image Marks, Boxes, Slits, Overlays etc.



47

In addition to the functionality described above, SALTICAM CON will receive a cluster/structure ofinformation from the controlling MMI via SALTICAM KER specifying marks to be shown on the imagedisplay. Specifically:

• Direction indicator showing North and East on the image• A ring showing the extent of the 8 arcmin diameter science field of view• A ring showing the extent of the 10 arcmin diameter science field of view• The projected position of the PFIS longslit on the science field of view• The projected positions of a set of PFIS slitlets on the science field of view• The projected positions of one or more optical fibres from the fibre feed• The projected position of a guide probe and a vignetting footprint• Additional catalogs (e.g. the USNO catalogs) or images (the digital sky survey images) to be overlayed

or shown alongside the SALTICAM image

Details remain to be worked out.

Table 18: Display Mark Information


DataType

Description S/C

Epoch Years 1800.0 – 2100.0 Floating pt. Epoch of the Target RAand Dec

C



C




C



48

12.11 Data Clusters/Structures, Software ICD

It has been agreed that commands, data and status to be exchanged between the MMI and SALTICAM KERshould be grouped in LabVIEW clusters/C structures. The clusters needed in terms of the information given inthe previous subsections are:

Table 20: Cluster Specification

Cluster DescriptionSC_Mode Cluster containing the mode command of up to 8

ASCII chars (see Table 4).SC_Status Cluster containing the status as a string of up to 8

ASCII chars.SC_Sub_Comm Cluster containing the sub-command of up to 8

ASCII chars for PROGRAM/INITIAL/INPUTModes (see Tables 5, 12 or 14).

SC_Sub_Status Cluster containing the corresponding sub-status ofup to 8 ASCII chars (see Tables 6 or 13).

SC_Timecrit Cluster containing a single entity: the TIMECRITflag which will be a boolean with value of TRUE orFALSE.

SC_Program Cluster containing the set of parameters describingthe program to be executed (see Table 7).

SC_Program_Ex Cluster containing status of the progress in theprogram currently being executed (see Table 8).

SC_AGuide Cluster containing two numbers: the RA and Decoffset between the measured position of the guidestar and where it should be. The units will be arcsecin both axes (NOT, e.g., seconds of time in RA).

SC_Instrument Cluster describing the instrument status as listed inTable 9.

SC_Target Cluster describing the target information as listed inTable 10.

SC_Telescope Cluster describing the pointing of the telescopeduring the observation as listed in Table 11.

The clusters will be exchanged via the TCS DSS if SOMMI or SAMMI are the controlling MMI (because DSSis not available in Linux’s version of LabVIEW, the data socket server will run on the TCS machine); and directlyfrom SALTICAM MMI to SALTICAM KER if SALTICAM MMI is the controlling MMI.

12.12 Communications Between SALTICAM KER and SALTICAM CON

Communications between SALTICAM KER and SALTICAM CON will take place via named pipes operating inboth applications (a prototype of this has been demonstrated and works well). The communications will take placevia text strings which are terminated by the `\0’ character (as in C).

The clusters listed later in Table 20 will be communicated by the named pipes mentioned in Table 21.

Table 21: Named Pipe Specification



49

Cluster Named PipeSC_Mode /tmp/SC_Mode_RSC_Status /tmp/SC_Status_WSC_Sub_Comm /tmp/SC_Sub_Comm_RSC_Sub_Status /tmp/SC_Sub_Status_WSC_Timecrit /tmp/SC_Timecrit_WSC_Program /tmp/SC_Program_RSC_Program_Ex /tmp/SC_Program_Ex_WSC_AGuide /tmp/SC_AGuide_WSC_Instrument /tmp/SC_Instrument_WSC_Target /tmp/SC_Target_RSC_Telescope /tmp/SC_Telescope_R

The text strings exchanged in the named pipes will be of the form "DESCRIPTOR = VALUE". For example:RA_Telescope = 13:47:11.2. The descriptors will be exactly as listed in the Tables describing the appropriateclusters.



50

13 Software Design: SALTICAM MMIThe purpose of this software is (i) to be in MMI control upon starting of the whole SALTICAM software suite,and (ii) to provide a Maintenance Mode MMI (see Table 2) for controlling the instrument in the absence of theSOMMI or SAMMI machines.

In the description below, SALTICAM MMI is describing as ensuring that information reaches or is retrieved fromthe LabVIEW clusters defined in the tables in the previous section of the document. As things currently stand,SALTICAM MMI will do this by communicating directly with SALTICAM KER. In the case where SOMMI orSAMMI are in MMI control, the exchange of information will take place by SALT Command Language and thenthe DSS on the TCS machine.

HOW IS MMI CONTROL GOING TO BE MEDIATED?

In the light of the design details given in the previous chapter for SALTICAM KER, the design of SALTICAMMMI is fairly straightforward:

13.1 SALTICAM MMI: Mode Commands and Status

SALTICAM MMI must cause Mode Commands, as defined in Table 4, to reach SALTICAM KER’s SC_Modecluster (Table 20) when instructed to do so via the SALTICAM MMI front panel (see later for front paneldefinition).

Top-level status must be retrieved from SALTICAM KER’s SC_Status cluster (Table 20) and displayed on thefront panel.

With the exception of the instrument being in PROGRAM Mode with the TIMECRIT flag set, SALTICAM MMImust retrieve the information in SALTICAM KER’s Instrument Parameter cluster, SC_Instrument (see Table 9),and display appropriate results on the front panel.

13.2 SALTICAM MMI: PROGRAM/INITIAL/INPUT Mode Sub-Commands and Sub-Status

When the instrument moves into PROGRAM, INITIAL or INPUT Mode, SALTICAM MMI must ensure thatSub-Commands as defined in Tables 5, 12 or 14 must continuously reach SALTICAM KER’s SC_Sub_Commcluster (Table 20).

Corresponding Sub-Status as defined in Tables 6 or 13 must be retrieved from SALTICAM KER’s SC_Sub_Status cluster and displayed on the front panel. In PROGRAM Mode, if the PROGRAM sub-status is setto READINFO (by SALTICAM CON), SALTICAM MMI must transmit target info (Table 10) to SALTICAMKER. There must also be the ability to type in the target info on the front panel of the MMI for use in MaintenanceMode.

In PROGRAM Mode, but with the exception of the TIMECRIT flag being set, SALTICAM MMI must retrievethe information in SALTICAM KER’s program-being-executed status cluster, SC_Program_Ex (see Table 8), anddisplay appropriate results on the front panel.

When the instrument first moves into PROGRAM Mode, SALTICAM MMI must cause the definition of theprogram to be executed to reach SALTICAM KER’s SC_Program (Table 7) cluster.

13.3 SALTICAM MMI: Front Panel



51

The front panel needs to display all available parameters associated with the instrument. In particular:

The following Status information needs to be displayed:

• Status (Table 4)• Sub-Status in PROGRAM, INITIAL or INPUT Modes (Tables 6 and 13)• In PROGRAM Mode, the status of the program being executed should be displayed (Table 8).• Instrument parameters (Table 9)

The following Control items are needed:

• Buttons allowing the Mode Commands and Sub-Commands to be sent to SALTICAM KER (Tables 4,5, 12 and 14). Buttons for sub-commands for top-level modes which are not enabled should be greyed outuntil that Mode is enabled. The Mode Command button will exclude the Mode Command PROGRAMto move into this Mode. This is because this button will be used most frequently to initiate imageacquisition, the most frequent task carried out by the instrument.

• Target information (Table 10). This should be enterable by typing in at the front panel controls.• The “current” set of program parameters for the next SNAP program (Table 7) to be executed.• The ability to define new programs (Table 7), store them and call them up later for transmission to

SALTICAM KER and subsequent execution.

All this information may not fit on one panel: tabs will be used to distribute the control and status in a logicalfashion.

A prototype front panel is shown in the attached printed pages and will be incorporate in this document as soonas I can figure out how to do that. Many details remain to be worked out. The Main Menu tab is reasonablycomprehensive.



52

14 Software Design: SALTICAM SDSUNote that SALTICAM SDSU includes the SDSU II controller as well as the PCI and Subsystem Controller blocksin Figure 1.

The overall structure of the software for these modules is that of “command from the controlling entity” and“status/data back to the controlling entity”. The controlling entity for this software is SALTICAM CON.

The general form of response to commands is:

Response DescriptionDON Command completed correctlyERR Error in execution of commandTOUT Timeout. Either the process in the DSP timed out before completion,

or there was no reply from the DSP within a specified time.Data Some commands require data to be returned – e.g. the RDM

command (see below)

14.1 SDSU-PCI:

This software is predefined, purchased with the SDSU system and written in DSP assembler. There are twocommand modes:

• Normal mode: Commands received over the standard communication channels.• Vector mode: Commands received from the host PC that cause an interrupt in the DSP.

The Normal mode command vocabulary is:

Command DescriptionRDA Receive image data and DMA transfer to PC memory buffer. During

this process the PCI module locks out all normal mode commandsand only responds to “vector commands”

IIA Initialize image data processing varaibles (set to 0)TRM Test on-board DRAMTDL Test data link – transmit received message to originatorRDM Read specified memory location & send data to originatorWRM Write data to specified memory location

The Vector mode command vocabulary is:

VectorCommand

Description

$8075 Return number-of-pixels read. This serves to indicate the progress ofthe image readout process.

$8077 Reset PCI DSP.$8079 Abort readout. Stop the readout image transfer process by sending

“Abort” to SDSU Controller.$807B Boot from EPROM. Equivalent to a “cold start” reset.

14.2 SDSU Controller:



53

This software is largely predefined, purchased with the SDSU system. Significant changes have been designedin various components.

The software is written in DSP assembler.

The controller is a dual-CPU system. Controller functionality is split between the two DSP CPUs, whichcommunicate over a private serial bus.

Variables are passed between the controller DSPs and SALTICAM CON by a system of noticeboards. Noticeboards are defined in DSP RAM, the contents of a noticeboard may be read by all CPUs but write privilegesare reserved to one “owner”. The “X” noticeboard is “owned” by SALTICAM CON, the “Y” noticeboardis owned by the respective DSP (Timing or Utility). A third noticeboard – the “P” noticeboard, provides thephysical addresses of the relevant “X” and “Y” noticeboards.

The TIMING DSP:

This handles all time-critical tasks associated with reading out the detector, including

• sets all DC bias and clock voltages• Defines the timing of the clock waveforms for the detector• Defines the timing of the clock waveforms controlling the video processor

In addition the TIMING DSP controls the fibre-optic communication to SDSU-PCI

The command vocabulary is:

Command DescriptionIDL Start idle mode clocking. The detector readout register is clocked

whenever the detector is not reading out an image.STP Stop idle mode clocking.RDC Read out detector & transmit image data.CLR Fast clear the image area of the detectorSGN Set video processor gainABR Abort readoutPON Switch on detector DC biases and clocksPOF Switch off all detector DC biases and clocksFTR Do a Frame Transfer clock sequenceTDL Test data link – transmit received message to originatorRDM Read specified memory location & send data to originatorWRM Write data to specified memory location

Timing DSP Noticeboards:

X Noticeboard: Owner: SALTICAM CON:

Variable DescriptionW_TBL Window table: Array of 220 numbers defining the coordinates of the

windows for the next readout.NFTRO number of rows in a Frame Transfer readout imageNFTX number of rows to shift prior to a Frame Transfer readoutXTOT number of columns in an single CCD in the mosaic



54

YTOT number of rows in a single CCD in the mosaicVD_FLAG video mode flagXBIN Prebin factor in x. Maximum value 9YBIN Prebin factor in y. Maximum value 9WIN_FLG window flag. Activates windowed readoutFT_FLAG Frame transfer flag. Forces next readout to be a frame transfer type.

Y Noticeboard: Owner: SDSU TIMING DSP:

Variable DescriptionERR_NO err numberN_WIN no of windows allowed

The UTILITY DSP

This handles all housekeeping tasks, including:

• Exposure sequence control and exposure timing• Shutter control• Detector temperature control• Telemetry

The command vocabulary is:

Command DescriptionBEX Begin normal exposure sequenceDEX Detect end-of-exposureSFX Begin frame-transfer type exposureAEX Abort exposureOSH Open shutterCSH Close shutterPON Switch on detector DC biases and clocksPOF Switch off all detector DC biases and clocksFTR Do a Frame Transfer clock sequenceTDL Test data link – transmit received message to originatorRDM Read specified memory location & send data to originatorWRM Write data to specified memory location

Utility DSP Noticeboards:

X Noticeboard: Owner: SALTICAM CON

Variable DescriptionDEM_EXP Required exposure time of next exposure. In millisecondsDEM_TEM Required temperature of CCD arraySH_OPT SHutter Flag. When set, shutter opens for next eaposureFT_FLAG Frame transfer exposure flag. When set, next readout is in frame

transfer modeVD_FLAG Video mode flag. While set, the controller repeats the expose-readout

sequence with the current X-noticeboard settings.



55

sequence with the current X-noticeboard settings.

Y Noticeboard: Owner: SDSU UTILITY DSP

Variable DescriptionCUR_EXP current exposure time in msCUR_TEM current temperature in mKSHUT_ST

shutter state ( 0 = open, 1 = closed, 2 = fault )

14.3 Subsystem Controller

This software is written in C.

Document Number 3390AS0001: Software Specification and ... · 1.3 21 Oct 2002 Post-completion...

Documents

Transcript of Document Number 3390AS0001: Software Specification and ... · 1.3 21 Oct 2002 Post-completion...