@Cort, maybe. Messages vary in length from one type to the next, but each message of a given type is the same length. Fields contained within messages vary from one type to the next. There are over 100 different message types. We could create a class for each message type with attributes leveraging the bitfield capability of MC-3020. If, upon arrival, the byte stream containing a message could be plopped at the base of the extent for the appropriate class, we could avoid imperative bit-whacking, so long as the content of a message does not vary with anything other than the message type. I have vague memories of “if byte 5, bit 3 is active, then bytes 6-7 contain this, otherwise they contain that,” so I need to have a closer look at the protocol.
I have sketched (in my head) the specification-class side of a model that once populated would describe each message type. This approach might eliminate the need to define a class for each message type (instead each one would be defined as preexisting instance data) or leverage the aforementioned model compiler features, but I need to find time to extract said model from my head and try out what I have in mind. However, it’s likely that using PEI data to define message structure is less convenient/accessible than doing so with classes.