4.11. Example Generation

The RTI Code Generator available with Connext Micro can generate DDS example applications with a type definition file as input.

Note that before running rtiddsgen, you might need to add <Connext Micro install folder>/rtiddsgen/scripts to your path environment variable folder.

To generate an example:

rtiddsgen -example -language <C|C++> [-namespace] <file with type definition>

This command generates an example using the default example template, which uses the Dynamic Participant Dynamic Endpoint (DPDE) discovery plugin.

rtiddsgen accepts the following options:

• -example: Generates type files, example files, and CMakelists files.

• -language <C|C++>: Generates C or C++ code.

• -namespace: Enables C++ namespaces when the language option is C++.

The generated example can be compiled using CMake <https://cmake.org/>_ and the CMakelists.txt file generated by the RTI Code Generator. A README.txt file is also generated with a description of the example and instructions for how to compile and run the examples.

The RTI Code Generator can also generate examples using custom templates by using the option -exampleTemplate <templateName>.

To generate an example using a custom template instead of the default one:

rtiddsgen -example -exampleTemplate <template name> -language <C|C++> [-namespace] <file with type definition>

To see the list of the available templates, use the following command:

rtiddsgen -showTemplates

The output from the command will look similar to this:

List of example templates per language:
    - C:
        - cert
        - dpse
        - mag/dpde
        - mag/dpse
        - mag/shared_memory
        - mag/static_udp
        - secure
        - shared_memory
        - static_udp
        - waitsets
    - C++:
        - dpse
        - mag/dpde
        - secure
        - waitsets
    - C++ Namespace:
        - dpse
        - waitsets

The following command will generate an example in the C language, using the ‘waitsets’ custom template instead of the default template:

rtiddsgen -example -exampleTemplate waitsets -language C <file with type definition>

4.11.1. Description of Examples

All examples consist of a publication and subscription pair to send and receive the type provided by user. Two applications are compiled: one to send samples and another to receive samples.

• Default template

  Discovery of endpoints is done with the dynamic-endpoint discovery. Only the UDP and INTRA transports are enabled. The subscriber application creates a DataReader, which uses a listener to receive notifications about new samples and matched publishers. These notifications are received in the middleware thread (instead of the application thread).

• cert

  An example that only uses APIs that are compatible with Connext Cert.

• dpse

  The only difference from the default template is that the discovery of endpoints is done with static-endpoint discovery. Static-endpoint discovery uses function calls to statically assert information about remote endpoints belonging to remote DomainParticipants.

• secure

  The only difference from the default template is that this example uses secure communication.

• shared_memory

  The only difference from the default template is that the only transport used is shared memory. Because the UDP transport is disabled and only the shared memory transport is enabled, both the publisher and subscriber applications need to run in the same OS.

• static_udp

  The only difference from the default template is that this example uses a static UDP interface configuration. Using this API, the UDP transport is statically configured. This is useful in systems that are not able to return the installed UDP interfaces (name, IP address, mask…).

• waitsets

  The only difference from the default template is that the Subscriber application creates a DataReader that uses a Waitset (instead of a listener) to receive notifications about new samples and matched publishers. These notifications are received in the middleware thread (instead of the application thread).

• mag

  All the example templates whose names start with ‘mag’ use the Micro Application Generator (MAG) to create the DDS entities. This means that the DDS entities and their configuration are generated from an XML file, instead of by calling DDS APIs in the application.

• mag/dpde

  The same as the default template, but DDS entities are created by using MAG instead of by calling by calling DDS APIs in the application.

• mag/dpse

  The same as the ‘dpse’ template, but DDS entities are created by using MAG instead of by calling DDS APIs in the application.

• mag/shared_memory

  The same as the ‘shared_memory’ template, but DDS entities are created by using MAG instead of by calling DDS APIs in the application.

• mag/static_udp

  The same as the ‘static_udp’ template, but DDS entities are created by using MAG instead of by calling DDS APIs in the application.

4.11.2. How to Compile the Generated Examples

Before compiling, set the environment variable RTIMEHOME to the Connext Micro installation directory.

Depending on the number of network interfaces installed on the local machine, you might need to restrict which interfaces are used by Connext Micro.

For a ‘mag’ example, you can find the setting in the file ‘<File name used to generate example>Qos.xml’ in the XML element <allow_interfaces_list>. For other (non-‘mag’) examples, use the option -udp_interface <interface name> when running the example.

The Connext Micro source bundle includes rtime-make (on Linux and macOS systems) or rtime-make.bat (on Windows systems) to simplify invocation of CMake. This script is a convenient way to invoke CMake with the correct options. For example:

Linux

macOS

Windows

cd <directory with generated example>

rtime-make --config <Debug|Release> --build --target x64Linux4gcc7.3.0 --source-dir . \
     -G "Unix Makefiles" --delete [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true] \
     [-DRTIME_MAG_FILES=<XML file>] [-DRTIME_LINK_SHMEM_LIBS=true]

cd <directory with generated example>

rtime-make --config <Debug|Release> --build --target x64Darwin20clang12.0 --source-dir . \
     -G "Unix Makefiles" --delete [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true] \
     [-DRTIME_MAG_FILES=<XML file>] [-DRTIME_LINK_SHMEM_LIBS=true]

cd <directory with generated example>

rtime-make.bat --config <Debug|Release> --build --target x64Win64VS2017 --source-dir . \
     -G "Visual Studio 15 2017" --delete [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE_eq_true] \
     [-DRTIME_MAG_FILES_eq_<XML file>] [-DRTIME_LINK_SHMEM_LIBS_eq_true]

Warning

RTI recommends using the same toolchain file to compile generated examples as was used to compile Connext Micro (as described in Building Connext Micro and Building the Source for Common Platforms).

For example, if Connext Micro was compiled with --target x64Linux4gcc7.3.0, then the example applications should also be compiled with --target x64Linux4gcc7.3.0. Failing to do so may cause warnings.

The executable can be found in the directory ‘objs’.

It is also possible to compile using CMake, e.g., when the Connext Micro source bundle is not installed.

Linux

macOS

Windows

cmake [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true] [-DRTIME_MAG_FILES=<XML file>] [-DRTIME_LINK_SHMEM_LIBS=true] \
      [-DCMAKE_BUILD_TYPE=<Debug|Release>] -G "Unix Makefiles" -B./<your build directory> -H. -DRTIME_TARGET_NAME=x64Linux4gcc7.3.0

cmake --build ./<your build directory> [--config <Debug|Release>]

cmake [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true] [-DRTIME_MAG_FILES=<XML file>] [-DRTIME_LINK_SHMEM_LIBS=true] \
      [-DCMAKE_BUILD_TYPE=<Debug|Release>] -G "Unix Makefiles" -B./<your build directory> -H. -DRTIME_TARGET_NAME=x64Darwin20clang12.0

cmake --build ./<your build directory> [--config <Debug|Release>]

cmake [-DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true] [-DRTIME_MAG_FILES=<XML file>] [-DRTIME_LINK_SHMEM_LIBS=true] \
      [-DCMAKE_BUILD_TYPE=<Debug|Release>] -G "Visual Studio 15 2017" -B./<your build directory> -H. -DRTIME_TARGET_NAME=x64Win64VS2017

cmake --build .\<your build directory> [--config <Debug|Release>]

The executable can be found in the directory ‘objs’.

The following options are accepted:

• -DRTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE=true adds a rule to regenerate type support plugin source files if the input file with the type definition changes. Default value is ‘false’.

• -DRTIME_MAG_FILES=<XML file with Application Generation definitions> adds a rule to generate application support files from XML.

• -DRTIME_LINK_SHMEM_LIBS=true adds a dependency to the shared memory transport libraries. This option shall be used only with the shared memory example. The default value is ‘false’.

4.11.3. How to Run the Generated Examples

By default, the example uses all available interfaces to receive samples. This can cause communication problems if the number of available interfaces is greater than the maximum number of interfaces supported by Connext Micro. For this reason, it is recommended to restrict the number of interfaces used by the application.

For a ‘mag’ example, you can find the setting in the file <File name used to generate example>Qos.xml in the XML element <allow_interfaces_list>. For other (non-‘mag’) examples, use the option -udp_interface <interface name> when running the example.

For example, if the example has been compiled for Linux i86Linux2.6gcc4.4.5, run the subscriber with this command:

objs/x64Linux3gcc4.8.2/<Type definition file name>_subscriber [-domain <Domain_ID>] [-peer <address>] \
             [-sleep <sleep_time>] [-count <seconds_to_run>] [-udp_intf <interface name>]

and run the publisher with this command:

objs/x64Linux3gcc4.8.2/<Type definition file name>_publisher [-domain <Domain_ID> -peer <address>] \
             [-sleep <sleep_time>] [-count <seconds_to_run>] [-udp_intf <interface name>]

Note that shared memory examples only accept the following options: [-domain <Domain_ID>], [-sleep <sleep_time>] and [-count <seconds_to_run>].

MAG examples only accept the following options: [-sleep <sleep_time>] and [-count <seconds_to_run>].