| Contents | Index |
| On this page… |
|---|
States can have different action types, which include entry, during, exit, bind, and, on event_name actions. The actions for states are assigned to an action type using label notation with this general format:
name/ entry:entry actions during:during actions exit:exit actions bind:data_name, event_name on event_name:on event_name actions
For example, different state action types appear in the following chart.

After you enter the name in the state label, enter a carriage return and specify the actions for the state. The order you use to enter action types in the label does not matter.
Note If you do not specify the action type explicitly for a statement, the chart treats that statement as an entry action. |
This table summarizes the different state action types.
| State Action | Abbreviation | Description |
|---|---|---|
| entry | en | Executes when the state becomes active |
| exit | ex | Executes when the state is active and a transition out of the state occurs |
| during | du | Executes when the state is active and a specific event occurs |
| bind | none | Binds an event or data object so that only that state and its children can broadcast the event or change the data value |
| onevent_name | none | Executes when the state is active and it receives a broadcast of event_name |
| on after(n, event_name) | none | Executes when the state is active and after it receives n broadcasts of event_name |
| on before(n, event_name) | none | Executes when the state is active and before it receives n broadcasts of event_name |
| on at(n, event_name) | none | Executes when the state is active and it receives exactly n broadcasts of event_name |
| on every(n, event_name) | none | Executes when the state is active and upon receipt of every n broadcasts of event_name |
For a full description of entry, exit, during, bind, and on event_name actions, see the topics that follow. For more information about the after, before, at, and every temporal logic operators, see Using Temporal Logic in State Actions and Transitions.
Note In the preceding table, the temporal logic operators use the syntax of event-based temporal logic. For absolute-time temporal logic, the operators use a different syntax. For details, see Operators for Absolute-Time Temporal Logic. |
Entry actions are preceded by the prefix entry or en for short, followed by a required colon (:), followed by one or more actions. Separate multiple actions with a carriage return, semicolon (;), or a comma (,). If you enter the name and slash followed directly by actions, the actions are interpreted as entry action(s). This shorthand is useful if you are specifying entry actions only.
Entry actions for a state execute when the state is entered (becomes active). In the preceding example in State Action Types, the entry action id = x+y executes when the state A is entered by the default transition.
For a detailed description of the semantics of entering a state, see Steps for Entering a State and State Execution Example.
Exit actions are preceded by the prefix exit or ex for short, followed by a required colon (:), followed by one or more actions. Separate multiple actions with a carriage return, semicolon (;), or a comma (,).
Exit actions for a state execute when the state is active and a transition out of the state occurs.
For a detailed description of the semantics of exiting a state, see Steps for Exiting an Active State and State Execution Example.
During actions are preceded by the prefix during or du for short, followed by a required colon (:), followed by one or more actions. Separate multiple actions with a carriage return, semicolon (;), or a comma (,).
During actions for a state execute when the state is active and an event occurs and no valid transition to another state is available.
For a detailed description of the semantics of executing an active state, see Steps for Executing an Active State and State Execution Example.
Bind actions are preceded by the prefix bind, followed by a required colon (:), followed by one or more events or data. Separate multiple data/events with a carriage return, semicolon (;), or a comma (,).
Bind actions bind the specified data and events to a state. Data bound to a state can be changed by the actions of that state or its children. Other states and their children are free to read the bound data, but they cannot change it. Events bound to a state can be broadcast only by that state or its children. Other states and their children are free to listen for the bound event, but they cannot send it.
Bind actions apply to a Stateflow chart whether the binding state is active or not. In the preceding example in State Action Types, the bind action bind: id, time_out for state A binds the data id and the event time_out to state A. This binding prevents any other state (or its children) in the chart from changing id or broadcasting event time_out.
If another state includes actions that change data or broadcast events that bind to another state, a parsing error occurs. The following example shows a few of these error conditions:

| The following action... | Causes a parsing error because... |
|---|---|
| bind: id in state B | Only one state can change the data id, which binds to state A |
| entry: time_out in state C | Only one state can broadcast the event time_out, which binds to state A |
Binding a function-call event to a state also binds the function-call subsystem that it calls. In this case, the function-call subsystem is enabled when the binding state is entered and disabled when the binding state is exited. For more information about this behavior, see Using Bind Actions to Control Function-Call Subsystems.
On event_name actions are preceded by the prefix on, followed by a unique event, event_name, followed by one or more actions. Separate multiple actions with a carriage return, semicolon (;), or a comma (,). You can specify actions for more than one event by adding additional on event_name lines for different events. If you want different events to trigger different actions, enter multiple on event_name action statements in the state's label, each specifying the action for a particular event or set of events, for example:
on ev1: action1(); on ev2: action2();
On event_name actions execute when the state is active and the event event_name is received by the state. This action coincides with execution of during actions for the state.
For a detailed description of the semantics of executing an active state, see Steps for Executing an Active State.
In State Action Types, you see how you can attach actions to the label for a state. You can also attach actions to a transition on its label. Transitions can have different action types, which include event triggers, conditions, condition actions, and transition actions. The action types follow the label notation with this general format:
event_trigger[condition]{condition_action}/transition_action
The following example shows typical transition label syntax:

| Transition | Event Trigger | Condition | Condition Action | Transition Action |
|---|---|---|---|---|
| State A to state C | event1 | temp > 50 | func1() | None |
| State A to state B | event2 | None | None | data1 = 5 |
In transition label syntax, event triggers appear first as the name of an event. They have no distinguishing special character to separate them from other actions in a transition label. In the example in Transition Action Types, both transitions from state A have event triggers. The transition from state A to state B has the event trigger event2 and the transition from state A to state C has the event trigger event1.
Event triggers specify an event that causes the transition to be taken, provided the condition, if specified, is true. Specifying an event is optional. The absence of an event indicates that the transition is taken upon the occurrence of any event. Multiple events are specified using the OR logical operator (|).
In transition label syntax, conditions are Boolean expressions enclosed in square brackets ([]). In the example in Transition Action Types, the transition from state A to state C has the condition temp > 50.
A condition is a Boolean expression to specify that a transition occurs given that the specified expression is true. Follow these guidelines for defining and using conditions:
The condition expression must be a Boolean expression that evaluates to true (1) or false (0).
The condition expression can consist of any of the following:
Boolean operators that make comparisons between data and numeric values
A function that returns a Boolean value
An in(state_name) condition that evaluates to true when the state specified as the argument is active (see Checking State Activity)
Temporal logic conditions (see Using Temporal Logic in State Actions and Transitions)
The condition expression can call a graphical function, truth table function, or MATLAB function that returns a numeric value.
For example, [test_function(x, y) < 0] is a valid condition expression.
The condition expression should not call a function that causes the Stateflow chart to change state or modify any variables.
Boolean expressions can be grouped using & for expressions with AND relationships and | for expressions with OR relationships.
Assignment statements are not valid condition expressions.
Unary increment and decrement actions are not valid condition expressions.
In transition label syntax, condition actions follow the transition condition and are enclosed in curly braces ({}). In the example in Transition Action Types, the transition from state A to state C has the condition action func1(), a function call.
Condition actions are executed as soon as the condition is evaluated as true, but before the transition destination has been determined to be valid. If no condition is specified, an implied condition evaluates to true and the condition action is executed.
In transition label syntax, transition actions are preceded with a forward slash (/). In the example in Transition Action Types, the transition from state A to state B has the transition action data1 = 5.
Transition actions execute only after the complete transition path is taken. They execute after the transition destination has been determined to be valid, and the condition, if specified, is true. If the transition consists of multiple segments, the transition action executes only after the entire transition path to the final destination is determined to be valid.
The following chart shows how action language constructs interact during simulation:

When you simulate the model, you get the following results:

The following actions occur in the TransAction state:
| Time | What Happens in the TransAction State |
|---|---|
| 0.0 | State TA becomes active. |
| In TA, the entry action executes by setting the value of outVal to 0. | |
| 0.1 | The transition from TA to junction J1 occurs, because the path is unconditional. |
| Evaluation of the condition between J1 and J2 occurs, which returns true. | |
| The transition action does not execute, because the full transition path from J1 to TB is not complete. | |
| Evaluation of the condition between J2 and TB occurs, which returns false. Therefore, execution returns to J1. | |
| The transition from J1 to J3 occurs, because the path is unconditional. | |
| Evaluation of the condition between J3 and TB occurs, which returns false. Therefore, execution returns to TA. | |
| In TA, the during action executes by decrementing the value of outVal by 1. | |
| 0.2 – 1.0 | The execution pattern from t = 0.1 repeats for each time step. |
| 1.1 | The transition from TA to junction J1 occurs, because the path is unconditional. |
| Evaluation of the condition between J1 and J2 occurs, which returns true. | |
| The transition action does not execute, because the full transition path from J1 to TB is not complete. | |
| Evaluation of the condition between J2 and TB occurs, which returns false. Therefore, execution returns to J1. | |
| The transition from J1 to J3 occurs, because the path is unconditional. | |
| Evaluation of the condition between J3 and TB occurs, which returns true. | |
| State TB becomes active. | |
| Because the transition from J3 to TB is now complete, the transition action executes by setting the value of outVal to 0. |
The following actions occur in the CondAction state:
| Time | What Happens in the CondAction State |
|---|---|
| 0.0 | State CA becomes active. |
| In CA, the entry action executes by setting the value of outVal_2 to 0. | |
| 0.1 | The transition from CA to junction J1 occurs, because the path is unconditional. |
| Evaluation of the condition between J1 and J2 occurs, which returns true. | |
| The condition action executes by decrementing the value of outVal_2 by 2. | |
| Evaluation of the condition between J2 and CB occurs, which returns false. Therefore, execution returns to J1. | |
| The transition from J1 to J3 occurs, because the path is unconditional. | |
| Evaluation of the condition between J3 and CB occurs, which returns false. Therefore, execution returns to CA. | |
| In CA, the during action executes by decrementing the value of outVal_2 by 1. | |
| 0.2 – 0.3 | The execution pattern from t = 0.1 repeats for each time step. |
| 0.4 | The transition from CA to junction J1 occurs, because the path is unconditional. |
| Evaluation of the condition between J1 and J2 occurs, which returns true. | |
| The condition action executes by decrementing the value of outVal_2 by 2. | |
| Evaluation of the condition between J2 and CB occurs, which returns false. Therefore, execution returns to J1. | |
| The transition from J1 to J3 occurs, because the path is unconditional. | |
| Evaluation of the condition between J3 and CB occurs, which returns true. | |
| The condition action executes by setting the value of outVal_2 to 0. | |
| State CB becomes active. |
![]() | Using Actions in Stateflow Charts | Combining State Actions to Eliminate Redundant Code | ![]() |

Learn how engineers use Stateflow to model state machines in their Simulink models.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |