Dir : mac

    This directory contains the programs that can be downloaded in the
                            Unimate Controller

The program 'moper' is the run time joint processor  /  vax  interface.  It
exists  in  eight  versions  (debug/nodebug  adc/noadc  val1/val2).   Moper
includes the files fifoio.h, rtc.h, cmdk.h and which.h in common  with  its
vax counterpart. Addefs.h and jcom.h contains bit definitions and macros to
allow the joint processors communications.


The C union 'how' allows to map the fifo buffer onto a structured variable.
The 'how' buffer transmitted to the vax is of variable length.  The minimum
length contains the external io register, joint encoder positions, if (ADC)
the  joint motor currents.  One 16 bits word is sequentially added for each
opened  adc  channel.  (adcopen  in  pack.c  and  moper  make  the  logical
correspondence between a channel and an array index).


The commands are obtained from the vax and the command buffer is a succession
of records like :

A_COMMAND v1 v2 v3 v4 v5 v6     same command for all the joints, six values

I_COMMAND v                     one command for one joint, one values
				(joint number in low byte)

G_COMMAND v                     one general command, one value

E_COMMAND                       one command, no value

This organization is reminder of the time the interface was very  slow  and
the  data  was  packed  on  byte  boundaries.  It has been kept for the new
interface although a buffer  containing  all  possible  combinations  would
probably  do  and  would  be  easier  to implement.  This has been kept for
compatibility and flexibility (it is very easy to add more  commands  while
not  increasing  the size of the buffers).  Now the commands are kept on 16
bits words boundaries because it is a lot more  efficient  and  simple  and
since the buffer size is not critical.

A complete command buffer looks like say :

| A_C v1 v2 v3 v4 v5 v6 | G_C | I_C v | .... | chck

And the buffer actually put into the fifo is :

wc | A_C v1 v2 v3 v4 v5 v6 | G_C | I_C v | .... | chck


The (NTEST) first exchanges  are  used  for  exercising  the  channel.  The
superviser  then  sends  a  how  buffer  and  gets an initialization buffer
containing the calibration data that make  the  superviser  independent  of
this calibration data.  The remaining exchanges are regular exchanges until
a G_END command is received that puts the clock to  sleep,  after  a  short
period  of  time  arm  poser is turned off.  This has been done to avoid to
cause a lot of stress on  the  gears  when  the  brakes  are  set  at  high
velocity.  It  causes  the joints to servo on the last point a while before
being locked.  The drawback is that a high current  is  suddenly  required.
(it  has  causes the power amp of joint 2 to smoke and blow it's transitors
before the fuses, but i guess that was an extreme case and it  is  probably
better  to  reduce  the gear's wear).  Once power is turned off, superviser
goes  back  monitoring  the  arm  power  press  button  and   will   resume
interrupting  the  vax  when pressed.  The normal code is dumb and does not
make any prints so it does not require to use two terminals.  If it  exits,
the  only  way to tell is that nothing happens.  Under odt, just restart it
(2000G).  If the error persists, the debug version may help.  If  not,  use
the channel test program.
Note : when the servo mode transitions from current to position,  a  glitch
is  caused  by unmatching current specifications.  Probably, during several
servo cycles the servo code does not behave properly.  The problem has been
partially  solved by changing the gravity current offset during a couple of
sample periods.  The result is still pretty ugly but the problem  could  be
solved only at servo level and would have caused too many troubles.


The maintenance program is stand alone and is also downloaded.  All it does
is   to  move  the  joints  individually  by  small  increments,  test  the
calibration procedure, and allow to free joints.  It is handy to use when a
disaster occurs for testing the controller.


The test programs 'lsitst vaxtst', only exercise the channel and allow
for some performance measurements.
