perm filename ENCODE[1,VDS]1 blob sn#081093 filedate 1974-01-07 generic text, type C, neo UTF8
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
			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.