Complete implementation of APT messages for MPC320

[auspicacious]

The APT protocol documentation contains the full list of messages that can be used with the MPC320 polarization controller.

We have also listed these messages here in UnimplementedAptMessageId.

Acceptance criteria

• All messages implemented in protocol.py
• Unit tests written for all messages, following the existing pattern
• Comments added for anything that is unusual or hard to understand from the official APT documentation

[auspicacious]

@master-of-ppap After https://github.com/moonshot-nagayama-pj/PnPQ/pull/55 is merged, I think that this is a good place for you to start.

[master-of-ppap]

For the first acceptance criteria, should we try to implement the actual functionality of the messages? Or would something simple like the DISCONNECT class be fine for now?

@dataclass(frozen=True, kw_only=True)
class AptMessage_MGMSG_HW_DISCONNECT(AptMessageHeaderOnlyNoParams):
    message_id = AptMessageId.MGMSG_HW_DISCONNECT

[auspicacious]

@master-of-ppap If I understand your question correctly, the question is whether we need to understand the content of the messages when we write these classes.

The answer is yes. The reason we are implementing these classes is to make communication with the devices more legible.

Also, not all of the messages are simple 6-byte messages.

For example, for MGMSG_MOT_GET_POSCOUNTER has an additional 6-byte data packet. We have to build a custom class to understand this message.

My suggestion is to start with a simple message, implement it, and open a PR. Don't try to do all of the message types all at once, and ask questions early if you can't find answers by looking at the Python documentation.