Documentation

Real-Time Execution in Normal Mode

Real-Time Windows Target™ extends Simulink® normal mode to run in real time.

The simulation algorithm for a Simulink normal mode model runs entirely within Simulink. The model can use either a fixed-step or a variable-step solver and runs as fast as it can, given the presence of competing Windows® processes. However, it is not synchronized with a real-time clock and cannot easily be used to operate real-time hardware.

You can synchronize a Simulink model with a real-time clock using Real-Time Windows Target I/O blocks. In real-time normal mode, Simulink executes the simulation algorithm, while a separate Windows kernel mode process runs I/O drivers for the I/O blocks. Both the Simulink process and the Windows kernel mode process run on the host machine, using a shared memory interface to transfer parameter data.

  • Signal acquisition — You can capture and display signals from your real-time application while it is running. Simulink retrieves signal data from the I/O driver and displays it in the same Scope blocks you used for simulating your model in nonreal time.

  • Parameter tuning — You can change parameters in your Simulink block diagram and have the new parameters take effect in your Simulink model in real time. The effects then propagate through the I/O driver to the hardware.

Because only the I/O drivers are synchronized with the real-time clock, Simulink can use either a fixed-step or a variable-step solver. The Sample Time setting in the Real-Time Windows Target block does not change the step size of the simulation. For a fixed-step simulation, the step size is set in the Fixed step size box from the Configuration Parameters dialog box. For a variable-step simulation, the step size is determined automatically by Simulink or by the Min Step Size attribute.

In real-time normal mode, at each sample interval Simulink evaluates each real-time block and writes the input data into a buffer it passes to the Windows kernel mode process. The kernel mode process propagates the data to the hardware, which writes response data into another buffer. At the next time tick, Simulink reads the response data and propagates it to the rest of the model.

A consequence of this kind of limited synchronization is that your simulation can be configured to miss real-time clock ticks and their associated data points. Ticks can be missed under the following circumstances:

  • Complexity of Model — The model might be so complex that Simulink cannot keep up with the real-time kernel. In this case, the number of missed ticks increases steadily with time. Once the number of missed ticks exceeds Maximum Missed Ticks, an error occurs, even if Maximum Missed Ticks is set to a large value. This situation is marked by a rising straight line on a Scope connected to the optional Missed Ticks port.

  • Process Contention — The model generally executes faster than required to keep up with the kernel, but process contention or some random operating system condition prevents Simulink from executing the model over some time period. In this case, the number of missed ticks jumps to some number, then decreases to zero as Simulink catches up with the kernel. This situation is marked by a sawtooth-like shape on a Scope connected to the Missed Ticks port.

  • Variable-Step Solver — If you are using a variable-step solver, the number of ticks per algorithm step may vary during simulation. If Simulink execution does not reach the Real-Time Sync or I/O blocks in time to synchronize with the tick, the number of missed ticks jumps to some number, then decreases to zero as Simulink catches up with the kernel. As with process contention, this situation is marked by a sawtooth-like shape on a Scope connected to the Missed Ticks port.

Was this topic helpful?