Control Function-Call Subsystems
For more control over when function-call subsystem execute, you can bind function-call
output events to specific states using bind actions. A function-call
subsystem is a subsystem that is active only when its parent state is active. You can create
this mode of opeation by binding the function-call output events by using bind actions. By
default, function-call subsystems activate when the chart initializes and remain active until
the chart becomes inactive. When you bind the function-call outputs, you can enable the
subsystem only when the parent state is active.
When you bind function-call subsystems, you can only broadcast the event through actions in that state or its child states.
Handle Outputs When the Subsystem Is Disabled
When you disable a function-call subsystem, that subsytem still provides output signals to other blocks in your Simulink® model. When you bind a function-call subsystem to a state, you can configure how these outputs behave when the subsystem is disabled by choosing to maintain their most recent values or to revert to their initial values. To configure this setting:
Double-click the Outport block of the subsystem to open the Block Parameters dialog box.

Select an option for Output when disabled.
Setting Action heldMaintain most recent output value resetReset output to its initial value Click OK.
The Output when disabled setting only affects function-call
subsystems that you bind to a state using a bind action.
Control Behavior of States When the Subsystem Is Active
When you bind a function-call subsystem to a state, you can control how the internal state variables behave when they activate. You can either maintain the values of the variables from when the subsystem was last active or reset them to their initial conditions each time the subsystem executes. To configure this setting:
Open the subsystem, then double-click the Trigger Port block to open the Block Parameters dialog box.

Select an option for States when enabling.
Setting Action heldMaintain the provious values of the subsystem that contains the trigger port resetRevert to the initial conditions of the subsystem that contains this trigger port inheritInherit this setting from the parent subsystem of the function-call initiator. If the parent of the initiator is the model root, the parameter uses the
heldoption. If the trigger has multiple initiators, the parents of all initiators must have the same setting for States when enabling.Click OK.
Bind Function-Call Subsystem to State
This model triggers a function-call subsystem with the trigger event E, which is bound to a state of a chart. The model uses a fixed-step solver with a fixed-step size of 1.

The chart contains two states. Event E binds to state A with the action
bind:E
Event E has a scope of Output to Simulink and a trigger type of function-call .

The function-call subsystem contains a Trigger Port block, an Input Port block, an Output Port block, and a simple block diagram. The block diagram increments a counter by 1 at each time step by using a Unit Delay block.

The Trigger Port block uses these settings:
Trigger type:
function-call.States when enabling:
reset. This setting resets the state values for the function-call subsystem to zero when it is active.Sample time type:
triggered. This setting sets the function-call subsystem to execute only when a calling event triggers the subsystem while the subsystem is enabled.
Setting Sample time type to periodic enables the Sample time parameter, which defaults to 1. This value executes the function-call subsystem for each time step while the subsystem 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 that coincides with the sampling rate in the Sample time parameter. States can send events with entry or during actions 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 the state controls the bound function-call subsystem, simulate the model.
At time
t = 0, the default transition to stateAoccurs. StateAexecutes its bind and entry actions. The binding action binds eventEto stateA, which enables the function-call subsystem and resets its state variables to 0. The entry action triggers the function-call subsystem and executes its block diagram. The block diagram increments a counter by 1 using the Unit Delay block. The Unit Delay block outputs a value of 0 and holds the new value of 1 until the next call to the subsystem.At time
t = 1, the next update event from the model tests stateAfor an outgoing transition. The transition to stateBdoes not occur because the temporal operatorafter(10,tick)allows the transition to be taken only after the state receives ten update events. StateAremains active and its during action triggers the function-call subsystem. The Unit Delay block outputs its held value of 1. The subsystem also increments its counter to 2, which the Unit Delay block holds until the next triggered execution.The next eight update events increment the subsystem output by one at each time step.
At time
t = 10, the transition from stateAto stateBoccurs. Because the binding to stateAis no longer active, the function-call subsystem is disabled, and its output returns to 0.At time
t = 11, the transition from stateBto stateAoccurs. The binding action enables the function-call subsystem. Subsequent update events increment the subsystem output by one at each time step until the next transition to stateBoccurs at time t = 21.

Avoid Binding Trigger Events with a Mux Block
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 block. For example, this model defines two function-call events to trigger a function-call subsystem using a Mux block.

In the chart, E1 binds to state A, but E2 does not. State B sends the triggering event E2 in its entry action.

When you simulate this model, the output does not reset when the transition from state A to state B occurs.

Binding is not recommended when you provide multiple trigger events to a function-call subsystem through a Mux block. Triggered events that use a Mux block can interfere with event binding and cause undefined behavior.