Variant Elements Within Buses

This example uses:

This example explains how to create bus signals with elements having different variant conditions.

Explore the Model

Open the slexVariantBus model.

open_system("slexVariantBus")

The model consists of two signals, a and b, which are merged to form a bus signal. These signals have variant conditions, V == 1 and W == 1 respectively. During simulation, the bus selector receives two signals with different variant conditions V == 1 and W == 1.

sim("slexVariantBus")

ans = 

  Simulink.SimulationOutput:

     SimulationMetadata: [1x1 Simulink.SimulationMetadata] 
           ErrorMessage: [0x0 char]

When you select individual signals from the bus using the bus selector, the corresponding variant condition is also selected. There is no difference in the propagation behavior of variant conditions when passing through virtual or nonvirtual buses. For more information on buses, see Explore Simulink Bus Capabilities.

Generate Code for Variant Buses

You can generate code for the model. To do so, on the Apps tab of toolstrip, click Embedded Coder, on the C Code tab, click Build. For more information on configuring model to generate code, see Prepare Variant-Containing Model for Code Generation.

Note

When generating code with preprocessor conditionals, the bus types and hierarchies of all bus inputs must be the same. For information on bus hierarchies, see View Bus Hierarchy.

Virtual and Nonvirtual Bus Behavior

A virtual bus does not appear as a structure or any other coherent unit in the generated code. A separate copy of any algorithm that manipulates the bus exists for each bus element. In general, virtual buses do not affect the generated code. In this example, the buses a and b pass through a Unit Delay block. The generated slexVariantBus.h file defines one Unit Delay block for each element of the virtual bus. Each Unit Delay block is enclosed in the variant condition of the corresponding element.

/* Block states (default storage) for system '<Root>' */
typedef struct {

#if V == 1
real_T UnitDelay_1_DSTATE;           /* '<Root>/Unit Delay' */
#define D_WORK_EX_BUS_VAR_COND_VARIANT_EXISTS
#endif                                 /* V == 1 */

#if W == 1
int32_T UnitDelay_2_DSTATE;          /* '<Root>/Unit Delay' */
#define D_WORK_EX_BUS_VAR_COND_VARIANT_EXISTS
#endif                                 /* W == 1 */

#ifndef D_WORK_EX_BUS_VAR_COND_VARIANT_EXISTS
char _rt_unused;
#endif
} D_Work_ex_bus_var_cond;

A nonvirtual bus appears as a structure in the generated code, and only one copy exists of any algorithm that uses the bus. The use of a structure in the generated code can be helpful when tracing the correspondence between the model and the code. In this example, the buses a and b pass through a Unit Delay block. The Simulink.Bus object myBus appears in the generated slexVariantBus_types.h file as a structure for the nonvirtual buses. The bus object used in the bus is unconditional and it generates unguarded code, as shown below. For more information on bus objects, see Specify Bus Properties with Bus Objects.

typedef struct {
real_T a;
real_T b;
} myBus;

The generated slexVariantBus.h file defines one Unit Delay block for the nonvirtual bus, using the myBus structure. The Unit delay block is enclosed in a logical OR of the variant conditions, V == 1 and W == 1, from all the elements of the nonvirtual bus.

/* Block states (default storage) for system '<Root>' */
typedef struct {
#if V == 1 || W == 1
myBus UnitDelay_DSTATE; /* '<Root>/Unit Delay' */
#define D_WORK_SLEXVARIANTBUS_VARIANT_EXISTS
#endif
#ifndef D_WORK_SLEXVARIANTBUS_VARIANT_EXISTS
uchar_T rt_unused;
#endif
} D_Work_slexVariantBus;

Variant Bus with Model Block

Consider this model containing a Model block.

This model has two signals a and b which have different variant conditions, V == 1 and V == 2. The Model block feeds the bus selector two signals having two different variant conditions (V == 1 and V == 2). During simulation, the Model block propagates the variant conditions received from the referenced model mVarBus_bot at its outports. The variant condition at each outport is the logical OR of the variant conditions V == 1 and V == 2 from the variant choices of the mVarBus_bot model. For more information on variant condition propagation with Model Reference blocks, see Propagate Variant Conditions to Enable or Disable Model or Subsystem References in Hierarchy.

Known Limitations

States logging of blocks (for example, Unit Delay) that accept buses with inactive elements is not supported.