During normal observing, the backend computer program which runs the AOS hardware is started by the UIP's AOS command. It is possible, however, to run the AOS software as a standalone program on the backend computer. This is frequently useful for engineering purposes.
It should be emphasised that running the program in standalone mode is never useful for normal observing. This is because the program can only accept commands from one source at a time. If the UIP starts the AOS program, then a TCP/IP port is the source of commands. If the program is run in standalone mode, then a terminal is the source of commands, and none of the UIP commands such ast OO_SCAN and CHOP_SLEWY will work. On the other hand, the backend computer can store scans in CLASS files even if the program is run in standalone mode, because the data are returned via a separate TCP/IP link, which is established regardless of how the program was invoked.
I should mention that while all comments in this memo refer to the AOS software, they apply equaly well to the downconverter software in the backend computer. The only acception is that to invoke the downconverter program, one executes the program /usr/rtm/dwncvtr/dwncvtr on the backend computer. I hope that this same sort of interface will be available on the antenna computer, to allow standalone testing of such things as the Stepper Motor Controller and the Phase Lock Loop.
To run the AOS program in standalone mode, log into my account (rtm) on the backend computer. You can get the password from Ant or me. Once you are logged on, you can start the program by executing the command
AOS {n}
where {n} is the number of the AOS you wish to operate. Note that you should not run the AOS program in standalone mode on AOS {n}, if AOS {n} has already been activated using the UIP's AOS command. I don't know what will happen if you do that, but it won't be pretty.
Once you've started the program, you will see a few messages scroll by as the program established its TCP/IP links to the VAX. Then the main menu will be printed. Basically all you must do from this point on is to chose options from this main menu and its submenus. If at any point you accidentally get to a menu that doesn't offer any option that you want to select, you may enter a number that doesn't appear in the menu, and the program will return to the main menu.
Option 4 on the main menu starts the background threads which actually run the AOS. Selecting this option will cause the program to start taking frames from the AOS, and to open an X window for display. If you want to re-direct the display to an X device other than the backend computer's own display, you must do this before selection option 4 and starting the background threads. To re-direct the X display, choose option 8 on the main menu, and option 2 on the menu which appears next. Then enter the IP address of the X display in the form xx.yy.zz:0 - exactly as you would if you were using the "setenv DISPLAY" command within the UNIX C shell. I would recomment entering the address numerically.
When the VAX sends commands to the AOS program, it traverses menus just as you will in standalone mode (the menu text isn't actually sent to the VAX, of course). So if you want to get the VAX to tell the AOS program to do some unusual function, you can first figure out how to do it by running the program in standalone mode, and then tell the VAX to select the same menu options. For example, if you want to turn the calibration comb on in the 50 MHz AOS, you would select option 7 on the main menu, and then option 3 on the submenu. Later, when the 50 MHz AOS has been activated by the UIP's AOS command (and you are not runing the program in standalone mode), you could have the VAX turn the comb on by issuing the UIP command
UIP> TO_A/50 7~3
Note that the ~ in the TO_AOS command tells the VAX to send a carriage return, so the above command sends 7{carriage return}3{carriage return} to the AOS program.
back to CSO documentation page
Taco (rtm@tacos.caltech.edu)
December 27, 1995