Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.naic.edu/~jeffh/cima.html
Дата изменения: Mon Dec 1 22:21:53 2003 Дата индексирования: Mon Oct 1 20:23:10 2012 Кодировка: Поисковые слова: occultation |
This is a primer on how to use the new AO observing system called CIMA, Control Interface Module for Arecibo.
To start CIMA offline from sun or linux:In all cases this will open a number of windows:
The old gui forced a set of windows on you. It blocked for possible responses and could hang. In the CIMA gui, you can bring up any window at any time. You can load and save parameters. Only when you tell CIMA to apply parameters or to start an observation does it effect the state of the telescope. The CIMA gui has the observing executive which receives the start and apply commands and makes them happen. This is where the observation blocks, waits for various events to occur. It tells the pointing system where to point, the IF/LO system to configure, and tells the backends to start. Separating the control aspects from the GUI aspects was crucial to the design.
Commands sent to the executive take time and these are not queued. For example, if you press "Start Observation" twice, the first will start the observation and the second will respond with "The executive is busy".
This is a "gif" file. Jpg looked bad too, what should I use?
The gui has the beginnings of a controllable on-line data displayer. To enable this choose "User Preferences" and then "Control IDL".
On the Control IDL window choose "Enable IDL". Then select the "Make hardcopy print of calibrate" checkbox if thats what you want.
Then, whenever you do a calibrate, IDL will display the result on the second screen. This takes a number of seconds. However, CIMA and the executive will not block. You can start your next observations as soon as the calibrate finishes.
Currently the displayer only displays and prints the result of a calibrate. Improvements here are coming soon.
Remember as to the control of the IF/LO system, the telescope pointing system and the interim correlator, this GUI is a house of cards on top of the old vxworks command line interface. Things sometimes mysteriously change and vxworks hangs or there is a new error message in a format that I havent seen yet or something. All you have to do is press abort to release the executive from blocking for a response from vxworks. This occurs occasionally when doing a quick tsys or configuring the IF/LO system. This is an on going battle and I havent yet found all the combinations. To address this problem, I am working to provide better support the WAPP as correlator and send lower level iflo commands.
If you find something wrong please let me know about it. In fact, I do have a life and I dont live at the telescope. But feel free to call me anytime. The telescope operator has my number. I want this to work in spite of the forces of evil working against it.
The CIMA gui now does everything the old gui does and more. It offers more information on the aostatus screen. The CIMA gui supports WAPP spectral line data for the Standard On and Standard On/Off functions in class format. The CIMA Gui supports the WAPP in all its modes including 4 WAPPs modes and raw sampling.
Sometimes when you select a receiver and allow the system to do a tsys, it will do a tsys on the wrong receiver. When this happens, press abort, select the receiver again but delelect the tsys checkbox.
Until I get to it, use the old gui for the other pulsar machines.
Also, the radar interface is supported from CIMA. The old one still functions in the same way without CIMA.
Another note. When you save a correlator configuration the file extension is will automatically be .gui. The user can optionally include it. It also saves the state of the spectral line options too. Placing this under correlator doesn't seem right. We need to discuss this.
Old correlator configuration (.par, .sls ) files are not applicable. The old feature of creating backward compatible vxworks source files is not currently supported. Loud enough complaints could change this but continued support will continue the dependence on observing scripts. It is my opinion that most observing here is not "special case" observing and if we only expanded our set of GUI parameters by a small factor we could support most observers.
I consider this a released product, but there are a few things I still need to do.