Considerations for Integrating Models from MathWorks Simulink® Software
- Updated2025-10-15
- 4 minute(s) read
Considerations for Integrating Models from MathWorks Simulink® Software
The Model Interface API identifies inports, outports, parameters, and signals in models you created and compiled in MathWorks Simulink® application software according to their configuration in the Simulink software. Case Study: Simple Models
Consider the following model from the Simulink software environment.
When you load this model in an application, the Model Interface API categorizes its components as described in the following table.
| Component in model | Type of component in LabVIEW |
|---|---|
| Raw_Sine | Signal |
| Sine_Gain | Parameter |
| In1 | Inport |
| Out1 | Outport |
Inports and Outports
Parameters
Compiled models contain one of two types of parameters: global parameters or block parameters:
- A global parameter, similar to a workspace variable in MathWorks MATLAB® software, applies to any model in the application that contains a parameter with the same name. Even if you open a parameter interface to update parameters for a specific model, the Model Interface API applies updates to all models that contain the same global parameter. If you specify to inline parameters in the Simulink software, MathWorks Real-Time Workshop® software converts MATLAB workspace variables to global parameters in the compiled model. You can identify global parameters as those whose paths are in the form of Model Name/Parameter Name.
- Block parameters are not global and apply only to the specific model to which they belong. If you do not specify to inline parameters in the Real-Time Workshop software, block parameters remain block parameters in the compiled model. You can identify block parameters as those whose paths are in the form of Model Name/Block Name/Parameter Name.
A Simulink model can contain only one type of parameter. However, an application can contain a model with global parameters and a model with block parameters.
Conditions Where Parameters Are Unavailable
The Model Interface API supports model references to submodels, but you cannot access parameters or signals in submodels. In other words, submodels execute in an application built with the Model Interface API, but their parameters and signals are not available for writing or reading.
In the Simulink software, you can inline parameters, but the Model Interface API cannot access inlined parameters to get or set their values. If you inline a parameter, you still can allow the Model Interface API to influence the parameter by configuring a variable that affects the parameter to be tuneable. For example, consider a model with the following characteristics:
- Contains a constant configured with the expression x + 3.
- Contains a sine wave block whose amplitude and frequency parameters are inlined, and therefore unavailable in the Model Interface API.
- Adds the result of the x + 3 constant to the output from the sine wave block.
Although the parameters of the sine wave block are unavailable, you can influence the operation by specifying that the x variable is tunable in the Simulink software. When x is tunable, it will appear in the list of parameters the model contains, so you can change the value of x like a parameter as the model executes.
SignalsModel signals are usually excluded when you convert a model into a compiled model unless you define a signal as a test point in the software you use to compile the model.
Conditions Where Signals Are Unavailable
The Model Interface API supports model references to submodels, but you cannot access parameters or signals in submodels. In other words, submodels execute in an application built with the Model Interface API, but their parameters and signals are not available for writing or reading.
Certain optimizations you enable in the Simulink software can make a signal unavailable to the Model Interface API. You can disable these options for the entire model to make all signals available for probing, but the memory footprint of the model increases as a result. Alternatively, you can mark individual signals as test points in the Simulink software to maintain a reduced memory footprint while keeping the test-point signals available for probing.
Bus Objects
In models compiled in the Simulink R2010b software or a later supported version, named components of bus objects, such as signals, are represented in the same hierarchy as in the uncompiled model. For models compiled in versions of the Simulink software earlier than R2010b, bus objects are represented as a single vector of components.