slbuild

Build standalone executable file or model reference target for model

Syntax

slbuild(model)

slbuild(model,buildSpec)

slbuild(model,Name,Value)

blockHandle = slbuild(subsystem)

blockHandle = slbuild(subsystem,'Mode','ExportFunctionCalls')

blockHandle = slbuild(subsystem,Name,Value)

Description

slbuild(model) builds a standalone Simulink^® Coder™ binary executable file from the specified model, using the current configuration parameter settings. If the model is not loaded, slbuild loads the model before starting the build process.

slbuild(model,buildSpec) builds a standalone Simulink Coder binary executable file from the model according to the specified code generation action.

slbuild(model,Name,Value) builds a standalone Simulink Coder binary executable file from the model as specified by one or more name-value arguments.

blockHandle = slbuild(subsystem) generates subsystem code and builds a Simulink Coder binary executable file by using the current configuration parameter settings of your model. If the selected system target file creates an S-Function block, the function returns a non-empty block handle to an autogenerated S-Function wrapper. Before you run the command, you must open or load the parent model.

blockHandle = slbuild(subsystem,'Mode','ExportFunctionCalls') generates code from the subsystem that includes function calls that you can export to external application code. This command requires Embedded Coder^®. If the Create block configuration parameter is set to SIL, the function returns the handle to a Model block in SIL mode. You can then use the Model block for numerical equivalence testing.

blockHandle = slbuild(subsystem,Name,Value) generates subsystem code and builds a Simulink Coder binary executable file as specified by one or more name-value arguments.

Examples

Generate Code and Build Executable File for Model

Generate C code for model CounterModel.

openExample('CounterModel')
slbuild('CounterModel')
% Same operation as ...
% slbuild('CounterModel','StandaloneCoderTarget') 

For the generic real-time (GRT) target, the coder generates these code files and places them in folders CounterModel_grt_rtw and slprj/grt/_sharedutils.

Model Files	Shared Files	Interface Files	Other Files
CounterModel.c CounterModel.h CounterModel_private.h CounterModeltypes.h	rtwtypes.h multiword_types.h builtin_typeid_types.h	rtmodel.h	none

If the following model configuration parameters settings apply, the coder generates additional results.

Parameter Setting	Results
Code Generation > Generate code only pane is cleared	Executable file CounterModel.exe
Code Generation > Report > Create code generation report is selected	Report appears, providing information and links to generated code files, subsystem and code interface reports, entry-point functions, inports, outports, interface parameters, and data stores

Build Multiple Models

This example shows how to use slbuild to generate executable code for two models, CounterModel and ParallelBuildA1. ParallelBuildA1 is a top model that references models and is configured to build the referenced models in parallel.

Open the models.

openExample("simulinkcoder/RegisterAndUseToolchainToBuildExecutableExample", ...
             supportingfile="CounterModel.slx")
openExample("simulinkcoder/MonitorBuildProcessForModelHierarchyExample", ...
             supportingfile="ParallelBuildA1.slx")

Build the models.

slbuild({'CounterModel', 'ParallelBuildA1'})

In the current folder, the build process creates standalone executable files, CounterModel.exe and ParallelBuildA1.exe.

For each model, in the Command Window, the build process displays a build summary.

Force Top Model Build

Generate code and build an executable file for the model TopModelCode, which refers to model ReferenceModelCode, regardless of model checksums and parameter settings.

openExample('simulinkcoder/FilePackagingModelsCodeAndDataExample',...
    'supportingFile','TopModelCode');
slbuild('TopModelCode','StandaloneCoderTarget',...
    'ForceTopModelBuild',true)

Generate Code and Build Executable File for Subsystem

Generate C code for subsystem Amplifier in model CounterModel.

openExample('CounterModel')
slbuild('CounterModel/Amplifier')

The code generator produces code files in the Amplifier_grt_rtw and slprj/grt/_sharedutils folders.

In your current working folder, the build process creates an executable file (Amplifier.exe).

Build Subsystem for Exporting Code to External Application

To export function calls to external application code, build an executable file from a function-call subsystem.

openExample('SimulinkFunctions')
set_param('SimulinkFunctions','GenCodeOnly','off');
slbuild('SimulinkFunctions/util','Mode','ExportFunctionCalls')

The executable file util.exe appears in your working folder.

Create Model Block for SIL Testing

From a function-call subsystem, create a Model block that you can use to test the code generated from a model.

Open subsystem util in model SimulinkFunctions.

Set the Code Generation > Verification > Advanced parameters > Create block configuration parameter to SIL.

Create the Model block.

openExample('SimulinkFunctions');
set_param('SimulinkFunctions','GenCodeOnly','off');
mysilblockhandle = slbuild('SimulinkFunctions/util',...
'Mode','ExportFunctionCalls')

The code generator produces the Model block in a temporary model. The Model block is configured as follows:

• Model name is set to the name of a new model that contains the content of the original subsystem.

• Simulation mode is set to Software-in-the-loop (SIL).

You can add the block to an environment or test harness model that supplies test vectors or stimulus input. You can then run simulations that perform SIL tests and verify that the Model block produces the same result as the original subsystem.

Input Arguments

model — Specifies model for the build process

handle | character vector | cell array of handles or character vectors

If you specify the model name as a handle or character vector, the build process creates a standalone executable file or model reference target.

If you specify multiple models through a cell array of handles or character vectors, the build process applies buildSpec to each model in the cell array.

Example: gcs

subsystem — Subsystem name

handle | character vector | cell array of handles or character vectors

Name of subsystem from which you want to generate code or build an executable file, specified as a handle or character vector representing the subsystem name or the full block path.

You can specify multiple subsystems through a cell array of handles or character vectors

Example: 'SimulinkFunctions/util'

buildSpec — Specifies the code generation action for the build process

'StandaloneCoderTarget' (default) | 'ModelReferenceSimTarget' | 'ModelReferenceCoderTarget' | 'CleanTopModel'

buildSpec directs the code generator to perform the selected build action for the model and the build process:

• Honors the setting of the Rebuild parameter on the Model Referencing pane of the Configuration Parameters dialog box.

• Requires a Simulink Coder license only if you build a model reference Simulink Coder target, not if you build a model reference simulation target only.

The buildSpec argument must be one of the following.

buildSpec Value	Build Action
'StandaloneCoderTarget'	Builds a standalone Simulink Coder binary executable file for the specified model, using the current model configuration settings. It also builds model reference coder targets for the referenced models. If the specified model is not loaded, slbuild loads it before initiating the build process.
'ModelReferenceSimTarget'	Builds a model reference simulation target (does not require a Simulink Coder license).
'ModelReferenceCoderTarget'	Builds a model reference Simulink Coder target.
'CleanTopModel'	Cleans the model build area enough to trigger regeneration of the top model code at the next build.

Example: 'ModelReferenceSimTarget'

Name-Value Arguments

Specify optional pairs of arguments as Name1=Value1,...,NameN=ValueN, where Name is the argument name and Value is the corresponding value. Name-value arguments must appear after other arguments, but the order of the pairs does not matter.

Before R2021a, use commas to separate each name and value, and enclose Name in quotes.

Example: 'UpdateThisModelReferenceTarget','Force'

UpdateThisModelReferenceTarget — Conditional rebuild option for model reference build

'Force' | 'IfOutOfDateOrStructuralChange' | 'IfOutOfDate'

Conditional rebuild option for the model reference build, specified as the comma-separated pair consisting of 'UpdateThisModelReferenceTarget' and 'Force', 'IfOutOfDateOrStructuralChange', or 'IfOutOfDate'.

This option applies only to the specified model, not to any models referenced by the specified model.

'UpdateThisModelReferenceTarget' Value	Equivalent Rebuild Option	Rebuild Action
'Force'	Always	Unconditionally rebuilds the model.
'IfOutOfDateOrStructuralChange'	If changes detected	Rebuilds the model if the build process detects any changes.
'IfOutOfDate'	If changes in known dependencies detected	Rebuilds the model if the build process detects any changes in known dependencies of this model.

For more information on the different rebuild options, see Rebuild.

Example: 'UpdateThisModelReferenceTarget','Force'

Dependencies

To use this option, set buildSpec to 'ModelReferenceSimTarget' or 'ModelReferenceCoderTarget'.

Data Types: char | string

BuildOutputType — Build output type

'Auto' (default) | 'Executable' | 'StaticLibrary | 'SharedLibrary'

If your top model uses an ERT or GRT system target file, use this option to specify the output type for the build process.

'BuildOutputType' Value	Build Action
'Auto' (default)	In the code generation folder, create a Simulink Coder binary file from the top model. The output type of the build process depends on the current configuration parameter settings. For example: If System target file is ert.tlc or grt.tlc, the build process typically produces a standalone binary executable file. If System target file is ert_shrlib.tlc, the build process produces a shared library file. If the model is mapped to a service interface configuration through an Embedded Coder dictionary, the build process produces a static library file. See Define Service Interfaces, Storage Classes, Memory Sections, and Function Templates for Software Architecture (Embedded Coder) and Embedded Coder Dictionary (Embedded Coder).
'Executable'	In the code generation folder, create a standalone Simulink Coder binary executable file from the top-model generated code. For example, myModel.exe.
'StaticLibrary'	In the build folder, create a static library from the top-model generated code. For example, myModel.lib. The library does not include the example main program.
'SharedLibrary'	In the build folder, create a shared library from the top-model generated code. For example, myModel.dll. The library does not include the example main program.

For information about code generation and build folders, see Manage Build Process Folders (Simulink Coder).

Example: 'BuildOutputType' ,'StaticLibrary'

Dependencies

To use this option, set buildSpec to 'StandaloneCoderTarget'.

Data Types: char | string

ForceTopModelBuild — Force top model of model hierarchy to build

false (default) | true

Option to force the top model of the model hierarchy to build, specified as the comma-separated pair consisting of 'ForceTopModelBuild' and true or false.

Setting the value to true directs the code generator to generate code and build an executable file for the top model of the model hierarchy, regardless of model checksums and parameter settings.

Example: 'ForceTopModelBuild',true

Dependencies

To use this option, set buildSpec to 'StandaloneCoderTarget'.

Data Types: logical

GenerateCodeOnly — Generate code only

false | true

If you do not specify a value, the Generate code only (GenCodeOnly) option on the Code Generation pane controls build process behavior.

If you specify a value, the argument overrides the Generate code only (GenCodeOnly) option on the Code Generation pane:

• true –– Generate code only.

• false –– Generate code and build executable file.

Mode — Export function calls (for subsystem builds only)

'ExportFunctionCalls' | 'Normal'

• 'ExportFunctionCalls' –– If you have Embedded Coder, generates code from subsystem that includes function calls that you can export to external application code.

• 'Normal' –– Does not export function calls.

ExportFunctionFileName — Function name

character vector

Name the exported function for the specified subsystem.

Example: slbuild(subsystem,'Mode','ExportFunctionCalls','ExportFunctionFileName', fcnname)

OpenBuildStatusAutomatically — Display build information

false (default) | true

Option to display the build information, specified as the comma-separated pair consisting of 'OpenBuildStatusAutomatically' and true or false.

To display build information in the Build Status window, specify true. The default is false. For more information about using the status window, see Monitor Parallel Building of Referenced Models (Simulink Coder).

The Build Status window supports parallel builds of referenced model hierarchies. Do not use the Build Status window for serial builds.

Dependencies

To use this option, set buildSpec to 'StandaloneCoderTarget'.

Data Types: logical

ObfuscateCode — Generate obfuscated C code

false (default) | true

Specify whether to generate obfuscated C code:

• true –– Generate obfuscated C code that you can share with third parties with reduced likelihood of compromising intellectual property.

• false –– Generated C code is not obfuscated.

IncludeModelReferenceSimulationTargets — Build model reference simulation targets

false (default) | true

Option to build model reference simulation targets, specified as the comma-separated pair consisting of 'IncludeModelReferenceSimulationTargets' and true or false.

Dependencies

To use this option, set buildSpec to 'StandaloneCoderTarget'.

Data Types: logical

Output Arguments

blockHandle — Block handle

handle

Block handle to an autogenerated S-Function wrapper block or Model block.

Extended Capabilities

Automatic Parallel Support

Accelerate code by automatically running computation in parallel using Parallel Computing Toolbox™.

To build referenced models in parallel, in the top model, select the configuration parameter check box Enable parallel model reference builds. For more information, see Reduce Build Time for Referenced Models by Using Parallel Builds (Simulink Coder).

In Parallel Computing Toolbox™ commands, for example, a parfor or spmd loop, do not invoke rtwbuild, rtwrebuild, or slbuild commands that build models that are configured for parallel builds.

Version History

Introduced before R2006a

R2020b: slbuild does not generate model reference simulation targets by default

Starting in R2020b, the slbuild function does not generate model reference simulation targets by default. Excluding the model reference simulation targets allows for faster code generation for model hierarchies.

You can generate both the simulation and code generation targets with the default buildSpec value ('StandaloneCoderTarget') by setting IncludeModelReferenceSimulationTargets to true.

When you specify 'ModelReferenceCoderTarget' for the buildSpec argument, slbuild no longer builds a model reference simulation target. It builds only a model reference Simulink Coder target.

R2020b: 'ModelReferenceCoderTargetOnly' is not recommended

Starting in R2020b, the buildSpec argument values 'ModelReferenceCoderTarget' and 'ModelReferenceCoderTargetOnly' have the same behavior. 'ModelReferenceCoderTargetOnly' is not recommended. Use 'ModelReferenceCoderTarget' instead.

There are no plans to remove 'ModelReferenceCoderTargetOnly'.

R2019a: 'StandaloneRTWTarget', 'ModelReferenceRTWTarget', and 'ModelReferenceRTWTargetOnly' are not recommended

In R2019a, these buildSpec argument values received new names for clarity:

• 'StandaloneRTWTarget' — Use 'StandaloneCoderTarget' instead.

• 'ModelReferenceRTWTarget' — Use 'ModelReferenceCoderTarget' instead.

• 'ModelReferenceRTWTargetOnly' — Use 'ModelReferenceCoderTargetOnly' instead.

There are no plans to remove the legacy buildSpec argument values.