|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
| On this page… |
|---|
A composite signal is a signal that is composed of other signals. The constituent signals originate separately and join to form the composite signal. They can then be extracted from the composite signal downstream and used as if they had never been joined. Composite signals can reduce visual complexity in models by grouping signals that run in parallel over some or all of their courses, and can serve various other purposes.
A Simulink composite signal is called a bus signal, or just a bus. A Simulink bus is analogous to a bundle of wires held together by tie wraps. Simulink implements a bus as a name-based hierarchical structure. A Simulink bus should not be confused with a hardware bus, like the bus in the backplane of many computers. It is more like a programmatic structure defined in a language like C.
The signals that constitute a bus are called elements. The constituent signals retain their separate identities within the bus and can be of any type or types, including other buses nested to any level. The elements of a bus can be any of the following:
Mixed data type signals (e.g. double, integer, fixed point)
Mixture of scalar and vector elements
Buses as elements
N-D signals
Mixture of Real and Complex signals
Some requirements and limitations apply when you connect buses to blocks or to nonvirtual subsystems. See Bus-Capable Blocks, Connecting Buses to Inports and Outports, and Composite Signal Limitations for more information.
A bus can be either virtual or nonvirtual. Both virtual and nonvirtual buses provide the same visual simplification, but their implementations are different.
Virtual buses exist only graphically. They have no functional effects and do not appear in generated code; only the constituent signals appear. See Virtual Signals for details. Simulink implements virtual buses with pointers, so virtual buses add no data copying overhead and do not affect performance.
Nonvirtual buses may have functional effects. They appear as structures in generated code, which can simplify the code and clarify its correspondence with the model. Simulink implements nonvirtual buses by copying data from the source signals to the bus, which can affect performance.
The two types of buses are interchangeable for many purposes, but some situations require a nonvirtual bus. See Virtual and Nonvirtual Buses for more information.
To view information about buses, use one of the following approaches:
Use the Signal Hierarchy Viewer to interactively display bus hierarchy (for bus signals)
From the MATLAB command line, display the type and hierarchy of a bus signal in a compiled model. For details, see CompiledBusType and SignalHierarchy Parameters.
Use the Signal Hierarchy Viewer to interactively display information about a signal. For a bus signal, the Signal Hierarchy Viewer displays the bus hierarchy.
Right-click a signal line.
Select the Signal Hierarchy option. The Signal Hierarchy Viewer dialog box appears.
For example, open the busdemo demo.
Right-click the main_bus signal (output signal for the Bus Creator block), and select Signal Hierarchy. The following information appears:
Each Signal Hierarchy Viewer is associated with a specific model. If you edit a model while the associated Signal Hierarchy Viewer is open, the Signal Hierarchy Viewer reflects those updates.
You can also open the Signal Hierarchy Viewer in the Simulink Model Editor.
Select View > Signal Hierarchy.
Select a signal
To filter the displayed signals, click the Options button
on the right-hand side of the Filter by name edit
box (
).
To use MATLAB regular expressions for filtering signal names, select Enable regular expression. For example, entering r$ in the Filter by name edit box displays all signals whose names end with a lowercase r (and their immediate parents). For details, see Regular Expressions.
To use a flat list format to display the list of filtered signals, based on the search text in the Filter by name edit box, select Show filtered results as a flat list. The flat list format uses dot notation to reflect the hierarchy of bus signals. The following is an example of a flat list format for a filtered set of nested bus signals.
To get information about the type and hierarchy of a bus signal in a compiled model, use these parameters with the get_param command:
CompiledBusType — For a compiled model, returns information about whether the signal connected to a port is a bus, and if so, whether the signal is a virtual or nonvirtual bus.
SignalHierarchy — If the signal is a bus, returns the name and hierarchy of the signals in the bus.
Before you use these commands:
In the Configuration Parameters > Diagnostics > Connectivity pane, set the Mux blocks used to create bus signals diagnostic to error.
Update the diagram or simulate the model.
For example, if you open and simulate the busdemo demo, the model looks as shown below:
The following code illustrates how you can use the SignalHierarchy and CompiledBusType parameters:
mdl = 'busdemo'; open_system(mdl) % Obtain the handle a port ph = get_param([mdl '/Bus Creator'], 'PortHandles'); % SignalHierarchy is available at edit time sh = get_param(ph.Outport, 'SignalHierarchy') % Compile the model busdemo([],[],[],'compile'); bt = get_param(ph.Outport, 'CompiledBusType') % Terminate the model busdemo([],[],[],'term');
If all signals in a bus are the same type, you may be able to use a contiguous vector or a virtual vector (mux) instead of a bus. For more information, see Mux Signals. In some cases, muxes and virtual buses can be treated interchangeably; implicit type conversion occurs when needed.
Do not mix muxes and buses in new applications.
One way that such a mux/bus mixture occurs is when you use a Mux block to create a virtual bus, such as a Mux block that outputs to a Bus Selector. This kind of mixture does not support strong type checking and increases the likelihood of run-time errors. MathWorks discourages treating muxes and buses interchangeably. Mux/bus mixtures may become unsupported in the future. Simulink generates a warning for this kind of mux/bus mixture when you load a model created in a release prior to R2010a. For new models, Simulink generates an error. Do not create such mux/bus mixtures in new applications, and consider upgrading existing applications to avoid such mixtures. The Configuration Parameters > Diagnostics > Connectivity pane provides diagnostics that report cases where muxes and virtual buses are used interchangeably, and includes capabilities that you can use to upgrade a model to eliminate such mixtures. See Avoiding Mux/Bus Mixtures for details.
Another way for a mux/bus mixture to occur is when a virtual bus signal is treated as a mux, such as a bus signal that inputs directly to a Gain block. To detect such mixtures, in the Configuration Parameters > Diagnostics > Connectivity pane, set the Bus signal treated as vector diagnostic to warning or error.
A bus can have an associated bus object, which can both provide and validate bus properties. A bus object is an instance of class Simulink.Bus that is defined in the base workspace. The object defines the structure of the bus and the properties of its elements, such as nesting, data type, and size. Bus objects are optional for virtual buses and required for nonvirtual buses. See Using Bus Objects for more information. You can create bus objects programmatically or by using the Simulink Bus Editor, which facilitates bus object creation and management. See Using the Bus Editor for more information.
The various techniques for defining buses are essentially equivalent for simulation, but the techniques used can make a significant difference in the efficiency, size, and readability of generated code. If you intend to generate production code for a model that uses buses, see Buses for information about the best techniques to use.
 | Using Composite Signals | Creating and Accessing a Bus |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
