perm filename ENCODE[1,VDS]1 blob
sn#081093 filedate 1974-01-07 generic text, type C, neo UTF8
COMMENT ā VALID 00004 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Encoder Specifications for Hand-Eye Work
C00005 00003 For reasons of simplicity and economy, and because of the rapidly
C00008 00004 Here are some typical encoder specs.
C00009 ENDMK
Cā;
Encoder Specifications for Hand-Eye Work
This file outlines some of the requirements we have for
encoders and their interfaces for some of the Hand-Eye project work.
Up till now we have been using Potentiometers as our general
purpose resolving devices. For increased resolution, improved
linearity, and better stability, it appears desirable to switch to
optical encoders on many of our "joints".
Two general types of encoders are available- "whole word" and
incremental". Whole word encoders have as
many tracks as bits of
output resolution and provide an n bit coded output of the position
of the encoder. Incremental encoders have two output tracks, (plus a
zero reference mark sometimes). They provide two output signals in
quadrature which are electronically decoded to drive an external
up-down counter. For unidirectional applications some of these
incremental encoders merely have one track and drive the counter
directly. Or else, a outside direction sensing switch changes the count direction
of the counter.
For reasons of simplicity and economy, and because of the rapidly
decreasing cost of i.c.electronics, most general purpose encoders are
of the incremental type. I am proposing to use these on most of the
new mechanical devices we design, and I am proposing to retrofit these
incremental encoders onto some of the already existing devices, starting
with the T.V. cameras.
The first device to be retrofitted will be the Sierra Camera because it
was designed to use encoders in the first place. Then the Cohu. Each camera will
use 2 encoders to start with. They will be quadrature output devices with a
zero reference track. 4X count multiplication circuitry
will be necessary to multiply the count output. Quadrature decoding will
also be required. The count should be stored in hardware counters to eleiminate
the need to reset the computer count everytime the system dies (done by
servoing the camera past the zero reference mark). I suggest that 16 bit counters
be designed to accomodate all possible encoders. These counters, and the related
logic must be stable and noise free to enable them to count error free for
periods of weeks or months. Possibly a battery pack, standby unit can be used to
provide power when the kludge bay power is off, otherwise the zeroing procedure will
have too be repeated.
Here are some typical encoder specs.
Number of lines- 1024 (gives 4096 counts per turn)
Output-unamplified model-
Output-integral amplifier model-
Max. expected count rate-50khz.