| Creating and Manipulating Models | ![]() |
Precedence and Property Inheritance
You can apply operations to LTI models of different types. The resulting type is then determined by the rules discussed in Precedence Rules. For example, if sys1 is a transfer function and sys2 is a state-space model, then the result of their addition
is a state-space model, since state-space models have precedence over transfer function models.
To supersede the precedence rules and force the result of an operation to be a given type, for example, a transfer function (TF), you can either
Suppose, in the above example, you want to compute the transfer function of sys. You can either use a priori conversion of the second operand
or a posteriori conversion of the result
| Note These alternatives are not equivalent numerically; computations are carried out on transfer functions in the first case, and on state-space models in the second case. |
Another issue is property inheritance, that is, how the operand property values are passed on to the result of the operation. While inheritance is partly operation-dependent, some general rules are summarized below:
sys.Ts = -1) sample times. Models resulting from such operations inherit the specified sample time, if there is one.
Notes and Userdata properties.
sys1 and sys2 are combined using operations such as +, *, [,], [;], append, and feedback, the resulting model inherits its I/O names and I/O groups from sys1 and sys2. However, conflicting I/O names or I/O groups are not inherited. For example, the InputName property for sys1 + sys2 is left unspecified if sys1 and sys2 have different InputName property values.
Variable property value from the operands. Conflicts are resolved according the following rules:
| Overview | Extracting and Modifying Subsystems | ![]() |
© 1994-2005 The MathWorks, Inc.