Parameters

About Parameters

This section discusses how the Simulink Coder product generates parameter storage declarations, and how you can generate the storage declarations you need to interface block parameters to your code. For information about defining block parameters in Simulink models, see Working with Block Parameters.

If you are using S-functions in your model and intend to tune their run-time parameters in the generated code, see Tuning Run-Time Parameters in the Simulink documentation. Note that

• Parameters must be numeric, logical, or character arrays.

• Parameters may not be sparse.

• Parameter arrays must not be greater than 2 dimensions.

For guidance on implementing a parameter tuning interface using a C API, see Data Interchange Using the C API.

Simulink external mode offers a way to monitor signals and modify parameter values while generated model code executes. However, external mode might not be the optimal solution for your application. For example, the S-function target does not support external mode. For other targets, you might want your existing code to access parameters and signals of a model directly, rather than using the external mode communications mechanism. For information on external mode, see Host/Target Communication .

Back to Top

Nontunable Parameter Storage

By default, block parameters are not tunable in the generated code. When Inline Parameters is off (the default), the Simulink Coder product has control of parameter storage declarations and the symbolic naming of parameters in the generated code.

Nontunable parameters are stored as fields within model_P (formerly rtP), a model-specific global parameter data structure. The Simulink Coder product initializes each field of model_P to the value of the corresponding block parameter at code generation time.

When the Inline parameters option is on, block parameters are evaluated at code generation time, and their values appear as constants in the generated code, if possible (in certain circumstances, parameters cannot be inlined, and are then included in a constant parameter or model parameter structure.)

As an example of nontunable parameter storage, consider the following model.

The workspace variable Kp sets the gain of the Gain block.

Assume that Kp is nontunable and has a value of 5.0. The next table shows the variable declarations and the code generated for Kp in the noninlined and inlined cases.

The generated code does not preserve the symbolic name Kp. The noninlined code represents the gain of the Gain block as model_P.Gain_Gain. When Kp is noninlined, the parameter is tunable.

struct Parameters_non_tunable_sin { real_T SineWave_Amp;
		real_T SineWave_Bias;
  			real_T SineWave_Freq;
  			real_T SineWave_Phase;
  			real_T Gain_Gain;
			};
			.
			.
			.
			Parameters_non_tunable_sin non_tunable_sin_P = {
  			1.0 , /* SineWave_Amp : '<Root>/Sine Wave' */
  			0.0 , /* SineWave_Bias : '<Root>/Sine Wave' */
  			1.0 , /* SineWave_Freq : '<Root>/Sine Wave' */
  			0.0 , /* SineWave_Phase : '<Root>/Sine Wave' */
  			5.0   /* Gain_Gain : '<Root>/Gain' */
			};
			.
			.
			.
			non_tunable_sin_Y.Out1 = rtb_u * 
			non_tunable_sin_P.Gain_Gain;

non_tunable_sin_Y.Out1 = rtb_u * 5.0;

Back to Top

Tunable Parameter Storage

A tunable parameter is a block parameter whose value can be changed at run-time. A tunable parameter is inherently noninlined. Consequently, when Inlined parameters is off, all parameters are members of model_P, and thus are tunable. A tunable expression is an expression that contains one or more tunable parameters.

When you declare a parameter tunable, you control whether or not the parameter is stored within model_P. You also control the symbolic name of the parameter in the generated code.

When you declare a parameter tunable, you specify

• The storage class of the parameter.

  The storage class property of a parameter specifies how the Simulink Coder product declares the parameter in generated code.

  The term "storage class," as used in the Simulink Coder product, is not synonymous with the term storage class specifier, as used in the C language.

• A storage type qualifier, such as const or volatile. This is simply a string that is included in the variable declaration.

• (Implicitly) the symbolic name of the variable or field in which the parameter is stored. The Simulink Coder product derives variable and field names from the names of tunable parameters.

The Simulink Coder product generates a variable or struct storage declaration for each tunable parameter. Your choice of storage class controls whether the parameter is declared as a member of model_P or as a separate global variable.

You can use the generated storage declaration to make the variable visible to external legacy code. You can also make variables declared in your code visible to the generated code. You are responsible for linking your code to generated code modules.

You can use tunable parameters or expressions in your root model and in masked or unmasked subsystems, subject to certain restrictions. (See Tunable Expressions.)

Override Inlined Parameters for Tuning

When the Inline parameters option is selected, you can use the Model Parameter Configuration dialog box to remove individual parameters from inlining and declare them to be tunable. This allows you to improve overall efficiency by inlining most parameters, while at the same time retaining the flexibility of run-time tuning for selected parameters. Another way you can achieve the same result is by using Simulink data objects; see Parameters for specific details.

The mechanics of declaring tunable parameters are discussed in Declare Tunable Parameters.

Back to Top

Tunable Parameter Storage Classes

The Simulink Coder product defines four storage classes for tunable parameters. You must declare a tunable parameter to have one of the following storage classes:

• SimulinkGlobal (Auto): This is the default storage class. The Simulink Coder product stores the parameter as a member of model_P. Each member of model_P is initialized to the value of the corresponding workspace variable at code generation time.

• ExportedGlobal: The generated code instantiates and initializes the parameter and model.h exports it as a global variable. An exported global variable is independent of the model_P data structure. Each exported global variable is initialized to the value of the corresponding workspace variable at code generation time.

• ImportedExtern: model_private.h declares the parameter as an extern variable. Your code must supply the variable definition and initializer.

• ImportedExternPointer: model_private.h declares the variable as an extern pointer. Your code must supply the pointer variable definition and initializer, if any.

The generated code for model.h includes model_private.h to make the extern declarations available to subsystem files.

As an example of how the storage class declaration affects the code generated for a parameter, consider the next figure.

The workspace variable Kp sets the gain of the Gain block. Assume that the value of Kp is 3.14. The following table shows the variable declarations and the code generated for the gain block when Kp is declared as a tunable parameter. An example is shown for each storage class.

Note   The Simulink Coder product uses column-major ordering for two-dimensional signal and parameter data. When interfacing your hand-written code to such signals or parameters by using ExportedGlobal, ImportedExtern, or ImportedExternPointer declarations, make sure that your code observes this ordering convention.

The symbolic name Kp is preserved in the variable and field names in the generated code.

typedef struct _Parameters_tunable_sin 
Parameters_tunable_sin;

struct _Parameters_tunable_sin {
  real_T Kp;
};

Parameters_tunable_sin tunable_sin_P = {
  3.14
};
.
.
tunable_sin_Y.Out1 = rtb_u * 
tunable_sin_P.Kp;

real_T Kp = 3.14; 
.
.
tunable_sin_Y.Out1 = rtb_u * Kp;

extern real_T Kp;
.
.
tunable_sin_Y.Out1 = rtb_u * Kp;

extern real_T *Kp; 
.
.
tunable_sin_Y.Out1 = rtb_u * (*Kp);

Back to Top

Declare Tunable Parameters

• Declare Workspace Variables as Tunable Parameters

• Declare New Tunable Parameters

• Declare Tunable Parameters Using the Model Configuration Parameter Dialog Box

• Select Workspace Variables

• Create New Tunable Parameters

• Set Tunable Parameter Properties

• Remove Unused Tunable Parameters

Declare Workspace Variables as Tunable Parameters

To declare tunable parameters,

1. Open the Model Parameter Configuration dialog box.

2. In the Source list pane, select one or more variables.

3. Click Add to table . The variables then appear as tunable parameters in the Global (tunable) parameters pane.

4. Select a parameter in the Global (tunable) parameters pane.

5. Select a storage class from the Storage class menu.

6. Optionally, select (or enter) a storage type qualifier, such as const or volatile for the parameter.

7. Click Apply, or click OK to apply changes and close the dialog box.

Declare New Tunable Parameters

To declare tunable parameters,

1. Open the Model Parameter Configuration dialog box.

2. In the Global (tunable) parameters pane, click New.

3. Specify a name for the parameter.

4. Select a storage class from the Storage class menu.

5. Optionally, select (or enter) a storage type qualifier, such as const or volatile for the parameter.

6. Click Apply, or click OK to apply changes and close the dialog box.

Declare Tunable Parameters Using the Model Configuration Parameter Dialog Box

The Model Configuration Parameter dialog box lets you select base workspace variables and declare them to be tunable parameters in the current model. Using controls in the dialog box, you move variables from a source list to a global (tunable) parameter list for a model.

To open the dialog box,

1. Select the Inline parameters check box on the Optimization > Signals and Parameters pane of the Configuration Parameters dialog box. This activates a Configure button, as shown below.

   

2. Click Configure to open the Model Configuration Parameter dialog box.

   

Note   The Model Configuration Parameter dialog box cannot tune parameters within referenced models. See Parameterizing Model References for tuning techniques that work with referenced models.

Select Workspace Variables

The Source list pane displays a menu and a scrolling table of numerical workspace variables. To select workspace variables,

1. From the menu, select the source of variables you want listed.

   To List...	Choose...
   All variables in the MATLAB workspace that have numeric values	MATLAB workspace
   Only variables in the MATLAB workspace that have numeric values and are referenced by the model	Referenced workspace variables

   A list of workspace variables appear in the Source List pane.

2. Select one or more variables from the source list. This enables the Add to table button.

3. Click Add to table to add the selected variables to the tunable parameters list in the Global (tunable) parameters pane. In the Source list, the names of variables added to the tunable parameters list are displayed in bold type (see the preceding figure).

   Note   If you selected a variable with a name that matches a block parameter that is not tunable and you click Add to table , a warning appears during simulation and code generation.

To update the list of variables to reflect the current state of the workspace, at any time, click Refresh list . For example, you might use Refresh list if you define or remove variables in the workspace while the Model Parameter Configuration dialog box is open.

Create New Tunable Parameters

To create a new tunable parameter,

1. In the Global (tunable) parameters pane, click New.

2. In the Name field, enter a name for the parameter.

   If you enter a name that matches the name of a workspace variable in the Source list pane, that variable is declared tunable and appears in italics in the Source list.

3. Click Apply.

The model does not need to be using a parameter before you create it. You can add references to the parameter later.

Note   If you edit the name of an existing variable in the list, you actually create a new tunable variable with the new name. The previous variable is removed from the list and loses its tunability (that is, it is inlined).

Set Tunable Parameter Properties

To set the properties of tunable parameters listed in the Global (tunable) parameters pane, select a parameter and then specify a storage class and, optionally, a storage type qualifier.

Remove Unused Tunable Parameters

To remove unused tunable parameters from the table in the Global (tunable) parameters pane, click Remove. All removed variables are inlined if the Inlined parameters option is enabled.

Back to Top

Tunable Expressions

• Tunable Expressions in Masked Subsystems

• Tunable Expression Limitations

The Simulink Coder product supports the use of tunable variables in expressions. An expression that contains one or more tunable parameters is called a tunable expression.

Tunable Expressions in Masked Subsystems

Tunable expressions are allowed in masked subsystems. You can use tunable parameter names or tunable expressions in a masked subsystem dialog box. When referenced in lower-level subsystems, such parameters remain tunable.

As an example, consider the masked subsystem in the next figure. The masked variable k sets the gain parameter of theGain.

Suppose that the base workspace variable b is declared tunable with SimulinkGlobal (Auto) storage class. The next figure shows the tunable expression b*3 in the subsystem's mask dialog box.

Tunable Expression in Subsystem Mask Dialog Box

The Simulink Coder product produces the following output computation for theGain. The variable b is represented as a member of the global parameters structure, model_P. (For clarity in showing the individual Gain block computation, expression folding is off in this example.)

/* Gain: '<S1>/theGain' */
  rtb_theGain_C = rtb_SineWave_n * ((subsys_mask_P.b * 3.0));

  /* Outport: '<Root>/Out1' */
  subsys_mask_Y.Out1 = rtb_theGain_C;

As this example shows, for GRT targets, the parameter structure is mangled to create the structure identifier model_P (subject to the identifier length constraint). This is done to avoid namespace clashes in combining code from multiple models using model reference. ERT-based targets provide ways to customize identifier names.

When expression folding is on, the above code condenses to

/* Outport: '<Root>/Out1' incorporates:
   *  Gain: '<S1>/theGain'
   */
 subsys_mask_Y.Out1 = rtb_SineWave_n * ((subsys_mask_P.b * 3.0));

Expressions that include variables that were declared or modified in mask initialization code are not tunable.

As an example, consider the subsystem above, modified as follows:

• The mask initialization code is

  t = 3 * k;
  

• The parameter k of the myGain block is 4 + t.

• Workspace variable b = 2. The expression b * 3 is plugged into the mask dialog box as in the preceding figure.

Since the mask initialization code can run only once, k is evaluated at code generation time as

4 + (3 * (2 * 3) )

The Simulink Coder product inlines the result. Therefore, despite the fact that b was declared tunable, the code generator produces the following output computation for theGain. (For clarity in showing the individual Gain block computation, expression folding is off in this example.)

/* Gain Block: <S1>/theGain */
rtb_temp0 *= (22.0);

Tunable Expression Limitations

Currently, there are certain limitations on the use of tunable variables in expressions. When an unsupported expression is encountered during code generation a warning is issued and the equivalent numeric value is generated in the code. The limitations on tunable expressions are

• Complex expressions are not supported, except where the expression is simply the name of a complex variable.

• The use of certain operators or functions in expressions containing tunable operands is restricted. Restrictions are applied to four categories of operators or functions, classified in the following table:

  Category	Operators or Functions
  1	+ - .* ./ < > <= >= == ~= & |
  2	* /
  3	abs, acos, asin, atan, atan2, boolean, ceil, cos, cosh, exp, floor, log, log10, sign, sin, sinh, sqrt, tan, tanh,
  4	single, int8, int16, int32, uint8, uint16, uint32
  5	: .^ ^ [] {} . \ .\ ' .' ; ,

  The rules applying to each category are as follows:

  • Category 1 is unrestricted. These operators can be used in tunable expressions with any combination of scalar or vector operands.

  • Category 2 operators can be used in tunable expressions where at least one operand is a scalar. That is, scalar/scalar and scalar/matrix operand combinations are supported, but not matrix/matrix.

  • Category 3 lists all functions that support tunable arguments. Tunable arguments passed to these functions retain their tunability. Tunable arguments passed to any other functions lose their tunability.

  • Category 4 lists the casting functions that do not support tunable arguments. Tunable arguments passed to these functions lose their tunability.

    Note   The Simulink Coder product casts values using MATLAB typecasting rules. The MATLAB typecasting rules are different from C code typecasting rules. For example, using the MATLAB typecasting rules, int8(3.7) returns the result 4, while in C code int8(3.7) returns the result 3. See Data Type Conversion in the MATLAB reference documentation for more information on MATLAB typecasting.

  • Category 5 operators are not supported.

• Expressions that include variables that were declared or modified in mask initialization code are not tunable.

• The Fcn block does not support tunable expressions in code generation.

• Model workspace parameters can take on only the Auto storage class, and thus are not tunable. See Parameterizing Model References for tuning techniques that work with referenced models.

• Non-double expressions are not supported.

• Blocks that access parameters only by address support the use of tunable parameters, if the parameter expression is a simple variable reference. When an operation such as a data type conversion or a math operation is applied, the Simulink Coder product creates a nontrivial expression that cannot be accessed by address, resulting in an error during the build process.

Back to Top

Linear Block Parameter Tunability

The following blocks have a Realization parameter that affects the tunability of their parameters:

• Transfer Fcn

• State-Space

• Discrete State-Space

The Realization parameter must be set by using the MATLAB set_param function, as in the following example.

set_param(gcb,'Realization','auto')

The following values are defined for the Realization parameter:

• general: The block's parameters are preserved in the generated code, permitting parameters to be tuned.

• sparse: The block's parameters are represented in the code by transformed values that increase the computational efficiency. Because of the transformation, the block's parameters are no longer tunable.

• auto: This setting is the default. A general realization is used if one or more of the block's parameters are tunable. Otherwise sparse is used.

  Note   To tune the parameter values of a block of one of the above types without restriction during an external mode simulation, you must set Realization to general.

Code Reuse for Subsystems with Mask Parameters

The Simulink Coder product can generate reusable (reentrant) code for a model containing identical atomic subsystems. Selecting the Reusable function option for Function packaging enables such code reuse, and causes a single function with arguments to be generated that is called when any of the identical atomic subsystem executes. See Reusable Function Option for details and restrictions on the use of this option.

Mask parameters become arguments to reusable functions. However, for reuse to occur, each instance of a reusable subsystem must declare the same set of mask parameters. If, for example subsystem A has mask parameters b and K, and subsystem B has mask parameters c and K, then code reuse is not possible, and the Simulink Coder product will generate separate functions for A and B.

Back to Top

Configuration Parameter Quick Reference Diagram

The next figure shows the code generation and storage class options that control the representation of parameters in generated code.

Back to Top

Generated Code for Parameter Data Types

For an example of the code generated from Simulink parameters with different data types, run the demo model rtwdemo_paramdt. This demo model shows options that are available for controlling the data type of tunable parameters in the generated code. The model's subsystem includes several instances of Gain blocks feeding Saturation blocks. Each pair of blocks uses a workspace variable of a particular data type, as shown in the next figure.

The Simulink engine initializes the parameters in the demo model by executing the script rtwdemo_paramdt_data.m. You can view the initialization script and inspect the workspace variables in Model Explorer by double-clicking the yellow boxes in the demo model.

In the demo model, note that the Inline parameters option on the Optimization > Signals and Parameters pane of the Configuration Parameters dialog box is selected. The Model Parameter Configuration dialog box reveals that all base workspace variables (with the exception of Kinline) have their Storage class property set to ExportedGlobal. Consequently, Kinline is a nontunable parameter while the remaining variables are tunable parameters.

To generate code for the demo model, double-click the blue boxes. The following table shows both the MATLAB code used to initialize parameters and the code generated for each parameter in the rtwdemo_paramdt model.

Kinline = 2;

rtb_Gain1 = rtwdemo_paramdt_U.In1 * 2.0F;
.
.
rtwdemo_paramdt_Y.Out1 = rt_SATURATE(rtb_Gain1, 0.0F, 2.0F);

Kcs = 3;

real32_T Kcs = 3.0F;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In2 * Kcs;
.
.
rtwdemo_paramdt_Y.Out2 = rt_SATURATE(rtb_Gain1, 0.0F, Kcs);

Ksingle = single(4);

real32_T Ksingle = 4.0F;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In3 * Ksingle;
.
.
rtwdemo_paramdt_Y.Out3 = rt_SATURATE(rtb_Gain1, 0.0F, Ksingle);

Kint8 = int8(5);

int8_T Kint8 = 5;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In4 * ((real32_T)( Kint8 ));
.
.
rtwdemo_paramdt_Y.Out4 = rt_SATURATE(rtb_Gain1, 0.0F,
  ((real32_T)( Kint8 )));

Kfixpt = Simulink.Parameter;
Kfixpt.Value = 6;
Kfixpt.DataType = ...
 'fixdt(true, 16, 2^-5, 0)';
Kfixpt.CoderInfo.StorageClass = ...
 'ExportedGlobal';

int16_T Kfixpt = 192;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In5 *
  (((real32_T)ldexp((real_T)Kfixpt, -5)));
.
.
rtwdemo_paramdt_Y.Out5 = rt_SATURATE(rtb_Gain1, 0.0F,
  (((real32_T)ldexp((real_T)Kfixpt, -5))));

aliasType = ...
 Simulink.AliasType('single');
Kalias = Simulink.Parameter;
Kalias.Value = 7;
Kalias.DataType = 'aliasType';
Kalias.CoderInfo.StorageClass = ...
 'ExportedGlobal';

typedef real32_T aliasType;
.
.
aliasType Kalias = 7.0F;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In6 * Kalias;
.
.
rtwdemo_paramdt_Y.Out6 = rt_SATURATE(rtb_Gain1, 0.0F, Kalias);

userType = Simulink.NumericType;
userType.DataTypeMode = ...
 'Fixed-point: slope and bias scaling';
userType.Slope = 2^-3;
userType.isAlias = true;
Kuser = Simulink.Parameter;
Kuser.Value = 8;
Kuser.DataType = 'userType';
Kuser.CoderInfo.StorageClass = ...
 'ExportedGlobal';

typedef int16_T userType;
.
.
userType Kuser = 64;
.
.
rtb_Gain1 = rtwdemo_paramdt_U.In7 *
  (((real32_T)ldexp((real_T)Kuser, -3)));
.
.
rtwdemo_paramdt_Y.Out7 = rt_SATURATE(rtb_Gain1, 0.0F,
  (((real32_T)ldexp((real_T)Kuser, -3))));

The salient features of the code generated for this demo model are as follows:

• The Simulink Coder product inlines nontunable parameters, for example, Kinline. However, the product does not inline tunable parameters, such as Kcs, Ksingle, and Kint8.

• The Simulink engine treats tunable parameters of data type double in a context-sensitive manner, such that the parameter inherits its data type from the context in which the block uses it. For example, Kcs inherits a single data type from the Gain block's input signal.

• If a parameter's data type matches that of the block's run-time parameter, the block can use the tunable parameter without any transformation. Consequently, the Simulink Coder product need not cast the parameter from one data type to another, as illustrated by Ksingle and Kalias. However, if a parameter's data type does not match that of the block's run-time parameter, the block cannot readily compute its output. In this case, the product casts parameters to the relevant data type. For example, Kint8, Kfixpt, and Kuser require casts to a single data type for compatibility with the input signals to the Gain and Saturation blocks.

• If you are using an ERT target and a parameter specifies a data type alias, for example, created by an instance of the Simulink.AliasType class, its variable definition in the generated code uses the alias data type. For example, the Simulink Coder product declares Kalias and Kuser to be of data types aliasType and userType, respectively.

• If a parameter specifies a fixed-point data type, the Simulink Coder product initializes its value in the generated code to the value of Q computed from the expression V = SQ + B (see the Simulink Fixed Point documentation for more information about fixed-point semantics and notation), where

  • V is a real-world value

  • Q is an integer that encodes V

  • S is the slope

  • B is the bias

  For example, Kfixpt has a real-world value of 6, slope of 2^-5, and bias of 0. Consequently, the product declares the value of Kfixpt to be 192.

Back to Top

Tunable Workspace Parameter Data Type Considerations

If you are using tunable workspace parameters, you need to be aware of potential issues regarding data types. A workspace parameter is tunable when the following conditions exist:

• You select the Inline parameters option on the Optimization > Signals and Parameters pane of the Configuration Parameters dialog box

• The parameter has a storage class other than Auto

When generating code for tunable workspace parameters, the Simulink Coder product checks and compares the data types used for a particular parameter in the workspace and in Block Parameter dialog boxes.

Variable 'K' is used in incompatible ways 
in the dialog fields of the following: 
cs_params/Gain, cs_params/Gain1. The 
variable'value is being used both directly
and after a transformation. Only one of 
these usages is permitted for any given 
variable.

Guidelines for Specifying Data Types

The following table provides guidelines on specifying data types for tunable workspace parameters.

The Simulink Coder product enforces limitations on the use of data types other than double in the workspace, as explained in Limitations on Specifying Data Types in the Workspace Explicitly.

Limitations on Specifying Data Types in the Workspace Explicitly

When you explicitly specify a data type other than double in the workspace, blocks typecast the parameter to a corresponding data type. This is an issue for blocks that use pointer access for their parameters. Blocks cannot use pointer access if they need to typecast the parameter before using it (because of a data type mismatch). Another case in which this occurs is for workspace variables with bias or fractional slope. Two possible solutions to these problems are

• Remove the explicit data type specification in the workspace for parameters used in such blocks.

• Modify the block so that it uses the parameter with the same data type as specified in the workspace. For example, the Lookup Table block uses the data types of its input signal to determine the data type that it uses to access the X-breakpoint parameter. You can prevent the block from typecasting the run-time parameter by converting the input signal to the data type used for X-breakpoints in the workspace. (Similarly, the output signal is used to determine the data types used to access the lookup table Y data.)

Back to Top

Tune Parameters

Tune Parameters from the Command Line

When parameters are MATLAB workspace variables, the Model Parameter Configuration dialog box is the recommended way to see or set the properties of tunable parameters. In addition to that dialog box, you can also use MATLAB get_param and set_param commands.

Note   You can also use Simulink.Parameter objects for tunable parameters. See Configure Parameter Objects for Code Generation for details.

The following commands return the tunable parameters and corresponding properties:

• get_param(gcs, 'TunableVars')

• get_param(gcs, 'TunableVarsStorageClass')

• get_param(gcs, 'TunableVarsTypeQualifier')

The following commands declare tunable parameters or set corresponding properties:

• set_param(gcs, 'TunableVars', str)

  The argument str (string) is a comma-separated list of variable names.

• set_param(gcs, 'TunableVarsStorageClass', str)

  The argument str (string) is a comma-separated list of storage class settings.

  The valid storage class settings are

  • Auto

  • ExportedGlobal

  • ImportedExtern

  • ImportedExternPointer

• set_param(gcs, 'TunableVarsTypeQualifier', str)

  The argument str (string) is a comma-separated list of storage type qualifiers.

The following example declares the variable k1 to be tunable, with storage class ExportedGlobal and type qualifier const. The number of variables and number of specified storage class settings must match. If you specify multiple variables and storage class settings, separate them with a comma.

set_param(gcs, 'TunableVars', 'k1')
set_param(gcs, 'TunableVarsStorageClass','ExportedGlobal')
set_param(gcs, 'TunableVarsTypeQualifier','const')

Other configuration parameters you can get and set are listed in Configuration Parameters for Simulink Models in the Simulink Coder Reference.

Interfaces for Tuning Parameters

The Simulink Coder product includes

• Support for developing a Target Language Compiler API for tuning parameters independent of external mode. See Parameter Functions in the Target Language Compiler documentation for information.

• A C application program interface (API) for tuning parameters independent of external mode. See Data Interchange Using the C API for information.

• An interface for exporting ASAP2 files, which you customize to use parameter objects. For details, see ASAP2 Data Measurement and Calibration.

Back to Top

Parameter Objects

• About Parameter Objects for Code Generation

• Use Parameter Objects for Code Generation

• Configure Parameter Objects for Code Generation

• Effect of Storage Classes on Code Generation for Parameter Objects

• Control Parameter Object Code Generation with Typed Commands

• Control Parameter Object Code Generation Using the Model Explorer

• Parameter Object Configuration Quick Reference Diagram

• Resolve Conflicts in Configuration of Parameter Objects

About Parameter Objects for Code Generation

Within the class hierarchy of Simulink data objects, the Simulink product provides a class that is designed as base class for parameter storage. This topic explains how to use parameter objects in code generation.

The CoderInfo properties of parameter objects are used by the Simulink Coder product during code generation. These properties let you assign storage classes to the objects, thereby controlling how the generated code stores and represents parameters.

The Simulink Coder build process also writes information about the properties of parameter objects to the model.rtw file. This information, formatted as Object records, is accessible to Target Language Compiler programs. For general information on Object records, see the Target Language Compiler documentation.

Before using Simulink parameter objects with the Simulink Coder product, read the discussion of Simulink data objects in the Simulink documentation.

Use Parameter Objects for Code Generation

The general procedure for using parameter objects in code generation is as follows:

1. Define a subclass of Simulink.Parameter.

2. Instantiate parameter objects from your subclass and set their properties from the command line or by using Model Explorer.

3. Use the objects as parameters within your model.

4. Generate code and build your target executable.

Configure Parameter Objects for Code Generation

In configuring parameter objects for code generation, you use the following code generation and parameter object properties:

• The Inline parameters option (see Parameters).

• Parameter object properties:

  • Value. The numeric value of the object, used as an initial (or inlined) parameter value in generated code.

  • DataType. The data type of the object. This can be any Simulink numeric data type, including a fixed-point, user-defined, or alias data type.

  • CoderInfo.StorageClass. Controls the generated storage declaration and code for the parameter object.

  Other parameter object properties (such as user-defined properties of classes derived from Simulink.Parameter) do not affect code generation.

  Note   If Inline parameters is off (the default), the CoderInfo.StorageClass parameter object property is ignored in code generation.

Effect of Storage Classes on Code Generation for Parameter Objects

The Simulink Coder product generates code and storage declarations based on the CoderInfo.StorageClass property of the parameter object. The logic is as follows:

• If the storage class is 'Auto' (the default), the parameter object is inlined (if possible), using the Value property.

• For storage classes other than 'Auto', the parameter object is handled as a tunable parameter.

  • A global storage declaration is generated. You can use the generated storage declaration to make the variable visible to your hand-written code. You can also make variables declared in your hand-written code visible to the generated code.

  • The symbolic name of the parameter object is generally preserved in the generated code.

See the table in Control Parameter Object Code Generation Using the Model Explorer for examples of code generated for possible settings of CoderInfo.StorageClass.

Control Parameter Object Code Generation with Typed Commands

In this section, the Gain block computations of the model shown in the next figure are used as an example of how the Simulink Coder build process generates code for a parameter object.

Model Using Parameter Object Kp As Block Parameter

In this model, Kp sets the gain of the Gain block.

To configure a parameter object such as Kp for code generation:

1. Instantiate a Simulink.Parameter object called Kp. In this example, the parameter object is an instance of the example class SimulinkDemos.Parameter, which is provided with the Simulink product.

   Kp = Simulink.Parameter
   Kp =
   Simulink.Parameter
             Value: 5
           CoderInfo: [1x1 Simulink.ParamCoderInfo]
       Description: ''
          DataType: 'auto'
               Min: []
               Max: []
          DocUnits: ''
        Complexity: 'real'
        Dimensions: '[1x1]'

   Make sure that the name of the parameter object matches the desired block parameter in your model. This enables the Simulink engine to associate the parameter name with the corresponding object. In the preceding model, the Gain block parameter Kp resolves to the parameter object Kp.

2. Set the object properties you need. You can do this by using the Model Explorer, or you can assign properties by using MATLAB commands, as follows:

   • To specify the Value property, type

     Kp.Value = 5.0;
     

   • To specify the storage class of for the parameter, set the CoderInfo.StorageClass property, for example:

     Kp.CoderInfo.StorageClass = 'ExportedGlobal';
     

   The CoderInfo parameters are now

   Kp.CoderInfo
   Simulink.ParamCoderInfo
             StorageClass: 'ExportedGlobal'
                    Alias: ''
       CustomStorageClass: 'Default'
         CustomAttributes: [1x1 
   SimulinkCSC.AttribClass_Simulink_Default]
   

Control Parameter Object Code Generation Using the Model Explorer

If you prefer, you can create and modify attributes of parameter objects using the Model Explorer. This lets you see all attributes of a parameter in a dialog box, and alleviates the need to remember and type field names. Do the following to instantiate Kp and set its attributes from Model Explorer:

1. Choose Model Explorer from the View menu.

   Model Explorer opens or activates if it already was open.

2. Select Base Workspace in the Model Hierarchy pane.

3. Select Simulink Parameter from the Add menu.

   A new parameter named Param appears in the Contents pane.

   

4. To set Kp.Name in the Model Explorer:

   1. Click the word Param in the Name column to select it.

   2. Rename it by typing Kp in place of Param.

   3. Press Enter or Return.

5. To set Kp.Value in Model Explorer:

   1. Select the Value field at the top of the Dialog pane.

   2. Type 5.0.

   3. Click the Apply button.

6. To set the Kp.CoderInfo.StorageClass in Model Explorer:

   1. Click the Storage class menu and select ExportedGlobal, as shown in the next figure.

      

   2. Click Apply.

The following table shows the variable declarations for Kp and the code generated for the Gain block in the model shown in the preceding model, with the Inline parameters and Eliminate superfluous local variables (Expression folding) check boxes selected (which includes the gain computation in the output computation). An example is shown for each possible setting of CoderInfo.StorageClass. Global structures include the model name (symbolized as model_ or _model).

model_Y.Out1 = rtb_u * 5.0;

struct _Parameters_model {
  real_T Kp;
}
.
.
Parameters_model model_P = {
  5.0
};
.
.
model_Y.Out1 = rtb_u * model_P.Kp;

extern real_T Kp;
.
.
real_T Kp = 5.0;
.
.
model_Y.Out1 = rtb_u * Kp;

extern real_T Kp;
.
.
model_Y.Out1 = rtb_u * Kp;

extern real_T *Kp;
.
.
model_Y.Out1 = rtb_u * (*Kp);

Parameter Object Configuration Quick Reference Diagram

The next figure shows the code generation and storage class options that control the representation of parameter objects in generated code.

Resolve Conflicts in Configuration of Parameter Objects

Two methods are available for controlling the tunability of parameters. You can

• Define them as Simulink.Parameter objects in the MATLAB workspace

• Use the Model Parameter Configuration dialog box

The next figures show how you can use each of these methods to control the tunability of parameter Kp. The first figure shows Kp defined as Simulink.Parameter in the Model Explorer. You control the tunability of Kp by specifying the parameter's storage class.

Parameter Object Kp with Auto Storage Class in Model Explorer

The next figure shows how you can use the Model Parameter Configuration dialog box to specify a storage class for numeric variables in the MATLAB workspace.

Parameter Kp Defined with SimulinkGlobal Storage Class

Note   Do not use both methods for controlling the tunability of a given parameter. If you use both methods and the storage class settings for the parameter do not match, an error results.

Back to Top

Structure Parameters and Generated Code

• About Structure Parameters and Generated Code

• Configure a Structure Parameter to Appear in Generated Code

• Control the Name of a Structure Parameter Type

About Structure Parameters and Generated Code

Structure parameters provide a way to improve generated code to use structures rather multiple separate variables. You also have the option of configuring the appearance of a structure parameter in generated code.

For more information about structure parameters, seeUsing Structure Parameters in the Simulink documentation. For an example of how to convert a model that uses unstructured workspace variables to a model that uses structure parameters, see sldemo_applyVarStruct.

Configure a Structure Parameter to Appear in Generated Code

By default, structure parameters do not appear in generated code. Structure parameters include numeric variables and the code generator inlines numeric values.

To make structure type definition appear in generated code for a structure parameter,

1. Create a Simulink.Parameter object.

2. Define the object value to be the parameter structure.

3. Define the object storage class to be a value other than Auto.

The code generator places a structure type definition or the tunable parameter structure in model_types.h. By default, the code generator identifies the type with a nondescriptive, automatically generated name, such as struct_z98c0D2qc4btL.

For information on how to control the naming of the type, see Control the Name of a Structure Parameter Type. For an example, see sldemo_applyVarStruct

Control the Name of a Structure Parameter Type

To control the naming of a structure parameter type, by using a Simulink.Bus object to specify the data type of the Simulink.Parameter object.

1. Use Simulink.Bus.createObject to create a bus object with the same shape as the parameter structure. For example:

   busInfo=Simulink.Bus.createObject(ControlParam.Value);

2. Assign the bus object name to the data type property of the parameter object.

   ParamType=eval(busInfo.busName);
   ControlParam.DataType='Bus: ParamType';

Only Simulink.Parameter can accept the bus object name as a data type.

For an example, see sldemo_applyVarStruct

Back to Top

Structure Parameters and Generated Code

Signals

Related Products & Applications

• Simulink
• Control Design
• Signal Processing & Communications
• Model-Based Design
• Physical Modeling
• Verification & Validation

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit