Rewrite the logic to assign the DDS telemetry data. This task will check the data to DDS is useful or not, and might add new field if needed. In addition, the DDS telemetry data should come from the GUI data directly.

Some comment from Russell Owen in the slack channel to debug DM-30550:

Te-Wei Tsai and I were talking. I suggested that the first step is for Te-Wei Tsai to print one or both of strutEncoderRaw and strutEncoder_microns (to stdout, a log, or a file – whatever is easy) from the dds telemetry packet when he publishes that packet. This will tell us if the problem is in the low-level controller or in the CSC. Also the code that sets these fields is suspicious and he will probably change it. But first I think it is important to prove whether the problem is actually in the low-level controller or in the CSC.

A longer-term improvement we have tentatively agreed on is to make the telemetry sent to the CSC identical to the telemetry sent to the EUI. That way if we see a problem in one, we expect to see it in the other as well. Unfortunately the amount of data sent to the EUI is likely too much — it may overwhelm the python in the CSC. So a variant of that suggestion is to divide the telemetry into two pieces: one has all the “important” information that is sent to the CSC and the EUI. The other piece has additional information that is only sent to the EUI.
This would be a big improvement over the present situation: the telemetry packet for the CSC is computed entirely separately from the telemetry packet sent to the EUI. A bug in one will not show up in the other.