|
|
|
| R2012a Documentation → Simulink | |
Learn more about Simulink |
|
| Contents | Index |
Signal Routing
The Merge block combines its inputs into a single output line whose value at any time is equal to the most recently computed output of its driving blocks. You can specify any number of inputs by setting the block's Number of inputs parameter.
Use Merge blocks only to interleave input signals that update at different times into a combined signal in which the interleaved values retain their separate identities and times. To combine signals that update at the same time into an array or matrix signal, use a Concatenate block.
Merge blocks assume that all driving signals share the same signal memory. The shared signal memory should be accessed only in mutually exclusive fashion. Therefore, always use alternately executing subsystems to drive Merge blocks. See Creating Alternately Executing Subsystems for an example.
All signals that connect to a Merge block, or exist anywhere in a network of Merge blocks, are functionally the same signal, and are therefore subject to the restriction that a given signal can have at most one associated signal object. See Simulink.Signal for more information.
When you use the Merge block, follow these guidelines:
Always use conditionally-executed subsystems to drive Merge blocks.
Write your control logic to ensure that at most one of the driving conditionally-executed subsystems executes at any time step.
Do not connect more than one input of a Merge block to the same conditionally-executed subsystem.
Always connect a Merge block to at least two input signals.
Ensure that all input signals have the same sample time.
Always set the Initial output parameter of the Merge block, unless the output port of the Merge block connects to another Merge block.
Do not branch a signal that inputs to a Merge block, if you use the default setting of Classic for the Configuration Parameters > Diagnostics > Underspecified initialization detection parameter. See the last example in Proper Merge Block Usage for additional usage guidelines relating to branched signals.
For all conditionally-executed subsystem Outport blocks that drive Merge blocks, set the Output when disabled parameter to held.
For each input of a Merge block, the topmost non-atomic and nonvirtual source must be a conditionally-executed subsystem that is not an Iterator Subsystem.
You can use the Model Advisor to check for proper Merge block usage in your model. For more information, see Check for proper Merge block usage.
The following schematic shows proper Merge block usage, merging signals from two conditionally-executed subsystems.
The following example is also a valid Merge block usage, where the topmost nonatomic, nonvirtual source is a conditionally executed subsystem.
The Atomic Subsystem block contains an enabled subsystem.
You can also use multiple Merge blocks at different levels of the model hierarchy. The following example contains a Merge block at the model root.
A Merge block is also located inside the Enabled Subsystem block, one level down.
A Merge block cannot connect to a Sine Wave block because that source block is not a conditionally-executed subsystem.
A Merge block cannot connect to a For Iterator Subsystem.
A Merge block cannot connect to a branched signal.
In the following model, the referenced model has a signal that branches. It inputs to a block in the referenced model and also inputs to the Merge block that is outside of the referenced model.
Although the top-level model appears that it would work, the Subsys1 subsystem includes a Model block that references referenced_model.
The referenced model includes a signal that incorrectly branches to a Gain block and to the Out2 Outport block, which connects to the Merge block that is outside of the referenced model.
The following example also shows a branched signal in a subsystem that connects to a Merge block, which is not allowed if you use the default setting of Classic for the Configuration Parameters > Diagnostics > Underspecified initialization detection parameter.
If you set the Underspecified initialization detection parameter to Simplified, then the following example does not generate an error. For more information on simplified initialization mode, see Underspecified initialization detection.
You can specify an initial output value for the Merge block by setting the Initial output parameter. If you do not specify an initial output value and one or more of the driving blocks do, the initial output of the Merge block equals the most recently evaluated initial output of the driving blocks.
When two or more sources initialize the same Merge block, the initialization ordering for these sources may vary. If you leave the initial output unspecified, initialization may be inconsistent for the simulation and the code generation of a model. For example, the following model can produce inconsistent initialization:
The model contains a Merge block with two inputs: one driven by a Stateflow chart and the other driven by a conditionally executed subsystem (such as an Enabled Subsystem).
The Merge block Initial output parameter is unspecified (that is, specified as empty matrix ([])).
The Stateflow chart initializes the output being merged to val1.
The conditionally executed subsystem initializes the output being merged to different value val2.
Both the Stateflow chart and the conditionally executed susystem do not execute at the first time step.
Because the initialization ordering may vary, the output of the Merge block at the first time step is val1 if the Stateflow chart initializes last and val2 if the conditionally executed subsystem initializes last. The initialization ordering is different for simulation and code generation.
To address this issue, use one of the following approaches:
Set the Initial output parameter of the Merge block, unless the output port of the Merge block connects to another Merge block.
Turn on simplified initialization mode: set the Model Configuration > Diagnostics > Data Validity > Underspecified initialization detection parameter to Simplified.
To use the Simplified initialization setting, specify the Initial output value for all root Merge blocks. A root Merge block is any Merge block with an output port that does not connect to another Merge block.
To upgrade your model to simplified initialization mode, use the Model Advisor Check consistency of initialization parameters for Outport and Merge blocks check.
For more information on simplified initialization mode, see Underspecified initialization detection.
Single-input merge is not supported. Each Merge block must have at least two inputs.
Use Merge blocks only for signals that require merging. If you were previously connecting a Merge block input to a Mux block, use a multi-input Merge block instead.
The Merge block accepts only inputs of equal dimensions and outputs a signal of the same dimensions as the inputs, unless you select the Allow unequal port widths parameter.
If you select Allow unequal port widths, the block accepts scalars and vectors (but not matrices) having differing numbers of elements. Further, the block allows you to specify an offset for each input signal relative to the beginning of the output signal. The width of the output signal is
max(w1+o1, w2+o2, ... wn+on)
where w1, ... wn are the widths of the input signals and o1, ... on are the offsets for the input signals.
Suppose that you have the following block diagram:
The Merge block has the following output width:
max(2+0,2+1)=3
In this example, the offset of v1 is 0 and the offset of v2 is 1. The Merge block maps the elements of v1 to the first two elements of v3 and the elements of v2 to the last two elements of v3. Only the second element of v3 is effectively merged, as shown in the scope output:
If you use Simplified Initialization Mode, you must clear the Allow unequal port widths check box. The input port offsets for all input signals must be zero.
Consider using Merge blocks only for signal elements that require true merging. Other elements can be combined with merged elements using the Concatenate block, as shown in the following example.
For more information on simplified initialization mode, see Underspecified initialization detection.
A Merge block does not accept input signals whose elements have been reordered or partially selected. In addition, you should not connect input signals to the Merge block that have been combined outside of a conditionally-executed subsystem.
For example, in the following block diagram, the Merge block does not accept the output of the first Selector block because the Selector block interchanges the first and last elements of the vector signal. Similarly, the Merge block does not accept the output of the second Selector block because the Selector block selects only the first three elements.
If you use simplified initialization mode, the following arrangement is not allowed because two signals are being combined outside of a conditionally-executed subsystem.
You can, however, combine or reorder Merge block input signals within a conditionally-executed subsystem. For example, the following model is valid.
The Enabled Subsystem contains the following blocks.
For more information on simplified initialization mode, see Underspecified initialization detection.
The Outports of conditionally-executed subsystems being merged should not reset when disabled. This action can cause multiple subsystems to update the Merge block at the same time. Specifically, the disabled subsystem updates the Merge block by resetting its output, while the enabled subsystem updates the Merge block by computing its output.
To prevent this behavior, set the Outport block parameter Output when disabled to held for each conditionally-executed subsystem being merged.
Note If you are using Simplified Initialization Mode, you must set the Outport block parameter Output when disabled to held. |
Instead of resetting the subsystem output when it is disabled, add an additional subsystem for the default case, and use control logic to run this subsystem if nothing else runs. For example, see the following block layout:
For more information on simplified initialization mode, see Underspecified initialization detection.
The Merge block can merge a signal from an S-Function block only if the memory used to store the S-Function block's output is reusable. Simulink software displays an error message if you attempt to update or simulate a model that connects a nonreusable port of an S-Function block to a Merge block. See ssSetOutputPortOptimOpts for more information.
The Merge block accepts real or complex signals of any data type that Simulink supports, including fixed-point and enumerated data types. All inputs must be of the same data type and numeric type.
For more information, see Data Types Supported by Simulink in the Simulink documentation.
Specify the number of input ports to merge.
Specify the initial value of output. If unspecified, the initial output equals the initial output, if any, of one of the driving blocks. You cannot set the initial output of this block to inf or NaN.
Select this check box to allow the block to accept inputs having different numbers of elements.
Enter a vector to specify the offset of each input signal relative to the beginning of the output signal.
The Merge block is a bus-capable block. The inputs can be virtual or nonvirtual bus signals subject to the following restrictions:
The number of inputs must be greater than one.
Initial output must be zero, a nonzero scalar, or a finite numeric structure.
Allow unequal port widths must be disabled.
All inputs to the merge must be buses and must be equivalent (same hierarchy with identical names and attributes for all elements).
For information about specifying an initial condition structure, see Specifying Initial Conditions for Bus Signals.
All signals in a nonvirtual bus input to a Merge block must have the same sample time, even if the elements of the associated bus object specify inherited sample times. You can use a Rate Transition block to change the sample time of an individual signal, or of all signals in a bus. See Using Composite Signals and Bus-Capable Blocks for more information.
You can use an array of buses as an input signal to a Merge block. For details about defining and using an array of buses, see Combining Buses into an Array of Buses. Using an array of buses with a Merge block involves these limitations:
Allow unequal port widths — Clear this parameter.
Number of inputs — Set to a value of 2 or greater.
Initial condition — Only this parameter (which might be, but does not have to be, a structure) is scalar-expanded to match the dimensions of the array of buses.
Bus-capable | Yes, with restrictions as noted above |
Direct Feedthrough | Yes |
Sample Time | Inherited from the driving block |
Scalar Expansion | No |
Dimensionalized | Yes |
Multidimensionalized | Yes |
Zero-Crossing Detection | No |
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 |
