• Acquisition
  • Nothing on OSPEC

• Global Server
  • Global Server Disconnect

• Detector Servers
  • Recover from Aborted Exposure
  • Restart a Failed Detector Server

• Servers (General)
  • Cannot start a server

• Motor Mechanisms
  • Filter Wheel Fault

Acquisition

Nothing on OSPEC

Symptom

After acquiring a star, there's nothing in the online data cube

Problem

Several possibilities:

1. Pointing origin is off
2. Filter change
3. DAR issues

Solution

Most of these issues are fairly minor and can be fixed by some additional steps during acquisition. If you're well and truly lost, try offseting to the OSIRIS imager to find your target as described in the Acquistion Cookbook.

1. To compensate for an incorrect pointing origin:
   1. Note the pixel of the star in the ORP cube from the AO checkout.
   2. Use the OTGUI to offset from that pixel in Hn3 0.020 scale to the center of your filter/scale combination.
   3. Make this offset before taking data on subsequent acquisitions.
2. The dispersing elements in OSIRIS are fixed so different filters illuminate different lenslets. If you change filters you must:
   1. Use the OTGUI to send the object from the center of filter/scale #1 to the center of filter/scale #2.
3. DAR = Differential Atmospheric Refraction. The OSPEC FOV is small enough that DAR is a factor. If you've done the initial offsets as described above, but still don't see light, please check:
   1. Does the AO system have the correct B-V for your object?
   2. Was DAR on from the LgsaoAcq Widget?

Global Server

Global Server Disconnect

Symptom

You see a popup on each Java GUI with a "KTL_OPEN" error.

Problem

Many possible causes, but essentially, the global server has lost communication with one or more sub-servers.

Solution

Restart the failed servers

1. If it's a detector server, first recover the failed detector server. Otherwise, restart the server via "osiris stop [server]", then "osiris start [server]"
2. The global server should automatically reconnect. If it does not, restart the global server via "osiris stop osiris", then "osiris start osiris".
3. If the above steps fail, you may try issuing an "osirisDisconnect", then "osirisConnect" to stop and restart all the servers.

Detector Servers

Recover from Aborted Exposure

Symptom

After issuing an "Abort All Immediately" command from the ODEC, one or both of the detectors does not take images.

Problem

Detector needs a re-initialization or the detector server needs a restart.

Solution

The first two steps can be performed by the observer. The restart of a detector server requires the SA (for now).

1. From the "OSIRIS" tab of the OTGUI, Flush the unresponsive detector.
2. Once the flush is complete, issue one of the following commands from a napili prompt:
   1. "modify -s osiris sinit=1" (for the SPEC detector)
   2. "modify -s osiris iinit=1" (for the IMAG detector)
3. If this does not solve the problem, please contact your support astronomer to restart a failed detector server.

Restart a Failed Detector Server

Symptom

One cannot take images with one of the two detectors.

Problem

The detector server has become unresponsive, possibly due to an "abort exposure" command.

Solution

Restart the detector server and reset keywords via the osirisRecover script.

1. Issue the command "osirisRecover [IMAG|SPEC]" from a napili prompt.
2. The script should make everything ok. Please note that this script CAN be run while taking data with the other detector.

Servers (General)

Cannot start a server

Symptom

When starting osiris keyword servers, you see many RPC errors.

Problem

The RPC info table may not have been cleared.

Solution

Clear the offending entry in the rpcinfo table

1. Login to osiris on napili: "ssh osiris@napili"
2. View the RPC table: "rpcinfo"
   

    798049830    1    tcp       0.0.0.0.128.126     server_op1s 726
    798050830    1    tcp       0.0.0.0.128.137     server_op2s 726
    798082830    1    tcp       0.0.0.0.128.149     server_oprs 726
    798449830    1    tcp       0.0.0.0.128.159     server_ot1s 726
    798450830    1    tcp       0.0.0.0.128.169     server_ot2s 726
    798467830    1    tcp       0.0.0.0.128.179     server_otcs 726
    797749830    1    tcp       0.0.0.0.128.189     server_om1s 726
    797750830    1    tcp       0.0.0.0.128.199     server_om2s 726
    797751830    1    tcp       0.0.0.0.128.209     server_om3s 726
    797752830    1    tcp       0.0.0.0.128.219     server_om4s 726
    797753830    1    tcp       0.0.0.0.128.230     server_om5s 726
    797754830    1    tcp       0.0.0.0.128.241     server_om6s 726
    790000000    1    tcp       0.0.0.0.129.235     server_osiris 726
                   

3. Remove the offending server entry: (e.g. "rpcinfo -d 797750830 1" to remove om2s)

Motor Mechanisms

Filter Wheel Fault

Symptom

Red X appears over spec filter in status gui.

Problem

Failed to achieve switch position

Solution

State the solution to the problem here, numbering the steps to be taken:

1. show -s om2s switch
2. show -s om2s pos
3. show -s om2s switch17 (if, for example, result from pos was 17)
4. modify -s om2s lockeng= 060817 (civil date)
5. modify -s om2s switch17= 128 (if, for example, result from switch was 128 which differed from switch17 read in step 3)
6. Note: If the problem with the switch mechanism resolves itself (as often happens) follow the above steps to restore the expected grey code back to the default value. In this case you do not need to reset the lockeng keyword.