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 Framework

Page Content

Description

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

The Orchestra framework represents the part of the Orchestra communication directly connected to RT-LAB.

As a consequence, one “OrchestraFramework” I/O interface must be created for each domain in a given Orchestra system.

Configuration

This is the main page where it is possible to customize the “OrchestraFramework” 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: OrchestraFramework configuration panel

Logo

Name

Description

Value

Logo

Name

Description

Value

 

Configuration validator

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

None

 

Help

Opens this document page from the UI.

None

 

DDF Importer

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

None

 

DDF file path

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

String

 

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).

String

 

Sync client at first step

Activates the wait-to-go feature. See Wait-To-Go for more informations

If checked, the wait-to-go is performed automatically at the first step of the simulation.

Checked or Unchecked

 

Timeout for sync client (ms)

The time period - in milliseconds - allowed for synchronization between the clients and the framework.

This is used only if the 'Sync client at first step' option is checked.

Int

 

 

External executable

The path to an external executable on the target platform with its possible arguments.

This executable will be started during the load of the associated model.

String

 

Show external executable debug console

A checkbox to open the debug console for the external executable from the previous field.

It will open only if the 'External executable' field is filled in.

Checked or Unchecked

 

Force domain synchronization in polling mode

Switches the Orchestra data synchronization method from the use of semaphores to the use of flags.

Flags allow faster synchronization; however, they are more CPU-consuming.

Checked or Unchecked

 

Sample time (s)

Duration in seconds between two active cycles where the Orchestra framework will perform its data exchange.

This time period must be a multiple of the model’s timestep. It’s equivalent to the decimation factor.

Float

RT-LAB model

Blocks

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 OpInput and OpOutput .

OpInput

The OpInput 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 OrchestraFramework I/O interface, output signals correspond to any item of the subscribe part of the DDF or the 'status' signal.

OpOutput

The OpOutput 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 OrchestraFramework I/O interface, input signals correspond to any item of the publish part of the DDF or the 'WaitToGo' signal (if activated).

Example

To illustrate a bit more what a typical framework 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 framework 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.

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 Connections management .

OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | opal-rt.com | +1 514-935-2323
Follow OPAL-RT: LinkedIn | Facebook | YouTube | X/Twitter