I have a model in which I use a Switch block to switch between two bus signals. The two bus signals feeding into the Switch block are generated by atomic subsystems upstream of the Switch block. I stepped through the model execution and I observed that both atomic subsystems are executed at every time step irrespective of which bus signal is passed through by the Switch block. This is not the case if the signals feeding into the Switch block are non-bus signals.
MATLAB: Do subsystems feeding bus signals into a Switch block not execute conditionally
busbussesconditionsimulink
Related Solutions
This enhancement has been incorporated in Release 2008b (R2008b). For previous product releases, read below for any possible workarounds:
The main difference between mux signals and bus signals is that the components of a bus signal can include more than one data type and can be hierarchical, while the components of a mux signal must all have the same data type and cannot be hierarchical. The documentation of Composite Signals explains this distinction:
<http://www.mathworks.com/help/releases/R2012b/simulink/composite-signals.html>Buses can provide consistency checking with the use of a Bus Object, but muxes cannot. Please refer the following for more information:
<http://www.mathworks.com/help/releases/R2012b/simulink/ug/using-bus-objects.html>Buses can be realized as structures in generated code, but muxes cannot. See:
<http://www.mathworks.com/help/releases/R2012b/simulink/slref/buscreator.html>MathWorks strongly discourages mixing muxes and buses. For example, do not use Mux blocks as Bus Creators. See:
<http://www.mathworks.com/help/releases/R2013a/simulink/ug/avoiding-mux-bus-mixtures.html>The Demux block has a Bus Selector mode. For information about when to use this mode, see:
<http://www.mathworks.com/help/releases/R2012b/simulink/slref/demux.html>Using a Bus Selector block, you can change the order of signals. This cannot be done with a Demux block. An example is attached to this solution (bus_mux_vec.mdl). In bus_mux_vec.mdl model, the order of the two input signals going through the Bus Creator and the Bus Selector blocks has been changed. After running the model, you will see [1 2 3 4] in Scope1, not [5 6 7 8]. However, the order of the two input signals going through the Mux and Demux blocks cannot be changed, so you will always see [5 6 7 8] in Scope1. For more information on how to change the order of signals using a Bus Selector block, see:
<http://www.mathworks.com/help/releases/R2012b/simulink/slref/busselector.html>Although the Demux block cannot rearrange the order of muxed signals, the Signal Selector block can. See:
<http://www.mathworks.com/help/releases/R2012b/simulink/slref/selector.html>Bus signals that are hierarchical or include components of different data types can drive only Bus Capable blocks. See:
<http://www.mathworks.com/help/releases/R2012b/simulink/ug/bus-capable-blocks.html>This limitation does not apply to a mux signal as long as the Mux block inputs are vectors or vector-like. A vector-like signal is any signal that is a scalar (one-element vector), a vector, or a single-column or single-row matrix. For example, a muxed signal can drive a Gain block, while a bus cannot. See:
<http://www.mathworks.com/help/releases/R2012b/simulink/slref/mux.html>For a list of Simulink virtual and conditionally virtual buses, see:
<http://www.mathworks.com/help/releases/R2012b/simulink/ug/virtual-and-nonvirtual-buses.html>The Bus Selector block supports matrix inputs. The Demux block does not support matrix inputs unless you double click on the Demux block and check "Bus selection mode". Run the attached model, bus_mux_matrix.mdl. It should work correctly. However, if you double click on the Demux block, uncheck "Bus selection mode" and run the model, it will generate an error.
The Bus Selector block has an option labeled 'muxed output'. This option is mislabeled: the output is a Bus and should be treated as such. Refer to the Related Solution for more information on this feature.
The problem is that adding blocks to your model (such as the XY Graph) causes the sorted order of all the blocks to change. Since there are no clear data dependencies in an algebraic system like this (which Simulink normally can use to provide a consistent sorted order), adding blocks can cause seemingly random changes. There is nothing special about the XY Block in particular, you will get the same issue if you add a display block to both the X and Y signals for example.
I believe the problem with changing the sorted order is that depending on which blocks are executing first, Simulink will automatically select an initial guess for that block's output. If that guess happens to be poor, the solution will diverge and you get no answer. If that guess is reasonable then it will converge on a solution.
When you want to force Simulink to solve an algebraic equation, a good approach is to use the Algebraic Constraint block. This allows you to explicitly specify an initial guess for one of the parameters and have a more consistent result. For example, here is a revision of your model using the Algebraic Constraint block with X as the algebraic state:
Related Question
- Is it possible to use a Multiport Switch to select between several buses in Simulink 6.1 (R14SP1)
- Do I obtain unexpected results from the output of a merge block when using Simulink
- Can you explain the different dialog options and behavior of the MERGE and the OUTPORT blocks when used together
- Does Real-Time Workshop 6.0 (R14) include an extra copy of bus signals in a model’s generated code
- Does passing busses through a Switch block generate an error in Simulink 6.0 (R14)
- How to have a Bus Selector block accept signal from an Inport block in a subsystem in Simulink
- Does an error occur when I update a diagram that uses bus objects and Configurable Subsystems in Simulink 6.1 (R14SP1)
- Does the Discrete Events Subsystem update at an incorrect rate when I have a Mux or Bus input in SimEvents 3.0 (R2009b)
Best Answer