[evla-sw-discuss] A VLA virtual front panel

[Ken Sowinski]

I have suggested earlier that we need a VLA front panel GUI.  It is a
natural home for many of the global switches which now reside in the
ARRAY file and for the antenna control functionality of the Wye-Mon.
This discussion is forced upon us by the impending replacement of
Wye-Mon with the M302/3 utility modules in antenna 24 but should, in
any case, have been started by now.  If it is wrongheaded of me to
think that both these control functions can have a common
implementation, someone should point that out.  There are sprinkled
below ocassional invitations to have a discussion about how something
ought to be done and I hope those invitations are clear.

I am thinking about this for use during the transition era when the
old correlator is still in use.  Once WIDAR is in place some of the
resource allocation problems will go away but we are sure to have
other problems in their place.

Here is a list of candidates for the necessary control elements and 
comments on how the buttons might interact with the executor and 
antennas.  First a list of things currently in the ARRAY file for 
which we may need some analog.

1.  Resource allocation.  Which array (in the EVLA e2e sense)
    controls:
    a) The correlator quadrants
    b) Integration time
    c) Each of the Fluke synthesizers

There are two levels here.  The operator must control which array 
owns each of these resources, but each array must be able to delegate
resource ownership to each of its internal subarrays if there is more
than one.  The latter is done at the script level; the former by the
operator.  I haven't given this much thought but it seems likely that
much of this resource allocation will be mediated by the yet to be
defined correlator object.  The defaults for the VLA are:
a) any subarray; this is very bad
b) subarray 1
c) subarray 1 for Fluke set 1; subarray 2 for Fluke set 2.
   This allows the use of the Flukes to work without intervention
   by the operator in almost all cases of multiple subarray observing.

2.  Feed deicers.
This should not be controlled by the script.  You might consider
that the scheduler will know weather conditions well enough to
be able to include as part of a scheduling block whether the 
deicers should be on or off and include that as an element of
the Scheduling Block provided to the executor.  This does not
work cleanly if there are multiple arrays.  

3.  Broken weather station
This switch signals that the weather station is broken or unreliable
and a default weather model should be assumed.  Historically it has 
been controlled by the operator because we did not trust software
to make this decision reliably.  To aid in the decision, CHK will
complain if it thinks the weather information is wacky.

4.  Correlator self test control
There is a set of observations for which we want correlator selftest
disabled.  This is the switch, under control of the operator that
does it.  This one, I think, would be more foolproof if included in
the script.  

5.  Staggered slew.
When the VLA site is powered by generators we try not to cause
all the antennas to slew at the same moment to avoid large spikey
inductive loads on the generators.  There should be a monitor
point which says when the generators are in use but it doesn't
work (reliably?) and so this switch exists.  We should probably
review with Serna/Broilo whether the staggered slew tactic is still
necessary.

6.  Gated correlator observation.
This is the switch, propagated to the correlator, which tells it
whether to believe the V_s counters or theory.  Another candidate for
inclusion in the script when it is required for gated observations.

7.  Use estimated weather.
An alternative to a default weather model is an estimation of the
temperature, dew point and barometer that may be supplied by the
operator if the weather station is known to be broken.  This has 
never been used and was only tested during Voyager days.

8.  Array configuration.
I don't know if we want this on a front panel or in the parameters
database.


Here is a list of antenna related things that can be controlled by 
the Wye-Mon which are candidiate for inclusion in this screen.  There 
is much more in and around the control building that it deals with 
but that will be ignored for the moment.  It would be a good idea
to think about those problems and be sure we have a solution which
allows for their easy inclusion in the future.  An important part 
of the Wye-Mon alarm alerting mechanism is audio alarms for critical
functions.  Can we tie alarm condtions to audio output, but be careful
not to overdo it and overload the operator?  

1.  Master Emergency Stop.
This is a large red button that sets the emergency stop for all 
antennas at once.  I have never seen it used in anger, but it has
been used as a convenient way to secure all antennas if they are to
be stowed for an extended time.

2.  Emergency stop, ACU reset, Non-critical power reset
All three of these can be sent to all the antennas on a single arm.
This was implemented because it came almost for free given how the
Wye-Mon is wired to the antennas.  I claim we do not need to support 
this in the future, but can do something that is more useful.  These
can all be sent to individual antennas and this should probably be 
mediated through the ACU screen that pops up when you click on an 
antenna.  There is no provision in the Wye-Mon to send either of the
resets to all antennas at once.


I expect that the operator will deal with the utility modules on two
levels.  First at the individual antenna level it will be dealt with
much as any other module.  Clicking on an antennna should bring up an
ACU screen just as now but including the antenna control and monitoring
part of the M302 either explicitly or by another click on the ACU screen.
It would be nice if the antenna changes color if any of the important
M302 alarms are set: fire alarm, ACU fault, NCP fault, 28V fault.  Any
of these would be a candidate for an audio alarm as well, other less
serious faults should not trigger audio alarms.  The ACU screen should
have a button to disable and enable the audio alarm.

In addition there should be a VLA virtual front panel which will
subsume all the global functions I have already described.  The screen
need not be always visible but should be easy to get to when needed.

What should be on the VLA front panel are global controls.
  a) Reset all the ACUs
  b) Reset the NCP at all antennas
  c) E-Stop all antennas
  d) Put all antennas in DPM
  e) Park or Stow all antennas
  f) Reset only the ACUs which are in a fault state
  g) Reset the NCP only for antennas which have a NCP fault
  h) Resource control switches
  i) Feed deicer control
  j) Broken weather station switch
  k) Stagger slew control
  l) Array configuration
  m) Global audio alarm enable/disable


In addition to having the interface to the utility modules being part
of the operator's GUI we need a secondary way of interacting with the
utility modules available in case the primary scheme is not working.
The secondary method should be as independent of the primary as
possible.  Clearly it depends on the network to the antenna being
available, but beyond that it should be a standalone program able to
run on any CPU and independent of browsers and java.  The bare
functionality needed is to be able to monitor the critical alarm
states and to set and clear the emergency stops.