By Guy Rouleau
The first time I used buses in Simulink, it was version 3.0 (R11). Bus signals and the way we use them in Simulink have evolved over time. In this post I want to give you a historical tour of how the bus has changed since R11. To start, in R11 I'm not even sure I should call it a bus. Why? Let's look at the Signal & Systems section of the R11 Simulink Library Browser:
Since that time, buses and muxes are slowly moving away from each other. To illustrate this, I went through the Archived MathWorks Documentation.
This is the oldest documentation available in the archive. The Bus Creator is now available.
A new diagnostic is introduced: Mux blocks used to create bus signals. Setting this diagnostic to error enforces what is called strict bus behavior. To help users receiving errors when enabling this diagnostic, a Model Advisor check and the function slreplace_mux is introduced.
Now the differences become more significant:
- A documentation section titled Intermixing Composite Signal Types is created.
- A new diagnostic is introduced: Bus signal treated as vector.
- A paragraph titled Avoiding Mixed Composite Signals When Developing Models states the following:
"The MathWorks discourages the use of mixed composite signals, and may cease to support them at some future time. The MathWorks therefore recommends upgrading existing models to eliminate any mixed composite signals, and permanently setting Mux blocks used to create bus signals and Bus signal treated as vector to error in all new models and all existing models that may undergo further development."
One more diagnostic is introduced to help avoiding Bus/Mux mixture: Non-bus signals treated as bus signals
Starting in R2010b, the diagnostics Mux blocks used to create bus signals is set to error by default when creating a new model. This is one more step toward the deprecation of mixed composite signals.
I cannot really predict the future, but I know that when implementing new features, Simulink developers now take into account that Mux blocks will not be used to create buses. This is why many new features require the Mux blocks used to create bus signals diagnostics being set to error. These features include for example:
- Array of buses
- Specifying Initial Conditions for Buses
- Support of bus object data type for Constant blocks
- Converting a Subsystem to a Referenced Model
- Getting information about type and hierarchy of a bus using the CompiledBusType and SignalHierarchy properties.
- Bus Support in Signal Specification block
- Simplified detection of underspecified initialization
- More robust and consistent behavior for the Discrete-Time Integrator block.
The number of features in this list increases every release, so if you don't avoid mux/bus mixture in your models, you will miss a lot of cool stuff!
The settings we recommend are:
Now it's your turn
Have you already converted to strict bus mode? If not, let us know why by posting a comment here.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.