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 | ![]() |