Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://vega.inp.nsk.su/~inest/OCAAS/ocaas17-23.ps Äàòà èçìåíåíèÿ: Fri Mar 16 13:05:40 2001 Äàòà èíäåêñèðîâàíèÿ: Mon Oct 1 19:59:00 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ð ï ð ï ð ï ð ï ð ï ð ï ð ï ð ï ð ï ð ï ð ï

obsreq
*.edb
*.sch
pc39.o
gpsd
wxd
telescoped
domed
camerad
telsched telrun
(tty)
apogee.o
xephem
xobservatory
camera
telrun.sls
Batch
Real­time
shm
OCAAS Data Flow
driver
process
GUI
file
fifo shared­mem I/O
telsched.cfg
camera.cfg
domed.cfg
focus.cfg
filter.cfg
wxd.cfg
telescoped.cfg
Introduction
OCAAS 2.0 November 12, 1998 1­7
1.4 Basic Software Architecture
OCAAS design takes full advantage of the UNIX architecture. It uses long­running daemon
processes to manage the low­level drivers which communicate with the actual hardware. These
daemons are accessed using simple text commands via fifos (also known as named pipes). The
commands which flow over these connections are high level and allow the daemons to hide all
hardware dependencies. These fifos are used by Graphical User Interface, GUI, processes to
offer real­time control of the system and by the batch scheduling processes to control the system
without direct user intervention. All daemons store their current state in a common shared
memory segment which processes may use to efficiently learn of current system state and
activity.
1.4.1 Data flow diagram
Follows is a diagram which summaries typical data flow through the system. Refer to the diagram
during the discussion which follows. This diagram is typical and some systems are built slightly
differently. This flexibility is a significant feature of this design.
1.4.2 Device Drivers
Starting on the right side of the diagram, the hardware is controlled using three drivers. Two of
these drivers, pc39.o and apogee.o are part of the OCAAS system. These are actually Linux
loadable drivers and are installed when the system boots from /etc/rc.d/rc.local.

Introduction
1­8 November 12, 1998 OCAAS 2.0
1.4.2.1 PC39
The stepper motors are controlled via the driver module for the OMS PC39 intelligent motor
controller. This driver provides synchronized message­based access to the controller from
multiple user processes. The driver supports the open, write, select, ioctl, and close file
operations. The special file to access the driver is $TELHOME/dev/pc39. The module itself is
pc39.o in the same directory. In the configuration depicted in the diagram, one process,
telescoped, uses the PC39 to control the motors, home and limit switches on the telescope
mount, focus motor and field rotator. Another process, domed, uses the PC39 to operate the
devices connected to the dome and shutter.
1.4.2.2 Camera
The CCD camera is controlled via a second driver module. This driver provides a uniform
interface for all brands of CCD cameras. Functions include:
. setting exposure parameters
. reading the cooler temperature and status
. setting a target cooler temperature
. initiating an exposure
. choice of blocked or polling notification of exposure completion
. reading the pixels from the camera
. aborting an exposure before it completes
Exposure parameters include whether the shutter should be opened, the location of a Subframe,
horizontal and vertical pixel binning factors, and exposure duration in seconds. The driver
supports the open, read, select, ioctl, and close file operations. Since this interface is generic
across all the cameras supported by OCAAS, application programs use a symbolic link,
$TELHOME/dev/ccdcamera, to access the camera. This link points to the special file of the
camera driver actually installed. In the configuration depicted in the diagram, the driver is one
which operates all models of camera from Apogee Instruments. This driver has a special file
named $TELHOME/dev/apogee. The module itself is apogee.o in the same directory.
1.4.2.3 Serial ports
The third driver is not really part of OCAAS but is part of the Linux distribution to access RS232
serial ports. These ports are used to connect to various peripherals such a sa weather station,
GPS receiver and auxiliary temperature sensors. If the computer does not have sufficient RS232
ports available, a multiport serial card can be used. We can report excellent results using the
Stallion EasyIO 4 port multiport board and their driver version 5.3.3.
1.4.3 Daemon processes
UNIX traditionally uses the term daemon to refer to processes which are runnable all the while an
application is active on the system and which have no direct user interface. Such is the case for
all processes described in this section. The OCAAS daemons can be started from the standard
Linux system start­up file /etc/rc.d/rc.local which runs the script $TELHOME/archive/config/boot.
This script in turn takes instructions from boot.cfg which varies per site depending on the exact

Introduction
OCAAS 2.0 November 12, 1998 1­9
configuration and whether the system was configured to be completely autonomous or to have a
real­time user interface.
Each daemon listens for relatively high­level commands and issues responses back using several
pairs of fifos (also known as named pipes) for interprocess communication. All fifos reside in
$TELHOME/comm. The fifo names end with .in when they are being read by a daemon, and end
with .out when being written by a daemon. Also in the comm directory are lock files containing the
pid of each daemon and insuring that only one instance of each daemon is running at one time.
All fifo traffic is the form of ASCII text. This is very handy for testing because commands can be
sent and received using simple UNIX tools such as echo and cat.
The daemons convert the high­level commands into system­specific commands to suitable device
drivers to carry out the command. When the commands are complete, or if errors occur, they
issue a response back via these fifos. Thus, fifo messages to the OCAAS daemons are always
initiated by a client process which always receives a response. The daemons never initiate
communications to other processes via the fifos. In this sense, the daemons may also be referred
to as server processes.
Note that processes using the fifos are not aware of the architecture of the daemons. There may
be one daemon handling each fifo, one handling all or any other combination. This allows the
implementation to take advantage of specific operating system and hardware features without
effecting application processes. It also allows sites to be uniquely configured by creating
daemons specifically matched to, say, an existing dome controller, by just dropping in a new
daemon (and possibly new hardware drivers).
All fifo responses are in ASCII and follow the same format: an integer, one space, then a brief
English description. The integer 0 always indicates success. Negative values indicate failure.
Positive values are used for intermediate progress reports. These and all subsequent fifo traffic
details are subject to change. Contact CSI for the latest detailed list.
1.4.3.1 telescoped
The telescoped daemon is usually responsible for operation of the mount axes, the field rotator,
the focuser, and the filter wheel. To perform these duties it uses the pc39 driver. Basic setup
options for telescoped are contained in the configuration file telescoped.cfg located in
$TELHOME/archive/config. In the same directory are configuration files for setting up the filter,
filter.cfg, and focus, focus.cfg. Only one instance of telescoped may be running at a time, so it
leaves a lock file in $TELHOME/comm named telescoped.pid which also contains the process id
of the daemon.
If the file $TELHOME/archive/config/telescoped.mesh exists, telescoped will use it to refine its
pointing accuracy. See the command line program pterrors for more information.
The following table summarizes the syntax of the communications to and from telescoped on
each channel.
Channel
Name
Input Syntax Description
Slew Alt: Az: slew to given Alt/Az and stop
Slew HA: Dec: slew to given HA/Dec and stop

Introduction
1­10 November 12, 1998 OCAAS 2.0
Channel
Name
Input Syntax Description(cont.)
Track RA: Dec: slew to given apparent (EOD0 RA/Dec and
track
Track RA: Dec: Epoch: slew to given astrometric RA/Dec/Epoch
and track
Track slew to described object and track
Ctrl Stop stops all motion immediately
Ctrl Reset stops all motion, and rereads all config files
Ctrl Home searches for all home switches
Ctrl Limits searches for all limit switches and records
their encoder values in home.cfg
Focus move focus motor the given signed
distance; scale is set in focus.cfg
Filter rotate to center the named filter, as
described in filter.cfg
Lights intensity, 0 through MAXFLINT. used for
dome flats.
1.4.3.2 domed
The domed daemon is responsible for operation of the dome. To perform these duties it uses the
pc39 driver. Basic setup options for domed are contained in the configuration file domed.cfg
located in $TELHOME/archive/config. Only one instance of domed may be running at a time, so it
leaves a lock file in $TELHOME/comm named domed.pid which also contains the process id of
the daemon.
The following table summarizes the syntax of the communications to and from domed on each
channel
Channel
Name
Input Syntax Description
Dome Az: rotate to given azimuth and stop
Dome Auto maintain slit with telescope without further commands
Dome Stop stops all motion immediately
Shutter Open open the shutter (set dome az if necessary) or roof
Shutter Close close the shutter (set dome az if necessary) or roof
Shutter Stop stops all motion immediately
1.4.3.3 camerad
The camerad daemon is responsible for batch operation of the camera. (The camera is operated
interactively using the Camera program) To communicate with the camera driver it uses the
symbolic link $TELHOME/dev/ccdcamera. This is possible because all CCD camera driver
modules within OCAAS adhere to the same interface. In the configuration described in the
diagram, this is a link to the Apogee driver, apogee. Only one instance of camerad may be
running at a time, so it leaves a lock file in $TELHOME/comm named camerad.pid which also

Introduction
OCAAS 2.0 November 12, 1998 1­11
contains the process id of the daemon. Basic setup options for camerad are contained in the
configuration file camera.cfg (note no d) located in $TELHOME/archive/config.
The following table summarizes the syntax of the communications to and from camerad on each
channel. Unlike other channels, there are two response from one Expose command to the
Camera channel. The first response indicates that the exposure is complete and the shutter has
been closed; the second response indicates the pixels have been read and the camera is free to
take another image. This feature allows the telescope to begin slewing to the next target as soon
as the camera shutter closes.
Channel
Name
Input
Syntax
Description Response code
Camera Expose ... Begin an exposure 0 Exposure complete
1 Pixel download complete
3 Camera setup error
4 Readout error
Camera Stop aborts the current exposure, if any 2 Aborted (even if none in progress)
1.4.3.4 gpsd
The gpsd daemon is responsible for continuous operation of the GPS receiver. To communicate
with the receiver it uses the tty specified in gpsd.cfg. Only one instance of gpsd may be running at
a time, so it leaves a lock file in $TELHOME/comm named gpsd.pid which also contains the
process id of the daemon.
The gpsd daemon has two roles. On system start­up, it waits to receive a lock from the receiver.
Then it reads the geographic location and compares it with that in the configuration file
telsched.cfg. (This file, like all configuration files, resides in $TELHOME/archive/config.) If the
location differs by more than one arc second, it updates the values by appending them to the file.
Also on system start­up, it reads the current time from the receiver and sets the Linux clock
immediately to this time using the settimeofday() system call.
The second role is to maintain system time on an ongoing basis. Gpsd gets the current time from
the receiver approximately once per minute. If it differs from the Linux clock, it updates the clock
using the adjtime() system call. This system call does not abruptly change the time. Rather, it
causes a small increase or decrease to the clock rate in a flywheel fashion until the time is correct
and then returns to the normal rate. In this way, it adjusts the time and yet maintains the invariant
that time always increases monotonically.
Note that neither of these system calls changes the hardware (CMOS) clock. OCAAS does not
set the hardware clock. It may be set manually, by root, using the /sbin/hwclock command.
Even though gpsd is not suid­root it has the permission to change the time because it is run from
the Linux start­up script /etc/rc.d/rc.local.
1.4.3.5 wxd
The wxd daemon is responsible for continual operation of the Peet Bros Ultimeter 2000 weather
station. To communicate with the station it uses the tty specified in the wxd.cfg configuration file.

Introduction
1­12 November 12, 1998 OCAAS 2.0
Only one instance of wxd may be running at a time, so it leaves a lock file in $TELHOME/comm
named wxd.pid which also contains the process id of the daemon.
The wxd daemon initializes the serial channel and sets up the Ultimeter 2000 to report all current
statistics once per second. It compares each new value with its old value from the previous
second. If any value changes by more than a configurable amount it writes a new record of
weather data statistics to a file. It also maintains the current weather statistics in a region of
shared memory and records a time stamp in shared memory of when the data were last stored. In
this way, processes which wish to use the weather data can decide whether the data is stale
(should the wxd daemon cease to function for any reason).
The wxd configuration file is wxd.cfg located in $TELHOME/archive/config. Each new weather
statistics record is appended to the file named wx.log located in $TELHOME/archive/logs. This
file is reopened, and created if necessary, for append each time a new record is added. Thus, it is
fine to move this file out from under wxd for archival purposes. The format of this file is ASCII
text, one record per line. Each line is fixed­width with the following format: (the rain total is reset
once each 24 hours, although at no particular time of day)
Role Columns Units
Julian Date 1­13 Days since Greenwich noon Jan 1,
4713 BC, %13.5f
Wind Speed 15­17 KPH, %3d
Wind Direction 19­21 Degrees E of N, %­3d
Temperature 23­27 degrees C, %5.1f
Humidity 29­31 percent (0..100), %3d
Pressure 33­38 millibars, %6.1f
Rain 40­44 mm since last reset, %5.1f
Weather alert codes 46­50 see below, %5s
Aux temp sensor 1 52­57 degrees C, %6.2f (­99.99 if absent)
Aux temp sensor 2 59­64 degrees C, %6.2f (``)
Aux temp sensor 3 66­71 degrees C, %6.2f (``)
The weather alert column consists of exactly 5 characters. Each character position may be a
code if active or a hyphen (­). The possible codes are, in order:
T Temp is higher than MAXT
C Temp is lower than MINT
H Humidity os higher than MAXH
W Wind speed is higher than MAXWS
R Rain has increased (any amount)

Introduction
OCAAS 2.0 November 12, 1998 1­13
1.4.4 Directory Structure
All files part of OCAAS are stored beginning at the directory named by the environment variable
$TELHOME. This is /usr/local/telescope by default. Follows is a summary of the basic directories
under this beginning.
$TELHOME/ Role
archive/calib bias, thermal and flat camera calibration files
archive/catalogs database files, including *.edb, ppm.xe, gsc
archive/config all calibration files, such as telsched.cfg, etc
archive/images selected images destined for archival storage
archive/logs engineering logs kept by all processes
archive/photcal Landolt photometric standard fields and data
archive/pointmesh images taken to model telescope pointing errors
archive/telrun current scheduled command list, in telrun.sls
archive/userlogs staging area for logs while being archived
bin all executables
comm communication fifos, lock files
dev driver modules, their entry points and generic links
user/images images taken during batch scheduled operation
user/logs per­schedule engineering log files
user/logs/summary concise descriptions of each telrun scan list
user/schedin individual *.sch schedule file submissions
xephem/auxil support files such as mars and moon images, help
xephem/catalogs symlink to ../archive/catalogs (for compatibility)
xephem/fifos symlink to ../comm (for compatibility)
1.4.5 Real­time vs Scheduled control
Operation of the observatory facility directly by an operator is accomplished primarily using the
xobs and camera GUI programs. These programs use the various fifos to communicate with the
daemon processes to perform each action. They also connect to the shared memory segment to
monitor all current state information.
But the fifos can also be connected to telrun instead in which case they are handling commands
being generated automatically from the scan sequences described in telrun.sls. One basic control
available from xobs is to switch Batch operation on and off, which really means to give control of
the fifos to telrun (and make sure it is running) or use the fifos directly, respectively.
It is possible to configure an OCAAS system so that when it is booted telrun is started
automatically. In this case xobs, and indeed any user interface at all, is optional. If xobs is started
and it finds telrun is already running, it reverts to a passive mode. Or booting can start just xobs
and be waiting for user input. These configurations are created by suitably modifying the script
$TELHOME/archive/config/boot.cfg