Difference between revisions of "OpenIGTLink/ProtocolV2/Type/Capability"
From NAMIC Wiki
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[OpenIGTLink/ProtocolV2/ | + | [[OpenIGTLink/ProtocolV2/Index | << Version 2 Index Page]] |
=Summary= | =Summary= | ||
| Line 48: | Line 48: | ||
==STP_CAPABIL== | ==STP_CAPABIL== | ||
| + | |||
| + | N/A | ||
| + | |||
| + | ==RTS_CAPABIL== | ||
N/A | N/A | ||
=Implementations= | =Implementations= | ||
| − | |||
| − | |||
| − | |||
=Contributors= | =Contributors= | ||
Latest revision as of 04:42, 30 November 2011
Home < OpenIGTLink < ProtocolV2 < Type < CapabilityContents
Summary
The CAPABILITY data type lists the names of message types that the receiver can interpret. Although the OpenIGTLink protocol guarantees that any receiver can at least skip messages with unknown type and continue to interpret the following messages, it is a good idea to get the capability information at system startup to ensure application-level compatibility of various devices. In a CAPABILITY message type, each message type name comes with format version number. If the receiver can interpret multiple versions for a certain message type, they should be listed as independent types.
Message Types
CAPABILITY
| Data | Type | Description |
| TYPE_0 | unsigned char [12] | Type name #0 |
| Type_1 | unsigned char [12] | Type name #1 |
| ... | ... | ... |
| Type_(N-1) | unsigned char [12] | Type name #N-1 |
Number of type names N is calculated by (Body size) / 12.
GET_CAPABIL
| Data | Type | Description |
STT_CAPABIL
N/A
STP_CAPABIL
N/A
RTS_CAPABIL
N/A
Implementations
Contributors
This message was originally proposed in version 1.
