Upgrading from an Earlier Release :: Stateflow 6.0 and Stateflow Coder 6.0 Release Notes (Stateflow® and Stateflow® Coder Release Notes)

Stateflow® and Stateflow® Coder Release Notes

Upgrading from an Earlier Release

This section describes the upgrade issues involved in moving from previous versions of Stateflow to Version 6.0 (R14).

API Scripts Looking for Old Parameters Need to be Changed

In R14, you can pass variables from the MATLAB workspace that includes Simulink parameters for a masked subsystem to constant data for a Stateflow block in the containment hierarchy by assigning a scope of Parameter to the Stateflow data. In previous versions, this was accomplished with data scoped as Constant and initialized from the workspace.

As part of the upgrade to R14, Stateflow data in existing models defined with a scope of Constant and initialized from the workspace is automatically redefined with the new Parameter scope. This means that existing API scripts looking for Constant data initialized from the workspace must be changed to look for data with the scope Parameter as shown in the following example:

Before R14:

d0 = sfm.find('-isa','Stateflow.Data','-and', 
'Scope','CONSTANT_DATA','-and','InitFromWorkspace',1);

After R14:

d0 = 
sfm.find('-isa','Stateflow.Data','-and','Scope','Parameter');

Custom Code Settings Not Copied from Simulation to RTW Target

In prior versions of Stateflow, creating an RTW target copied custom code settings from the simulation target to the new RTW target. This is no longer true for nonlibrary models, which configure an RTW target in Simulink, not Stateflow. However, for library models you create an RTW target in Stateflow that still copies the custom code settings of the simulation target in Stateflow.

New Way to Bring Simulink Parameters Into Stateflow

In prior versions of Stateflow, the mechanism to bring Simulink parameters into Stateflow charts was to create data of type Constant and enable its Initialize From Workspace property. This initialized the constant with the value of a variable of the same name in the MATLAB workspace, in this case, a Simulink parameter. There were several limitations with these parameters:

The parameters could only be scalars.
The parameters were not tunable.
Stateflow's parameter name resolution did not honor Simulink's name resolution. Specifically, if a parameter could not be resolved in the immediate mask workspace containing the chart, an error was thrown instead of trying to resolve the parameter in the next parent's workspace.
Library charts that contained the parameters could not participate in code reuse.

All of the preceding limitations are now fixed. Furthermore, Stateflow data has a new Parameter scope that implements constant Simulink parameters. All old models that have constant data initialized from the workspace are now grandfathered to have the new Parameter scope.

Chart Parented Temporary Data is Obsolete

Chart parented data no longer has the option of being marked temporary. Instead, an optimization in Stateflow generated code converts chart parented local data acting as temporary data to temporary data.

No conversion needs to be made to old models; chart parented temporary data is automatically converted to local data.

Stateflow Supports Directional Vectors

In Stateflow 5.1.1 (R13SP1) and prior versions, data defined with the size of [1,3] was automatically converted to a nondirectional vector of size 3. In Stateflow 6.0 (R14), the directionality is preserved. The effect of this change is that, if this data happens to be chart input or output, a directional row vector is used to interface with Simulink. This data needs to be accessed as a two-dimensional matrix in Stateflow action language in state/transition labels, for example, as x[0][1].

Trailing 1's Removed After Second Dimension of Array Size

Sizes specified for the third dimension or higher of an array that result in a trailing set of 1's are removed by Stateflow. Here are some examples.

Size Specified by User
Size Specified by Stateflow

[2, 3, 1]
[2, 3]

[3, 5, 1, 1, 1]
[3, 5]

[3, 4, 1, 1, 2]
No change

[4, 1]
No change

Size Specified by User	Size Specified by Stateflow
`[2, 3, 1]`	`[2, 3]`
`[3, 5, 1, 1, 1]`	`[3, 5]`
`[3, 4, 1, 1, 2]`	No change
`[4, 1]`	No change

For size specifications like those shown in rows 1 and 2 of the preceding table, you must change array indexing in state and transition actions accordingly. For example, if you specify the size of the array my_array as [4, 5, 1, 1, 1], you can no longer specify the element my_array[2][3][0][0][0] in an action. Instead, specify the element as my_array[2][3].

Major Bug Fixes Known Software Limitations