MCAO Control System

1
MCAO Control System

• Corinne Boyer

2
Changes since the CoDR

• The requirements for all the sub-systems of the
  MCAO have been modified and refined.
• The Interface Control Documents (ICDs) between
  MCAO and the other telescopes systems have been
  written as well as the internal sub-system
  interface ICD.
• Preliminary design documents (mainly flow
  diagrams) have been written for some of the
  sub-systems.

3
MCAO sub-system of the OCS - 1
4
MCAO sub-system of the OCS - 2

• This solution is different from the one chosen
  for the Altair, which is a subsystem of the TCS.
  The reasons are
• The MCAO system is an independent system with a
  minimal interface to the TCS,
• The MCAO system needs to be synchronized with the
  other instruments controlled by the OCS,
• There will be some very complex sequences that
  need to be done at the level of the Sequencer
  which will be most efficiently performed by using
  a direct-access tool like ocswish.

5
Position in the Gemini architecture
6
Interface with other sub-systems
7
Interface Control Documents

• Interfaces are described in the following ICDs
• ICD 1.13.5/3.1 MCAO to OCS
• ICD 1.13.5/1.6 MCAO to AG
• ICD 1.13.5/1.4.4 MCAO to SCS
• ICD 1.13.5/1.1.11 MCAO to TCS
• The MCAO system uses the standard GIS interface
  already described in ICD 1.1.13.
• Note that there is no interface to the Gemini
  Data Handling System. Diagnostic displays will
  require very high refresh rates and so will be
  generated and sent directly to video displays.

8
MCAO controller architecture

• The MCAO control system will be split in six
  independent sub-systems
• The Real Time Controller,
• The AOM Component Controller ,
• The BTO / LLT Component Controller,
• The Laser Controller,
• The SALSA Controller,
• The Diagnostics Wavefront Sensor Controller.

9
Gemini model

• The MCAO control system will be implemented using
  the standard Gemini control system model.
• An Instrument Sequencer will manage the 6
  independent subsystems and act as the main public
  interface for the entire MCAO system.
• The sequencer will coordinate all of the internal
  tasks and provide external systems with the
  commands and status information they need, to
  control the MCAO System.

10
System hierarchy
11
MCAO Sequencer - 1

• The Sequencer will be implemented using only
  standard EPICS records.
• Command and status information that pass between
  the OCS and MCAO systems is described in the
  OCS/MCAO ICD.
• The commands reboot, initialize, datum, park,
  test, simulate and debug will be implemented to
  perform global actions on all of the associated
  devices for all the sub-systems.

12
MCAO Sequencer - 2

• The standard commands pause, continue, stop and
  abort will not be implemented. The observe
  command will be rejected during the preset
  directive and the others commands verify,
  endVerify, guide, endGuide, endObserve will be
  ignored.
• Night operation and calibration and maintenance
  sequences will be implemented using ocswish tool.
• The setup/engineering command set can be found in
  the MCAO Internal ICD.

13
BTO/LLT Component Controller

• This sub-system is responsible for managing all
  of the opto-mechanical devices associated with
  the BTO and LLT under the direct control of the
  MCAO Instrument Sequencer.
• The commands initialize, datum, park, test,
  simulate and debug will be implemented to perform
  global actions on all of the associated devices.
• The component controller will be a hybrid
  EPICS/VxWorks implementation which uses a mix of
  standard EPICS records and custom assembly and
  device control records and also dedicated VxWorks
  tasks.

14
BTO/LLT CC Interfaces

• The BTO/LLT CC will interface directly with
• the RTC to receive Fast Steering Array commands,
• the SALSA sub-system to sense the state of the
  SALSA shutter,
• the Gemini GIS system to disable all motions in
  the case of a hardware interlock,
• the TCS system to read the telescope pointing
  information.

15
BTO/LLT CC Design - 1
16
BTO/LLT CC Design - 2
17
BTO/LLT CC Design - 3
18
BTO/LLT CC Design - 4
19
BTO/LLT CC Design 5

• The BTO/LLT CC will be implemented using two
  separate CPU boards.
• The first CPU board will provide the EPICS
  interface and all device control. This board will
  also implement the following slow closed loop
  algorithms
• PM, KM, CM closed loop,
• Beam diagnostic WFS and CA and PA closed loop,
• Quarter wave plate closed loop.
• The second CPU board (non EPICS) will be
  dedicated to the fast TT mirror control at 800Hz.
  
• All of the closed loops will maintain circular
  buffers to hold debugging and display history
  data.

20
BTO/LLT CC hardware environment
21
AOM Component Controller

• This sub-system is responsible for managing all
  of the opto-mechanical devices (except the DM,
  TTM and the readout of the WFS) associated with
  the AOM under the direct control of the MCAO
  Instrument Sequencer.
• The commands initialize, datum, park, test,
  simulate and debug will be implemented to perform
  global actions on all of the associated devices.
• The component controller will be an all-EPICS
  implementation based on the Gemini Altair model
  which uses a mix of standard EPICS records and
  custom assembly and device control records.
• All of the closed loops will maintain circular
  buffers to hold debugging and display history
  data.

22
AOM CC Interfaces

• The AOM CC will interface directly with
• the RTC to receive LGS WFS pupil alignment data,
  to receive NGS probe position offsets and to send
  NGS probe positions,
• the SALSA sub-system to sense the state of the
  SALSA shutter,
• the Gemini GIS system to disable all motions in
  the case of a hardware interlock,
• the TCS system to read the telescope pointing
  information and to receive NGS probe position
  demands,
• the AG to read OIWFS data,
• The OCS to receive observing data.

23
AOM CC Design - 1
24
AOM CC Design - 2
25
AOM CC Design - 3
26
AOM CC Design - 4
27
AOM CC Design - 5
28
AOM CC hardware environment
29
SALSA Controller

• Presented with the SALSA sub-system later in the
  morning

30
DWFS Controller Requirements

• The Diagnostic Wavefront sensor is 32x32
  sub-aperture SH WFS, each sub aperture being
  composed of at least 16x16 pixels. A 1024x1024
  standard CCD will be used.
• This diagnostic WFS will only be used during the
  day to calibrate the DM commands to insure the
  science path wavefront quality.
• Basic signal processing will be required at a
  slow rate
• read the pixel image, save to a file,
• subtract a dark to a pixel image,
• compute the centroids and save the centroids to a
  file.

31
DWFS Controller Design

• A frame grabber installed on a PC system or on a
  Unix host will be implemented to read the pixel
  data.
• Two solutions to perform signal processing
• Use of WaveLab,
• in house developed IDL routines.
• In the two cases, it will be very easy for the
  instrument sequencer to interface these tools.
• Interface with MCAO sequencer has been defined
  and is described in the ICDs.

32
Real Time Controller

• This controller is dedicated to the AO control
  loop itself. It is the heart of the system and
  the most critical in terms of real time
  performances
• It will handle 3 basic real time functions
• The NGS real time control loop,
• The LGS real time control loop,
• The optimization and background processes.

33
RTC block diagram
34
LGS process Requirements

• Five 16x16 SH WFS (2x2 sub-aperture). Total 2040
  illuminated sub-apertures
• EEV CCD39s with 4 outputs and 80x80 pixels each
• 3 DMS (total active actuators 636)
• DM0 21x21, active 240, extrapolate 109
• DM45 24x24, active 276, extrapolate 192
• DM9 17x17, active 120, extrapolate 121
• Rate up to 800Hz
• Number of operations 2.26GFlops.

35
NGS process requirements

• 3 tip/tilt sensors using APDs
• 1 TTM
• 3 DM modes
• Rate up to 800Hz
• Operation number 3.16 MFlops

36
RTC synchronisation
37
Computation requirement summary

• Computation requirement also estimated for all
  optimization and background processes.

38
RTC architecture

• Since the CoDR, 2 actions
• a VSS4 Synergy Micro Systems board a VME64 back
  plane has been purchased VME DSP-Quad PPC
  7400_at_433Mhz, 256 Mb, 8Mb Backside Cache (21
  ratio), VME64x. Benchmarks are right now
  performed by HIA to assess the suitability of
  this board.
• contract some vendors to study other
  architectures for our requirements. Two vendors
  have been selectioned
• The Optical Science Company (tOSC), located in
  Anaheim-California,
• SHAKTIWARE, located in Marseille France.

39
One possible RTC approach
40
RTC software design

• RTC will be a hybrid EPICS/VxWorks system
• Minimal software design for on the baseline
  approach presented in the document (architecture
  is not yet defined)
• Interfaces with other systems described in the
  ICDs
• with the TCS to read pointing data and cass
  rotator angle and to send M1 data and cass
  rotator angle offset,
• with the AG to read OIWFS data and seeing data,
• with the SCS to send M2 data,
• with the SALSA sub-system to sense the state of
  the SALSA shutter,
• with the Gemini GIS system to disable all motions
  in the case of a hardware interlock
• with the AOM CC to receive NGS probe positions
  and send NGS probe offsets and pupil alignment
  commands
• with the BTO CC to send FSA commands
• All of the closed loops will maintain circular
  buffers to hold debugging and display history
  data.

41
PDR Agenda

• Friday, 5/25
• 0800 Laser System
• 0900 CTIO Sodium Studies
• 0915 Control System
• 0945 Break
• 1000 RTC Electronics
• 1045 Safety System
• 1100 Availability analysis
• 1130 Closed vendor Sessions
• 1200 Lunch

• 1300 Cost and schedule
• 1400 Committee session
• 1700 Committee report
• 1800 Adjourn

42
RTC benchmark and studies

• VSS4 benchmark
• linux installed
• Benchmark in progress. First results presented by
  Les Saddlemyer HIA
• tOSC study
• Investigate how VME/PCI architectures based on
  SHARC, PowerPC G4 processors associated with
  floating point/fixed point processing will fully
  conform the MCAO requirements.
• Draft report delivered for the PDR and results
  presented now by Steve Brown
• SHAKTIWARE study (Joint funding Gemini and ESO)
• Investigate the different processors (DSP, PPC
  and FGPA) as well as COTS boards which will fully
  meet the MCAO requirements
• Final report delivered for the PDR and results
  presented now by Didier Rabaud