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

[Barry Clark]

> 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.

Since this is a transition item, we should do things in the simpliest 
possible way.  The current Modcomp way is more complicated than necessary
for some of these things.

> 
> 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.
> 
I'm thinking this function can be done by the script launcher.  It could
tell the script interpreter which 'correlator subarrays' it can talk to
and which Fluke set to use.  Correlator subarray 1 controls integration
time, line/cont, quadrants for line.  Modcomps have stuff to prevent subarrays
from fighting over Fluke sets.  fuhgedaboutit.

> 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.  

Screen want a three position switch on-auto-off.  In 'auto' position, 
a thread has a look at the relative humidity every five minutes and 
makes up its own mind.
> 
> 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.

My understanding is that we won't be able to run antennas and WIDAR
on the generators.

> 
> 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.

This, and item 3, are, I think, most easily handled by the script launcher.
> 
> 8.  Array configuration.
> I don't know if we want this on a front panel or in the parameters
> database.
> 

Another thing that would be nice to have buttons outside the scrip is
include/exclude from phased array sum.

> 
> 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.
> 
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>