You can combine signals into a bus signal and then access the bus as a whole or select specific signals from the bus. These examples show the fundamentals of creating and using buses in models and in generated code. For additional information, see Virtual Bus.
Example | Description |
---|---|
Virtual buses provide the simplest approach for using buses to reduce signal clutter in a block diagram. | |
Create and Use Nonvirtual Buses | Nonvirtual buses support modeling components (such as S-functions or MATLAB Function blocks) that require explicitly specified interfaces. |
Generate Code for Buses | Generated code for virtual and nonvirtual buses differs. Code generation for a nonvirtual bus produces a structure, which can be helpful for tracing the correspondence between a model and its generated code. |
slexBusExample | Simple examples that introduce using bus-related blocks, including animations for smart editing of bus signals. |
For models that include bus signals composed of many bus elements that feed subsystems, consider using the In Bus Element and Out Bus Element blocks. You can use these bus element port blocks instead of Inport with Bus Selector blocks for inputs, and Outport with Bus Creator blocks for outputs. These bus element port blocks:
Reduce signal line complexity and clutter in a block diagram.
Make it easier to change the interface incrementally.
Allow access to a bus element closer to the point of usage, avoiding the use of a Bus Selector and Goto block configuration.
For more information, see Simplify Bus Interfaces.
These examples are simple, to focus on the basic steps in creating and using buses. Buses are most useful when you have many signals that make sense to combine to reduce visual complexity. The examples also include steps to label blocks and signals, to clarify the relationship between signals and buses and between blocks. If you choose to build the example models step-by-step, you can skip those steps if you like.
This example shows how to combine signals into virtual buses. The model selects individual signals (bus elements) from a virtual bus and uses the bus elements as individual signals.
To change bus element values without adding Bus Selector and Bus Creator blocks that select bus elements and reassemble them into a bus, you can use a Bus Assignment block. For details, see Assign Signal Values to a Bus.
To see the completed model, open the ex_bus_tutorial_virtual
model. When you simulate
the model, the bus signal lines indicate that the buses are virtual.
Perform these steps to gain experience creating and using virtual buses.
From the Simulink® Start Page, select a blank model template.
In the Simulink Editor, add a Chirp Signal block and a Sine Wave block.
Create a bus for the signals from the two blocks. Drag to select the blocks and in the action bar that appears, click Create Bus.
Simulink adds a Bus Creator block and connects the input signals to that block.
By default, the Bus Creator block name does not appear. To
add a block name, select the block and from the action bar that appears,
select Show Block Name. Then edit the name, changing it
from Bus Creator
to SubBus
.
You do not have to label the signals in a bus. However, labeling makes it
easier to see the relationship between bus element signals and bus signals.
Label the output signal for the Chirp Signal block.
Right-click the signal and select Properties. In the
Signal name property, enter
chirp
. Similarly, set the Sine Wave
signal name to sine
.
Inputs to a Bus Creator block must have unique names.
If there are duplicate names, the Bus Creator block
appends (signal#)
to all input signal names, where
#
is the input port index.
Do not use a less than character (<
) to start a
signal name.
Add a Step block below the Sine Wave block.
To create a nested bus, add a Bus Creator block to the
right of the current blocks. Connect the signal from the
SubBus
block and the signal from the
Step block to the second Bus Creator
block.
Label the output signal from the SubBus
block
subBus
and the signal from the Step
block step
.
Show the block name for the Bus Creator block that creates
the nested bus. Change the name to NestedBus
.
Attach a Scope block to the nestedBus
signal.
To the right of the NestedBus
block, add a
Subsystem block and connect the
NestedBus
output signal to the subsystem.
Connect the Subsystem block output port to a Scope block.
In the subsystem, disconnect the Inport and Outport blocks and insert a Bus Selector block to the right of the Inport block. Connect the Inport block to a Bus Selector block.
Show the Bus Selector block name. Change the name to
BusSelector
.
To the right of the Bus Selector block, add a
Saturation block and set its Lower
limit parameter to -inf
.
Combine the chirp
signal and the
Saturation block output signal into a bus.
Combine the bus signal and the step
signal into a
nested bus.
Connect the nested bus to the Outport block.
To see the simulation results, simulate the model and open the Scope blocks.
This example changes the virtual buses used in the
ex_bus_tutorial_virtual
model to nonvirtual buses. To see the
completed model, open the ex_bus_tutorial_nonvirtual
model. Nonvirtual
buses are required for certain modeling situations. Generating code for a nonvirtual
bus represents the bus as a structure. For more information about when to use
nonvirtual buses, see Nonvirtual Bus.
When you simulate the model, the bus signal lines indicate that the virtual are converted to nonvirtual buses.
Perform these steps to gain experience creating and using nonvirtual buses.
Open the ex_bus_tutorial_virtual
model.
Bus signals do not specify whether they are virtual or nonvirtual; they inherit that specification from the block in which they originate. Every block that creates or requires a nonvirtual bus must have an associated bus object.
For the SubBus
block, specify to produce nonvirtual bus
output. In the Block Parameters dialog box, set Output data
type to Bus: subBus
. This setting uses the
subBus
bus object, which provides bus properties that
Simulink uses to validate the bus signal.
Also, select the Output as nonvirtual bus parameter.
When you use bus objects to create nonvirtual buses, the bus object must be in the base workspace before simulating the model. You need to define the bus object or use an already defined bus object. To simplify this example, when you open the model, a model callback loads the necessary bus objects into the base workspace. To see the callback, on the Modeling tab, under the Model Settings dropdown, click Model Properties and open the Callbacks tab.
For information about creating bus objects, see Specify Bus Properties with Bus Objects.
In the NestedBus
block, set Output data
type to Bus: topBus
and select the
Output as nonvirtual bus parameter.
The subBus
bus object expects the second input signal
in the bus to be called sine
. Although the Bus
Selector block selected the sine
signal from
the bus, the default name of the output signal of the
Saturation block is not sine
. Use the
Signal Properties dialog box to name the
Saturation block output signal
sine
.
The topBus
bus object expects the first input signal in
the bus to be called subSignal
. Use the Signal
Properties dialog box to name the bus signal
subSignal
.
To see the simulation results, simulate the model and open the
Scope blocks. The results are the same as when you
simulate the ex_bus_tutorial_virtual
model that you used
as a base for this model.
The simulation results are the same for the model that uses virtual buses
(ex_bus_tutorial_virtual
) and for the model that uses
nonvirtual buses (ex_bus_tutorial_nonvirtual
). However, the
generated code is different.
Adding a Unit Delay block and an Outport block after the Subsystem block in each of the models helps to highlight the differences in the generated code.
Generate code from the ex_bus_tutorial_virtual_code_gen
model.
The virtual buses do not affect the generated code. For example, in the
generated file ex_bus_tutorial_virtual_code_gen.c
, the
algorithm in the model step
function effectively implements
three Unit Delay blocks (one for each meaningful signal, such as
chirp
, that passes through the block).
/* UnitDelay: '<Root>/Unit Delay' */ rtb_chirp = ex_bus_tutorial_virtual_code_DW.UnitDelay_1_DSTATE; /* UnitDelay: '<Root>/Unit Delay' */ rtb_signal2 = ex_bus_tutorial_virtual_code_DW.UnitDelay_2_DSTATE; /* UnitDelay: '<Root>/Unit Delay' */ rtb_step = ex_bus_tutorial_virtual_code_DW.UnitDelay_3_DSTATE;
For the nonvirtual bus model, the Output data type is set
to Bus: topBus
and Scope blocks are commented
out, because Scope blocks are not needed for the generated code
and do not support code generation.
Generate code from the ex_bus_tutorial_nonvirtual_code_gen
model.
The nonvirtual buses appear in the generated code as structures. Each
Simulink.Bus
object appears as a structure type. The type
definitions appear in
ex_bus_tutorial_nonvirtual_code_gen_types.h
.
typedef struct { real_T chirp; real_T sine; } subBus; typedef struct { subBus subSignal; real_T step; } topBus;
The algorithm in the model step
function can implement the
Unit Delay block as a single line of code. The block state
and output are structures of type topBus
.
/* UnitDelay: '<Root>/Unit Delay' */ rtb_UnitDelay = ex_bus_tutorial_nonvirtual_c_DW.UnitDelay_DSTATE;
Simulink.BlockDiagram.addBusToVector
| Simulink.Bus.cellToObject
| Simulink.Bus.createMATLABStruct
| Simulink.Bus.createObject
| Simulink.Bus.objectToCell
| Simulink.Bus.save