RT Blockset

Precedente Home Su Successiva

Link for RT blockset download: (version 1.1 of 21.03.2004)

Matlab 5.3+: RTv5.3 1.1.0.zip (37,0Kb) (22.11.2004)

Matlab 6.0: RTv6.0 1.1.0.zip (37,7Kb) (21.03.2004)

Matlab 6.5: RTv6.5 1.1.0.zip (27,3Kb) (21.03.2004)

Matlab 7.1: RTv7.1 1.1.0.zip (40.4Kb) (19.05.2007)

Matlab 7.1 & Visual C++ 2005: RTv7.1 1.3 (VC2005).zip (32Kb) (16.05.2008)

Matlab 7.11 & Visual C++ 2008: RTv8.0.zip (19Kb) (09.07.2012) - just executables

New! Matlab 7.5 notes: Rapid Accelerator Mode

Information

Introduction

The Real-Time Blockset is born in the context of my former study at university of Rome, when I was trying to run the Simulink models at the same speed of the real time processes. At that time, no Real-Time solution was available (like xPC or RTWT) and moreover, the solutions based on an external real-time card was too expensive.

The OS where this solution was first developed is Windows NT 4.0, then this blockset is based on the Win32 library timing functions and process control functions. The actual released blockset has been realized only for the Windows platform and has been tested on a Win2000 and WinME OS with different speed processors.

Updates

09.07.2008 - The blockset has ben recompiled for Matlab 64-bit;

22.02.2008 - The RT blockset has been update to remove a conflict with the default definition of Matlab (priority is a key name of the new releases of Matlab) and some troubles with the latest release of Visual C++ 2005. Thanks to Rob & Ellen Boyle from England.

19.05.2007 - The RT blockset is now available also for Matlab 7.1 (thanks for its request to María Jesús Lara González, from Madrid). Options for Build must contain C++ flag active, and options for linking must contain the references to RT.lib and winmm.lib, as specified later in this text. 

22.11.2004 - The RT blockset is now available also for Matlab 5.3 (thanks for its request to Tobias Obst, from Germany). Take care for the Make command options (see below) that are slightly different from 6.x versions.

21.03.2004 - Thanks to Norbert Hohenbichler (Aachen University, Germany), that signaled me the presence of a bug in the RTW compilation of the block, the bug has been removed. Now (it seems that) it works even for RTW. The 6.5 version of the blockset has been added. The "Make Command" on this page has been corrected (not timer.lib but rt.lib)

Matlab 7.5 notes: Rapid Accelerator Mode

Perform the following actions (Thanks to Jim Lasswell from USA for the question):

Select the menu item: Simulation-->Configuration Parameters...

In the dialog, select on the left tree Real-Time Workshop-->Custom Code

In the group Include list of Additional: select Libraries

Type in the Libraries textbox: ..\rt.lib ..\winmm.lib

Press the button OK and start the simulation.

That's all

The RT Blockset for Simulink: how does it work

The blockset is actually composed by only one block, that has been realized using an S-function written in C++ language. Respect to the other products, the RT blockset doesn't use a separate OS or runs a RT kernel to provide an RT simulation. This blockset is based on the simple concept that, to make the Simulink run with a real-time temporization, the cycle time (the time that Simulink needs to calculate a simulation step, that is function of the hardware and the OS in which Simulink is running) should be lower then the desired simulation step. If this assumption is not valid, no real-time simulation is possible, whichever is the applied scheduling method. 

Obviously, this statement is not completely valid, for example if we suppose to work with a real-time OS, in which the scheduling can be fully controlled. Anyway, the Windows OS is not in this case, because it's a multitasking environment with a partial controllable scheduling approach. The only controllable feature of Windows is the possibility of assigning a greater priority to the running process. In this blockset, a block allows the selection of the preferred priority to assign to Simulink. 

This blockset simply hold the execution of the Simulink simulation attached to the time flow, in the sense that, if the cycle time is lower then the simulation step, this block wait for the time needed to fill the simulation step, leaving the remaining CPU time to all the WIndows Process that need it. This concept is very simple but effective.

Another feature that may let you prefer this blockset respect to xPC and RTWT, is the lack of limitation that this block impose to the use of Win32 instruction in your C/C++ S-functions. xPC, for example, being running in a separated OS, doesn't allow the use of many features normally available on Windows, like the full file access, the control of particular control board, or even the installation of a number of serial port greater then four. RTWT, instead, running in a separated virtual machine, limits the use of the instructions in Simulink (i.e.: sockets, particular file access, and others, often needed, instructions).

This blockset may virtually cooperate with any Win32 or DirectX instruction. Personally, I tested the RTW version of this block even on WinNT Embedded, with interesting results. 

The RT blocks description

Initialization
Timer: Set the characteristics of a real-time simulation. The settings of the simulation are selectable using the block panel. The parameters are:
Timestep: in milliseconds, defines the temporization with which Simulink requires to the Operating System the availability of resources for the execution of the simulation step. The value should be fixed equal to the simulation step of Simulink (the timestep);
Priority: defines the class of task priority required, that can be one of the following values:
IDLE PRIORITY: Low priority, typical of an idle process (priority less than normal)
NORMAL PRIORITY: Typical priority of a typical windows application;
HIGH PRIORITY: Typical priority of a relevant application, that needs more resources of a normal application;
REAL-TIME PRIORITY: Exclusive priority of a unique process that needs all the resources of the operating system.
Thread Priority: defines the class of task priority required, that can be one of the following values:
IDLE : The thread should run when the main process is inactive.
LOWEST : The thread runs with a minimal respect of the temporization;
NORMAL : The thread runs with the same priority of the main process;
HIGH : The thread runs with the major priority respect to the main process;
REAL-TIME : The process runs when the simulation thread is in idle state.

The block has one output port: 

time: the time difference between the real time and the simulation time, in seconds, and the time that the RT block left to the other processes, in milliseconds.

Remarks:

The timestep time is only an indication. When the Operating System needs too much resources, it's impossible for Simulink to take control of the CPU: in this case, the real time needed from one step to a new one could be much greater than the simulation time.

The REAL-TIME priority should be used only in exceptional cases. When REAL-TIME priority is selected, the operating system can perform only few operations and the user may loose the control of the OS.

The HIGH priority, in many cases, is largely sufficient to control the great part of simulations in real-time, getting needed resources independently of the Windows User Interface, that is normally executed as a NORMAL PRIORITY process.  

The limitations of the RT blocks in a Simulink (non RTW) environment

The rule of the RT block is to keep the simulation attached to the real time. The major obstacle to this behaviour is the actions of the user during the simulation. Any window process, in fact, is constrained to manage windows messages, like the mouse messages. Matlab and Simulink are typical Windows application (contained in an unique process) and normally, they are blocked or delayed if an user send multiple messages (like the simple holding down of the mouse message).

Due to the fact that the RT block attempts to enhance the priority of the Simulink environment, the simulation is protected from the other processes but not from the Simulink itself. In few words, during the simulation , do not use or move the mouse over any  Simulink Window, that runs in the same thread as the simlation managed by the RT block.

For the purpose of understanding what can be cause of delay for your simulation, I want to remember that Matlab and Simulink runs the same process, while Simulink runs in a separated thread. Then, increasing the priority of the process, it will increase the priority of both Matlab and Simulink respect to the other processes; increasing the priority of the simulation thread, it will increase the priority of Simulink respect to Matlab and all the other applications.  

This problem will not affect the simulation compiled with the RT Workshop, when the RTW blockset will be available, because the simulation, in this case, runs in a separated process.

The enhancements resulting of a greater priority of a process and/or a thread is more evident under NT-like OS (WinNT and Win2000) respect to the 9x-like OS (Win98, WinME), due to the greater control of the processor offered by the NT' OSs.

RT blockset Application Example

An application example is the one contained in the installation pack of the blockset (RTex.mdl). In this simple example, the timer constraint the execution of the filter function over a pulse function. The simulation is performed with a fixed step, integration ode3, timestep 0.05 seconds, duration 10 seconds.

The RTex.mdl sample

The simulation has been executed during the execution of another CPU-time requiring process, a Visual Studio build of a project that requires 7-8 seconds of a normal priority task. The compilation is launched soon after the start of the simulation. Before starting the building, the mouse pointer has been moved over a toolbar icon of Simulink, just the time to wait that the tooltip is shown. This last simple operation is instead very heavy for an application, as is shown in the figure that follows. Due to the fact that the toolbar belongs to Simulink, that is in the same thread where the simulation runs, a sharp peak of CPU request results in the simulation.

The results are reported in the graphs that follows, using different priority for the RTBlock. The blu line represents the delay in the execution of the timestep (that should be near to zero, in this case 50 ms), while the green line represents the remaining time for which Simulink waits for the next step (and leave the CPU to the remaining Windows applications). The first delaying operation occurs at 2 secs, while the build starts at 4 secs and ends after the end of the simulation 8.7 secs. 

Normal Process Priority

Normal Thread Priority

High Process Priority

Time-Critical Thread Priority

Real-Time Process Priority

Time-Critical Thread Priority

Note the effect of the other windows application on the task. The effect is visible on the first simulation but invisible in the second and third simulation. Another effect that is due only to Simulink is the little delay present at the start of the simulation, due to the initialization of the graph window (that is erased and redrawed, operation that needs much processing time). This effect is not visible in the last simulation. The sharp peak at 2 seconds is always present in all the simulations because the change of priority is effective respect to others tasks but not respect to Simulink itself.

The RTW release of the RT blockset

Normal Process Priority

Normal Thread Priority

High Process Priority

Time-Critical Thread Priority

The preceding experience has been repeated launching the RTW version of the simulation, applying tha same disturbs. As you can see, the tooltip showed by Simulink has no effect in the simulation, while the simulation runs without any delay when the process and thread priority is greater respect to other windows tasks. 

How to use the RT block 

The RT block delays the simulation until the next time run occurs. Then, is better to put the Simulink block as the first block in your model (i.e., the first block added in the model), or using the output of the block to conditioning the execution of a subsystem in which your simulation block resides, as shown in the figure that follows. 

How to use the 
RT block

The input In1 of the subsystem that contains your simulation, is only added to let the subsystem depends on the RTBlock function.

How to build your model with Real Time Workshop

To make your stand-alone simulation with RTW, you have to add to the RTW make the following files:

RTBlock.c: The source of the RTblock, is compiled and linked automatically from RTW when an RTBlock is present in your model;
RT.lib: The core library that contains the functions needed for the synchronization;
winmm.lib: A library (from Microsoft) that contains functions for precise timing; 

These file must be copied in your current directory (the directory where are your model).

To compile and link successfully with RTW a project that contains a RT Block, you should set the following options:

Simulation parameters panel: Real Time Workshop Tab:
System Target File: grt.tlc
Template Makefile: grt_default_tmf (or grt_vc.tmf)
Make Command (for Matlab 6.x and Matlab 7.1): make_rtw S_FUNCTIONS_LIB="..\rt.lib ..\winmm.lib"
Make Command (for Matlab 5.3): make_rtw S_FUNCTIONS_LIB="rt.lib winmm.lib"
Language (only Matlab 7.1): use C++

To see an example of settings, open the rtex.mdl model.

Information and Warranty for the End User

I must remember to all the users of this blockset that this is a product not covered by any warranty about its working performances and characteristics, because it's completely free.  All the material and the manual has been realized by myself independently from any contractual constraint with any University or company, then the intellectual property is exclusive of the author (me). 

The present library is actually under development and more blocks will be added. The notice from the users of any problem will be appreciated and recorded and any collaboration will be mentioned in the final version of the blockset.

Installation of the RT blockset

At the start of this page, a link to the file RT.zip allows the download of the RT blockset library. The zip file has been memorized without any reference to an installation directory, then the directory will be selected from the end user at the installation time.

After the start of the Winzip (or equivalent) program, press the button "Extract" to extract all files in the desired directory. Preferably, select a folder (or create a new folder) insied the <MatlabDir>\work directory.

Installation Directory selection window

After the completion of the setup, add the path of the selected directory utilizing the menu item File-->Set Path...

Now the installation is complete. To open the RT Blockset library is sufficient to type in the Matlab command window the command "RT". A window containing all the available blocks will be displayed.

This page has been updated on day 10/07/12.

Leonardo Daga's Warehouseâ, http://leonardodaga.insyde.it
Send any Comments to: leonardo.daga@gmail.com