Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.apo.nmsu.edu/Telescopes/HardwareControllers/index.html
Дата изменения: Wed Sep 3 21:30:45 2014
Дата индексирования: Sat Apr 9 23:18:14 2016
Кодировка:
Поисковые слова: п п п п п п п п п п п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п
|
Hardware Controllers Manual
Introduction
These controllers move telescope axes, process guide images,
adjust mirrors, operate devices in the enclosure, and control the
mirror covers and such. Each controller accepts text commands via a
standard RS-232 serial interface. In addition, some controllers
require a separate highly accurate 1 Hz reference pulse.
Multiple controllers (except the guide image controller) may
co-exist in one box and share one serial interface. Specify which
controller before sending a command. Prefix the command with a device
specifier word. For example, ROT STATUS solicits status from the
rotator controller.
Standard Interface
Each hardware controller uses the following standard interface. It
is based on FORTH controllers, since those are widely used. It was
designed to be simple and easy to implement. Some of these rules only
apply to commands that the TCC may execute, and so may be relaxed for
engineering commands. "Commands" and "input" refer to data input to
the controller. "Replies" and "output" refer to data output by the
controller.
- Commands and replies are plain, readable ASCII text.
- Commands are terminated with <cr> (carriage return).
- Commands must be echoed.
- The command echo should be in the same case as the received
command. If it helps, the TCC can be expected to supply commands in the
appropriate case to make this so. However, it would be best not to rely
on this.
- Data and error messages may not appear on the same line as
the command echo, but instead must start on a new line. Otherwise the
TCC will think that the command was garbled.
- Unsolicited output is prohibited except after the controller is
reset or restarted, or after catastrophic failure requiring reset. The
TCC may ignore unsolicited output or it may try to initialize or reset
the controllers; the TCC's behavior is unpredictable. Do not use
unsolicited output as an attempt to get the TCC's attention.
- Each line of output must be terminated with a carriage return. A
linefeed may also be supplied, but will be ignored by the TCC. If
supplied, the linefeed may be sent just before or just after the
<cr>, but "before" is preferred because it is less likely to
cause mysterious symptoms in case of trouble.
- The last line of output in response to a command must be
terminated with "OK" and the termination mentioned above.
- This OK may be appended to the last line of output (in which
case it must be preceded by at least one space) or it may appear by
itself on a new line. Case is irrelevant.
- Exception: a blank command (zero or more spaces followed by a
carriage return) must receive just one line of reply, consisting of
zero or more spaces followed by OK.
- Parameters are separated by one or more spaces. This is a strong
recommendation but not a requirement.
Note: The Galil motion controllers output a semicolon for each
command that appears on a line (as part of the command echo). As a
result, the TCC's standard interface driver was enhanced to allow
ignoring one specific character in replies. When talking to the
Galils the TCC ignores semicolons in replies.
Russell
Owen