I've been reviewing the Interprete and RawType tags in protocol definitions, and I see that best practices suggest using:
-
Interprete.RawType = other for strings
-
Interprete.RawType = numeric text for numbers
- For discreets = depends
This seems to cover all possible variable types for standalone parametersP, yet there are many RawType options available (e.g., bcd, signed number, unsigned number, text...). Given that DataMiner "will not" process a value if it doesn’t match the expected RawType, I assume these types serve a purpose beyond just categorization.
However, when I tried passing a string value to a parameter expecting a number, the parameter was set to 0 instead of being ignored. This suggests that DataMiner does process the value, but with some default handling for mismatches.
Could someone explain why these additional RawType values exist since even DIS snippets never contain some of them? Are there cases where best practices don't apply, or are these mainly for backward compatibility and specific protocol requirements?
Hi Tarik,
The additional RawType options, such as BCD, double, signed/unsigned number, and text, primarily exist to support serial connectors that communicate with devices using binary protocols.
Since data exchanged with the device is in binary form, these RawType definitions ensure the connector correctly interprets the received bytes. Without them, the system wouldn't be able to determine the intended meaning of the data.
For example, if a device sends the two-byte sequence 0x47F7, its interpretation depends on the specified RawType:
unsigned number: 63303
signed number: -2233
double: 8.87064e-41
other: "G÷"
The interpretation is also influenced by other options such as Length, Endian, ByteOffset, Bits...
If none of these options fit your use case, the best approach is to use RawType: Other with Type: String and handle the custom conversion in a QAction. You can retrieve the raw bytes using SLProtocol.GetData and process them as needed.