| Simulink® Release Notes | |
Model API Can Return an Incorrect Initial State Vector
In this release, Simulink's simulation commands can return an incorrect initial state if the model contains integrator blocks that have external initial condition ports and the model does not use either Constant or IC blocks to specify the initial conditions at these ports. To extract the correct state vector:
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.
Logging Signals as Specified By Model May Not Work for Library Signals
The Log signals as specified by the referenced model option on the Model Reference Signal Logging dialog box may not log signals that are defined and enabled for logging in a library used by the referenced model. To avoid this problem, uncheck the Log signals as specified by the referenced model option and use the Model Reference Signal Logging dialog box to specify all signals that you want to be logged, including signals defined in libraries referenced by the model.
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. If you select the first option, Simulink removes the old project directory. However, it does not delete any old simulation targets that exist in the current working directory. You should remove these old targets yourself to ensure that they do not get used by the current release. The targets have the form modelname_msf.mexext, where modelname is the actual name of the model from which the target was generated and mexext is the target file's platform-dependent extension (e.g., dll on Windows).
Model Reference SIM target may fail to compile
If a referenced model contains a triggered subsystem with a constant sample time and also has a continuous sample time, the model reference code may fail to compile. The compiler errors out because of a missing clockTick0 element in a structure.
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.
Cannot Selectively Disable Debugging for Embedded MATLAB Function Blocks
This release allows you to enable or disable debugging for all Embedded Matlab Function blocks in a model. You cannot selectively enable or disable debugging for some blocks.
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 editor'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 Fcn, State-Space, or Zero-Pole block. If you do specify a sample time of 0 during the discretization process, Simulink signals an error.
| | Known Software and Documentation Problems | Simulink 6.0 Release Notes | |
© 1994-2005 The MathWorks, Inc.