Documentation Center

  • Trial Software
  • Product Updates

Merge

Combine multiple signals into single signal

Library

Signal Routing

Description

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.

Guidelines for Using the Merge Block

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 Model Configuration Parameters > Diagnostics > Underspecified initialization detection parameter. See the last example in 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.

Merge Block Usage

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 Merge block usage in your model. For more information, see Check usage of Merge blocks.

The following schematic shows valid 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.

Each 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 a Sine Wave 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. The subsystem Subsys1 includes a Model block that references referenced_model. It includes a block that inputs to a block in the referenced model and also inputs to the Merge block that is outside of the referenced model.

The referenced model includes a signal that incorrectly branches to a Gain block and to the Out1 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 Model 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.

Initial Output Value

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, the block's initial output depends on the initialization mode and the driving blocks. In Simplified initialization mode, for an unspecified (empty matrix []) value of Initial output, the block uses the default initial value of the output data type. For information on the default initial value, see Initializing Signal Values. In Classic initialization mode, for an unspecified (empty matrix []) value of Initial output, the initial output of the block equals the most recently evaluated initial output of the driving blocks. Since the initialization ordering for these sources may vary, 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 ([])) and the model uses Classic initialization mode.

  • 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 subsystem 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 Parameters > 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

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.

Input Dimensions and Merge Offsets

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.

Combining or Reordering of Input Signals

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.

Each Enabled Subsystem contains the following blocks.

For more information on simplified initialization mode, see Underspecified initialization detection.

Conditionally-Executed Subsystem Outport Reset

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.

Merging S-Function Outputs

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.

Data Type Support

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.

Parameters and Dialog Box

Number of inputs

Specify the number of input ports to merge.

Initial output

Specify the initial value of output For more information, see Initial Output Value.

Allow unequal port widths

Select this check box to allow the block to accept inputs having different numbers of elements.

Input port offsets

Enter a vector to specify the offset of each input signal relative to the beginning of the output signal.

Bus Support

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 Specify 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 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 Combine 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.

Characteristics

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

Was this topic helpful?