Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-21699

Clean up XML for (MT) Rotator and Hexapod



    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Story Points:
    • Sprint:
      TSSW Sprint - Dec 9 - Dec 20, TSSW Sprint - Dec 23 - Jan 3, TSSW Sprint - Jan 06 - Jan 17
    • Team:
      Telescope and Site


      The XML for Rotator and Hexapod has some misfeatures I would like to fix if and when we are sure that we are writing our own CSCs. (Actually we could easily fix these even if we keep the vendor's code):

      • The Hexapod inPosition event has no inPosition field, so there is no way to indicate "not in position". Note that the Rotator inPosition event is fine. I suggest also adding an array of 6 booleans to indicate if each actuator is in position, perhaps named actuatorInPosition.
      • The Rotator tracking and trackLost events have no boolean value so cannot be output properly. They should be combined into a single event with a boolean flag.
      • Some telemetry is not output. I will not output them yet, but keep them in mind for the future, should we decide we need them:
        • copley_fault_status_register; note that similar latching registers are output.
        • input_pin_states
      • Several events are sent only when something (such as tracking, or a problem) starts, but not when it ends. We should send the event when the condition starts and when it ends, with suitable data (e.g. a boolean that is true if the condition is present).
      • Most events and telemetry topics have a timestamp field. That is a waste of space because it duplicates private_sndStamp.
      • The telemetry topic names are capitalized and so do not meet our current standards.

      These are at least partly fixed in DM-21694:

      • There is no detailed state event, even though that state is crucial for these CSCs. Fixed in DM-21694 by adding the controllerState event.
      • The deviceError event has a code field that is a string, and as implemented by the vendor, that "code" describes a single error so the event is output once for each error condition that is present. In DM-21694 I improved this by adding an applicationStatus field to the new controllerState event that has the bit mask. In addition I output deviceError once for a given set of error conditions, with code set to a comma-separated list of descriptions of each error so the event only when the error conditions change. I hope we can get rid of the deviceError event as duplicated information, even though a string can be nice.

      This task will also clean up the Jira tickets:

      (1) DM-20969 and DM-20971 for the telemetry.

      (2) CAP-362 and CAP-369 for the event.


          Issue Links



              rowen Russell Owen
              rowen Russell Owen
              Te-Wei Tsai
              Andrew Heyer [X] (Inactive), Bo Xin [X] (Inactive), Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai
              0 Vote for this issue
              6 Start watching this issue




                  No builds found.