Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Story Points:3
-
Epic Link:
-
Sprint:TSSW Sprint - Dec 9 - Dec 20, TSSW Sprint - Dec 23 - Jan 3, TSSW Sprint - Jan 06 - Jan 17
-
Team:Telescope and Site
Description
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-21694by 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-21694I 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:
Attachments
Issue Links
- mitigates
-
- Done
-
- Won't Fix
- relates to
-
DM-21949 Only output tracking and trackLost events when newly true
- Done
-
- Won't Fix
(1 mentioned in)
Activity
| Field | Original Value | New Value |
|---|---|---|
| Team | Telescope and Site [ 13500 ] |
| Description |
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):
- There is no detailedState event, even though that state is crucial for these CSCs. I note that here but plan to fix it in - 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. - The deviceError event has a "code" field that is a string, and as implemented by the vendor that "code" describes just one error, even if many error conditions are present. For the Python CSC I made "code" a comma separate string of all error conditions. But I think we need to output a bitmask that describes all error conditions, with an associated enumeration. (We could retain the text string as well, though it duplicates information). - Most events and telemetry topics have a timestamp field. That is a waste of space because it duplicates {{private_sndStamp}}. - The telemetry topic names do not meet our current standards. |
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):
- Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): - copley_fault_status_register - 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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a "code" field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
| Description |
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):
- Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): - copley_fault_status_register - 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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a "code" field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
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):
- Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- copley_fault_status_register -- 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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a "code" field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
| Description |
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):
- Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- copley_fault_status_register -- 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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a "code" field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
| Description |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
| Description |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In This task will also clean up the Jira tickets: [ |
| Watchers | Russell Owen [ Russell Owen ] | Russell Owen, Te-Wei Tsai [ Russell Owen, Te-Wei Tsai ] |
| Watchers | Russell Owen, Te-Wei Tsai [ Russell Owen, Te-Wei Tsai ] | Rob Bovill, Russell Owen, Te-Wei Tsai [ Rob Bovill, Russell Owen, Te-Wei Tsai ] |
| Reviewers | Te-Wei Tsai [ ttsai ] |
| Description |
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}}. - Some telemetry is not output, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In This task will also clean up the Jira tickets: [ |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In This task will also clean up the Jira tickets: [ |
| Description |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - The deviceError event has a {{code}} field that is a string, and as implemented by the vendor that "code" describes just one error and the event is output once for each error condition that is present. In This task will also clean up the Jira tickets: [ |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: [ |
| Description |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: [ |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: (1) (2) |
| Watchers | Rob Bovill, Russell Owen, Te-Wei Tsai [ Rob Bovill, Russell Owen, Te-Wei Tsai ] | Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai [ Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai ] |
| Description |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: (1) (2) |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: (1) (2) |
| Epic Link |
|
| Sprint | TSSW Sprint - Dec 9 - Dec 20 [ 977 ] |
| Story Points | 4 |
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 22739 ] |
| Description |
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, including (these may be intentional but I would rather output them unless there is a good reason not to): -- {{copley_fault_status_register}} -- {{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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: (1) (2) |
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 - There is no detailed state event, even though that state is crucial for these CSCs. Fixed in - 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 This task will also clean up the Jira tickets: (1) (2) |
| Watchers | Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai [ Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai ] | Andrew Heyer, Bo Xin, Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai [ Andrew Heyer, Bo Xin, Michael Reuter, Rob Bovill, Russell Owen, Te-Wei Tsai ] |
| Remote Link | This issue links to "Page (Confluence)" [ 22740 ] |
| Status | In Progress [ 3 ] | In Review [ 10004 ] |
| Story Points | 4 | 3 |
| Sprint | TSSW Sprint - Dec 9 - Dec 20 [ 977 ] | TSSW Sprint - Dec 9 - Dec 20, TSSW Sprint - Dec 23 - Jan 3 [ 977, 978 ] |
| Sprint | TSSW Sprint - Dec 9 - Dec 20, TSSW Sprint - Dec 23 - Jan 3 [ 977, 978 ] | TSSW Sprint - Dec 9 - Dec 20, TSSW Sprint - Dec 23 - Jan 3, TSSW Sprint - Jan 06 - Jan 17 [ 977, 978, 992 ] |
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
| Status | Reviewed [ 10101 ] | In Review [ 10004 ] |
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
| Resolution | Done [ 10000 ] | |
| Status | Reviewed [ 10101 ] | Done [ 10002 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 26701 ] |
| Link | This issue relates to SUMMIT-5251 [ SUMMIT-5251 ] |
| Link | This issue relates to SUMMIT-5404 [ SUMMIT-5404 ] |
| Link | This issue relates to SUMMIT-5796 [ SUMMIT-5796 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 26701 ] |