| 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" on page 2-5. 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:
'p' has precedence over 's'.
'z^-1' has precedence over 'q' and 'z', while 'q' has precedence over 'z'.
| Operations on LTI Models | Extracting and Modifying Subsystems | ![]() |