Real-Time Execution in Connected IO Mode
Simulink® Desktop Real-Time™ Connected IO mode extends normal mode or accelerator mode to run in real time.
The simulation algorithm for a non-real-time normal mode or accelerator 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 operating system 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 Simulink Desktop Real-Time I/O blocks. In Connected IO mode, Simulink executes the simulation algorithm, while a separate operating system kernel mode process runs I/O drivers for the I/O blocks. Both the Simulink process and the 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
Scopeblocks 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.
You cannot run a Simulink Desktop Real-Time model in rapid accelerator mode.
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 Simulink Desktop Real-Time block does not change the step size of the simulation. For a fixed-step simulation, you set the step size in the Fixed step size box from the Configuration Parameters dialog box. For a variable-step simulation, you set the step size by using the Min Step Size attribute, or Simulink determines the step size automatically.
In Connected IO mode, at each sample interval Simulink evaluates each real-time block. Simulink writes the input data into a buffer that it passes to the 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 can 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. You can identify this situation by a rising straight line on a
Scopeconnected to the optional
Process Contention — The model generally executes faster than required to keep up with the kernel. However, 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. You can identify this situation by a sawtooth-like shape on a
Scopeconnected to the
Variable-Step Solver — If you are using a variable-step solver, the number of ticks per algorithm step can vary during simulation. If Simulink execution does not reach the Simulink Desktop Real-Time blocks in time to synchronize with the tick, the number of missed ticks jumps to some number. As Simulink catches up with the kernel, the number of missed ticks decreases to zero. As with process contention, you can identify this situation by a sawtooth-like shape on a
Scopeconnected to the