| Simulink® Release Notes | ![]() |
Known Software and Documentation Problems
The following known problems occur in Version 6.1.
Some Bus Features May Not Work With Mux Buses
Some bus features introduced in the previous release (Simulink 6.0), specifically bus objects and bus-capable blocks, may not work correctly in this release with buses, i.e., composite signals of mixed element types or dimensionality, created by Mux blocks. You can avoid this problem by using Bus Creator blocks exclusively to create buses in your models. This release provides the following tools to facilitate conversion of existing models to use Bus Creator blocks exclusively.
Strict Bus Diagnostic
This diagnostic detects use of Mux blocks to create buses. The diagnostic considers a signal created by a Mux block to be a bus if the signal meets either or both of the following conditions:
In this release, you must use the following MATLAB command to enable or disable the diagnostic:
where model is the name of the model and diagnostic_action specifies the action that the diagnostic takes when you update or simulate a model:
This option enforces the following "strict bus" behavior during model editing, updating, and simulation:
If this option detects a Mux block that violates strict bus behavior while updating or simulating the model, it halts the model update or simulation and displays a message in the Simulink Diagnostic Viewer. The message identifies the offending Mux block.
This option does not enforce strict bus behavior. However, if it detects a Mux block that creates a bus during model update or simulation, it displays a message in the MATLAB Command Window that identifies the offending block. It does this for the first ten Mux blocks that it encounters that violate strict bus behavior.
Disables checking for Mux blocks used to create buses. This is the default setting for this diagnostic.
If the Real-Time Workshop is installed on your system, you can use its Model Advisor to check for Mux blocks used to create buses as follows:
It the Model Advisor displays a list of Mux blocks, replace the Mux blocks with Bus Creator blocks and repeat the previous procedure. Otherwise, set the StrictBusMsg diagnostic to ErrorLevel1 and recompile your model.
Using the Diagnostic to Find Mux Blocks That Create Buses
Because it does not stop when it detects a problematic block, the Warning option can allow you to identify as many as ten Mux blocks that create buses simply by updating your model. You can then replace the Mux blocks identified by the warning messages with Bus Creator blocks. If the diagnostic detects ten such blocks, you should replace the blocks and then update the model. Repeat this process until you have found and replaced all Mux blocks that create buses. A script for automating this process, slreplace_mux, is available from the MathWorks tech support Web site.
The Warning option, and therefore the slreplace_mux script, may in rare cases not detect problematic blocks.The ErrorLevel1 option, however, detects all cases that violate strict bus behavior. Therefore, to ensure that you have removed all problematic Mux blocks. you should, after manually replacing blocks detected by the Warning option or after running the slreplace_mux script, switch to the ErrorLevel1 option and update your model. You may get an error in the following format:
Selected signal 'busName.signal' in 'ModelName/Bus Selector' is not part of the bus entering the Bus Selector.
This indicates that the bus is created by a Mux block. You should then identify the Mux block and replace it by a Bus Creator block. Repeat this process until no more errors of this type occur.
Misleading Bus Sample Time Mismatch Error
In this release, Simulink can report a bus sample time mismatch error message of the following form:
The input bus to block 'blockA' does not match the bus specified by the bus object 'BusObject' on the block dialog. The following errors were detected : --> Bus element 'e1' of bus object 'BusObject' is specified to be of sample time [periodE1 offsetE1], but the incoming signal is of sample time [periodS offsetS]. --> Bus element 'e2' of bus object 'BusObject' is specified to be of sample time [periodE2 offsetE2],but the incoming signal is of sample time [periodS offsetS]. --> Bus element 'e3' of bus object 'BusObject' is specified to be of sample time [periodE3 offsetE3], but the incoming signal is of sample time [periodS offsetS].
where the bold elements represent variable parts of the message that depend on the block, the bus, and the sample times involved.
This message may not indicate the actual cause of the problem. It can occur if the block specified in the message changes the bus elements' sample times, e.,g., the block is a Rate Transition or Unit Delay block, and the bus's bus object does not specify the sample times as inherited (- 1). If this message occurs and the bus passes through a block that changes its sample times, check the element sample times specified by the bus's bus object to ensure that they are set to inherited (-1).
Issue with SHIFT_JIS Characters on Non-Japanese Systems
On systems for which SHIFT_JIS is not the default character set, e.g., Windows configured for the English language, Simulink may not be able to load or save models containing SHIFT_JIS characters or may misinterpret the characters. Saving a model in such cases can corrupt the Japanese text that it contains. This problem does not occur on Windows configured for the Japanese language or other host systems configured to use the SHIFT_JIS character set by default.
Cannot Drag Multiple Objects From Search Panel
You cannot use drag-and-drop to move multiple objects from the Model Explorer's Search Results pane to another location. You can, however, use drag-and-drop to move a single object.
Function-Call Subsystem Enabling Issue
The trigger port of a Function-Call Subsystem can specify reset states on enable for its States when enabling parameter only if its initiator issues an explicit enable. Suppose a function-call subsystem's trigger port specifies reset for its States when enabling parameter. That setting is only guaranteed to be honored if the S-function serving as the initiator of the function-call subsystem explicitly issues enable and disable events. If reset is specified and the S-function does not explicitly issue events, this release reports an error.
A way to correct the model is to choose inherit or held as the setting of the trigger port's States when enabling parameter. Another way is to update the S-function as described in the documentation. Function Call Generator and Stateflow blocks do explicitly issue events, so this note does not apply to them.
| Major Bug Fixes | Model API Can Return an Incorrect Initial State Vector | ![]() |
© 1994-2005 The MathWorks, Inc.