Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Labels:
-
Story Points:1
-
Epic Link:
-
Sprint:TSSW Sprint - Jul 19 - Aug 02
-
Team:Telescope and Site
-
Urgent?:No
Description
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes).
If this also applies to the MTRotator then please consider filing a ticket for that.
In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one.
Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change.
Note. Rename the structure related to the parameter/config to have no word of telemetry, which is confusing. This change will affect the EUI as well.
Attachments
Issue Links
- is triggered by
-
- Done
-
- Done
- is triggering
-
- Done
-
- Done
- relates to
-
- Done
Activity
| Epic Link |
|
| Labels | hexapod |
| Description |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change. |
| Description |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change. |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. {color:#de350b}*Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change.*{color} |
| Link | This issue relates to SUMMIT-5251 [ SUMMIT-5251 ] |
| Description |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. {color:#de350b}*Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change.*{color} |
Please consider having the low-level MTHexapod controller send exactly the same telemetry and configuration packets to the CSC as it sends to the EUI/GUI, instead of having to maintain two separate structures that are so similar.
I have tested the CSC and it can keep up with 2x the data it is getting now at 20 Hz. That said, we have no need for 20 Hz so I suggest you offer the ability to cut the rate of telemetry to the CSC, e.g. by skipping every other telemetry packet (as long as that won't miss any important state changes). If this also applies to the MTRotator then please consider filing a ticket for that. In my opinion this is not high priority, but is a "nice to have" in that it should make the low-level controller code a bit easier to maintain and understand. It will require small changes to the CSC; one of us can file a separate ticket for that once you figure out if you have time and inclination to implement this one. {color:#de350b}*Note. For the configuration (or parameter) telemetry, it should be published only when there is the value change.*{color} {color:#de350b}*Note. Rename the structure related to the parameter/config to have no word of telemetry, which is confusing. This change will affect the EUI as well.*{color} |
| Link | This issue relates to SUMMIT-5404 [ SUMMIT-5404 ] |
| Link | This issue relates to SUMMIT-5404 [ SUMMIT-5404 ] |
| Link | This issue relates to SUMMIT-5404 [ SUMMIT-5404 ] |
| Sprint | TSSW Sprint - Jul 19 - Aug 02 [ 1108 ] | |
| Story Points | 1 |
| Story Points | 1 | 2 |
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
| Story Points | 2 | 1 |
Please help to review the PRs:
1. https://github.com/lsst-ts/ts_hexapod_controller/pull/21
2. https://github.com/lsst-ts/ts_hexapod_gui/pull/15
I do not test these PRs on summit yet because I believe I may need your help to update the CSC to test this ticket.
Thanks!
| Reviewers | Russell Owen [ rowen ] | |
| Status | In Progress [ 3 ] | In Review [ 10004 ] |
Reviewed on github
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
| Summary | Please consider having the hexapod send exactly the same telemetry and config data to the EUI and CSC | Please have the hexapod send exactly the same telemetry and config data to the EUI and CSC |
| Resolution | Done [ 10000 ] | |
| Status | Reviewed [ 10101 ] | Done [ 10002 ] |
| Link | This issue relates to SUMMIT-5796 [ SUMMIT-5796 ] |
DDS and GUI have the same telemetry now. Removed the unused telemetry structure. Renamed the telemetry of parameter structure.
Updated the GUI for the rename of telemetry. Removed the command frame.
Supported to configure the DDS telemetry rate.