Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Labels:
-
Story Points:3
-
Epic Link:
-
Sprint:TSSW Sprint - Nov 22 - Dec 06, TSSW Sprint - Dec 06 - Dec 20, TSSW Sprint - Dec 20 - Jan 03
-
Team:Telescope and Site
-
Urgent?:No
Description
Acknowledge the SAL command from Hexapod PXI. This will let the CSC know the status of SAL command.
Note. This update will need the CSC to use the SyncPattern = 0x5555 instead of 0xB4B4 or 0x6666 to identify the command comes from the DDS instead of GUI. Only the DDS command will get the command acknowledgement.
Attachments
Issue Links
- is triggering
-
- Done
-
- Done
-
- Done
-
- Done
- relates to
-
- Done
-
- Done
Activity
Russell suggested the following in slack:
Since you are already modifying the command struct, please consider also adding a 7th float parameter field or a bool field. We won’t use it right now (and never for the rotator) but the hexapod could use it to support a move command that includes all 6 positions plus the synch flag. Maybe. Someday.
Please help to review the following PR:
https://github.com/lsst-ts/ts_hexapod_controller/pull/30
It is a combination of two PRs in rotator:
(a) https://github.com/lsst-ts/ts_rotator_controller/pull/29
(b) https://github.com/lsst-ts/ts_rotator_controller/pull/30
The main difference is the function: commanding_estDuration().
Thanks!
Reviewed on github. A very nice improvement.
This would be wonderful. It would make the CSC more reliable, since it would not have to guess.
In my experience there are two basic ways to handle this:
1) Asynchronous commands:
Slow commands, such as point to point moves, are not done until the move finishes, fails, or is aborted. In this model you need to support multiple commands running at the same time (e.g. so a user can stop a point-to-point move) and commands need a client-assigned identifier, such as an integer sequence number (private_seqNum in SAL) that is echoed in command status replies. I suggest the following command status replies:
This matches SAL pretty closely, but has no ACK, since I don't think we need it here. Any command should quickly receive one of these status replies.
2) Synchronous commands:
Make all commands run quickly, and only allow one command to run at a time.
In that model, slow commands such as point-to-point moves are reported as done when the command starts, and the client has to use other information to figure out when such commands finish. If you do that then I think you do not need the client to specify a command sequence number and you only need "succeeded", "failed" replies.