Fix Version/s: None
Sprint:TSSW Sprint - Nov 08 - Nov 22, TSSW Sprint - Nov 22 - Dec 06
Team:Telescope and Site
Acknowledge the SAL command from Rotator PXI. This will let the CSC know the status of SAL command.
Note. It looks like I may need to use sync pattern to identify the command comes from the DDS or GUI. Only the CSC needs the command acknowledgement. In addition, in the future, the GUI specific code will be deprecated. There should be no difference between the GUI and CSC code at that time. In this case, I may need to update the GUI code to use another sync pattern value instead.
Note. I do need to change the GUI for sync pattern.
- is blocked by
DM-32472 Refactor the commanding.c in Rotator Low-Level Controller
- is triggering
DM-32693 Update MT hexapod and rotator CSCs to read command ack messages
DM-32727 Update the Rotator EUI to Read the Command Status
DM-32730 Reply the Command Status of State Transition of Rotator Controller
DM-33068 Test the New Version of Rotator Code on Summit
- relates to
DM-31232 Acknowledge the SAL Command from Hexapod PXI
The discussion of command status structure with Russell in slack:
I suggest considering what fields it needs. I think the ideal struct would have these fields:
1. The command ID assigned by the user (int)
2. The response code (int)
3. An estimated duration (for a long-running command that has started, e.g. a point-to-point move) (double or float)
4. A description of what went wrong, if a command is rejected or fails (presumably a fixed-length string).
You could probably get away without that last item, but it would truly make the replies much more useful.
As to estimated duration…I think a long time is better than nothing. Most commands are short enough that it doesn’t matter. But point-to-point moves do matter. If you can give a decent estimate it will be a big help — not only to the CSC but to users of the CSC.
The summarization of discussion with Russell:
Just to summarize what we talked about in the low-level controller:
- There is no support for acknowledging completion of long-running commands (point-to-point moves are the only example I can think of) because of the black box nature of the Simulink model.
- Each command will receive a final code of OK or NotOK. That will arrive very quickly after being sent.
- NotOK will include a reason. These could be quite terse, but if it’s not too much extra work it’d be really nice to have details. For example: “position=123.1 out of range [-90.0, 90.0]“, “velocity=45 > max=10”, “enabled substate=moving point to point instead of stationary”, “state=fault instead of enabled”. If that’s too much work than short messages such as “position out of bounds”, “enabled_substate not stationary” would be OK.
- If the low-level controller notices a missing command ID then it will report Missing. I consider this optional. If you implement it, please don’t be fooled when the ID wraps around.
- On a related note: please consider making the user-assigned command ID some form of unsigned int.
- For slow commands, such as point-to-point moves, the OK will include an estimate of how long the move will take. A double or float in seconds.
- The CSC will continue to receive enough information in the telemetry to determine if a point-to-point move succeeded (including an “in position” flag).
Please also consider reporting the ID of the most recent point to point move in the telemetry. That might help the CSC figure out a bit better if a command is done. In fact it actually allows the low-level controller to report that, but that complicates command reporting since we now need separate “started” and “finished” states for long-running commands.
Please help to review the PRs:
Please ignore the fail of Jenkins for GUI. That is the problem of Jenkins itself. I had emailed Diego in CTIO to fix it.
The current command c struct does have a "counter" field (the 2nd field) that is a unique identifier for each command. This is ideal for identifying the command when reporting command success or failure.
The minimum needed information is "command rejected" or "command done".
Other items that would be very helpful:
It is probably possible to add this information to the Telemetry struct, but please consider making a new struct (if that will not mess up the EUI) because the information really is not very "telemetry-like" and it only needs to be output when a command is accepted, rejected or done.
I will be delighted to make any necessary changes to the CSC.