Documentation Home Page RT-LAB Home Page
Pour la documentation en FRANÇAIS, utilisez l'outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.

Orchestra Client

Page Content


This document describes the I/O interface “OrchestraClient”.

The Orchestra client represents the part of the Orchestra communication directly connected to the internal / external model.

As a consequence, an “OrchestraClient” I/O interface should be created only when an RT-LAB model is expected to be directly associated with it in a given Orchestra system.


This is the main page where it is possible to customize the “OrchestraClient” I/O Interface.

It can be accessed from the target I/O interface in two ways:

  • Double-clicking on it

  • Right-clicking on it and selecting the “open” option

Then, the following setting panel will open:

FIG 1: OrchestraClient configuration panel









Configuration validator

Checks the validity of the general configuration of the selected I/O Interface.



Opens this document page from the UI.


DDF Importer

Opens the file explorer and allows to import the target DDF.



DDF file path

The path to the DDF file. Can be set up manually by modifying the field directly, or by using the DDF Importer.



Domain name

The name of the domain, defined in the DDF file, which will be used by the “OrchestraFramework” I/O interface and the “OrchestraClient” I/O interface to exchange data (Shared memory).



Client performs wait to go during start()

Defines if the wait-to-go feature is loaded during the load of the model, or during the start.

For RT-LAB, it must ALWAYS be checked if the wait to go function is used.

Checked or Unchecked


Flag polling delays (us)

Internal delay in microseconds between two consecutive attempts to lock the publish or subscribe memory space in each Orchestra data exchange.

This is only used if the field 'Force domain synchronization in polling mode' is checked in the corresponding


RT-LAB model


I/O interfaces allow defining datapoints that are handled outside the models themselves. In order to bring the data going through those datapoints inside the models, we need to use two specific blocs called and .


The block gives the ability to create an input connection within the model. Thus, it may be connected to any output signal coming from any associated I/O interface.

In the case of the OrchestraClient I/O interface, output signals correspond to any item of the publish part of the DDF or the 'status' signal.


The block gives the ability to create an output connection within the model. Thus, it may be connected to any input signal coming out of any associated I/O interface.

In the case of the OrchestraClient I/O interface, input signals correspond to any item of the subscribe part of the DDF.


To illustrate a bit more what a typical client model would look like, here is a simple example.

Let’s consider two models running separately and exchanging exactly one signal in both directions.

  • The first model is the framework model: it will simply send back the exact same data it received

  • The second model is the client model: it will send an incremented version of the received data

In such system, the client subscribes one signal and publishes one signal. The corresponding RT-LAB model would then simply look like what can be seen in figure FIG 4.

Remember that the DDF describes the Orchestra items in the point of view of the framework. So, the item called 'publish_item' in FIG 3 is actually subscribed by the corresponding client.

Performing the connections between the model datapoints delivered by the OpInputs/OpOutputs and the datapoints from the I/O interfaces is explained in the following page .


OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | | +1 514-935-2323