| Simulink® Release Notes | |
Context-Sensitive Data Typing of Tunable Parameters
In this release, if a model's Inline parameters setting is selected, Simulink regards the data type of a tunable parameter as context-sensitive if the data type is not specified. In particular, this release allows the block that uses the parameter to determine the parameter's data type. By contrast, Release 13 regards the type of the parameter to be double regardless of where it is used.
Change in Simulink Behavior
This change affects the behavior of Simulink in two cases. First, in Release 13, if a tunable parameter's data type is unspecified and a block that uses it needs to convert its type from double to another type, Simulink by default stops and displays an error message when you update or simulate the model. The error alerts the user to the fact that the type conversion is a downcast and hence could result in a loss of precision. In this release, by contrast, a typecast never occurs because the block itself determines the appropriate type for the parameter. Hence, in this release, Simulink never generates a downcast error for tunable parameters of unspecified data type.
The following model illustrates the difference in behavior between this release and Release 13 in this case.
Assume that the model's Inline parameters setting is selected (thereby making parameters nontunable by default) and the model declares k as a tunable parameter on the Model Configuration Parameters dialog box. Also assume that the user has specified the value of k on the MATLAB command line as follows:
In other words, the user has specified a value for k but not a data type. In this case, this release regards the type of k to be int16, the type required by the Gain block to compute its output. By contrast, Release 13 regards the type of k to be double and hence assumes that the Gain block must downcast k to compute its output. Release 13 therefore stops and displays an error message by default in this case when you update or simulate the model.
The behavior of this release also differs from Release 13 in the case where a model uses a tunable parameter of unspecified data type in more than one place in the model and the required data type differs in different places. This case creates a conflict under the assumption that the block in which the parameter is used determines the parameter's data type. This assumption requires Simulink to assign different data types to the same parameter, which is impossible. Therefore, in this release, Simulink signals an error to alert the user to the conflict. By contrast, in Release 13, Simulink does not throw an error because the data type of the parameter is double regardless of where it is used. You can avoid the conflicting data types error in Release 13SP1 by specifying the tunable parameter's data type.
The following model illustrates this change in behavior.
The two Gain blocks in this model both use k, a tunable parameter of unspecified type, as their gain parameter. Computing the outputs of the blocks requires that the gain parameter be of types int16 and int32, respectively. In Release 13, Simulink regards the data type of k to be double and the Gain blocks use typecasts to convert k to the required type in each case. Simulink simulates the model without error (if the parameter downcasting diagnostic is set to none or warning). By contrast, this release signals an error because this model requires k to be both type int16 and int32, an impossibility. You can avoid this error by explicitly specifying k's data type; for example:
| | Simulink 5.1 Release Notes | Conditional Execution Behavior | |
© 1994-2005 The MathWorks, Inc.
