Bind actions in a state bind specified data and events to that state. Events bound to a state can be broadcast only by the actions in that state or its children. You can also bind a function-call event to a state to enable or disable the function-call subsystem that the event triggers. The function-call subsystem enables when the state with the bound event is entered and disables when that state is exited. Execution of the function-call subsystem is fully bound to the activity of the state that calls it.
By default, a function-call subsystem is controlled by the chart in which the associated function call output event is defined. This association means that the function-call subsystem is enabled when the chart wakes up and remains active until the chart goes to sleep. To achieve a finer level of control, you can bind a function-call subsystem to a state within the chart hierarchy by using a bind action (see Bind Actions).
Bind actions can bind function-call output events to a state. When you create this type of binding, the function-call subsystem that is called by the event is also bound to the state. In this situation, the function-call subsystem is enabled when the state is entered and disabled when the state is exited.
When you bind a function-call subsystem to a state, you can fine-tune the behavior of the subsystem when it is enabled and disabled, as described in the following sections:
Although function-call subsystems do not execute while disabled, their output signals are available to other blocks in the model. If a function-call subsystem is bound to a state, you can hold its outputs at their values from the previous time step or reset the outputs to their initial values when the subsystem is disabled. Follow these steps:
Double-click the outport block of the subsystem to open the Block Parameters dialog box.
Select an option for Output when disabled:
|Maintain most recent output value|
|Reset output to its initial value|
Click OK to record the settings.
Setting Output when disabled is meaningful only when the function-call subsystem is bound to a state, as described in Bind a Function-Call Subsystem to a State.
If a function-call subsystem is bound to a state, you can hold the subsystem state variables at their values from the previous time step or reset the state variables to their initial conditions when the subsystem executes. In this way, the binding state gains full control of state variables for the function-call subsystem. Follow these steps:
Double-click the trigger port of the subsystem to open the Block Parameters dialog box.
Select an option for States when enabling:
|Maintain most recent values of the states of the subsystem that contains the trigger port|
|Revert to the initial conditions of the states of the subsystem that contains this trigger port|
Inherit this setting from the function-call initiator's
parent subsystem. If the parent of the initiator is the model root,
the inherited setting is held. If the trigger has multiple initiators,
the parents of all initiators must have the same setting: either all
Click OK to record the settings.
Setting States when enabling is meaningful only when the function-call subsystem is bound to a state, as described in Bind a Function-Call Subsystem to a State.
The following model triggers
a function-call subsystem with a trigger event
binds to state
A of a chart:
This model specifies a fixed-step solver with a fixed-step size of 1 in the Solver pane of the Model Configuration Parameters dialog box.
The chart contains two states,
and connecting transitions, along with some actions:
E binds to state A with the action
E is defined for the chart with a scope of
to Simulink and a trigger type of
The function-call subsystem contains a trigger port block, an input port, an output port, and a simple block diagram. The block diagram increments a counter by 1 at each time step, using a Unit Delay block:
The Block Parameters dialog box for the trigger port appears as follows.
The States when enabling parameter uses
reset. This setting resets
the state values for the function-call subsystem to zero when it is
The Sample time type parameter uses the
triggered. This setting sets the
function-call subsystem to execute only when it is triggered by a
calling event while it is enabled.
Setting Sample time type to
the Sample time field below it, which defaults
to 1. These settings force the function-call subsystem to execute
for each time step specified in the Sample time field
while it is enabled. To accomplish this, the state that binds the
calling event for the function-call subsystem must send an event for
the time step coinciding with the specified sampling rate in the Sample
time field. States can send events with
at the simulation sample rate.
For fixed-step sampling, the Sample time value must be an integer multiple of the fixed-step size.
For variable-step sampling, the Sample time value has no limitations.
To see how a state controls a bound function-call subsystem, begin simulating the model in Model That Binds a Function-Call Subsystem to a State. The following steps describe the output of the subsystem.
In the chart, the default transition
A becomes active, it
executes its bind and entry actions. The binding action,
E to state
action enables the function-call subsystem and resets its state variables
A also executes its entry action,
which sends an event
E to trigger the function-call
subsystem and execute its block diagram. The block diagram increments
a count by 1 each time using a Unit Delay block. Because the previous
content of the Unit Delay block is 0 after the reset, the initial
output is 0 and the current value of 1 is held for the next call to
The next update event from the model
A for an outgoing transition.
The temporal operation on the transition to state
tick), allows the transition to be taken only after ten
update events are received. For the second update, the during action
which sends an event to trigger the function-call subsystem. The held
content of the Unit Delay block, 1, outputs to the scope.
The subsystem also adds 1 to the held value to produce the value 2, which the Unit Delay block holds for the next triggered execution.
The next eight update events increment the subsystem output by 1 at each time step.
On the 11th update
event, the transition to state
B occurs and state
Because the binding to state
no longer active, the function-call subsystem is disabled, and its
output drops to 0.
When the next sampling
event occurs, the transition from state
B to state
the binding action,
bind: E, enables the function-call
subsystem and resets its output to 0.
The next 10 update events produce the following output.
The example in Behavior of a Bound Function-Call Subsystem shows how binding events gives control of a function-call subsystem to a single state in a chart. This control does not work when you allow other events to trigger the function-call subsystem through a mux. For example, the following model defines two function-call events to trigger a function-call subsystem using a Mux block:
In the chart,
E2 does not.
B sends the triggering event
its entry action:
When you simulate this model, you get the following output:
E2 in state
the output, which no longer resets.
Binding is not recommended when you provide multiple trigger events to a function-call subsystem through a mux. Muxed trigger events can interfere with event binding and cause undefined behavior.