\documentstyle[12pt,final,twoside,times,sfheads]{rccldoc}
\begin{document}
\tolerance=1000
\pagenumbering{roman}
\title{RCCL/RCI Hardware Installation Notes}
\author{John Lloyd}

\date{August 1988, June 1990, July 1992}
\maketitle
\parskip = 2ptplus3pt

\begin{abstract}
This document describes the hardware arrangements necessary to install
RCCL/RCI on either a MicroVAX-II, or a VME-based system
such as a Sun4, an SGI IRIS, or VxWorks, and connect it
to a Unimation PUMA controller.
\bigskip\bigskip
\begin{center}
\large\bf Acknowledgements
\end{center}
\bigskip
We would like to thank John Day and Joe Erbin at Digital Equipment Corp.\ for
their help in locating and fixing the hardware 
bug in the MicroVAX inter-processor 
doorbell interrupt. We would also like to thank Larry Alexander (also from
DEC) and Arlie Long (at NASA Goddard Space Flight Center) for their
work in finding a fix for the hardware bug in the Q22-bus interface for the DRV11
parallel port. 

\par\vfill
\copyrightNotice
\end{abstract}

\tableofcontents
\newpage
\pagenumbering{arabic}

\chapter{Basic System Concepts}

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/concept.eps}}%
{Basic RCCL/RCI system concept with one host CPU connected to a 
single robot controller.}
\label{concept.fig}%
\end{figure}

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/cpu2.eps}}%
{A more complex RCCL/RCI system utilizing multiple CPUs and connected to
multiple robot controllers.}
\label{multiple.fig}%
\end{figure}

Figure \ref{concept.fig} gives a simple schematic of the basic elements
of an RCCL/RCI system. Overall robot control 
is orchestrated by a UNIX process
running on the {\it host system}. This process, which is also known as the
{\it planning task}, issues motion requests to a {\it trajectory control
task}. The trajectory control task executes at high priority, at a fixed
sample rate, 
and is responsible for generating position and current setpoints
for the individual joints of the robot(s) being controlled. 
A typical sample rate for the trajectory task used by RCCL programs
is 50 Hz. The planning and trajectory tasks communicate using shared
memory.

Every trajectory control cycle, the computed joint setpoints
are sent from the host system to a robot controller over a high speed link. 
There they are received by a special piece of communication software
(called ``{\tt moper}'', for historical reasons) which dispatches the joint
setpoint commands to individual joint servo controllers. On Unimation
Mark X controllers, each joint servo runs on an individual microprocessor
at a typical sample rate of 1000 Hz. 

{\tt moper} is essentially a data concentrator, which runs in sync with
the trajectory control task. In addition to handling joint servo commands,
it collects feedback data from the joints and other input devices attached to
the controller, such as teach pendants, analog-to-digital converters, 
and force sensors, and sends it back to the host system at the
beginning of the next control cycle. On Unimation controllers, the {\tt moper}
software is downloaded to the robot controller from the host system and
replaces the manufacturer-supplied VAL software.

The operation of the real-time trajectory task, plus the low level
communication with the robot, is the responsibility of the subsystem
known as RCI (Real-time Control Interface, or, alternatively, 
Robot Control Interface). 

\section{Multiple Robots and Multiple CPUs}

An RCCL/RCI system may (1) be attached to more than one robot, and
(2) utilize auxiliary CPUs which are connected to the same backplane as
the host system CPU. Each additional CPU can be used to execute one or
more RCI control tasks, which can in turn drive one or more robots.
A schematic of this is shown in Figure \ref{multiple.fig}.

In multiple CPU systems, the main UNIX CPU is known as the {\it arbiter} CPU,
and the other CPUs are known as {\it auxiliaries}.

Physically, adding additional robots just involves installing
the interface boards for their controllers into the host system
backplane. Ideally, adding additional CPUs simply involves plugging them into
the backplane as well. The latter may be complicated, however,
by the fact the bus
architectures are often fussy about how they accommodate multiple CPUs.

Auxiliary CPUs also need to be loaded with an appropriate real-time 
kernel. This is handled automatically by RCI software.

\section{What is Currently Supported}

At the present, single-CPU implementations of RCCL/RCI exist
for MicroVAX-II, Sun4, SGI IRIS, and VxWorks host systems. 

A multiple-CPU implementation
exists for MicroVAX-II systems.

Most systems are connected to Unimation PUMA robots and the Mark
I, II, or III controllers. An RCCL/RCI
system was configured to connect to a home-built robot controller
at the Jet Propulsion Laboratory, but this work was very site-specific
and is not part of the standard system distribution.

This document specifically describes what you need to do to hook up a
Unimation Mark X controller to either a MicroVAX-II or a VME
based host system (VME-based systems include
Sun4, SGI IRIS, and VxWorks).
It also describes what you have to do to add auxiliary CPUs to a MicroVAX-II
system. 

\chapter{General Hardware Requirements}

Roughly speaking, an RCCL/RCI system attached to a Unimate box
will need the following:

\begin{list}{}{}
\item[1.]{\bf Host system.}
Either a MicroVAX-II (section \ref{microVAX}),
or a VME system (section \ref{Sun4}).

\item[2.]{\bf Robot and Controller.}
A PUMA 260, 560, or 760 robot, and a Mark I, II, or III controller.
The CPU on the controller should be checked. If it is not an
LSI-11/73, it may be necessary to upgrade it. See section \ref{pumaCpu}
about this.

\item
You may want to make some small modifications to the robot
controller. These could include adding a circuit to measure the current
applied to the motors (section \ref{current.sec}), setting up the controller
so that RCI can turn on the arm power automatically (section 
\ref{poweron}), and adding a force sensor (section \ref{force}).

\item[3.]{\bf Host-Controller Interface.}
A high speed parallel interface is needed to connect the host system to the 
Unimate controller. Most commonly, this is achieved using a parallel
port on the host (such as a DEC DRV11 for the MicroVAX or a XYCOM XVME 240 
for the VME systems), which connects to a parallel port (such as a DRV11)
on the Unimate controller. You can also use shared memory cards to link the
two systems; this has been done at General Electric and at JPL.
The advantages and disadvantages of shared memory cards, as well
as other possible interfaces, are discussed below.

\item[4.]{\bf Serial Connection to the Controller.}
The controller console line should be connected to a serial
port on the host system.
This is used for initialization (i.e., downloading {\tt moper}),
and for diagnostics.

\item[5.]{\bf Clock Timer Module.}
{\it NOTE: this option only applies to MicroVAX and Sun4 systems.}
If you are anticipating running control applications at rates faster
than about 30 Hz., then you should also consider installing a clock timer
module into your system. This provides a reliable time base for running
RCI control tasks. In the absence of a clock timer module, RCI uses
the UNIX system clock. However, if the per-cycle execution time for the RCI
control task exceeds the time interval for the UNIX clock, the UNIX clock may
lose ticks and the timing will become unreliable. This is because RCI needs to
mask out {\it all} CPU interrupts for the duration of the control task.
What sort of clock timer module you need depends on your UNIX system
(section \ref{uVAXclock} or \ref{Sun4clock}).  (Another consideration
is that as the control cycle rate approaches the UNIX clock
granularity, timing accuracy becomes progressively worse, breaking down
completely when control cycles are supposed to happen more often than
UNIX clock ticks do.)

\end{list}

Other things which are convenient to have on hand include:

\begin{list}{}{}

\item[$\diamondsuit$]
A tape drive capable of reading the RCCL/RCI distribution.

\item[$\diamondsuit$]
\TeX\ and \LaTeX\ typesetting software, and a PostScript printer for
making hard-copies of the system documentation. All
of the illustrations in the doc set are distributed as
PostScript files.

\item[$\diamondsuit$]
An oscilloscope, and a few basic electrical tools such as wire
cutters and strippers, a soldering iron, and wire wrap equipment.

\end{list}

\section{Communication Device Speed}

The major technical consideration in chosing the communication device
between the host and the robot controller is
speed. A good benchmark figure for the amount of data that needs to
be transferred between the robot controller and the host system
during a control cycle is
about 50 16-bit words. This usually happens in two bursts, with the robot
controller sending approximately 30 words of feedback data to the host near
the beginning of the control cycle, and the host sending about 20 words of
commands back down to controller later on. The average word count can be
used, along with the device bandwidth, to calculate the typical communication
overhead for each control cycle, which in turn affects the fastest
rate at which the trajectory generator can run.

\section{Communication Device Drivers}

Each communication device is
generally associated with three pieces of driver software:

\begin{list}{}{}

\item[$\diamondsuit$]
An RCI communication driver which reads and writes packets of data on the
host system;

\item[$\diamondsuit$]
The counterpart to the RCI communication driver which lives in {\tt moper};

\item[$\diamondsuit$]
A RCI UNIX device driver which fields device interrupts
{\it (not needed on VxWorks systems)}.

\end{list}

This needs a little more explanation. RCI does not go through the UNIX I/O 
system at
all when doing device communication. Instead, it accesses the device registers
on the bus directly, reading and writing data to them, and polling and busy
waiting when necessary. This is not inefficient, since RCI tasks are
usually quite time critical and need to obtain their data quickly anyway;
waiting for an interrupt would cause delays. Instead, the paradigm is that RCI
tasks can be woken up on an interrupt. The interrupt can come from any RCI
device for which there is a special UNIX driver whose main job is to 
simply catch the interrupt and then wake up RCI. (On VxWorks, the interrupt
handling is done by an extra routine in the RCI communication driver.)

The RCI communication drivers live in {\filefont \$RCCL/drivers}, their {\tt
moper} counterparts live in {\filefont \$RCCL/lsi11}, and the RCI UNIX drivers
live in either {\filefont /sys/rciext} or {\filefont /sys/vaxuba}, depending on
the system. 

If you use an interface for which drivers are not already provided, then you
will need to write your own, although this will probably not be too difficult
if you clone one of the existing ones, and consult the manual page 
{\tt IOdevice(7)}, which describes the general interface for RCI communication
drivers.

\chapter{Installation on a MicroVAX-II Host System}\label{microVAX}

\section{Host System Requirements}

You will need a MicroVAX-II, running stock BSD 4.3 UNIX, with about 
50 Mbytes of {\it free} disk space, a couple of serial ports,
a TK50 drive for booting, and at least 5 Mbytes (but preferably 9 Mbytes)
of main memory.

\section{Communication Devices}\label{microVAXcom}

So far, two types of device have been used to connect
MicroVAX-II systems with the Unimate box: (1) parallel ports,
and (2) shared memory interfaces.
Both are relatively easy to obtain, and the same device can be used
at each end since the MicroVAX-II and the PUMA controller are both
Q-bus systems. No attempt has been made to use DMA devices, although this
is another option discussed below.

\subsection{Using a DRV11 parallel port}\label{drv11}

The most common set up involves using a pair of DRV11 parallel ports.
For this, you will need:

\begin{enumerate}

\item 
2 DEC DRV11 parallel ports,
one to plug into the MicroVAX and one to plug into the Unimate box.
Note: you want a plain DRV11, {\it not} a DRV11-J or a DRV11-B.

\item
2 40-conductor ribbon cables,
which preferably should not exceed 20 feet in length and should be shielded
(ground plane or twisted pair cable is desirable, but we have gotten away
without it).

\end{enumerate}

DRV11s can be obtained from DEC itself (expensive), or from second-hand
DEC dealers (less expensive). The DRV11 is a fairly robust piece of hardware,
so one should probably not worry too much about buying it second hand.
A clone of the DRV11, called the DT-2768, is available from Data 
Translation. See the vendor list in section \ref{vendors}.

Data is transferred between the DRV11s using software handshaking, with the
CPUs at either end busy-waiting. The overall data transfer rate has been
measured at about 33 Kwords per second, which implies a typical communication
overhead of about 1.5 milliseconds per control cycle. This is quite adequate
for trajectory sample rates as high as 50 Hz., or perhaps a bit higher in a
pinch.

\medskip
\begin{quote}
{\bf NOTE:} If you buy a DEC DRV11, be aware that there
is a small address decoding bug on it which prevents it from being used on the
MicroVAX-II Q-bus unless a little change is made as illustrated
in Figure \ref{bugfix}. The change consists of cutting one trace and
jumpering it to ground. This fixes things at the expense
of preventing the port from
being accessed in single byte mode (which is not a major problem). 
The bug does not exist on the Data Translation boards.
\end{quote}

The RCI communication driver for the DRV11 is called {\tt pri},
and it lives in {\tt priDriver.c} in {\filefont \$RCCL/drivers}. The
counterpart driver 
for {\tt moper} lives in {\filefont lsi11/drv11.c}. The RCI UNIX driver
is also called {\tt pri},
and lives in {\filefont /sys/vaxuba/pri.c}. 

Detailed information about the DRV11 can be obtained from the DEC manual
(which is DEC part number EK-ADV11-OP-002).

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/drv11fix.eps}}%
{Making a DRV11 runnable on a MicroVAX-II Q22-bus.}
\label{bugfix}%
\end{figure}

\subsection{Using a DRV11-J parallel port}\label{drv11j.sec}

The other type of parallel port available for Q-bus systems is the
DRV11-J, although it has not yet been used in any system, with the
possible exception of the University or Waterloo. Again, two would be
required, and you would need 2 50-conductor ribbon cables. This port is
in principle a better device since it
has a higher 
bit density and so allows about twice as much data to be transferred between
systems at once. The board itself is also much more versatile and
likely to be useful for a wider range of applications.

Because of the double density of the card, and the fact that register
directions can be changed dynamically, we could expect to transfer up to
32 bits per handshake, or twice the rate of the DRV11, giving a typical
per-cycle communication overhead of about .75 msec.

Driver software for the DRV11-J has been written but {\it not yet
tested}, at least at McGill; the driver was written for the University
of Waterloo at their request, based on information provided in a manual
but without a physical device to test it with. However, the driver
is almost identical, in terms of what it does, to the {\tt pri} driver; the
main change has been to redefine a few registers and protocol bits.
As written, the driver does not take advantage of the high density of the
DRV11-J, and so should only run at about the same speed as a DRV11. 
Upgrading the speed should be relatively simple.

The RCI communication driver is called {\tt drj}, and the code
for it lives in {\tt drjDriver.c} in the directory 
{\filefont \$RCCL/drivers}. The
companion driver for {\tt moper} 
lives in {\filefont lsi11/drvj.c}. The RCI UNIX driver
is called {\tt drvj},
and lives in {\filefont /sys/rciext/drvj.c}.

\subsection{Shared memory}

Shared memory provides one of the fastest means of communication
between systems, although only a few RCCL/RCI systems have
used it. Q-bus to Q-bus shared memory boards can be
obtained from Bit-3 Corporation (see \ref{vendors}).
It is important that any shared memory device you use be able to send
interrupts between both systems. 

Shared memory should give an improvement in data transfer rates of
about an order of magnitude (or perhaps a bit better) over the speed of a
DRV11, to give a per-cycle communication overhead of about .15 milliseconds.

There is no standard RCI driver available for Q-bus to Q-bus shared memory,
but shared memory drivers are very easy to write and all tend to be
very much the same.
If you have to write one, the easiest thing to do would be to clone
the {\tt mem} driver ({\filefont drivers/memDriver.c}), which was
written for a shared memory interface between a MicroVAX-II
system and a robot controller running on a VME bus.

Shared memory devices have two main drawbacks: (1) they tend to be expensive,
and (2) you need to connect them to the double-height version of
the Q-bus that is used by the Unimate controller.

\subsubsection{Dealing with the double-height Unimate Q-bus}\label{double.sec}

If you have a quad-height Q-bus device that you absolutely {\bf must}
connect to the Unimate box, there are a couple of options: (1) extend the
Q-bus to attach to one or more quad-height slots, either using a proper set of
extender cards or by extending the wiring on the backplane directly (the
latter can made to work; we have done it, and, yes, it {\it is} ugly), 
or (2) move the entire Q-bus 
portion of the Unimate box into a quad-height enclosure, such as a BA11.
This might actually be worth doing if you have a spare enclosure handy and you
are planning on adding one or two extra peripherals to the controller's
Q-bus anyway.

\subsection{DMA devices}

We have never used DMA devices to connect the host and controller, but it
might be worthwhile to investigate this possibility. As with shared memory,
one should be able to obtain about an order of magnitude improvement in data
transfer rates over the polled I/O used by the DRV11. One should subtract
from this the overhead of setting up the transfer, but the communication
overhead might very well drop to about .25 msec.\ or so per cycle.

The easiest way to work with DMA devices it to get two compatible ones and
hook them up back to back. This is easy in the case of the MicroVAX-II and the
Unimate controller since both ends of the connection are Q-bus machines.
DMA devices available for the Q-bus include the DRV11-W and the DRV11-B,
although the DRV11-B is a quad height device and therefore some work
would be necessary to connect it to the Unimate Q-bus (see \ref{double.sec}).
It is, however, extremely cheap (about \$225, new, from Newman
Computer Exchange; 1989 price).

\section{Clock Timer Module}\label{uVAXclock}

The RCI clock device which we use on the MicroVAX-II system is one which we
built ourselves from a DRV11 and a little counter circuitry.
Like the UNIX system clock, this device provides a
stream of periodic
interrupts used to run RCI tasks and maintain a time count, but unlike the
system clock, it also maintains an internal count that can be
read back by RCI to determine if a clock interrupt was lost. The count only
needs to be large enough to span the maximum time interval that interrupts are
likely to be blocked by an RCI task.

\begin{quote}
{\bf NOTE:} If you are planning to use auxiliary MicroVAX CPUs, then this
device is not as necessary since the RCI clock can be maintained on one
of the auxiliary CPUs, and since RCI tasks do not have to mask interrupts
when running on an auxiliary CPU, clock ticks will not be lost.
\end{quote}

Instructions for building a copy of the RCI MicroVAX clock timer are
given below.

\subsection{Hardware design}

Users building this device should be familiar with the DEC DRV11 parallel
port, which occupies 3 device registers in Q-bus I/O space, has two interrupt
vectors, and is connected to external circuitry using two 40 line ribbon
cables 
terminated with Berg connectors (note also the fix required to
make DRV11s run on MicroVAX-II systems; see section \ref{drv11}).
The device registers are 16 bits each and
are arranged as follows:
\begin{verbatim}
            addr:   control status register (csr)
            addr+2: output buffer
            addr+4: input buffer 
\end{verbatim}
When the parallel port is combined with the timer circuitry, then output
buffer bit 0 is used to enable the clock, output buffer bit 1 is used to clear
it (but we have to wait for a clock edge), input buffer bits 0-3 form a 4
bit counter, and csr bit 6 is used to enable clock interrupts. All other
bits are unused.

The circuit which implements the clock function is shown in Figure \ref{foo3}.
\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/clockcircuit.eps}}%
{Schematic of the RCI arbiter clock
circuit.}%
\label{foo3}%
\end{figure}
 
It is interfaced to the parallel port using seven of the cable lines. 
Unfortunately, these lines span both of the connectors, so it is still
necessary to use two cables to make the connection. The 7 I/O lines
and their respective pin numbers on the connectors are shown below:

\bigskip
\centerline{\tablebox{\halign{%
#\hfil&\qquad#\hfil&\qquad#\hfil\cr
Signal Name&Pin Number&Function\cr
\noalign{\medskip\hrule\medskip}
OUT00 & J1-C & clock enable\cr
OUT01 & J1-K & clock clear \cr
IN00 & J2-TT & counter bit 0 \cr
IN01 & J2-LL & counter bit 1\cr
IN02 & J2-H & counter bit 2\cr
IN03 & J2-BB & counter bit 3 \cr
REQA & J1-LL & VAX interrupt line \cr
\noalign{\medskip}
& J1-A & +5 (needs special connection)\cr
& J1-J & GND \cr
}}}

J1 is the top 40 pin connector, and J2 is the bottom 40 pin connector. 
Power for the circuit can also be run over the cables
using pin J1-A, which should be tied to +5 on the parallel port side by
connecting it to the VCC of some chip on the DRV11. 
Using pin J1-A should not
interfere with other uses of the board since both it and its
counterpart pin, J2-VV, are unconnected.
Ground can be obtained from a number of pins which are grounded by the
parallel port; we used J1-J.
The circuit itself is on a small PC board that can be mounted conveniently 
somewhere in the MicroVAX-II cabinet.
A picture of a complete unit, with
the DRV11 connected to the timing circuit by the two ribbon cables, is shown 
in Figure \ref{unit}.
\begin{figure}[thb]
%\rect 3.75 truein by 4 truein%
\boxedsizedfig{3.75truein}{4truein}%
{\psfig{figure=figs/drv11connect.eps}}%
{DRV11 connected to timing circuit.}%
\label{unit}%
\end{figure}


The timing for the circuit is provided by a 555 timer wired to give
a train of narrow, negative pulses. The rising edge of each pulse, when
enabled through OUT00, sends an interrupt to the VAX through line
REQA. This line is asserted until it is time to send the next interrupt, at
which point it is dropped briefly to allow another positive edge to be
noticed. 
In the circuit shown, the 555 timer is wired to deliver pulses at a 
100 Hz rate. If $t$ is the total time between pulse edges, 
and $t_n$ is the time the pulse is negative,
then the following formulas apply:
\[
        t = .693 (R_1 + R_2 + 2 R_3) C
\]
\[
        t_n = .693 (R_3) C
\]
R1 is a trim pot used to bring $t$ as close as possible to the desired
overall rate, and R3 is a trim pot designed to make the negative part of the
pulse as narrow as possible. We wish to make the negative part of the pulse
narrow because interrupts will be delivered only when REQA is positive.

Line OUT01 sets the counter to clear on the next clock pulse, although this
is not currently used because it involves waiting for a clock edge.
The counter is a 74LS163; this number was selected over the 74163 because
(1) we had it around, and (2) the 74LS163 allows the clear line to be asserted
any time, whereas on the 74163 clear can be asserted only when the clock
is low. 

\subsection{Driver software for the device}

The clock device sends interrupts to the VAX which catches them in software.
The interrupt handler increments a time value,
uses the counter to see if any interrupts were missed, and if so
increases the time value by whatever additional count is necessary.
This is done by the interrupt handler built into the UNIX
driver for the clock device,
which is called {\tt drvclk} and lives in the file
{\filefont /sys/rciext/drvclk.c}.

If the {\tt drvclk} driver is already configured into the UNIX kernel,
then UNIX will search for it automatically at boot time. It will look
for a device at the Q-bus
address specified for {\tt drvclk} in the system
config file located in {\filefont /sys/conf}, and will assign it a vector
specified by the {\tt flags} field entry in the config file
(DRV11s can't cause themselves to interrupt and therefore can't
auto-configure their vectors). When installing a clock device
it is necessary to set the address and base vector correctly in the
config file, as will be discussed below.

\section{Hooking it Up}

This section gives particular details for setting up a system
where the host-controller link consists of a pair of DRV11s.

\subsection{What goes where}

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/uVAXhookup.eps}}%
{RCCL/RCI MicroVAX hardware configuration using DRV11 parallel ports}
\label{uVAXhookup.fig}%
\end{figure}

The system is connected up as shown in figure \ref{uVAXhookup.fig}.

The console line of the Unimate controller is connected 
to a spare serial port on the MicroVAX. This is used to download
the {\tt moper} software from the VAX to the controller, and 
provide an interactive interface to {\tt moper} while it is running.
The VAX system and the controller are also connected by the 
DRV11 parallel ports. If the MicroVAX system 
is also configured with a clock module, then this is plugged 
into the Q-bus on the MicroVAX.

These items will now be dealt with in more detail.

\subsection{Connecting the serial line}\label{serial.sec}

If the console cable from the Unimate
controller terminates with a standard DB-25 connector, then 
you should be able to just plug this in to the VAX port directly, although you
may have to use a gender adapter. It is likely that you will also have to
interchange the cable's transmit and receive lines
(pins 2 and 3), which can be done using a null-modem adapter.
If the console cable does not terminate with a DB-25 connector,
you should cut the cable and add a DB-25 connector yourself.

Once the serial line is hooked up, you should disable logins on the
associated port. How you do this will depend somewhat on
your system. For BSD style systems, you edit the file {\filefont
/etc/ttys} (this is {\filefont /etc/ttytab} on a Sun), set the ``status''
for the port to {\tt off}, and then 
restart the system init process by sending it a ``hang-up'' signal:
\begin{verbatim}
      % kill -HUP 1
\end{verbatim}

Remember the name of the port's entry in {\tt /dev};
this will be needed from time to time. It is convenient to create a symbolic
link to this entry which has some system independent name like
{\filefont /dev/puma0}. For instance, if the serial line is referenced through
{\filefont /dev/tty5}, you might do something like this:
\begin{verbatim}
      % ln -s /dev/tty5 /dev/puma0
\end{verbatim}

Creating {\filefont /dev/puma0} is worthwhile because some RCCL system
software (such as the command {\tt down}, which downloads {\tt moper})
will automatically refer 
to this device name if another is not explicitly specified.

When other robots are added to the system, their console lines can be assigned
device names like {\filefont /dev/puma}X.

Once the console is attached to the host system, you can still talk directly
to the controller through a terminal emulator program. RCCL supplies
a simple terminal emulator program called {\tt termlink}. To communicate
directly with {\filefont /dev/puma0}, one can use the following command,
\begin{verbatim}
      % termlink -d /dev/puma0 -s 9600 
\end{verbatim}
which connects the keyboard and screen directly to 
{\filefont /dev/puma0} at 9600 baud. This allows direct interaction
with whatever software is currently running in the controller
(such as VAL or {\tt moper}). The default escape character to break out
of a {\tt termlink} session is a tilde ({\tt \~{}}). This puts you into a {\tt
termlink} 
command menu with the prompt {\tt termlink> }, and you can get out of this
by typing {\tt quit}.

\subsection{Installing the DRV11 on the MicroVAX}

The DRV11 plugs directly into the MicroVAX Q-bus. Before
adding the device, you should set the address and the interrupt vector
to correspond to free locations in the bus space. The easiest way to find
free locations is to examine the output produced by your system when it boots;
it should give a listing of what devices appear at what locations, as well
as which interrupt vectors are used. 

\begin{quote}
If you are using a stock DEC DRV11, make sure you have fixed the hardware bug
described in section \ref{drv11}.
\end{quote}

On a stock DEC DRV11, the address and vector are set with wire jumpers
(described in section \ref{drv11install.sec}).
On the Data Translation DT-2768, the address is set with switches.

\subsubsection{Configuring the device into the system}

The DRV11 address needs to be configured into both UNIX and RCI. 

For UNIX, the address information is provided to the configuration file entry
for the RCI UNIX driver {\tt pri}. A typical entry looks like this:
\begin{verbatim}
      device  pri0  at uba? csr <address> flags <vector> vector priintr
\end{verbatim}
where {\tt <address>} and {\tt <vector>} are the selected address and vector
number. Note that the vector number is passed to the driver through the
{\tt flags} field. Remember, of course, to rebuild UNIX after changing the
configuration file.

For RCI, the device address should be entered into the file 
{\filefont conf/robots}
as the address of the RCI communication driver {\tt pri}. A typical
entry looks like this:
\begin{verbatim}
      robot=Apollo device=pri address=<address> interrupt=/dev/priRCI0
\end{verbatim}
RCI does not need to know the vector number.
No recompilation is necessary after you change the {\tt robots} file.

For more information on device configuration, see the 
{\it RCCL/RCI Startup and Installation Guide}.

\subsection{Installing the DRV11 on the Unimate controller}\label{drv11install.sec}

\begin{figure}[tp]
%\rect 6truein by 3truein%
\boxedsizedfig{4.5truein}{6.25truein}{\psfig{figure=figs/drv11jumpers.eps}}%
{Jumpers on the DEC DRV11 parallel port.}%
\label{drv11jump.fig}%
\end{figure}

This DRV11 is plugged into the controller's Q-bus. 

The address and vector should be set as necessary;
address 0xfe00 and vector 0xa0 appear
to be free on most Unimate controllers. 
On a DRV11, these values are set using jumpers: jumpers A3
through A12 set address bits 0 through 12, while jumpers
V3 through V7 set bits 3 through 7 of the vector number.
A bit value of ``1'' is produced by removing the jumper;
a bit value of ``0'' is produced by installing it.
For example, setting an address of 0xfe00 and a vector
of 0xa0 would involve
installing jumpers A3 through A8, V3, V4,
and V6, and removing the rest.

The jumpers for the DRV11 are shown in Figure \ref{drv11jump.fig}.
On the DT-2768, the address and vector are set using switches;
consult the manual for that device for more information.

When installing the board into the Q-bus, make sure that there 
are no empty slots between it and the system CPU (which resides in the 
first slot). 

The address and vector should be
configured into the {\tt moper} code by editing the
configuration file {\filefont \$RCCL/lsi11/<robotName>.c}.
This is done by setting the arguments for the
call to {\tt hostDevice()} in that module:
\begin{verbatim}
      hostDevice (<address>, <vector>);
\end{verbatim}

The {\tt moper} for the robot in question should be rebuilt afterwards.

\subsection{Connecting the two boards together}

The boards are connected together by the ribbon cables such that 
connector J1 on one board is connected to J2 on the other board, and
vice versa. The first pins match up in all cases.

\subsection{Installing the clock timer module}

If you are adding a DRV11-based a clock timer module to your system, then
you install it as you would any other DRV11, first finding an appropriate
address and vector for it, setting this on the board, and plugging it into
the system.

\subsubsection{Configuring the clock into the system}

The clock timer needs to be configured into UNIX. The associated device driver
is {\tt drvclk}, and the usual entry for this device in the system
configuration file looks something like the following:
\begin{verbatim}
      device  drvclk0 at uba? csr <address> flags <vector>
                              vector drvclkintr
\end{verbatim}

The special file {\filefont /dev/rciclk} should be created for this device. 
When an RCI program starts up, it checks to see if it can open
{\filefont /dev/rciclk};
if it can, it presumes that a clock timer module is present on the system
and it proceeds to use it. Otherwise, it will use the UNIX system clock.

\section{Adding Auxiliary CPUs to the MicroVAX-II}

The MicroVAX-II hardware has been designed so that up to four MicroVAX CPU
boards may be placed on the same Q-bus, with one serving as the
{\it arbiter} CPU and the others serving as {\it auxiliary} CPUs. The
arbiter CPU handles all Q-bus interrupts and provides the bus arbitration
logic. Each CPU contains 1 Mbyte of on-board memory, sections of
which can be shared with other CPUs by mapping them onto the Q-bus.

The RCI system contains software which is capable of using one of more of
these auxiliary CPUs as dedicated processors to run control tasks. 
This can, of course, greatly
increase the performance of the system. 

\subsection{Installing the CPUs in the Q-bus}

The auxiliary CPUs must be placed into the Q-bus slots which contain a
CD interconnect. Usually, on a MicroVAX-II system, only the first few
slots have this characteristic: the first 4 slots in a BA-123 enclosure,
and the first 3 in a BA-23. The CD interconnect is used by the CPU
board to implement a private memory bus.

\medskip
\begin{quote}
\bf NOTE: Plugging a MicroVAX CPU into a non-CD
slot will blow the CPU.
\end{quote}
\medskip

MicroVAX memory expansion boards are also plugged into the CD slots. 
Although we have not added expansion memory to any of the auxiliary CPUs,
it appears that this is possible
simply by placing memory boards in the CD slots
directly adjacent to the CPU in question on the side facing away from
slot 1, and attaching the private memory cable. Unfortunately, adding
expansion memory eats up CD slots.

Adding CPUs to the Q-bus requires adjusting the bus impedance. 
Normally, the Q-bus has a $120\Omega$ impedance. In stock BA-123 and BA-23 
MicroVAX-II systems,
this is achieved with a set of $240\Omega$ termination resistors plugged 
into the far end of the bus, in parallel with the $240\Omega$ termination on the
CPU card. Each additional CPU that is added introduces an additional
parallel $240\Omega$ impedance. If the termination
resistors on the bus itself are removed, one can add
one additional CPU and still have a bus impedance of $120\Omega$.
Adding more than one CPU technically requires distributing the Q-bus across
two backplanes (see the reference to the DEC OEM Micro Notes at the end
of this section), but at the RCA site we have been running
with 2 additional CPUs in a BA-123 cabinet (a net impedance of $80\Omega$)
without any untoward consequences.

A typical slot assignment for a set of auxiliary CPUs is:

\bigskip
\centerline{\tablebox{\halign{%
\hfil#\hfil&\qquad#\hfil\cr
SLOT 1:&Arbiter CPU\cr
SLOT 2:&Memory Expansion for arbiter CPU\cr
SLOT 3:&Auxiliary CPU 1\cr
SLOT 4:&Auxiliary CPU 2\cr
}}}

Installing an auxiliary CPU is pretty much just a matter of plugging it in.
Each CPU card is told what CPU number it is (i.e., arbiter, auxiliary 1, etc)
by setting some dip switches, which are also used to set the baud rate of the
console serial line. The dip switches are not located on the card itself,
but on a small configuration card (called the KA630-CNF)
that plugs into the CPU through two 
Berg connectors on the edge of the board. 

\subsection{Obtaining auxiliary CPUs}

How does one obtain auxiliary CPUs? There are two ways: order one from
DEC, or simply borrow one from another MicroVAX-II. At this point, we should
point out that there are two types of MicroVAX-II boards: the KA630, which is
the standard board which comes with all MicroVAX-II units, and the KA620,
which 
is a similar board but has a slightly different virtual memory implementation.
From the user's point of view, about the only difference between the two
boards is that you can't boot VMS or UNIX on the KA620 
(although one could probably build a UNIX that did boot on a KA620 with
very little effort). 
From DEC's point of view, the KA620 is intended for real-time applications
which run VAXELN and not VMS. Consequently, KA620s are not as common
as the KA630; the latter is currently selling for \$500 U.S. (1992 price,
from The Newman Group; see section \ref{vendors}).

The other alternative is to simply borrow a KA630 from an existing MicroVAX-II
and plug it in as an auxiliary CPU. This is not a problem for RCI
applications; the real-time kernel that runs on the 
auxiliary CPU doesn't care whether it is a KA620 or KA630. The only
problem with borrowing a KA630 is that one has to find a 
configuration card (KA630-CNF). See the section below for details on this.

\subsection{The configuration card}

The MicroVAX CPU has two connectors, J2 and J3, which are used
to bring out the console serial line unit and various signal lines that set 
CPU options. J3 is a 9 pin connector (one middle pin is omitted for
polarization) and J2 is a 20 pin connector. A drawing of the connectors
is shown in Figure \ref{j1j2}.

\begin{figure}[thb]
%\rect 6truein by 3truein%
\boxedsizedfig{5.75truein}{3truein}{\psfig{figure=figs/uVAXconfig.eps}}%
{MicroVAX CPU board configuration connectors.}%
\label{j1j2}%
\end{figure}


The KA630-CNF is a configuration board that plugs directly into
connectors J2 and J3 on the CPU board (see Figure \ref{cnf}).
\begin{figure}[thb]
%\rect 5truein by 4truein%
\boxedsizedfig{5truein}{4truein}{\psfig{figure=figs/ka630cnf.eps}}%
{KA630-CNF configuration module.}%
\label{cnf}%
\end{figure}

It contains another connector (J1) to break out the serial line unit,
two lines (BAT+ and BAT-)
to connect to the time-of-year clock battery backup (of no
concern to us here), and a set of 10 dip switches which configure the
CPU. The functions of the dip switches are to set (1) the processor
halt behavior, (2) the console line baud rate, (3) the power-up
behavior, (4) the CPU number (either the arbiter, or auxiliary 1, 2 or 3),
and (5) the console line operating mode. 

A KA630-CNF, or equivalent circuit, is needed when installing a MicroVAX board
as an auxiliary. The problem is obtaining a KA630-CNF. If you have purchased
a KA620 CPU board, then one will be provided by DEC with the purchase.
However, if you are using a CPU board not bought directly from DEC, then you
have to fashion your own since DEC does not sell the KA630-CNF separately.
To make this easy, a schematic diagram of the KA630-CNF is
given in Figure \ref{cnfscheme}. 

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/cnfscheme.eps}}%
{Schematic diagram of the KA630-CNF.}%
\label{cnfscheme}%
\end{figure}


For exact details on the function of all the signal lines and switches,
consult either the KA630 or KA620 {\it User's Guide} 
(referenced at end of this section).

\subsection{The MicroVAX CPU doorbell bug}

There is one other detail of concern to people using auxiliary MicroVAX
CPUs. Inter-CPU communication is effected using a form of mailbox interrupt
which DEC refers to as the ``interprocessor doorbell''. It turns out that
there is a hardware bug on the CPU board which results in this doorbell
interrupt occasionally being dropped. The bug is affected by component
tolerances and may not be present on all boards.

We discovered the problem and worked out its cause with DEC in the
fall of 1987. Since that time, DEC has issued an ECO for the KA620
and the early version of the KA630. 

What to do about the bug depends on what type of CPU board(s) you have.

\subsubsection{KA620}

If the board is a KA620 and
was recently manufactured, it should have the bug corrected.
The correction is known as tech tip KA-620-AA-TT-02, and was issued
January 18, 1988. If the board does not have the correction already, DEC
will fix it for you, although whether this costs you anything or not probably
depends on your service contract.

You can also fix the bug yourself quite easily. The fix involves lowering
a pull-up resistor value on a signal line from 10K$\Omega$ to about 2K$\Omega$.
This is done by soldering a 2.7K resistor from the signal line to +5 Volts.
The signal line is at pin 4 on the resistor sip shown
in Figure \ref{ka620fix}, and 
+5 Volts can be most easily obtained at pin 1 on the same sip.
\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/ka620fix.eps}}%
{Fix for the doorbell interrupt bug on the KA620 and KA630 (non-cost-reduced)
processors.}%
\label{ka620fix}%
\end{figure}


\subsubsection{KA630 (non-cost-reduced)}

The KA630 (non-cost-reduced) is the original KA630 processor. The board was
later redesigned  
for greater cost efficiency and renamed the KA630-CR (cost-reduced),
which is described in the next section.

The bug will always be present on this board since DEC stopped making it
before the ECO was issued. However, depending on your relationship with DEC,
they may perform the ECO on the board for you (again, tech tip KA-620-AA-TT-02),
although they might have to be persuaded to apply a KA620 tech tip to a KA630.

The engineer at DEC who fixed the bug and prepared the ECO
is John Day. His present phone number is 617-490-9053, and he can be
helpful in letting field service know what is going on.

If you wish to fix the bug yourself, this is done in exactly the same way as
for the KA620 (see above).

\subsubsection{KA630-CR (cost-reduced)}

The KA630-CR is the current production-line version of the KA630. No ECO was issued
for this processor (at last word), although this seems to have been more
for bureaucratic and cost-related reasons than anything else. 

Consequently, if you have a KA630-CR, you have to fix the bug yourself. Again,
you do the same thing as you would for the KA620 or original KA630, but
the location and orientation of the resistor sip is different. Consult
Figure \ref{ka630crfix}.
\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/ka630crfix.eps}}%
{Fix for the doorbell interrupt bug on the KA630-CR (cost-reduced)
processor.}%
\label{ka630crfix}%
\end{figure}

\subsection{Reference manual information}

Most of the information described above is explained in much more detail in
the either the KA630 or KA620 {\it User's Guide} 
(DEC part numbers EK-KA630-UG-001 or EK-KA620-UG-001). 
More information on putting multiple MicroVAX CPUs onto the Q-bus can be
found in DEC OEM Micro Note 26, ``The MicroVAX II CPU Multicomputing
Capability'', by Mike Collins.
Information about expanding the Q-bus is provided in
DEC OEM Micro Note 29 ``Q-bus Expansion Concepts'', by Charlie Giorgetti, and
Micro Note 35, ``Backplane Expansion/Termination'', by Jack Toto.

\chapter{Installation on a VME-Based Host System}\label{Sun4}

\section{Host System Requirements}

\subsection{SGI IRIS systems}

Your host system should have about 60 Mbytes of free
disk space, plus at least 1 free serial port
and 16 Mbytes of main memory (we need a lot of memory because
the entire RCCL/RCI program needs to be locked ``in core'').

You should also have at least one free VME bus slot for every robot you are
planning to attach. SGI Personal IRIS systems have one VME slot
each. The Power Series systems have more slots.

\subsection{Sun4 systems}

Your host system should have about 60 Mbytes of free
disk space, plus at least 1 free serial port
and 16 Mbytes of main memory.

You should also have at least one free VME bus slot for every robot you are
planning to attach, plus a free slot for the clock timer module, if you are
planning to use one of those.

If your system does not have a VME bus, you should provide it with one
using a bus adaptor. Several options are available. For S-bus 
machines, a very good S-bus to VME adaptor, the PT-SBS915, 
is made by Performance Technologies, Inc. (section \ref{vendors}). 
This board can be supplied with some driver software (including
a modified version of the UNIX {\tt config} program), that makes it
completely transparent: 
entries for VME devices can be specified in the system config file as
though the system had a VME bus directly attached.

\subsection{VxWorks systems}

Your VxWorks development system should have about 75 Mbytes of free
disk space, plus at least 1 free serial port. The VME card on which 
RCCL/RCI will be run should have at least 4 Mbytes of memory.

The VME system should have one free bus slot for every robot you are
planning to attach. 

\section{Communication Devices}\label{Sun4com}

So far, the only arrangement that has been used to connect
a VME system with a Unimation controller consists of
a XYCOM XVME 240 digital I/O module on the VME side, connected to
a DEC DRV11 (or equivalent unit) on the Unimate side. Other possibilities
will be discussed below.

\subsection{Using an XVME 240 connected to a DRV11}

This is the ``standard'' configuration, in the sense that it has been
used, all the drivers work, and we supply the necessary wiring diagrams in
this document. You will need:

\begin{enumerate}

\item
A XYCOM XVME 240 digital I/O module for the VME system.

\item 
A DEC DRV11 for the Unimate box. You can also use the 
Data Translation DT-2768, which is a clone of the DRV11. 
Note: you want a plain DRV11, {\it not} a DRV11-J or a DRV11-B.

\item 
A pair of 50-conductor cables for the XVME 240, a pair of 40-conductor cables
for the DRV11, and a cable interface to connect them together. The cable
interface will probably have to be built in-house (see section
\ref{cablecon.sec}).

\end{enumerate}

For information on where to obtain the interface boards, see the vendor list
in section \ref{vendors}.

The cables linking the two ports should be kept as short as possible (under 20
feet would be good), and should also be kept as  noise free as possible.
Using twisted pair or ground plane cable might be a good idea, if you can
afford it. The biggest noise problem is likely to be introduced by the cable
connector, so if you are in a noisy environment, you may want to enclose this
in a metal box.

Data is transferred between the XVME 240 and the DRV11 using software
handshaking, with the CPUs at either end busy-waiting when necessary. The
overall data 
transfer rate should be about the same as that for the DRV11s used in the
MicroVAX-II system, which is around 33 Kwords per second. This implies
a typical communication overhead 
of about 1.5 milliseconds per control cycle, which is adequate for
trajectory sample rates at least as high as 50 Hz., and perhaps as high as 100
Hz., given the faster speed with which most VME system CPUs
can execute the remainder of
the trajectory control task.

The RCI communication driver for the XVME 240 is called {\tt xyd},
and it lives in {\tt drivers/xydDriver.c}. The
counterpart driver for {\tt moper} lives in {\filefont lsi11/drv11.c}. 
The RCI UNIX driver 
which takes care of interrupt handling is also called {\tt xyd},
and lives in {\filefont rciext/xyd.c}. 

\subsection{Using an XVME 240 connected to a DRV11-J}

The other type of parallel port that could be put in the Unimate controller
is a DRV11-J. While this has not yet been done, it would offer the advantage
of doubling the transfer speed since the DRV11-J has twice the bit density of
the DRV11 (and the XVME 240 has a high bit density to begin with).
This means the per-cycle communication overhead could be reduced
to as little as .75 msec.\ per controller.

Some driver software for the DRV11-J has been written, but it remains
untested (see section \ref{drv11j.sec}) and has not been optimized to
take advantage of the higher bit density. This is the software
that would be used by {\tt moper}, and it lives
in {\filefont lsi11/drvj.c}. The RCI communication driver {\tt xyd} for the
XVME 240 would also have to be modified to take
advantage of the higher bit density. The RCI UNIX {\tt xyd} driver for the
XVME 240 would probably not have to be modified.

\begin{quote}
{\bf NOTE:} 
Using a DRV11-J would also require changing the design of the cable interface.
\end{quote}

\subsection{Shared memory}

Shared memory has not yet been used to link a VME system and a Unimate box,
although such interfaces do exist between the VME and the Q-bus
and can be obtained from Bit-3 Corporation (see \ref{vendors}).
Remember that any such interface you get must also be able to send interrupts
between both systems.

Shared memory should give an overall improvement in data transfer rates of 
at least an order of magnitude, reducing the per-cycle communication overhead
to about .15 msec.

No drivers are provided in the system distribution for a VME to Unimate
shared memory unit, but the driver which probably comes closest is the
{\tt vem} driver, which lives in {\filefont drivers/vemDriver.c}.
This was written
at JPL for a shared memory link 
between a Sun4 host
and a version of {\tt moper} which ran on a custom
VME controller. You would also have to write the RCI UNIX driver for 
handling interrupts, plus the driver on the {\tt moper} side.

The same drawbacks that apply to shared memory boards with MicroVAX-II systems
will apply to shared memory boards used with VME systems: (1) expense, and
(2) fitting them into the Unimate controller, since shared memory
boards for the Q-bus tend
to be quad height and the controller Q-bus is double height. See section
\ref {double.sec}.

\subsection{DMA devices}

You might also want to consider using DMA devices to connect the VME with the
Unimate controller, although this will be harder than with the MicroVAX-II
version because connecting two DMA devices means finding two DMA devices which
are compatible. There are DMA devices available for the VME which provide
compatibility with the DEC DRV11-W; check out what is offered by 
VME Microsystems (section \ref{vendors}).

As with shared memory,
DMA should give about a one order of magnitude speed improvement
over simple parallel port communication.
You will need to write an RCI communication driver, a counterpart driver
for {\tt moper}, and an RCI UNIX driver to handle interrupts.

\section{Hooking it Up}

This section assumes that the host system is to be connected to the robot
controller by an XVME 240 and a DRV11.

\subsection{Hardware diagram}

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/VMEhookup.eps}}%
{RCCL/RCI VME hardware configuration using an XVME 240 and a DRV11}
\label{VMEhookup.fig}%
\end{figure}

The system is connected up as shown in figure 
\ref{VMEhookup.fig}. 

The console line of the Unimate controller is connected 
to a spare serial line unit on the host system (or development
system, in the case of VxWorks). This is used to download
the {\tt moper} software from the host to the controller, and 
provide a interactive interface to {\tt moper} while it is running.
The XVME 240 is installed in the VME bus, and the DRV11 is installed
in the controller. The DRV11 is hooked up to a pair
of 40-pin ribbon cables, the XVME 240 is hooked up to a pair of
50-pin ribbon cables, and the two cable sets are joined by a
cable interface, which takes care of routing the signals appropriately.
If the system is configured with a clock module, this is installed in the VME 
backplane.

These items will now be described in more detail.

\subsection{Connecting the serial line}

The procedure is identical to that described in section \ref{serial.sec}.

\subsection{Installing the XVME 240 on the VME system}

To install the XVME 240 into the VME bus, you simply set a few jumpers
and switches and plug it in. The canonical switch and jumper
settings are given in table \ref{xvme240.tab}.

\begin{table}[htb]
\centerline{\tablebox{\halign{%
#\hfil&\quad#\hfil&\quad#\hfil\cr
Jumper&Function&Setting\cr
\noalign{\medskip\hrule\medskip}
J2 &address space selection&B (short I/O space)\cr
J3 through J10 &interrupt edge detection&A (latch on rising edge)\cr
\noalign{\medskip\hrule\medskip}
Switch Block&Function&Setting\cr
\noalign{\medskip\hrule\medskip}
S1&VMEbus interrupt request level&0x6 (level 6)\cr
S2(switches 1-6)&module base address&as required\cr
S2(switch 7)&access control&closed (global access allowed)\cr
S2(switch 8)&address space selection&closed (short I/O space)\cr
}}}
\caption{\quad Jumper and switch settings for the XVME 240.}%
\label{xvme240.tab}
\end{table}

The base address for the board can be set to any free 1K block in the system
short I/O space. On Sun4 and SGI systems, a good way to find a free address
is to check the output produced by the system when it boots, which contains a
list of all the devices attached to the bus and their their interrupt
vectors. 

The address is set using
switches 1-6 of switch block S2, where switches 6 through 1 control address
bits A15 through A10, respectively. An address bit is set to 1 if the 
corresponding switch is open, and 0 if the switch is closed.

Once the jumpers and switches are set, the board should be plugged into 
the VME bus. Slot order is not particularly important. 

\begin{quote}
{\bf WARNING: Remember to remove the jumper on the back of the VMEbus
shorting IACKIN to IACKOUT, or the board may be damaged.} The four jumpers
shorting the BGxIN to BGxOUT may also be removed, although this is
not necessary.
\end{quote}

See section \ref{VMEconf.sec} for a description of how to configure
the device into the system software.

\subsection{Installing the DRV11 on the Unimate controller}

This procedure is identical to that described in section
\ref{drv11install.sec}.

\subsection{Building the cable interface}\label{cablecon.sec}

The XVME 240 is connected to the external world through two 50-pin ribbon
cables. The DRV11 is connected to the external world through two 40-pin ribbon
cables. The cables from each board are interfaced to each other
using a cable interface (figure \ref{plink.fig}).

\begin{figure}[thb]
\boxedsizedfig{6truein}{5.25truein}{\psfig{figure=figs/plink.eps}}%
{Cabling between the XVME 240 and the DRV11.}
\label{plink.fig}%
\end{figure}

It will probably be necessary to construct the cable interface yourself. 
One easy way to do this is described here. The following components
are required:

\begin{enumerate}
\item Perforated vector board.

\item Two (2) 50 pin 3M connector sockets, male. Wirewrap leads
are recommended.

\item Two (2) 40 pin 3M connector sockets, male. Wirewrap leads
are recommended.

\item Mounting hardware for the connectors.

\item A metal box to put the connector in, if you are concerned about 
noise.

\end{enumerate}

3M connectors are the same sort of connectors that are used on the
DRV11 and XVME 240 boards themselves. The connectors 
can be mounted in the vector board and screwed down.
Connectors with wirewrap leads are the easiest to wire up.
If the leads are set at right angles to the interface body, then the
connectors can be placed on their sides and arranged as in figure
\ref{cablecon.fig}. Each connector in that diagram is given the same
name as the corresponding parallel port connector
(at the other end of the cable).

\begin{figure}[thb]
\boxedsizedfig{4.75truein}{2.5truein}{\psfig{figure=figs/cablecon.eps}}%
{Cable interface built by arranging 3M connectors on a piece of vector 
board.}
\label{cablecon.fig}%
\end{figure}

Once the connectors have been set in place, they should be wired
together as described by the
list given in tables \ref{wirelistJ1.tab} and
\ref{wirelistJ2.tab}. Notice that many of
the signal lines are not connected. 

\begin{quote}
NOTE: Pin 1 on each connector is usually identified
by a small inverted triangle. Some connectors identify their
pins by letter codes, in which case pin 1
corresponds to pin ``VV''. 
\end{quote}

\begin{table}[thbp]
\centerline{\small\tablebox{\halign{%
#\hfil&\quad#\hfil&\quad#\hfil&\quad#\hfil\cr
Pin No.&Corresponding&Connecting pin(s)&Corresponding\cr
       &DRV11 signal&                  &XVME 240 signal\cr
\noalign{\medskip\hrule\medskip}
40 (A) & open                   & NC            & open  \cr
39 (B) & open                   & NC            & gnd   \cr
38 (C) & out00                  & JK1-25        & id00  \cr
37 (D) & open                   & NC            & gnd   \cr
36 (E) & open                   & NC            & gnd   \cr
35 (F) & open                   & NC            & gnd   \cr
34 (H) & open                   & NC            & gnd   \cr
33 (J) & gnd                    & NC            & gnd   \cr
32 (K) & out01                  & JK1-26        & id01  \cr
31 (L) & out04                  & JK1-29        & id04  \cr
30 (M) & gnd                    & NC            & gnd   \cr
29 (N) & out05                  & JK1-30        & id05  \cr
28 (P) & init h                 & NC            & open  \cr
27 (R) & out06                  & JK1-31        & id06  \cr
26 (S) & gnd                    & NC            & gnd   \cr
25 (T) & out07                  & JK1-32        & id07  \cr
24 (U) & out03                  & JK1-28        & id03  \cr
23 (V) & gnd                    & NC            & gnd   \cr
22 (W) & out08                  & JK1-37        & id10  \cr
21 (X) & out09                  & JK1-38        & id11  \cr
20 (Y) & gnd                    & NC            & gnd   \cr
19 (Z) & out10                  & JK1-39        & id12  \cr
18 (AA) & out11                 & JK1-40        & id13  \cr
17 (BB) & out12                 & JK1-41        & id14  \cr
16 (CC) & gnd                   & NC            & gnd   \cr
15 (DD) & csr1                  & JK1-2, JK1-21 & idX1, intr1\cr
14 (EE) & gnd                   & NC            & gnd   \cr
13 (FF) & out13                 & JK1-42        & id15  \cr
12 (HH) & out14                 & JK1-43        & id16  \cr
11 (JJ) & out15                 & JK1-44        & id17  \cr
10 (KK) & gnd                   & NC            & gnd   \cr
 9 (LL) & req a                 & JK1-13        & odX0  \cr
 8 (MM) & gnd                   & NC            & gnd   \cr
 7 (NN) & out02                 & JK1-27        & id02  \cr
 6 (PP) & gnd                   & NC            & open  \cr
 5 (RR) & open                  & NC            & open  \cr
 4 (SS) & gnd                   & NC            & open  \cr
 3 (TT) & open                  & NC            & gnd   \cr
 2 (UU) & gnd                   & NC            & open  \cr
 1 (VV) & new data ready        & NC            & open  \cr
}}}
\caption
{\quad Wiring list for the cable interface J1. NC denotes ``not connected''.
In the first column, the pin number is followed, in parentheses,
by the corresponding letter ID used for some types of connectors.}%
\label{wirelistJ1.tab}%
\end{table}

\begin{table}[thbp]
\centerline{\small\tablebox{\halign{%
#\hfil&\quad#\hfil&\quad#\hfil&\quad#\hfil\cr
Pin No.&Corresponding&Connecting pin(s)&Corresponding\cr
       &DRV11 signal&                  &XVME 240 signal\cr
\noalign{\medskip\hrule\medskip}
40 (A) & open                   & NC            & open  \cr
39 (B) & open                   & NC            & gnd   \cr
38 (C) & data trans             & NC            & open  \cr
37 (D) & open                   & NC            & gnd   \cr
36 (E) & open                   & NC            & open  \cr
35 (F) & open                   & NC            & gnd   \cr
34 (H) & in02                   & JK2-3         & od02  \cr
33 (J) & gnd                    & NC            & gnd   \cr
32 (K) & csr0                   & JK1-1, JK1-9  & idX0, intr0 \cr
31 (L) & gnd                    & NC            & gnd   \cr
30 (M) & in15                   & JK2-20        & od17  \cr
29 (N) & in14                   & JK2-19        & od16  \cr
28 (P) & in13                   & JK2-18        & od15  \cr
27 (R) & gnd                    & NC            & gnd   \cr
26 (S) & req b                  & JK1-14        & odX1  \cr
25 (T) & gnd                    & NC            & gnd   \cr
24 (U) & in12                   & JK2-17        & od14  \cr
23 (V) & in11                   & JK2-16        & od13  \cr
22 (W) & in10                   & JK2-15        & od12  \cr
21 (X) & gnd                    & NC            & gnd   \cr
20 (Y) & in09                   & JK2-14        & od11  \cr
19 (Z) & in08                   & JK2-13        & od10  \cr
18 (AA) & gnd                   & NC            & gnd   \cr
17 (BB) & in03                  & JK2-4         & od03  \cr
16 (CC) & in07                  & JK2-8         & od07  \cr
15 (DD) & gnd                   & NC            & gnd   \cr
14 (EE) & in06                  & JK2-7         & od06  \cr
13 (FF) & open                  & NC            & gnd   \cr
12 (HH) & in05                  & JK2-6         & od05  \cr
11 (JJ) & gnd                   & NC            & gnd   \cr
10 (KK) & in04                  & JK2-5         & od04  \cr
 9 (LL) & in01                  & JK2-2         & od01  \cr
 8 (MM) & gnd                   & NC            & gnd   \cr
 7 (NN) & init h                & NC            & open  \cr
 6 (PP) & gnd                   & NC            & gnd   \cr
 5 (RR) & init h                & NC            & open  \cr
 4 (SS) & gnd                   & NC            & gnd   \cr
 3 (TT) & in00                  & JK2-1         & od00  \cr
 2 (UU) & gnd                   & NC            & gnd   \cr
 1 (VV) & open                  & NC            & open  \cr
}}}
\caption
{\quad Wiring list for the cable interface J2. NC denotes ``not connected''.
In the first column, the pin number is followed, in parentheses,
by the corresponding letter ID used for some types of connectors.}%
\label{wirelistJ2.tab}%
\end{table}

For reference, figure \ref{pinout.fig} provides 
a diagram of the leads that would appear on the reverse
side of the cable interface shown in figure \ref{cablecon.fig}.

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/pinout.eps}}%
{Pin diagram for the flip side of the cable interface diagramed
earlier.}
\label{pinout.fig}%
\end{figure}

After the cable interface has been wired up, it is advisable to cover the
connector leads. A simple way to do this is to fasten another piece of
vector board over the back, using standoffs to keep it from touching
the leads. You may also want to put the assembly in a metal box for better
noise protection.

\section{Configuring the Device Into the System}\label{VMEconf.sec}

It is necessary to configure the XVME 240 into the system software.
The procedures for doing this are discussed
in the {\it RCCL/RCI Startup and Installation Guide}. This section
assumes that the system kernel has already been configured
for RCI operation, and you only need to add support
for the XVME 240 board.

\subsection{Sun4 systems}

An RCI UNIX driver for the device must be configured into the kernel.
This is done by adding an entry for the RCI UNIX {\tt xyd} driver
to the UNIX kernel configuration file. A typical entry looks like this:
\begin{verbatim}
      device  xyd0 at vme16d16 ? csr <address> priority <ipl>
                                 vector xydintr <vector>
\end{verbatim}
where {\tt <address>} and {\tt <ipl>} should match the bus address
and IPL values
set on the board, and {\tt <vector>} should be an unused VME vector number
(which will be set on the board by the driver software).

UNIX must then be rebuilt.

An special file must be created in {\filefont /dev} for the
{\tt xyd} RCI UNIX driver. This will have a name like
{\tt /dev/xydRCI0}, where the trailing digit
indicates the unit number.

An entry also needs to be made in the file {\filefont conf/robots}
for the robot which uses the device.
A typical entry will look like this:
\begin{verbatim}
      robot=<robotName> device=xyd address=<address> 
                        interrupt=/dev/xydRCI0
\end{verbatim}
The {\tt robot} field gives the name of the robot, and the {\tt device}
field gives the name of the RCI communication driver ({\tt xyd} in this
case). {\tt <address>} is the bus address set on the board. 
The {\tt interrupt} field names the special file used by the RCI UNIX
{\tt xyd} driver. RCI does not need to know the vector number.

No recompilation is necessary after you change the {\tt robots} file.

\subsection{SGI IRIS systems}

An RCI UNIX driver for the device must be configured into the kernel.
This is done by adding an entry for the RCI UNIX {\tt xyd} driver
to the UNIX configuration file {\tt /usr/sysgen/rciext/system}. 
A typical entry looks like this:
\begin{verbatim}
      VECTOR: module=xyd vector=<vector> ipl=<ipl> unit=0 
              base=<sysaddr> probe=<sysaddr+0x81> probe_size=1
\end{verbatim}
{\tt <sysaddr>} is the bus address of the device set on the board,
{\it added} to the base address of the VME A16D16 supervisor
space in system virtual memory (check the {\it RCCL/RCI Startup and
Installation Guide}). {\tt <ipl>} should match the IPL value
set on the board, and {\tt <vector>} should be an unused VME vector number
(which will be set on the board by the driver software).
The {\tt probe} field provides an address (offset from {\tt sysaddr} by
0x81) used by the driver probe routine.

UNIX must then be rebuilt, by running 
\begin{verbatim}
      % make unix.new
\end{verbatim}
in the directory {\tt /usr/sysgen/rciext}.
{\tt unix.new} can then be copied to {\tt /unix}.

A special file must be created in {\filefont /dev} for the
{\tt xyd} RCI UNIX driver. This will have a name like
{\tt /dev/xydRCI0}, where the trailing digit
indicates the unit number.

An entry also needs to be made in the file {\filefont conf/robots}
for the robot which uses device.
A typical entry will look like this:
\begin{verbatim}
      robot=<robotName> device=xyd address=<address> 
                        interrupt=/dev/xydRCI0
\end{verbatim}
The {\tt robot} field gives the name of the robot, and the {\tt device}
field gives the name of the RCI communication driver ({\tt xyd} in this
case). {\tt <address>} is the bus address set on the board. 
The {\tt interrupt} field names the special file used by the RCI UNIX
{\tt xyd} driver. RCI does not need to know the vector number.

\subsection{VxWorks systems}

No kernel driver is necessary on VxWorks systems. Instead, the interrupt
handling is done by an extra routine in the RCI communication driver
{\tt xyd}. Information used by this routine is specified by additional
fields in the {\tt robots} file, which for VxWorks systems
is located in {\tt conf/robots.vxw}.

The entry the {\tt conf/robots.vxw} should look like:
\begin{verbatim}
      robot=<robotName> device=xyd address=<address> 
                        interrupt=xyd intraddr=<address>
                        ipl=6 vector=24 
\end{verbatim}
The {\tt robot} field gives the name of the robot, and the {\tt device}
field gives the name of the RCI communication driver ({\tt xyd} in this
case). {\tt <address>} is the bus address set on the board. 
The {\tt interrupt} field names the RCI communication driver that will
handle interrupts (also {\tt xyd} here), and {\tt intraddr} gives 
the bus address of the associated device (also {\tt <address>} here).
{\tt <ipl>} should be the IPL value set on the board,
and {\tt <vector>} should be an unused VME vector number
(which will be set on the board by the driver software).

\section{Installing the Clock Timer Module on Sun4 Systems}\label{Sun4clock}

If you want to add a clock timer module to your Sun4 system, 
then you should buy a XYCOM XVME 203 clock timer module.
This will require an additional VME slot on the Sun4.
This option is not currently supported on SGI or VxWorks systems.

If the system is being configured with the XVME 203 clock module, then
the jumpers on this board should be set as described in table
\ref{xvme203.tab}.

\begin{table}[htb]
\centerline{\tablebox{\halign{%
#\hfil&\quad#\hfil&\quad#\hfil\cr
Jumper&Function&Setting\cr
\noalign{\medskip\hrule\medskip}
ja10 - ja15&module base address&as required\cr
J1&access control&removed (global access allowed)\cr
}}}
\caption{\quad Jumper and switch settings for the XVME 203.}%
\label{xvme203.tab}
\end{table}

The module base address should be set to a free location in 
VME A16D16 space. Note that the board occupies 1 Kbyte in this space.
Jumpers ja10 through ja15 select VME address bits 
10 through 15. An address bit is set if the
corresponding jumper is removed. A module address of 0x1000 would hence
be selected by removing jumper ja12 and leaving all the others
installed.

\subsubsection{Configuring the clock into the system}

The clock timer needs to be configured into UNIX. The associated device driver
is {\tt xydclk}, and its usual entry in the system
configuration file looks like:
\begin{verbatim}
      device  xyclk0 at vme16d16 ? csr <address> priority <ipl>
                        vector xyclkintr <vector>
\end{verbatim}
{\tt <address>} should match the address setting on the board,
{\tt <ipl>} should be set to match the clock's interrupt priority, which is
defined by {\tt VME\_IPL} in {\filefont rciext/xyclkreg.h}, 
and {\tt <vector>} should be an unused VME vector number.

The special file {\filefont /dev/rciclk} should be created for this device. 
When an RCI program starts up, it checks to see if it can open
{\filefont /dev/rciclk};
if it can, it presumes that a clock timer module is present on the system
and it proceeds to use it. Otherwise, it will use the UNIX system clock.

\chapter{Hardware Work Required for the Unimation Controller}

\section{Upgrading the CPU}\label{pumaCpu}

If you have a PUMA controller, check out the type of the CPU. If it is
an LSI-11/02, then you will probably want to upgrade to something faster
(like an LSI-11/73) to speed up both {\tt moper}
and the communication with RCI (this is particularly
necessary if you are using a parallel port for communication).

\subsection{Types of LSI-11 processors}

Old Mark I controllers usually have an LSI-11/02. Old Mark II controllers
contain an LSI-11/23, which is about twice the speed of an LSI-11/02,
and all the new controllers have an LSI-11/73, which is twice the speed
again, plus the speed up due to the existence of an 8 Kbyte
cache memory.

It is best to upgrade the CPU to an LSI-11/73 (or an LSI-11/23 at the
very least). To illustrate the speed differences between the various
CPUs, minimum robot controller cycle times are presented which 
include reading encoder information from the joints,
communicating with a MicroVAX host system, and sending commands out to
each of the six joints:

\bigskip
\centerline{\tablebox{\halign{%
\hfil#\hfil&\qquad\hfil#\hfil\cr
CPU type&Cycle time (msec.)\cr
\noalign{\medskip\hrule\medskip}
LSI-11/02 &13\phantom{.5}\cr
LSI-11/23 &\phantom{1}8.5\cr
LSI-11/73 &\phantom{1}4\phantom{.5}\cr
}}}

These numbers include {\it all} processing time on the LSI-11. The sub-portion
of this time which is spent communicating
with the host is about 1.5
msec.\ for an LSI-11/73, as has been mentioned elsewhere.

The second-hand cost of an LSI-11/73 CPU is about \$1,000 U.S. (1992
price), while the second-hand cost of
an LSI-11/23 is about \$400 U.S. (the latter is much cheaper since it only has
an 18 bit address space, but this is irrelevant to {\tt moper} applications).
The LSI-11/23 is not as recommended since it is only about half the speed.

\medskip
\begin{quote}
{\bf NOTE:} If you upgrade to an LSI-11/73 processor, then your
controller may no longer be able to run VAL (unless you
reinstall the original processor). 
This is because the LSI-11/73 needs to explicitly turn its clock on in
software, and versions of VAL which are not written for the LSI-11/73 will not
probably note do this. 
\end{quote}

\subsection{Where to get processors}\label{getcpu}

The official DEC name for an LSI-11/73 CPU is the KDJ11-A.

There are 3 types of KDJ11-A:

\bigskip
\centerline{\tablebox{\halign{%
\hfil#\hfil\qquad&#\hfil\cr
KDJ11-AA: & No floating point.\cr
KDJ11-AB: & No floating point, but has sockets for it.\cr
KDJ11-AC: & Floating Point. \cr
}}}

Floating point is {\bf not} needed unless you are planning to do things
with {\tt moper} that we never considered.

The official name for an LSI-11/23 is the KDF11-B. There are different flavors 
of it: KDF11-BA, BE, BF; most of these designations seem to be related to what
boot software it comes with. The 
KDF11-BA would probably be the best bet.

Processors, and other DEC components, can be ordered second-hand from 
any of the second hand DEC vendors listed in section \ref{vendors}.

\subsection{Installation}

This is trivial. Just pull out the old CPU from the controller
(it is the single dual board at the head of the bus) and
drop in the replacement. That's it. 

When you order the CPU, make sure you get a user's guide with it
(Newman Exchange will do this; I do not know about the other vendors).
The DEC part number for the {\it KDJ11-A User's Guide} is
EK-KDJ1A-UG-001.

\section{Adding an Automatic Arm-Power-On Circuit}\label{poweron}

It should be possible to wire up your controller so that
RCCL/RCI can turn the robot power on automatically using
software. Installing this feature
can save trips to the robot controller every time you
start an RCCL/RCI program. 

The basic idea is as follows: Unimate controllers
generally have an input line
that can be used to turn on the arm power remotely; this
is usually called ``ARM POWER ON''. Connecting one of
the controller's output signal lines
to this input line allows the arm power to be activated
by software.

\subsection{Wiring the controller}

\begin{table}
\centerline{\tablebox{\halign{%
#\hfil&\quad#\hfil\cr
signal&connection\cr
\noalign{\medskip\hrule\medskip}
remote arm power on A (pin 5D) & out ``X'' A \cr
remote arm power on B (pin 6D) & remote supply 0V (pin 8C) \cr
remote supply +24V (pin 9C) & out ``X'' B \cr
}}}
\caption{\quad External connections to arrange for an 
automatic power-on capability
with the Mark III controller. ``X'' 
denotes the output signal line to be used.}%
\label{poweron.tab}
\end{table}

The first thing you should do is chose the output signal
line. Make a choice that does not
interfere with other anticipated uses of the signal lines.

The normal interface to these output lines is through relays.
On Mark I and Mark II controllers, relays are supplied by
{\it I/O modules} which you attach to your system. Usually
only one module is provided by default, and this only
provides access to the first 8 output lines. Accessing the
other lines requires buying additional modules.
On the Mark III controller, the relays are built into
the controller box, and more are provided.

If you want to make the connection through the relays, then
you need to arrange things so that setting the indicated
output line relay causes a ``high level'' to be seen by
the ``ARM POWER ON'' relay. 
On the Mark III controller, this is fairly easy because
the necessary power signals are already supplied by the controller.
One only needs to make the connections described in Table
\ref{poweron.tab}.
For this to work, you must also set
the ``Remote/Local'' key switch on the front panel
to ``Remote''.

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/outputbit2.eps}}%
{Location of output bit 16 and the ``ARM POWER ON'' signal
on the MARK I controller.}%
\label{foo2}%
\end{figure}

It is also possible to avoid using the relays, and do the wiring
directly using internal signal bits. This offers the advantage
of using only one wire. 

Internally, the Unimate controller uses a high density parallel port interface
that provides 32 output bits and 32 input bits. The device occupies 
4 Q-bus words starting at address 0176740:
\begin{verbatim}
            0176740:      output port 0
            0176742:       input port 0
            0176744:      output port 1
            0176746:       input port 1 
\end{verbatim}
Output lines 1-16 are controlled by bits 0-15 of output port 0, and 
lines 17-32 are controlled by bits 0-15 of output port 1.
In relation to the output lines, these bits are normally
active {\it low}.

On the Mark I controller, the bits are directly accessible from the
P/C board at the back of the controller (see Figure
\ref{foo2}). At McGill, we simply connected bit 16 (i.e.,
bit 0 of port 1) to the ARM POWER ON line shown
in the figure. (This figure may be valid for the Mark II controller
as well; we haven't checked.) Finding the pins for other
bits may require a bit of detective work with a volt meter.

\subsection{Configuring {\tt moper} for automatic power-on}

Some variables need to be set inside the {\tt moper} program
so that when it receives a request to turn on the arm power
it sets the proper output bit in the right way.
Refer to the section ``Configuring {\tt moper}'' in the
{\it RCCL/RCI startup and installation guide}.

The relevant variables in the {\tt moper} config file
are {\tt powerChan}, {\tt powerBit}, {\tt powerNegative}, and
{\tt powerPulse}. 

{\tt powerChan} and {\tt powerBit} identify the output bit.
{\tt powerChan} identifies which output port to use (it is
an index into the table {\tt pioOutAddr}, located in the same
file). This will normally be set to either 0 or 1.
{\tt powerBit} is a bitmask identifying the bit within the
port, so that {\tt 0x1} would
identify bit 0, {\tt 0x8} would identify bit 3, etc.
So using ``output line 18'' to control
the power would involve using bit 1 of port 1, or setting
{\tt powerChan} to {\tt 1} and {\tt powerBit} to {\tt 0x2}.

{\tt powerNegative} and {\tt powerPulse} control how the bit is
asserted. If {\tt powerNegative} is true (which should almost
always be the case), then the bit is considered
active {\it low}; otherwise, it is considered active {\tt high}.
The bit is asserted for the duration of a spin count whose
value is given by {\tt powerPulse}. So for example, if {\tt powerNegative}
is {\tt 1} and {\tt powerPulse} is {\tt 1000}, then when {\tt moper}
receives a request to turn the arm power on, it will {\it clear}
the power bit, wait for 1000 machine cycles, and then {\it set} the
bit again. If {\tt powerPulse} is 0, the bit will not be cleared until
power is actually turned off; this is not recommended since it interferes
with the emergency stop switches. 
Because of time delays, 
{\tt powerPulse} needs to be set higher when it is operating through
relays (but setting it too high  may cause enough delay in {\tt moper} for RCI
to timeout).

\section{Diagnostic Trace Bits}\label{trace}

It is useful when running robot control applications to be able
to monitor the timing of the control functions on an oscilloscope. This can be
done by having the functions set and clear bits in a parallel port.

For RCI systems in which the interface board in the robot controller
is a DRV11 (or a clone thereof), some of the bits on that board
can be used to monitor control function activity. Specifically, the
communication handshake bits, which fluctuate while data is being transferred
between the controller and the host, can be watched to give an indication of
what is going on.

The three bits of interest can be obtained by soldering taps onto the
backs of the J1 and J2 connectors of the robot controller's
DRV11 (this port is the easiest to get to). The lines,
as named on that port, are:

\bigskip
\centerline{\tablebox{\halign{%
#\hfil&\qquad#\hfil\cr
Line & Function \cr
\noalign{\medskip\hrule\medskip}
CSR0 &Controller interrupt to host\cr
REQA &Host interrupt to controller\cr
REQB &Communication handshake bit\cr
}}}

\noindent
These taps can be placed on the back of the DRV11 at the
solder points indicated by 
Figure \ref{taps}.
\begin{figure}[thb]
%\rect 4 truein by 5 truein%
\boxedsizedfig{4.75truein}{5truein}{\psfig{figure=figs/drv11trace.eps}}%
{Where to connect DRV11 trace lines.}%
\label{taps}%
\end{figure}


CSR0 is set, or pulsed, every time the controller sends an interrupt to
the RCI host system. This will happen once every control cycle if
the robot control task is being
scheduled using either the {\tt ON\_FUNCTION} or {\tt ON\_TRIGGER}
disciplines, since in these cases the controller is responsible
for waking up the control task\footnotemark.
\footnotetext
{If the control task is being run on an auxiliary CPU, no interrupt
is actually received, but the controller will set the bit anyway.}

REQA is set by the host to interrupt the controller; this will be done
once near the beginning of every control cycle
if the control task is scheduled using either {\tt ON\_CLOCK} or {\tt
ON\_TRIGGER}.

REQB is one of the handshake bits, and it oscillates between high and low
whenever data is being transferred between the two systems.
Watching this bit gives an
indication of the length 
of time required for control task communication and computation. If REQB is
observed on a scope, then a pattern similar to the one shown in Figure 
\ref{pattern} should be seen.
\begin{figure}[thb]
% \rect 5 truein by 3 truein%
\boxedsizedfig{5truein}{3truein}{\psfig{figure=figs/reqb.eps}}%
{Typical REQB pattern during communication.}%
\label{pattern}%
\end{figure}

The first set of pulses occurs 
near the beginning of the control function when the robot
input function is called and feedback data is sent to the host.
This is followed by an interval of
a couple of milliseconds during which the input function
unpacks the data into the
{\tt HOW} structure and performs limit checks. The control function may
then do other processing at this point. The second set of pulses
occurs when the robot output function is called and commands are sent down to
the robot controller. 

On some systems, after the output function returns, the REQB bit may be set
high again by the RCI control function, and kept high until it returns,
as indicated in the figure. This allows timing of the entire
control cycle and determination of the percentage of host CPU time
consumed by the control functions. At the moment, this is done by both the
RCCL and CHASE trajectory generators on MicroVAX systems where the host
interface device is a DRV11 using the {\tt pri} driver.

Some extra tracing support is available on VME systems where the host
interface device is an XVME 240 which uses the {\tt xyd} driver.
This involves setting an otherwise used
output bit of the interface high whenever the RCI control functions are 
active. Tracing this bit on a scope provides another means of measuring
the control function timing.

\section{Current Measuring Circuit}\label{current.sec}

Applications which require an estimate of the joint torque
can achieve this by measuring the joint current.
A circuit to do this was fabricated at McGill University for the
Mark I PUMA 260 controller. It works by reading the currents
using an analog-to-digital converter on the Q-bus of the 
robot controller. 
The following description of the
circuit has been taken verbatim from the author's Master's thesis.

The motor current for each joint on the PUMA 260 is controlled by a separate 
microprocessor, which may operate in either a {\it position} mode, 
where the current
is regulated so as to servo the joint to a desired location, or a 
{\it current} mode, 
where the current is simply set to some value specified by the
supervisor controller (or RCI control task). 
The position mode uses a PID  control
algorithm which results in highly quantized output values for the joint
currents. Since the current values themselves are used as a measure of the
joint torques, such quantization can lead to large errors in these values.
One alternative would be to replace the joint microprocessor software with a
control algorithm developed to suit our needs. This would 
however, have been quite costly. A simpler solution was to make use of the
fact that the joint controllers run at a sample rate of 1000 Hz, whereas the
joint torque estimation operates at a (typical) 
rate of 36 Hz. It was therefore
possible to put a low pass filter into the loop, between the current sensing
resistor and the analog-to-digital converter, to provide averaging of the
current measure.

The whole current circuit is shown in Figure \ref{foo4},
and the sensing filter itself
is shown in Figure \ref{foo5}.
The current signal from the joint
microprocessor is amplified, sent to the motor, and returns
through a low-valued sensing resistor.
The voltage drop across this
resistor can then be measured, and used to determine the current. Because the
system has a very low impedance, noise proved to be an important
design consideration. The voltage signal across the resistor
is measured with a differential
amplifier, and then averaged
by an active low-pass filter with a time constant of 15
milliseconds. This averaged signal is then sampled by the analog-to-digital
converter.
The joint torque $t$ can be computed from the ADC voltage readings
according to the equation
\[
t = k \; {\rm adc}
\]
where $k$ is a constant equal to
\[
k = \sigma V_g / R,
\]
$\sigma$ is the motor torque sensitivity (Newton-meters/Ampere),
$V_g$ is voltage gain of the circuit plus the analog-to-digital converter,
and $R$ is the resistor value.

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/currentcircuit.eps}}%
{Joint motor current circuit.}%
\label{foo4}%
\end{figure}

\begin{figure}[tp]
\boxedfullpagefig{\psfig{figure=figs/currentfilter.eps}}%
{Current sensing filter circuit.}%
\label{foo5}%
\end{figure}

Once the current sensing circuit is installed, it is necessary
to configure the {\tt moper} software so that it will read
the ADC, get the current values for the different
joints, and return them to RCI.
The necessary changes are made to the {\tt moper} configuration
file {\tt lsi11/<robotName>.c}. 

First, the variable {\tt torqueAvail} should be set to {\tt 1};
this tells {\tt moper} that torque sensing is available. 
Then, the routine {\tt getTorque()} (located near the
end of the file) should be recoded so that it can read
current values from whichever type of ADC device is being used.
The routine should behave as follows: whenever the variable
{\tt torqueOn} is true, it reads ADC current values for all
six joints, places them in the array of {\tt short}s supplied
as a argument, and returns {\tt 1}. If {\tt torqueOn} is not true,
it simply returns {\tt 0}.
The routines {\tt startTorque()} and {\tt stopTorque()}
can be left as supplied:
they simply set or clear {\tt torqueOn} in response to the
RCI interface command {\tt SET\_TORQUE\_READ()}.

When torque reading is enabled, the ADC current values are
returned by {\tt moper} to the RCI robot input function,
which multiplies them by the {\tt currentToMtorque} constants
in the robot's {\tt JLS} structure and places the results in
the {\tt mtorque} field of the {\tt HOW} structure. The values
are also further multiplied by the transpose of the gear
ratio matrix and placed in the {\tt jtorque} field of the 
{\tt HOW} structure.

\section{Adding a Lord Force Torque Sensor}\label{force}

The {\tt moper} programs that come with RCCL/RCI have 
code which is capable of communicating with a
Lord F/T series force/torque sensor, using a
serial line interface (we have not implemented code
for the sensor's parallel interface).
This force data is relayed back by {\tt moper} to
RCI, which places it in the {\tt forceInput} field of
the robot's {\tt HOW} structure.

To connect a Lord force sensor to {\tt moper}, simply attach the sensor's
serial line to one of the free serial ports on the robot controller. 
By default, {\tt moper} expects the force sensor to be connected to
serial port number 2; this is the last port (out of four) located
on the first
serial card. On the Mark I controller, it is attached to the output
connector labeled ``accessory''. 

If you want to connect the force sensor to a different serial port, then you
need to edit
the {\tt moper} configuration file {\filefont lsi11/<robotName>.c} 
to change the serial port that
{\tt moper} expects. For instance, many sites use port number 3, the first
port on the second serial board. To make the change, find the routine
{\tt initForce()} and change the argument for {\tt sluGet()}
to the desired port number. 
The serial port number is actually just an index into the
array {\tt serialDevs}, which is located in the same file. By looking at 
(and possibly changing) that array, you will see what serial line units are
actually available. You will also see that some ports are not included in this
array at all (such as the console port), which is why the numbering of the
ports is a bit funny. 

Once the sensor is attached, {\tt moper} needs to be configured
so that it knows there is a force sensor available.
This is done by setting the static variable
{\tt forceAvail} in {\filefont lsi11/<robotName>.c} to {\tt 1}.
{\tt moper} should then be rebuilt.
The installation should now be complete:
calling the RCI macro {\tt SET\_FORCE\_READ()} should
enable the force sensor and cause force values to appear in the
{\tt forceInput} field of the robot's {\tt how} structure (though perhaps
not for a few control cycles; the sensor needs time to receive the
initialization string).

Also note that the serial force/torque interface will run at a peak rate
of about 50 Hz. If you run the control task faster than this, then the force
interface should still work, but you probably won't receive new force data
each cycle. You can check this by testing the {\tt forceOK} field
in the {\tt HOW} structure, which should be set to {\tt 1} whenever the
force data is fresh.

If you have trouble, you should immediately check two things: (1) the baud
rate on the serial line you are using, and (2) the initialization command that
{\tt moper} sends to the force sensor. This is contained in the string
{\tt forceInitCmd}, also located in {\filefont lsi11/<robotName>.c}. In fact, 
all of the force sensor interface code is located in this file, so if you have
to do some debugging, this is where you should start.

\section{Adding Other Sensors}\label{extra}

If your Unimate controller does not come with an analog-to-digital converter,
it might be worth adding one (any Q-bus ADC board will do). These devices
are useful as general sensor interfaces, and are also necessary if the
current sensing circuit of section \ref{current.sec} is being implemented.
An ADC interface is built into the RCI {\tt HOW} structure. 

Much of the sensor interface code used by {\tt moper} is contained
in the {\tt moper} configuration file {\tt lsi11/<robotName>.c}
Code to handle an Analog Devices
RTI-1251 analog-to-digital converter
lives here, as well as stub code to handle a joystick interface.
The various routines should be modified as required for
each particular robot.

\chapter{List of Hardware Vendors}\label{vendors}

{\it Please note: some of these addresses may be out of date.}

\noindent
Data Translation DT-2768 cards may be obtained from

\begin{quote}
Data Translation, Inc. \\
100 Locke Drive, Marlboro, MA USA 01752 \\
(617) 481-3700

\medskip

Data Translation Ltd. \\
The Business Centre, Wokingham, Berks RG11 2QZ, UK. \\
Tel. Reading (0734) 793838
\end{quote}

\noindent
Digital processor boards, such as the KDJ11-AA (LSI-11 CPU), or
the KA630 (MicroVAX CPU), as well as interface cards
such as the DRV11, DRV11-J, DRV11-B, or the DRV11-W,
can be obtained from DEC (of course), or second hand from 

\begin{quote}
The Newman Group \\
P.O. Box 900 \\
7400 Newman Blvd \\
Dexter, Michigan 48130 \\
(313) 426-3200 \\
FAX (313) 426-0777
\end{quote}

\begin{quote}
Midwest Systems Incorporated.\\
2800 Southcross Drive West,\\
Burnsville, MN 55337\\
1-800-328-7000
\end{quote}

\begin{quote}
Digital Basics Inc.\\
689 Souch Canterbury Drive,\\
Shakopee, MN 55379\\
800-522-1742\\
612-496-2550\\
FAX 612-496-2639
\end{quote}

\noindent
The XYCOM XVME 203/293 Real Time Counter Module and the
XYCOM XVME 240 Digital I/O Module may be obtained from

\begin{quote}
XYCOM \\
750 North Maple Road \\
Saline, Michigan  48176 \\
(313) 429-4971
\end{quote}

\noindent
The PT-SBS915 S-bus to VME adaptor can be obtained from

\begin{quote}
Performance Technologies, Incorporated \\
315 Science Parkway \\
Rochester, New York \\
USA 14620 \\
(716) 256-0200
\end{quote}

\noindent
Q-bus to Q-bus and Q-bus to VME-bus shared memory boards may be obtained
from 

\begin{quote}
Bit-3 Computer Corporation \\
8120 Penn Avenue South \\
Minneapolis, MN 55431-1393 \\
(612) 881-6955 \\
FAX: (612)881-9674
\end{quote}

\noindent
DMA boards for the VME bus which are compatible with the Q-bus DRV11-W
may be obtained from

\begin{quote}
VME Microsystems International Corp.\\
12090 South Memorial Parkway\\
Huntsville, Alabama\\
(205) 880-0444\\
(800) 322-3616\\
FAX: (205) 882-0859
\end{quote}

\end{document}
