Difference between revisions of "OpenIGTLink/ProtocolV2/Type/Capability"

From NAMIC Wiki
Jump to: navigation, search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[OpenIGTLink/ProtocolV2/Proposals | << Version 2 Draft Page]]
+
[[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=
POSITION type is implemented in the following files:
 
*[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlStatusMessage.h igtlStatusMessage.h]
 
*[http://svn.na-mic.org/NAMICSandBox/trunk/OpenIGTLink/Source/igtlStatusMessage.cxx igtlStatusMessage.cxx]
 
  
 
=Contributors=
 
=Contributors=

Latest revision as of 04:42, 30 November 2011

Home < OpenIGTLink < ProtocolV2 < Type < Capability

<< Version 2 Index Page

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.

Comments