The chat responses are generated using Generative AI technology for intuitive search and may not be entirely accurate. They are not intended as professional advice. For full details, including our use rights, privacy practices and potential export control restrictions, please refer to our Generative AI Service Terms of Use and Generative AI Service Privacy Information. As this is a test version, please let us know if something irritating comes up. Like you get recommended a chocolate fudge ice cream instead of an energy managing application. If that occurs, please use the feedback button in our contact form!
Skip to content

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.

Max String Size

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.

Max Vector Size

Shared Memory

As the RIB uses shared memory to access data through Industrial OS as well as the Software-PLC (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.

Max SHM Description

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:

SW-PLC typecode memory limit [MB]
S7-1505 SP (F)2
S7-1505 SP T (F)3
S7-1507 S (F)5
S7-1508 S (F)10
S7-1508 T (F)12.5

⚠️ 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.

Max RIB Clients

Number of Data Blocks

The SW-PLC supports in total up to 20 Cyclic Interrupt DataBlocks as of TIA Portal v19.
Additionally, the RIB supports only up to 16 Consumer / Provider DataBlocks.
As each topic in the YAML configuration defines one Cyclic Interrupt DB (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.

Max Data Blocks

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

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 ROSie 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 ROSie API code is based on the C++17 standard.
  • The ROSie 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.

ROS 2 data typeRIB data typeTIA data typeComment
boolRIB_BOOLBool
byteRIB_BYTEByte
charRIB_BYTEChar
float32RIB_FLOATReal
float64RIB_DOUBLELReal
int8RIB_INT8SInt
int16RIB_INT16Int
int32RIB_INT32DInt
int64RIB_INT64LInt
uint8RIB_UINT8USInt
uint16RIB_UINT16UInt
uint32RIB_UINT32UDInt
uint64RIB_UINT64ULInt
stringRIB_BYTE[254]StringThe maximum string length is currently capped at 254 characters
wstringunsupportedunsupportedWide strings are not supported yet

For arrays the conversion is:

For vectors the conversion is:

ROS 2 data typeRIB data typeTIA data typeComment
[10] [10] Array of [0..9]

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

ROS 2 data typeRIB data typeTIA data typeComment
[] [64] Array of [0..63] of Vectors will be converted to arrays of a fixed size (currently storing 64 elements)
RIB_UINT32UDIntAdditionally a i_valid_elements_* variable will be created for each ROS 2 vector on the RIB and TIA side to track the actual elements the ROS 2 vector contains / shall contain.