Last modified on 29 October 2019, at 22:03

SiTech

Revision as of 22:03, 29 October 2019 by Hannah (Talk | contribs) (Troubleshooting)

The SiTech software runs Lesedi on 1ms1 (="1-metre server 1", i.e. Lesedi's TCS PC). 1ms2 is Lesedi's backup machine. There is a main GUI for the telescope (SiTechExe.exe), a communications GUI (ServoSCommunicator.exe), a GUI for each rotator (SiTechRotatorTCP.exe and "SiTechRotatorTCP.exe left"), one for the secondary and tertiary mirrors (SiTechFocuserTCP.exe), one for the dome (DomeControlTCP.exe) and a GUI that communicates with each subsystem's software (ObservatoryControlSAAO.exe). All of these GUIs must be running for the telescope to function fully, and only one instance of each can be run at a time, else problems will arise.

It is vital to ensure that no parameter is changed in any of these GUIs.

Starting SiTech software

The software should be opened on lesedi-nuc, by connecting by ssh to 1ms1 and running the software using the mono library. If working remotely from Cape Town, VNC to lesedi-nuc:

1. Open Remmina Remote Desktop Client, select "VNC" from the dropdown menu and double click on Lesedi_Nuc from the list of servers. Enter the password and the lesedi-nuc desktop will be displayed on the screen.

2. Look for an existing terminal on lesedi-nuc, else open a new one, and log in to 1ms1:

         ssh -Y observer@1ms1.suth.saao.ac.za  (you don't need the full path from inside the network, just observer@1ms1) 

3. Check for existing instances of the software already running:

         ps aux | grep SiTech
         ps aux | grep Servo
         ps aux | grep Dome
         ps aux | grep Obs

4. If any existing jobs are listed and are not open on lesedi-nuc -- and you are sure they are not in use by someone working elsewhere -- kill them all:

         sudo kill -9 xxxx    (where xxxx is the relevant process ID)

5.(a) All the SiTech software can be opened using a startup script in the home directory:

         sudo ./startup.sh

5.(b) or opened individually in the following order, putting each task in the background:

         cd bin 
         sudo mono SiTechExe.exe  (always open this one first, and wait until the GUI has loaded and the message window has closed)
         CTRL-Z
         bg
         sudo mono ServoSCommunicator.exe   (always open this one second, and wait until the GUI has loaded)
         CTRL-Z
         bg
         mono DomeControlTCP.exe &
         mono SiTechRotatorTCP.exe left &
         mono SiTechRotatorTCP.exe &
         mono SiTechFocuserTCP.exe &
         mono ObservatoryControlSAAO.exe &  (always open this one last)

6. If you ever need to restart either ServoSCommunicator or SiTechExe, you will first need to close all the other subsystem GUIs, and reopen them in the order above.


Troubleshooting

1. If a subsystem (rotator, secondary/tertiary mirror, dome) loses comms with ServoSCommunicator, a (pinkish) red warning box will appear in that subsystem's GUI complaining of Bad Comms. The first fix to try is to navigate to the appropriate subsystem's tab in the ServoSCommunicator GUI and reselect the port from the dropdown list. The ports are as follows:

  • Rotators: /dev/ttyUSBRot2
  • Secondary & tertiary mirrors: /dev/ttyUSBFoc3
  • Dome: /dev/ttyUSBDom4

The pink warning box will disappear from the relevant GUI if the problem is resolved.

2. The most common issue is loss of dome comms. There is a watchdog on the dome that causes it to close after five minutes of bad comms - sometimes the warning message does not appear before the dome automatically closes. This problem isn't usually solved using the fix above and ServoSCommunicator will need to be restarted. If the SiTech software was started using the script, you'll need to close all the GUIs and start again. Otherwise you can leave SiTechExe running (you'd probably want to do this if the dome hasn't yet closed, and you want the telescope to keep tracking while the instrument is exposing) and close everything else: first close ObservatoryControl, then the rotator, focuser and dome GUIs, then ServoSCommunicator, and restart in the order given in Step 5b.