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:

• started: the command has been accepted and started, but will take awhile to finish. Please include a predicted duration, preferably as a float/double in seconds.
• rejected: the command was unacceptable for some reason. Please include a string explaining the reason.
• succeeded: the command finished successfully.
• failed: the command failed after being acknowledged as started. Please include a string explaining why it failed.
• superseded: the command was superseded by another command. An example is starting a point-to-point move and then aborting it with a stop command.

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.

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.