[evlatests] what we should do about the ACU

[Ken Sowinski]

To provide context for what follows I have included here my
summary earlier this week of the ACU behavior that has been 
the cause of our problems.  This message is folowed by a 
summary of the discussion which was engendered in the form 
of two proposals: one to fix the ACU and another to fix the
ACU MIB to accommodate the ACU.  We welcome any comments as
to whether the proposed hardware or software changes are 
necessary and sufficient to address the limit seeking problem.

----- Begin Included Message -----

>From ksowinsk at nrao.edu  Mon Jan 30 09:30:42 2006
Return-Path: <ksowinsk at nrao.edu>
Date: Mon, 30 Jan 2006 09:30:41 -0700 (MST)
From: Ken Sowinski <ksowinsk at aoc.nrao.edu>
To: pwhiteis at nrao.edu, rmoeser at nrao.edu, bbutler at nrao.edu, bclark at nrao.edu
Subject: ACUs and limits
Cc: ksowinsk at nrao.edu
X-Sun-Charset: US-ASCII
Content-Length: 2042
X-Lines: 40
Status: RO

The ACU has two behaviors, which taken together may cause the 
antennas to unintentionally be driven toward limits.

The behaviors as described in the ACU manual are:
1.  When an antenna stows for any reason the commanded elevation
position in the ACU is replaced with zero.  
2.  The ACU has an 'invisible' state which when entered requires
that it get three sequential valid commands before it will transiiton
to standby with a side effect of executing the third valid command.  
The ACU enters the 'invisible', Waiting, state on power up and 
transition from local to computer control, both of which also replace 
the commanded azimuth position with zero.

In addition there is observational evidence, but no documentation
to support the following:
1.  The Waiting state can be entered when an ACU timeout occurs.
2.  Entering the wait state clears the azimuth command register.
I can find no support for these observations in the ACU manual or
the logic diagrams.  Carefully crafted experiments may be able to
distinguish exactly what is happening if we need this level of
understanding.

Ordinarily we never have a problem because the ACU has seen a
steady stream of az and el position commands before it is placed
in DPM and it just goes where it is told.  The case we must worry
about is when a single az and el, for example the park position,
is sent to the ACU followed by a DPM command.  If the ACU is in the
invisible state, it rejects the first two commands, executes the 
third and goes to the postion in the cleared azimuth and elevation
command registers.

The simplest solution is for the MIB to recognize simple pointing
commands, those with only a value field, and send then to the
ACU three times to ensure that at least one of them is acted upon
in all cases.  This still leaves us open to the possible user error
of placing an antenna in DPM without having sent any postion commands
at all.  It is less clear to me how to protect against this in all
cases.  It would help a lot of the Waiting state were not invisible.




----- End Included Message -----

The following is the formulation of we would do to either
the ACU or the MIB.


There was an email discussion earlier this week among a smaller
group concerning why EVLA antennas go into limits and how to 
reliably prevent it.  I present a summary of that discussion 
hoping that a wider audience may point out any shortcomings in 
our solutions before we are forced to learn about it the hard way.

The root cause of the problem is the annoying property of the
ACU to clear its commands registers when reset and there are
many things which cause such a reset; some clear only the 
elevation command register, some clear both axes.  If the ACU
were to preset its command registers to 360 and 90 degrees
rather than to zero the problem would be solved.  This can be
easily accomplished by adding four TTL inverters to the ACU.
An inverter in the input and output of the 360 degree bit of azimuth 
and the 90 degree bit of elevation would be all that is necessary
to provide the desired behavior.  This would be a foolproof 
solution with no opportunity for unforeseen behavior.

Adhering to the principle that software changes are easier than
hardware changes we can try to address the problem in the MIB.
Now we will also have to deal with the ACU property which causes 
it to require three squential, valid commands before it will act.
the first two commands, while valid, are ignored.  We propose two
changes to the MIB behavior to accommodate the ACU.
1.  A 'bare' position command if presented to the MIB will be sent
to the ACU three times.  'Bare' is a quaint term for a random 
position command which is not intended to cause the ACU to track
an astronomical object.  This guarantees that even if the ACU is 
in its reset state, the position command will make its way to the
command register.
2.  After a command to place the ACU in Digital Position Mode, the
MIB also send the current value of its Az and El position command
registers.  No limit checking need be done here because that is
enforced at a lower level of MIB software where the command to the
ACU is formulated.  This tries to ensure that the ACU has valid 
positions whenever it is placed in Digital Pointing Mode.

This will likely prevent antenna wandering to limits in most cases
but it is still possible to invent scenarios of that will cause
motion toward a limit.  It is easy to recover from this if it is
recognized by sending another position (such as the ACU screen park
button) command to each axis.  As long as software is involved there
is always the possiblity of unintended behavior in a complex system
which has had patches made to it from time to time to fix perceived
problems.