NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > ReleaseNotes_5_1

Changes | Index | Contents | Search | Statistics | Go

M&C 5.1 Release Notes

Released on Wednesday, February 16, 2005 with a new AIPS++ stable

This release was coupled with a new GFM, which is significantly enhanced from the prior version.

• Testing Activities
• Major Changes and Additions
  • Premier Release of the Astronomer's Integrated Desktop (Astrid)
  • gbtaio1 Retired
  • Updated Balancing Commands and Usage
• New Features and Improvements
  • IF Rack Balancing Sensible when Input Power Too Low
  • Turtle Upgrades
  • GO Additions
  • PF Receivers are Synchronous
  • Enable Startup of CCU from Local Hard Disk
  • Default Project ID Changed from "test" to "JUNK"
  • Other
• Known Issues
  • LO1 Manager Loss of External Reference (remains from last cycle)
  • Power Supply 5 in Motor Rack (remains from last cycle)

Testing Activities

Major Changes and Additions

Premier Release of the Astronomer's Integrated Desktop (Astrid)

Note: please do not attempt to use astrid for the first time without first consulting with a member of the project team.

The Astronomer's Integrated Desktop (astrid) is a single, unified workspace that incorporates, but does not replace, the suite of applications that can be used with the GBT. This is an application manager, which means that all of the underlying science is taken care of by the individual applications. If all the real work is done by the underlying applications, why should we have an application manager at all? The answer is: to make it easy to launch all the applications you need for an observing session, without remembering which applications you need, or which commands to use. The integrated desktop also makes it easy for you to find the most up-to-date documentation at 3am without searching the wiki. The default applications are:

• Observation Management (turtle)
  • Access to the config_tool and the Balance API is provided automatically through the "Command Console" at the bottom of the screen. No "import" statements are necessary.
• Data Display (gfm)
• Documentation (by going to Help->Documentation in the menu bar across the top of the screen)

You can also access a text editor, a Python editor, or extra copies of any of the above applications.

If you are accustomed to using a three- or four-headed monitor, you may not see a need for an integrated desktop. Keep in mind two things: first, you can always open up multiple copies of astrid, one per screen, to manage your windows. Second, we must develop with remote observers in mind, who rarely have the luxury of multiple monitors and must be accommodated in different ways.

A suggested configuration on titania in the control room might be:

• Screen 1: Astrid with Observation Management (turtle) visible
• Screen 2: Astrid with Data Display (gfm) visible
• Screen 3: Cleo Container
• Screen 4: A terminal window with gbtstatus executed, plus web windows

gbtaio1 Retired

This cycle, several managers were moved to the machine fire, including PF1 and PF2 receivers, the LO1 Router, the PF Support Rack, the IF Rack, and the Motor Rack. There is no longer any production software running on the VxWorks machine gbtaio1. The electronics group made a new cable to support a connection to machine fire and also spent some time tightening up the connections, so reliability has been improved on both the hardware and software sides.

Updated Balancing Commands and Usage

Balancing the BCPM during observations from within a scheduling block is now possible. An example turtle script called "kband_acs_tp_bcpmbaltest.tp" can be found in the under the TREG project from within the application.

The following syntax is legal from within a Scheduling Block (turtle script), and is RECOMMENDED PRACTICE:

Balance()
Balance("IFRack")
Balance("Spectrometer")
Balance("SpectralProcessor")
Balance("RcvrPF_1")
Balance("RcvrPF_2")

The following syntax is legal from the Astrid "Command Console", which exposes the Balance API, and is RECOMMENDED IF YOU NEED TO BALANCE MID-SCAN ONLY. Though it is also legal from within a Scheduling Block (turtle script), it is not recommended.

Balance(["ifrack"])
Balance(["ifrack","pf","sp","acs"])
Balance(("ifrack",))
Balance(("ifrack","pf","sp","acs"))

Note that when balancing multiple items, the items are balanced in the order specified; only include those items that you wish to balance. There is a fine balance between readability and minimizing keystrokes, which is why for most observers the first methods are recommended.

New Features and Improvements

IF Rack Balancing Sensible when Input Power Too Low

Previously, when a user would balance the IF Rack without enough input power to reach the target level, the attenuator would always ends up at 31 db. At this point the attenuator would have to be set by hand to zero to optimize the power.

Now, each optical driver which is selected for balancing is read and its attenuator adjusted until it is within .5 dB of the desired value, or 10 attempts have been made. The attenuator is not further adjusted regardless of whether balancing was successful or not. At the end of balancing a Notice message is generated if the signal is too weak, even with the attenuator set to zero. This message is cleared if a new balance effort succeeds. At the end of balancing a Warning message is generated if the signal is not within .5 dB of the desired value. This message is cleared if a new balance effort succeeds, if the attenuator is set directly, or if the driver is de-selected for balancing. During monitoring an Error message is generated if the power is 10 volts or higher and cleared otherwise.

Turtle Upgrades

• When turtle is running a Scheduling Block containing Peak or Focus procedures, if the expected LPC values are not available in 15 seconds, turtle will pause the script and generate a dialog containing a warning and providing the user with the option of continuing or aborting the block.
• Turtle now relies on GFM to produce local focus corrections and local pointing corrections. In the past, it has generated its own. This is no longer the case.
• The turtle Edit tab has been upgraded with an Python-aware editor that also shows line numbers.
• Turtle handles Grail errors more robustly, i.e. the setting of illegal parameters/parameter values is now caught and an error message is displayed to the user.

GO Additions

This cycle, SDD aimed to deliver as many of the items at GOItemsC12005 as possible. The following are included in the C1 release:

• GO retains velocity and velocity definition when changing observing modes. Velocity frame must be reset after pointing, because GO will now change your configuration. Any questions should be directed to Ron.
• Rates are not settable when using Nod. Instead, the Nod now eliminates the rate widgets and uses zero rates at all times.
• Peak is now set to pick offsets, which is necessary for GFM to work and is something IARDS can handle as well.
• Procedure iteration count has been repaired for GO tables, in response to PO#1019.
• Off-line users running GO in simulate mode are limited from affecting telescope setup via IARDS.

During testing, we found that even minor changes to GO at this point lead to unexpected and sometimes treacherous failures. We do not recommend that any further additions to GO be made because of the evident instability.

PF Receivers are Synchronous

• Now that they have been ported to Linux, the PF receivers now operate as synchronous managers, like all the other receivers.

Enable Startup of CCU from Local Hard Disk

• The Central Control Unit (CCU) is the servo controller for the azimuth and elevation drives. Currently this is hosted on single board computers running VxWorks V5.1, which boot from a unix host (virgo) on the network. In the previous configuration, if the power was interrupted to the CCU and virgo, the auto-stow procedure may not execute. The problem was due to a dependency on virgo to reboot the CCU after loss of power. In order to alleviate this dependency, the CCU and SCU were augmented with solid-state SCSI disk drives this past cycle.

Default Project ID Changed from "test" to "JUNK"

• Prior to this release, the default projectId when any Manager boots was named "test" which is not considered a legal projectId according to operations. Though for scheduled observing and testing this default is overwritten to a legal value, during routine investigations into problems where the production of data is ignored or unintended, data is often written to the "test" directory. This change ensures that such data is written to a "throw-away" project, a "/dev/null" as it were, which is called "JUNK".

Other

• The sparrow build process was significantly streamlined this cycle. The M&C libraries have been completely decoupled from the sparrow build, and all sparrow applications now use a more recent version of Python. This will not affect users at all, but it makes the lives of several people in the SDD much more enjoyable.

Known Issues

LO1 Manager Loss of External Reference (remains from last cycle)

• A fix that was originally attempted for PO#941, "Add LO1 Warning for Loss of External Reference," was backed out of in early January. At that time Roger was supposedly working in the lab to determine the correct behavior of the LO1 under these circumstances. As a result, the LO1 Manager will not set up the synthesizers to force to external reference. The SDD is waiting for further instructions before attending to this issue. The user will NOT see an error if there is a loss in the 10 Mhz reference signal on LO1.

Power Supply 5 in Motor Rack (remains from last cycle)

• Power supply 5 in the Motor Rack has a hardware problem. It always shows failed and the logs are not written.