6. Working with RTI Connext Micro and RTI Connext DDS¶
In some cases, it may be necessary to write an application that is compiled against both RTI Connext Micro, RTI Connext Cert, and RTI Connext DDS. In general this is not easy to do because RTI Connext Micro and RTI Connext Cert supports a very limited set of features compared to RTI Connext DDS. However, while RTI Connext Cert is subset of RTI Connext Micro, it is relatively easy to write applications that support both.
Due to the nature of the DDS API and the philosophy of declaring behavior through QoS profiles instead of using different APIs, it may be possible to share common code. In particular, RTI Connext DDS supports configuration through QoS profile files, which eases the job of writing portable code.
Please refer to Introduction for an overview of features and what is supported by RTI Connext Micro. Note that RTI Connext DDS supports many extended APIs that are not covered by the DDS specification, for example APIs that create DDS entities based on QoS profiles.
6.1. Development Environment¶
There are no conflicts between RTI Connext Micro and RTI Connext DDS with respect to library names, header files, etc. It is advisable to keep the two installations separate, which is the normal case.
RTI Connext Micro uses the environment variable RTIMEHOME to locate the root of the RTI Connext Micro installation.
RTI Connext DDS uses the environment variable NDDSHOME to locate the root of the RTI Connext DDS installation.
6.2. Non-standard APIs¶
The DDS specification omits many APIs and policies necessary to configure a DDS application, such as transport, discovery, memory, logging, etc. In general, RTI Connext Micro and RTI Connext DDS do not share APIs for these functions.
It is recommended to configure RTI Connext DDS using QoS profiles as much as possible.
6.3. QoS Policies¶
QoS policies defined by the DDS standard behave the same between RTI Connext Micro and RTI Connext DDS. However, note that RTI Connext Micro does not always support all the values for a policy and in particular unlimited resources are not supported.
Unsupported QoS policies are the most likely reason for not being able to switch between RTI Connext Micro and RTI Connext DDS.
6.4. Standard APIs¶
APIs that are defined by the standard behave the same between RTI Connext Micro and RTI Connext DDS.
6.5. IDL Files¶
RTI Connext Micro and RTI Connext DDS use the same IDL compiler (rtiddsgen) and RTI Connext Micro typically ships with the latest version. However, RTI Connext Micro and RTI Connext DDS use different templates to generate code and it is not possible to share the generated code. Thus, while the same IDL can be used, the generated output must be saved in different locations.
6.6. Interoperability¶
In general, RTI Connext Micro and RTI Connext DDS are wire interoperable, unless noted otherwise.
All RTI products, aside from RTI Connext Micro, are based on RTI Connext DDS. Thus, in general RTI Connext Micro is compatible with RTI tools and other products. The following sections provide additional information for each product.
When trying to establish communication between an RTI Connext Micro application that uses the Dynamic Participant / Static Endpoint (DPSE) discovery module and an RTI product based on RTI Connext DDS, every participant in the DDS system must be configured with a unique participant name. While the static discovery functionality provided by RTI Connext DDS allows participants on different hosts to share the same name, RTI Connext Micro requires every participant to have a different name to help keep the complexity of its implementation suitable for smaller targets.
When interoperating with RTI Connext DDS, RTI Connext Micro must specify at least one unicast transport for each DataWriter and DataReader, either from DDS_DomainParticipantQos::transports or the endpoint DDS_DataReaderQos::transport and DDS_DataWriterQos::transport, as it expects to use the unicast transport’s RTPS port mapping to determine automatic participant IDs if needed. This also affects RTI Connext Micro itself, where participant IDs must be set manually if only multicast transports are enabled.
Also, when interoperating with RTI Connext DDS, only one multicast transport can be specified per DataReader of RTI Connext Micro.
6.7. Admin Console¶
Admin Console can discover and display RTI Connext Micro applications that use full dynamic discovery (DPDE). When using static discovery (DPSE), it is required to use the Limited Bandwidth Endpoint Discovery (LBED) that is available as a separate product for RTI Connext DDS. With the library a configuration file with the discovery configuration must be provided (just as in the case for products such as Routing Service, etc.). This is provided through the QoS XML file.
Data can be visualized from RTI Connext Micro DataWriters. Keep in mind that RTI Connext Micro
does not currently distribute type information and the type information has
to be provided through an XML file using the “Create Subscription” dialog.
Unlike some other products, this information cannot be provided through the
QoS XML file. To provide the data types to Admin Console, first run the code
generator with the -convertToXml option:
rtiddsgen -convertToXml <file>
Then click on the “Load Data Types from XML file” hyperlink in the “Create Subscription” dialog and add the generated IDL file.
Other Features Supported:
Match analysis is supported.
Discovery-based QoS are shown.
The following resource limits in RTI Connext Micro must be incremented as follows when using Admin Console:
Add 24 to DDS_DomainParticipantResourceLimitsQosPolicy::remote_reader_allocation
Add 24 to DDS_DomainParticipantResourceLimitsQosPolicy::remote_writer_allocation
Add 1 to DDS_DomainParticipantResourceLimitsQosPolic::remote_participant_allocation
Add 1 to DDS_DomainParticipantResourceLimitsQosPolicy::remote_participant_allocation if data-visualization is used
RTI Connext Micro does not currently support any administration capabilities or services, and does not match with the Admin Console DataReaders and DataWriters. However, if matching DataReaders and DataWriters are created, e.g., by the application, the following resource must be updated:
Add 48 to DDS_DomainParticipantResourceLimitsQosPolicy::matching_writer_reader_pair_allocation
6.8. Distributed Logger¶
This product is not supported by RTI Connext Micro.
6.9. LabVIEW¶
The LabVIEW toolkit uses RTI Connext DDS, and it must be configured as any other RTI Connext DDS application. A possible option is to use the builtin RTI Connext DDS profile: BuiltinQosLib::Generic.ConnextMicroCompatibility.
6.10. Monitor¶
This product is not supported by RTI Connext Micro.
6.11. Recording Service¶
6.11.1. RTI Recorder¶
RTI Recorder is compatible with RTI Connext Micro in the following ways:
If static endpoint discovery is used, Recorder is compatible starting with version 5.1.0.3 and onwards.
If dynamic endpoint discovery is used (not supported by Connext Cert), Recorder is compatible with RTI Connext Micro the same way it is with any other DDS application.
In both cases, type information has to be provided via XML. Read Recording Data with RTI Connext Micro for more information.
6.11.2. RTI Replay¶
RTI Replay is compatible with RTI Connext Micro in the following ways:
If static endpoint discovery is used, Replay is compatible starting with version 5.1.0.3 and onwards.
If dynamic endpoint discovery is used (not supported by Connext Cert), Replay is compatible with RTI Connext Micro the same way it is with any other DDS application.
In both cases, type information has to be provided via XML. Read Recording Data with RTI Connext Micro for more information on how to convert from IDL to XML.
6.11.3. RTI Converter¶
Databases recorded with RTI Connext Micro contains no type information in the DCPSPublication table, but the type information can be provided via XML. Read Recording Data with RTI Connext Micro for more information on how to convert from IDL to XML.
6.12. Spreadsheet Addin¶
RTI Connext Micro can be used with Spreadsheet Add-in starting with version 5.2.0. The type information must be loaded from XML files.
6.13. Wireshark¶
Wireshark fully supports RTI Connext Micro.
6.14. Persistence Service¶
RTI Connext Micro only supports VOLATILE and TRANSIENT_LOCAL durability and does not support the use of Persistence Service.