| Simulink® Release Notes | ![]() |
Known Software and Documentation Problems
The following known problems occur in Version 6.0.
Turn the New Wrap Lines Option Off
The MATLAB Command Window has a new Wrap lines option. Many Simulink error messages are very long. This can cause some display problems. Therefore, when using Simulink, you should turn the Wrap lines option off using the Preferences setting. For more information on this issue, see the Technical Support Solution 29082 from the MathWorks Web page.
Model Referencing Problems
Model referencing has the following known problems in this release.
Logged Signals May Be Sampled at Too Fast a Rate
Simulink logs signals nested below the top level in a model reference hierarchy at the fastest rate of the top-level referenced model, regardless of the actual sample times of the logged signals. For example, suppose that model A references model B, which references model C. Further, suppose that you have specified that Simulink log signal s in model C, where the sample time of s is 0.2 seconds. Finally, suppose that signals in model B run at either a 0.1- or 0.2-second sample time. In this case, Simulink logs model B's signals at the correct rates but it logs s at a sample time of 0.1 seconds, although s changes every 0.2 seconds. A workaround for this problem is to specify decimation factors for signals that are logged too frequently. For example, in the case of s, a decimation factor of 2 would result in s being logged only at the correct sample times.
Viewed Signals May Be Sampled at Too Fast a Rate
A Scope viewer (created with the Signal & Scope Manager) in a top model displaying signals in a referenced model executes at a rate that is equal to or faster than the sample rate of the top-level Model block that directly or indirectly references the model containing the signal being displayed. This rate may be faster than the actual rate of the signal being displayed. A workaround for this problem is to specify a decimation factor in the Scope viewer.
Referenced Model Names Case-Insensitive on Unix
On Unix, when building targets for referenced models, Simulink does not distinguish between models whose names differ only in case. This can lead to unpredictable simulation results if the MATLAB path contains models whose names differ only in case. The workaround is to ensure that this condition does not occur when updating or simulating a model containing model references.
Inconsistent Signal Logging Tunability
You can tune the decimation and max points properties of a signal in a referenced model, using MATLAB variables, only if the referenced model is open. If the referenced model is closed, the values of those properties are the values of the MATLAB variables that specify them when the model was last saved. To avoid this difference in behavior between when the referenced model is closed and when it is opened, you should not use MATLAB variables to tune the decimation and max points properties of signals in referenced models.
Project Directories Are Not Compatible Between Releases
Model referencing project directories (slprj) are not compatible between releases. If you try to update or simulate a model that references models for which there is a slprj directory from a previous release, Simulink displays a dialog that gives you the choice of removing the old project directory and continuing or aborting the model update or simulation.
Embedded MATLAB Function Block
The Embedded Matlab Function block has the following known problems in this release.
Local and Constant Scope Disabled
The Model Explorer lets you assign a scope of Local or Constant to Embedded MATLAB Function block variables. However, you cannot simulate or generate Real-Time Workshop code from models that assign these scopes to such variables. Attempting to do so results in an error. Future versions of Simulink will not allow you to assign these scopes to Embedded MATLAB Function block variables.
Embedded MATLAB Function Block Stateflow Dependencies
The new Embedded MATLAB Function block uses the same code-generation infrastructure as Stateflow for simulation and debugging. The Simulink user interface reflects this dependency in the following ways.
The dependency of the Embedded MATLAB Function block on the Stateflow code-generation infrastructure has significant ramifications for Stateflow and Real-Time Workshop users as well. See "Embedded MATLAB Function Block Stateflow Dependencies" in the Stateflow release notes for details.
Block Positions Limited to Less Than 32768
Block positions have been restricted to be less than 32768. You can probably only reach this limit by using ADD_BLOCK to automatically generate extremely large models. Workarounds include shrinking the size of your blocks, or rearranging the blocks to fit the available space.
Cannot Modify Instantiated Class
The Simulink Data Class Designer prevents you from modifying classes if they have already been instantiated during the current MATLAB session.
Blocksets Menu Sometimes Fails to Appear
The Blocksets menu sometimes fails to appear when selected from the model window's Help menu. If this happens, click anywhere in the model window and then select Blocksets from the Help menu.
PostSaveFcn Cannot Find Model on First Save
The first time you save a new model that has PostSaveFcn functions, the PostSaveFcn functions cannot find the model.
Saturation Block's Output Differs on Different Platforms
On Linux, the Saturation block outputs NaN if its input is NaN; on Windows, the block outputs its lower limit if its input is NaN.
Limitation on Discretizing Models in the S Domain
When discretizing a model in the S domain, you cannot specify a sample time of 0 if the model contains a Transfer Function, State Space, or Zero Pole block. If you do specify a sample time of 0 during the discretization process, Simulink signals an error.
Finder, Debugger Help Buttons Broken
Clicking the Help button on the dialog boxes of the Finder and Simulink Debugger causes the Help Browser to display a "documentation not found" message. However, the documentation for both dialog boxes exists.
Changing a Subsystem Port Number Can Corrupt a Model
In this release as in previous releases, changing the number of an input or output port number in a subsystem can cause an extra port to be added to the subsystem block in the parent system.
| Change in Sample Time Behavior of Unary Minus Block | Simulink 5.1 Release Notes | ![]() |
© 1994-2005 The MathWorks, Inc.