The new version of this well-known real-time simulation software environment is more robust than the previous ones and attempts to repair known issues and to enhance the user experience.
A major new release of any software usually demands some adaptation from users and this document intends to summarize specific changes related to software operation, in order to facilitate migrating from RT-LAB 10 to RT-LAB 11.
RT-LAB comes with further detailed documentation, such as an Installation Guide, User Guide, C API, and Python API references.
RT-LAB no longer requires administrator privileges to be used, it can be operated by any user. This scenario is much more consistent with most institutional and academic environments.
Administrator privileges are required only in particular situations, such as the first launch of RT-LAB, MATLAB auto-repair operation and model compilation after changing the current MATLAB version.
In RT-LAB 10 versions, the MetaController had to be manually launched and closed.
The behavior of this important component has been reviewed in RT-LAB 11: from now on, launching/closing RT-LAB will automatically launch/close the MetaController.
MATLAB auto-repair operation
The management of MATLAB versions has been improved in this version of RT-LAB. Previously, installing MATLAB after having installed RT-LAB could lead to some unpleasant issues.
Now, these products can be safely installed in any order; every time RT-LAB launches a MATLAB instance, it verifies whether the required files already exist in the appropriate folder. If these files are not there, RT-LAB creates them (this requires administrator privileges).
Full support of 64-bit versions of MATLAB
Even though it was possible to use 64-bit versions of MATLAB in previous versions of RT-LAB, there were very important limitations. For example, it was not possible to use a Simulink console (SC subsystem) in order to interact with the real-time simulation. Since RT-LAB 11.1.4, 64-bit versions of MATLAB are fully supported.
Runtime and development licenses
RT-LAB targets accept two types of licenses for model compilation permissions:
Runtime license: use of all RT-LAB features, except model compilation. This license is for users who only need to run their models on the target.
Development license: all build steps on the target, including model compilation.
If you wish to compile a model, but your target has a runtime license, the build process will display the following message.
If this is your case, please request a development license.
Relocation of files
The following files have been moved from their previous folders to more intuitive locations:
Controller.log used to be a single logfile common to all projects, stored in the folder %RTLAB_ROOT%/common/bin/.
From now on, each project has its own separate file, stored in its folder.
The size of such file is limited to 10MB (editable in Hardware.config); RT-LAB will automatically create another file if the current one exceeds the maximum size.
Hardware.config, MetaController.state and other files have been moved from %RTLAB_ROOT%/common/bin to %ProgramData%/OPAL-RT/RT-LAB/%VERSION%/.
Files for asynchronous processes and S-Functions
For models containing asynchronous processes and/or S-Functions, RT-LAB automatically detects the required files for such components and adds them to the list of extra files. In order to repair known issues related to the mixture of asynchronous processes and S-Functions files, the “Files Properties” page of the model editor has been reviewed, allowing the user to choose the category of extra files.
The category is automatically detected by RT-LAB but can be changed by the user. If an extra file is not automatically added to this list, the user can also perform this operation manually. Please refer to the User Guide for further information.
Makefile for asynchronous processes
Improving the way asynchronous processes are managed by RT-LAB has required the use of additional libraries when compiling the user code. For that reason, existing custom makefiles used by asynchronous processes must be updated as shown below.
If you are closing RT-LAB and intend to use a version older than 11.x at a later time, you will have to exit the software by selecting File > Exit and reconfigure for 10.x.
This procedure is necessary because some properties of older versions are not compatible with this new version and they must be reconfigured so that the operating system can launch an older version of RT-LAB.
On the other hand, upgrading from older versions to RT-LAB 11.x is an automatic process that does not require any special procedure.
In order to improve the stability and the upcoming features of the software, the following products are no longer compatible with RT-LAB 11:
Microsoft ended support of Windows XP in April 2014. As a result, RT-LAB 11 compatibility with Windows starts from Windows Vista,
Support for QNX as a target OS will end with RT-LAB 11. Please contact OPAL-RT technical support to see how you can migrate to Red Hat Enterprise Linux,
It is always recommended to create a new workspace when migrating from previous major versions (11.3.x / 11.2.x / 11.1.x / 11.0.x / 10.7.x / 10.6.x / …).
To import the projects you have worked on in previous versions of RT-LAB, there are two options:
Import the project through
File > Import > RT-LAB > Existing RT-LAB Project
Create an empty project and import the models through
File > Import > RT-LAB > Existing RT-LAB Model
If the user loads an RT-LAB workspace from a previous major version, some components may present error messages and/or the Project Explorer may be duplicated.
This problem may happen if the user opens perspectives or components (views or editors) from RT-LAB 11.1 that do not exist in older versions. Fixing this problem is quite simple: the user should simply close the incompatible views and editors, close all perspectives and then reopen them.
Modification of network interfaces
The handling of network interfaces has been significantly improved, allowing users to operate RT-LAB on machines with multiple network interfaces, a configuration that was not supported in previous versions. There are, however, some known issues that may occur in very particular situations, for example, RT-LAB must be closed and all models must be stopped before any modification in network configuration (e.g. if Wi-Fi is activated while using RT-LAB).
Multiple subsystems and Dolphin connections
Pausing and resuming a model with multiple subsystems per core and Dolphin connections will make RT-LAB stop working properly.
The following procedure will cause a crash of RT-LAB:
(1) load a model with real-time communication link set to Dolphin (proper hardware required);
Even if such a problem has never been reported by users, it has been detected during internal tests.
OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | opal-rt.com | +1 514-935-2323