LBTO TCS Simulator

The TCS simulation has been packaged to run as a "virtual machine appliance" which is supplied by LBTO to instrument builders. Once this appliance is imported into your virtual machine hosting software (such as VirtualBox, VMWare, etc.), it can be configured to use an IP address appropriate for its host's network. The ICE server in the TCS simulator then listens on that IP for requests from any ICE client.

The control software for any instrument can be made to use the TCS simulator just by configuring its ICE client to communicate with the IP address of the TCS simulation appliance. When an instrument is brought to the LBT, it needs only to change the IP being used by its ICE client to that of the real IIF. The instrument will then be able to drive the telescope.

The timing behavior of the TCS simulation is roughly the same as that of the real TCS. Actual telescope timing for things like guide star acquisition and offsetting is variable depending on observing conditions and many other factors. So you cannot use the simulation to get precise timing information.

Starting the TCS Simulator Appliance

The TCS simulator appliance needs to be started using some Virtual Machine hosting software such as VirtualBox or VMWare. It is wise to keep a copy of the appliance file in it's initial state. Restarting the same VM every time is a convenient way to use the software, but could lead to probems if the software some how gets into a bad state. You need to retain the ability to revert to the original form of the TCS simulator. When you revert, you will have to do some re-initialization/re-configuration.

Running the TCS

Any one using the TCS simulator necessarily puts themselves in the position of being the telescope's operator. Fortunately, only a small fraction of the TCS capabilities have to be understood in order to make it function well enough to develop TCS interface software for an instrument.

The TCS is run through a number of different GUIs which are accessed via a web page. To access the TCS simulator GUIs, type the IP of the simulator into the browser's address bar (where you would normally type an URL). You should see a display like the one shown below. (If you see a blank screen, try clicking the browsers re-load symbol in the address bar or typing a CTRL-R.) This works with most browsers.


LBTO users in Tucson will note that this GUI (and all the other simulator GUIs) looks like a real telescope control GUI in every way. Please take care to not confuse real telescope control GUIs (which may sometimes be found on the screens in the Tucson remote observing room) with control GUIs from a simulation system.

If the background of the GUI is blue instead of gray, try clicking on the "start all" button in the "Network Servers" section (upper left corner). Normally it should start with all network servers running, but the user can stop them by clicking the "stop all" button in the "Network Servers" section. Normally there should be no reason for the simulation user to stop the network servers.

This is the main TCS GUI. From this GUI all others can be invoked. The TCS GUI shows which of the TCS's 16 subsystems is running, and which computer they are running on (in simulation mode, they will all be on the same computer). Each of the red text boxes in the display above describes one TCS subsystem. The 8 subsystems in the upper central column are not "sided", that is, there is only one of each of them running at any time. The two lower groups are 4 different types of subsystems which always have one instance running for each side of the telescope. For simulation purposes you often do not need all 16 of these subsystems running.

LSS is the logging system, DDS is the Data DIctionary Subsystem, IIF is the Instrument Interface Subsystem, ENV is the Environmental subsystem, ECS is the Enclosure Control System, MCS is the Mount Control System, PCS is the Pointing Control System, OSS is the Optical Support System. The sided systems are PMC the Primary Mirror System, PSF is the Point Spread Function (collimation) System, GCS is Guiding Control System and AOS is the Adaptive Optics System.

The GUI above shows all subsystems stopped. A subsystem is started or stopped by clicking its associated "start" or "stop" button (or "kill" if it refuses to stop). In simulation mode we usually do not run the DDS, the ENV, and the ECS subsystems so those should normally show as "stopped". All the rest should be running, except possibly the AOS. The text next to their names should show "tcs-sim" in green letters on a black background. Click "Start" buttons as needed to make the GUI look like the example below. If the scripts or operations you are going to run do not use the AO system, you should stop it (click the AOS "stop" button on both left and right sides of the GUI). In that case, you may need to set up the PSF system for a "rigid" secondary, or vice versa. This is described below.


Note the scroll bar at the bottom of your browser window. At any moment you are seeing only about 1/3 of the total draw space used by the TCS simulator. When you click on buttons to bring up other GUIs, be aware that they may appear on a part of the display which is outside the visible display window. Use the scroll bar to examine the WHOLE draw space and you will find them.


The next thing to check is the instrument authorization. This is done with the IIF GUI (Instrument Interface). Click the "GUI" button for the IIF subsystem (third one from the top). That will open this:IIFGUI.png

You will probably want to keep this GUI open because it shows you, what the TCS is doing with the commands that the instrument is sending to it. The scrolling window at the bottom shows important IIF messages. Messages displayed in red indicate error conditions, bad commands, etc. If a preset or offset fails because the object is below the horizon or the co-pointing limit was exceeded, it will show up there. (The LSS GUI can also be used to see messages from ALL subsystems.)

The first thing to notice in the IIF GUI is the authorization at the top on the left and right. This example shows the IIF has authorized LBC on the left side and MODS on the right. If you intend to use use LUCIFER on both sides, for example, then you should re-authorize for LUCIFER. If you intend to use only one side of the telescope, then you can re-authorize for say, LBC on the left and "NONE" on the right. It is an error condition for an instrument which is not authorized to send commands to the IIF. The commands will be ignored and an error message will be displayed in the IIF GUI scrolling display (and the LSS GUI). Authorization is done with the "Control" button at the top of this GUI. Click that to open this GUI:


The top section allows you to change the authorization. Pull down the menu at the top under "left instrument" and select the desired instrument. Do the same on the right side (shown in the example). So, in our left monocular example it would show "LBC" on the left and "none" on the right. Then click the "authorize" button in the top row center. Notice that this GUI also allows you to select pseudo monocular mode (center region checknboxes) and to cancel or abort a preset. (If IIF gets stuck, and cancel or abort don't work, re-authorizing will often get it sorted out - just re-click the "authorize" button. More on that later.) You can close the control menu immediately after authorizing, but completion of authorization can take many seconds. (The control GUI is normally not needed other than to authorize or abort.) Watch the scrolling messages at the bottom of the IIF GUI to see the messages that say that authorized on left and right side has finished. (It can take about 30 seconds to move the imaginary M3 mirror.)

Just below the "authorize" button is the "Simulator" button. Do NOT click this button. The text next to it should say "No". One might think that, since we are simulating, that this should say "yes", but that is not the case. This is for a different kind of simulation which is not useful in this context. This text is also echoed on the IIF GUI (top, center) , so don't be misled by it.

Mount Control

After the authorization is configured the way you want it, the next step is to open the MCSGUI. Click on the "GUI" button for the MCS (Mount Control System). It will open this GUI:


The "Tracking State" status in the top section should show "HOLDING" for AZ and EL. One or both tracking states may come up in the "Tracker_Vel_Mode" state (meaning servo is in velocity mode). If the last user left the TCS while it was tracking a target, the Tracking State will be "TRACKING". In that case, you should probably click the "HOLD" button on left and/or right side so that the tracking state is "HOLDING". If the Tracking State shows "TRACKER_VEL_MODE, as in this example, then you must click the associated "hold" button (the left one in this example) so that it shows "HOLDING". If the status displays in this GUI are showing just a hyphen, "-", then the TCS simulation cannot talk to the mount simulation - that should never happen. Contact the LBTO software group. You will probably find it useful to keep the MCSGUI open while you are running your instrument. You can stop the mount from tracking by clicking the "HOLD" button for both axes. In a few seconds that will kill the active preset, which is sometimes a desirable thing to do. This is a graceful way to stop the active preset (explained more fully below). You can use the "SlewToHold" buttons to move the telescope to any desired AZ/EL position: enter a number in degrees in the associated text box, hit carriage return so that the text turns from red to black (black indicates a legal argument) and then click the SlewToHold button. That axis will move to that position and stop there. The "on source" indicators at the top of the GUI show if the telescope is on the desired tracking position. On Source goes true if the telescope is within 2.0 arcseconds of the target position for at least 1 second. It is measured separately for AZ and EL and for AZ and EL combined.

Rotator Control

If you are using an instrument mounted at the left front, right front, left direct, or right direct focal station (normally MODS or LUCIFER), then you should next check the state of the instrument rotators for that instrument. (If not, then you can skip this "Rotator Control" section.) The rotators which your simulation will use must be turned on. When you click on the "Rotators" button (center left in the MCS GUI), this GUI will popup:


Select the rotator GUI which you need to see. The example shows the "Left Front" rotator. That would bring up a rotator GUI which probably looks like one of the 2 different states shown below:



Notice the top left "Drive Power" status in the GUI. If it says "off", as in the top image of the GUI, then you have to click the "ON" button to turn on the rotator. It takes about 15 seconds for it come up. If your left front rotator GUI looks like the bottom version, then the rotator is already ON and is ready to use. Check whichever of the rotators that you intend to use. One usually closes these GUIs after they are turned on (unless you need to watch the rotator behavior while you run your simulated observations). Detailed position and speed information can be viewed by clicking the "Position" button.

PCS Subsystem GUI

The PCSGUI shows very detailed information on RADEC and DETXY offset status which may be of interest to an observer to verify that an observing script is doing what is intended. If this is of interest, open the PCS GUI by clicking on the "GUI" button for the PCS subsystem. Like any of the GUIs, it can be closed at any time without affecting the operation of the underlying subsystem.

Again, if you click on the PCS GUI button (or ANY GUI button) and do not see any change in the display, scroll horizontally to find the GUI. The GUI has been opened outside the region of the window which you are viewing.


As RADEC or DETXY offsets are executed and "absorbed", you will see them take effect here.

Using the AOS System

If you intend to use observing scripts which make AO observations, then the AOS system (in the TCSGUI) must be running. If AO is not needed, then the left and right AOS subsystems can be left in a "stopped" condition. Whether using AO or not, you will never need to do anything in the AOS GUI. However, the PSF subsystem may need to be configured for your AO requirements. If you are doing a seeing-limited observation (non-AO), then the PSF GUI should show that the "rigid" secondary is being used. That is the initial default state but the simulator remembers the state it was in when it was last used, so you may find it in a different state. If you want to do AO observations, the PSF GUI should show the "Adaptive" secondary is being used. Open the left and/or right PSF gui by clicking on the "GUI" button for the left or right PSF. The PSF GUI is shown below:


Note that next to the "simulator" button at the left side it must always say "yes". "Yes" is the default state for the PSF in the TCS simulation, but it could be changed to "No" if some one accidentlally clicked the "Simulator" button. So, verify that it is a "yes".

If you intend to do seeing-limited observations then the "Mirror" status should show "Rigid". "Rigid" is selected, the AOS subsystem could be running or stopped. It does not matter. If your scripts intend to use the AO system, than the Mirror status MUST be "Adaptive" and the AOS subsystem must be running.

To change the "Mirror" status, click the "control" button in the PSF GUI. That will open the GUI shown below:


To change the type of secondary, click the "secondary" button in the upper left corner. Regardless of whether you intend to use AO or not, if the Secondary has been selected to be "Adaptive", then the AO subsystem must be running.

Useful TCS Information

Below are listed some useful facts about running the TCS and some explanation of TCS terminology.

There Must be an Active Preset to Command the Telescope

After a preset is sent to the TCS, and the preset acquisition phase is able to complete (does not fail), there then exists an "active preset". That means the TCS has an astronomical target to track and it is tracking it. The IIFGUI has a left and right "preset" status display. Those displays are yellow while a preset's acquisition phase is in progress. Typically "acquisition in progress" means the telescope is slewing to the astronomical target and has not gotten there yet. After it gets there, if the preset mode is GUIDE or ACTIVE, the guider has to acquire the guide star and then the telescope has to be collimated. All of this can go on for a minute or two after the telescope has arrived at the target and the MCSGUI shows that is is "tracking" "on Source". After all that is done, the preset's acquisition phase is said to be "finished" and the preset is now "active". The black on yellow preset status in the IIFGUI will turn to green on black when this state change happens. If the preset mode is "TRACK", then there is no guide star, so no guiding or collimation is done. The acquisition phase will be finished as soon as the telecope is "On Source".

Once there is an active preset running, then the telescope can respond to offset commands. A typical observing script has a preset as its first step. After that, it has a series of offsets and exposures and, possibly even other presets. When the script finishes running and all your data is saved, the preset is STILL "active". The telescope is still tracking. If a preset is active, you could then execute a script which does only an offset and nothing else. If there is no active preset, then an attempt to execute that same script will generate an error from the TCS. It will say "no active preset".

Stopping A Preset, IIF Error Recovery

There may be times when a preset is running and you want to stop it or cancel it. If the MCSGUI shows that the "tracking state" is "TRACKING", then you can abort the preset gracefully by clicking the AZ and EL "HOLD" buttons in the MCSGUI. This makes the simulated telescope mount stop moving and ignore the tracking polynomials coming from the PCS. Within a few seconds the difference between the simulated telescope's actual position and the commanded position will become too large for the IIF to tolerate ("On Source" becomes false) and it will cancel all active presets and re-initialize itself.

The "control" button at the top of the IIFGU will open the control GUI. That GUI also gives you another way to cancel or abort a preset. Experience has shown that in simulation mode the "cancel" and "abort" buttons may not be effective if there has been some kind of error (one that didn't fail the preset). In the real world, the cancel and abort buttons always work, but in simulation mode they are not so reliable. The method described above ("hold" buttons in the MCSGUI) is more effective, if the MCSGUI shows that it is "TRACKING". If you have a problem getting the IIFGUI "preset" displays to show "cancelled" or "failed", one way to usually get the IIF straightened out is to open the IIF "Control" GUI again and re-authorize. That is, just click the "authorize" button at the top of the GUI. That reinitializes a lot of IIF logic and stops any active preset.

Mount and Rotator Control

The mount can be commanded manually even if there is no preset active. This is done with the MCSGUI using the "HOLD" and "SlewToHold" buttons. If the mount is in "TRACKING" state (as shown by the MCSGUI), clicking one of the HOLD buttons will make the associated axis come to a stop and ignore the tracking polynomials it is receiving from the PCS. If there is an active preset, this will kill it. To move the AZ or EL axis to a particular position and have it hold there, type the desired position (in decimal degrees) into the text box next to the "SlewToHold" button for each axis. While you type, your key strokes will be echoed in red. After you hit carriage return, the number will turn black if it is legal. If it remains red, it is out of range and will not be used. Try again. After the text in the the text box is black, then you can click the associated "SlewToHold" button and the axis will move to the indicated position. Most of the other MCSGUI buttons (like stow pins or HBS) do not do anything useful in simulation mode.

If you open one of the Rotator GUIs, you will find it has the same type of manual control as the AZ and EL axes.

TCS and/or IIF Subsystem restart

In rare cases it may be necessary to stop and restart the IIF subsystem or the whole TCS simulation. If that is done, the ICE connection which instrument ICE client has to the IIF ICE server becomes stale and the instrument will no longer be able to communicate with the TCS. In this case the instrument then has to re-establish its ICE conection to the IIF. Experience has shown it is convenient to give the instrument software an easy way to do this reconnection - a button on a GUI, for example.


The control software which runs on each LBT instrument, connects to the LBT Telescope Control System (TCS) by communicating with the TCS's IIF subsystem using an ICE RPC framework. ICE is a software product made by an organization called ZeroC. RPC, or Remote Procedure Call, is a general software concept describing any scheme that allows a program to, in effect, make calls to functions (or subroutines, or methods) which reside in a completely different program. The other program can be running on the same computer as the program making the call, or it can be on some other computer as long as there is a network connection between the two computers. So, ICE client software, running on the instrument control computer, can send commands to the ICE server software running on the TCS. This allows the instrument control software to execute functions in the TCS in order to make the telescope do things like presets and offsets, and to read back TCS and telescope status information.

In normal operation the TCS software is connected to a large number of hardware devices which control all the telescope's systems. Although the TCS was not originally designed to run in a simulation mode, it was possible to retrofit this feature to it. This means we can run a copy of the TCS software on a computer which is connected to no telescope hardware at all, yet it behaves as though it is connected to a real telescope. At least, well enough, so that any instrument software connected to it via the ICE RPC, cannot detect the difference. As long as the RPC commands return the right things at the right time to the instrument, the illusion is complete.

-- %USERSIG{TomSargent - 2017-02-28}%


I Attachment Action Size Date Who Comment
IIFGUI.pngpng IIFGUI.png manage 394 K 28 Feb 2017 - 21:24 UnknownUser IIF GUI
iifControl.pngpng iifControl.png manage 227 K 28 Feb 2017 - 21:55 UnknownUser control GUI
main-1.pngpng main-1.png manage 345 K 28 Feb 2017 - 22:52 UnknownUser  
mainAlt.pngpng mainAlt.png manage 317 K 28 Feb 2017 - 22:42 UnknownUser alt. view of TCSGUI
mcsGUI.pngpng mcsGUI.png manage 289 K 28 Feb 2017 - 22:12 UnknownUser MCSGUI
pcsGUI.pngpng pcsGUI.png manage 255 K 28 Feb 2017 - 23:04 UnknownUser  
psfControl.pngpng psfControl.png manage 37 K 03 Mar 2017 - 21:24 UnknownUser  
psfGUI.pngpng psfGUI.png manage 109 K 28 Feb 2017 - 23:51 UnknownUser  
rotGUI.pngpng rotGUI.png manage 156 K 28 Feb 2017 - 22:57 UnknownUser  
rotGUIon.pngpng rotGUIon.png manage 150 K 28 Feb 2017 - 22:58 UnknownUser  
rotSelection.pngpng rotSelection.png manage 23 K 28 Feb 2017 - 22:33 UnknownUser  
Topic revision: r5 - 14 Mar 2017, TomSargent
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback