Limitations¶

String Size¶

The RIB only supports fixed size arrays of bytes to store string like texts.
Therefore, ROS 2 message types that contain strings e.g. string frame_id in std_msgs/msg/Header will translate those strings to a fixed size byte array with the size of 254 bytes (as shown in the picture below).
⚠️ As the byte array will be available as a string on the PLC side, it is also converted on the PLC side. The PLC based string data type defines the maximum string length of 254 bytes.

Vector Size¶

As the RIB does not provide dynamic SHM allocation during runtime, all ROS 2 based vector types are currently limited to a fixed size of 64 elements.
⚠️ Additionally, a valid elements counter variable will be added to the PLC side, so that the user can define, how many valid elements are stored in the vector, if the number is smaller than 64.

Shared Memory¶

As the RIB uses shared memory to access data through Industrial OS as well as the Software Controller (SW-PLC),
The actual size of the used shared memory area is therefore limited and has to be conform to the memory limit of the SW-PLC.

An example usage is shown in the picture above, where the two ROS 2 message types geometry_msgs/msg/Twist and sensor_msgs/msg/BatteryState are used to provide data to the PLC (ros2_to_plc) via shared memory.

Those two definitions are combined to one shared memory area during runtime, that shall not exceed the actual SW-PLC memory limitations:

⚠️ Note: As those limitations are defining the total PLC code memory limit, the used ROS 2 .msg typse that needs to be transfered to the PLC or vice versa should not be too big regarding memory layout.

Number of RIB Clients¶

The RIB and its participant manager RIB_App supports up to 128 client applications.
But as the generated ROS 2 package uses a precompiled RIB API library, currently only one ROS 2 client connection is possible, combined with one SW-PLC based connection.

Number of Data Blocks / Symbols¶

The SW-PLC supports in total up to 20 Cyclic Interrupt Organization Blocks (OBs).
As each topic in the YAML configuration defines one Cyclic Interrupt OB (ROS 2 -> PLC and vice versa), the user needs to make sure that the provided YAML defines less than 20 topics in total or up to 16 topics for each side (ROS 2 -> PLC and vice versa) as shown in the picture below.

⚠️ The user has to keep in mind that the defined topics and therefore Cyclic Interrupt OBs will be added to already existing ones.

Additionally, the RIB provides the following maximum specifications:

Comments¶

ROS 2 .msg files may contain comments using the # character.
ROXSIE carries these comments over into the generated SCL code, if they follow one of the two supported syntaxes:

Inline comment: A # directly after a variable definition on the same line, followed by the comment text:

float32 voltage          # Voltage in Volts (Mandatory)

Continuation comment: A line consisting only of leading whitespace followed by #, continuing the comment of the variable + comment defined on the previous line:

float32[] cell_voltage   # An array of individual cell voltages for each cell in the pack
                         # If individual voltages unknown but number of cells known set each to NaN

Both styles are demonstrated in the ROS 2 standard interface package: sensor_msgs/msg/BatteryState.msg.

⚠️ Comments that do not follow either of the above formats — for example, standalone comment blocks not attached to a variable, or continuation lines missing the required leading whitespace — will not be included in the generated SCL code.

Constants¶

ROS 2 .msg files support the definition of typed constants by assigning a fixed value to a named identifier using the = sign.
ROXSIE recognizes these constant definitions and generates corresponding constant declarations in the generated SCL code.

A ROS constant follows the syntax <type> <NAME> = <value>, optionally followed by an inline comment:

uint8 POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0 # Unknown battery technology
uint8 POWER_SUPPLY_TECHNOLOGY_NIMH = 1    # Nickel-Metal Hydride battery

By convention, constant names are written in UPPER_SNAKE_CASE to distinguish them from regular variable definitions.
Inline comments on constant lines are carried over into the generated SCL code using the same rules as described in the Comments section above.

Full examples of constant definitions can be found in the ROS 2 standard interface package: sensor_msgs/msg/BatteryState.msg.

⚠️ Constants are read-only values and will not be mapped to any RIB shared memory — they are purely informational declarations available on the PLC side.

Topic Rates¶

At this stage, the RIB connections provided in the YAML config should not exceed a specified rate of 1000 Hz.
⚠️ The jitter for a defined rate highly depends on the complexity of the provided data type. For example, a geometry_msgs/msg/Twist is able to reach a stable rate of 1 kHz, but a more complex data type such as trajectory_msgs/msg/MultiDOFJointTrajectory with its vector of strings and nested structs will cause a loss of data at this rate or exceeding the PLC cycle time causing the PLC to stop!
⚠️ The usage of strings and/or vectors and/or nested structs of them should be avoided at higher frequencies (>100 Hz) as their conversion is time consuming!

Generated ROS 2 Package¶

The generated C++ based ROS 2 package has the following properties:

• The generated ROXSIE API C++ code is not thread safe (as the RIB connection does not provide thread safe shared memory access).
• The global RIB cycle time for ROS 2 values written to the RIB will be set to the highest of all topic frequencies defined in the provided YAML config file.
• The ROXSIE API code is based on the C++17 standard.
• The ROXSIE generated ROS 2 code is only tested with Humble and Jazzy.
• The ROS 2 data type wstring is currently not supported, but all other primitive ROS 2 types.

Type Conversions¶

The following table shows the available standard data types and their corresponding data types in ROS 2, RIB and TIA.

For arrays the conversion is:

For vectors the conversion is:

⚠️ Transferring ROS 2 vectors with more elements than the maximum size (current default is 64) will lead to data loss.