Proto-MR for Limiting Scan-Segment Parameter Feedback

Modification Request #n (Q99 2099)

1. Introduction

The GBT control system is based upon controllers or managers which perform various functions during a scan. Scan parameters which fully describe these actions are sent to devices prior to starting the scan via a control interface known as the 'panel'. When a scan is started the devices all report their settings to any user-interface or other programs via the panel feedback mechanism.

The Antenna, Active Surface, LO1 and Scan coordinator contain parameters which are used to specify motions of the antenna during a scan. In most cases a scan will be described in a handful of segments. However, some scan types result in thousands of scan-segments. When a large number of these are used, the processing of the feedback presents a significant load on programs, and can cause the appearance of a temporary 'system lockup'.

This is all rather unnecessary, as nothing actually uses the scan-segment feedback. This MR describes a change which would allow a manager to limit the number of records sent back to other programs and user-interfaces.

2. Background

(Optional - Remove this section if not used.)

3. Requirements

3.1 Add Parameter Feedback Length Set Method

Add a method to Parameter (all types) to specify the amount of data sent back for a given parameter. The default shall be to send all data.

3.2 Add Parameter Feedback Length Get Method

Add a method to Parameter (all types) to return either the length returned by 'getIOLength()', or the feedback length specified.

3.3 Update Manager reportValue Method

Modify the Manager::reportValue() method to use the feedback-limited size instead of 'getIOLength()'.

3.4 Update Scan-segment Parameters in Managers

Modify the antenna coordinator, antenna manager, LO1 coordinator, and scan coordinator programs to limit the feedback of the parameters 'primarySegments', 'primaryOffsets', and 'userSegments' to the size of one (or other integral multiple) segment of the respective type.

4. Design Strategy & Summary

As it turns out, there is already a mechanism to limit parameter I/O transfer sizes. (This was done for some specially crafted objects which embed other information inside the parameter.) This mechanism can not be used, because it limits both the set and get sizes.

This change requires an extra field in Parameter object, which notes the feedback limit size. Access methods for setting this field (by a derived manager) and getting this field in the Manager::reportValue() method are required.

5. Impacts

Since this MR requires the modification of base-classes, a full re-install will be required to deploy this change.

6. Deployment Checklist

What has to get done to integrate this completely into the system. The generated checklist must be completed before Cycle Integration Testing begins.

Note - The questions below are just to get you thinking. Remove irrelevant questions. Answer relevant ones, but don't keep the question text. And, please take a moment to think of anything else that needs to happen during deployment.

  • Communication with Computing group needed?
  • What documentation needs to be updated?
  • Training Needed? Is this being released to staff astronomers or everyone right now?
  • Notification Needed?

7. Test Plan

Critical!! ChangeControlCommittee will be reviewing these. Please send a link to this MR to ToneyMinter along with a suggestion for two reviewers when it is ready for CCC review.

Don't forget to include/acquire any additional GBT test time needed outside integration/regression testing! Get your requests in early!

Important! If possible, you should conduct as many of your tests as possible in offline modes and/or with a simulator. We should constantly endeavor to minimize our use of telescope time for testing!

7.1 Internal Testing

This section covers things like unit testing, simulator testing, and any other tests required to make sure this MR is ready for sponsor/integration/regression testing.

7.2 Sponsor Testing

This section is for the sponsor. What do you need to do in order to ensure that the MR is complete and correct? These tests are the prerequisite for sign off for the "accepted/delivered by sponsor" item in the "signatures" section.

7.3 Integration/Regression Tests

What do the integration/regression testers need to do in order to test this MR.


Signatures

APPROVED: To the best of my knowledge, the requirements section of this MR is complete and the other sections contain a reasonable plan forward. I have thought through this request, and believe it to be an important feature to implement or bug to fix.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests.

Written symbol - name - date
Checked symbol - name - date
Approved by Sponsor symbol - name - date
Approved by CCC symbol - name - date
Accepted/Delivered by Sponsor symbol - name - date

Symbols:
  • Use %X% if MR is not complete (will display ALERT!)
  • Use %Y% if MR is complete (will display DONE)


CCC Discussion Area

-- JoeBrandt - 2010-12-21
Topic revision: r1 - 2010-12-21, JoeBrandt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback