In earlier versions, you had to navigate to the top level link and then perform the "Go to library block" operation. Now it is directly possible to do so for blocks within a linked block.
In previous releases, the addterms function created an extra Terminator block when terminating a block with a connected action port, for example, a Switch Case Action subsystem. The function also failed to ground the unconnected inputs of Triggered subsystems with connected trigger ports and Enabled subsystems with connected enable ports. This release fixes these problems.
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.
It was possible in certain situations for an iterator system to be incorrectly assigned a constant sample time. This would cause the system to generate incorrect results. This has been fixed in this release.
The S-function macros
ssSetInputPortReusable ssSetOutputPortReusablecontrary to what their name suggests, not only mark the ports as being reusable but also allow the ports to become local variables.
To avoid inadvertant usage that can cause bugs in S-functions, the above macros are being obsoleted.
Please update the S-functions by replacing:
ssSetIn(Out)putPortReusable(S, ip, 1)with
ssSetIn(Out)putPortOptimOpts(S, ip, SS_REUSABLE_AND_LOCAL)and replacing
ssSetIn(Out)putPortReusable(S, ip, 0with
ssSetIn(Out)putPortOptimOpts(S, ip, SS_NOT_REUSABLE_AND_GLOBAL)for the corresponding input and output ports, respectively.
In previous releases, clicking on category items, e.g., ---Solver
performance------- in the options list of the Diagnostics
pane of the Simulation Parameters dialog box (renamed the
Configuration Parameters dialog box in this release), could cause
an
error. This occurred only on non-Windows platforms. This problem has been
fixed in this release.
We now guard against redundant reqeusts to save a model.
Previous releases did not detect the condition whereby the rate at which blocks inside an enabled subsystem are enabled differs from the rate at which their outputs are updated. In this release, if this condition is detected and the multitask rate transition diagnostic is set to warning or error, Simulink displays a warning or error message, respectively.
Previous releases do not detect that the inputs to an S-function that
specifies the SS_OPTION_REQ_INPUT_SAMPLE_TIME_MATCH option
do not match in the following case: the S-function inherits its block
sample time and one of the inputs is operating at the inherited sample
time and another port is operating at a different sample time. This
release displays an error if such a condition occurs.
When Simulink data objects were originally implemented, we resolved both signal and parameter objects in the same way, which included the resolution of Simulink signal objects in mask workspaces. We now believe that this functionality is both unnecessary and potentially confusing. As a result, we now only allow signal labels to resolve to Simulink signal objects in the base (MATLAB) workspace.
Previously it was possible to see the error message:S-function should set the sample time of output port 1 of 'S-function block' to the value specified by the sample and offset time arguments of method mdlSetOutputPortSampleTime.even though the S-function always sets the sample time to the one Simulink hands it. This happened due to a bug allowing Simulink to pass the S-function an inherited sample time. This has been fixed.
The trigger port of a function-call subsystem can specifyreset states on enablefor its States when enabling parameter only if its initiator issues an explicit enable. Suppose a function-call subsystem's trigger port specifiesresetfor 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. Ifresetis specified and the s-function does not explicitly issue events, and error will be reported in Release 14.A way to correct the model is to choose
inheritorheldas 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.
In R14LCS, if one model referenced another and both had the state logging options off, it was possible to incorrectly receive an error stateing that the options did not match. This was due to one model having a hidden parameter set improperly and has been fixe din R14FCS.
Previously if a port-based sample time S-function has no input ports, it was possible to see an error message about the output port sample times being set even though all of the input port sample times had been set. Now if the output ports sample times are all unset and there are no input ports, Simulink tries to set the output port sample time instead of throwing an error.
The Pulse Generator block makes use of variable sample time in some modes. When it does so, blocks that inherit a sample time from it will inherit a continuous sample time. Because of this, a rate transition error was being incorrectly reported for a variable sample time block connected to a continuous sample time block. This has been fixed.
In previous releases, a latched Inport block could inherit a constant sample time. This caused a model to give different answers when inline parameters were turned on than when they were turned off. This release fixes the problem by not allowing an Inport block to inherit a constant sample time if the input is latched.
In previous releases, linmod and dlinmod ignored the connections between data store write and read blocks. This release fixes the problem.
In previous releases, in some cases, the MATLAB Function block's rem function would return a nonzero remainder when a zero remainder was expected. This result would occur when the rem function's divisor argument was a fraction and was an exact divisor of the numerator argument, e.g., rem(2.32, 0.02) would give 0.02 instead of 0. The incorrect result was caused by round-off error. This release fixes this problem.
Toggling the Model Browser will now affect every window in the model rather than just a single window.
Previously the input of a subsystem that was both enabled and triggered could be driven by a block with a rate different from the trigger rate. This should be a rate transition error in multitasking mode. Now this situation produces an error message.
In previous releases, changing the Integrator block's external reset parameter from 'none' to 'level' and back to 'none' in the same session does not restore the external reset parameter to 'none' as expected. This release fixes this problem.
Root level inport blocks marked with an inherited (-1) sample time could under certain circumstances get a constant sample time. This does not work correctly with specifying the input values to be loaded from workspace. The root level inport blocks will no longer be propagated with a constant sample time.
Previous releases could color S-function blocks with port-based sample times as "hybrid" even if all of the ports had the same sample time. The sample-time coloring problem has been corrected.
In previous releases, the Signal Builder block produces incorrect output when a signal has a vertical segment with repeated points at the final value. This release fixes the problem.
In previous releases of the Microsoft Windows version of Simulink, simulations suspend when M-code reaches a pause statement. In this release, simulations continue when M-code pauses.
In previous releases, setting breakpoints in the MATLAB debugger while the Simulink debugger was running would cause a syntax error. This release fixes the problem.
Specified initial state values does not take effect for discrete and continous integrator if the following conditions are satisfied 1. the discrete or continous integrator has external ic, 2. the initial state values is specified with dlinmod(...) This has been fixed in Simulink 6.0.
When logging states for amodel with the structure or structure with time format, there will now be an additional field in the signals structure called inReferencdeModel. This field is a logical indicating whether the given state is attached to a block that is inside a refereced model. If it is, then the blockName associated witht he state will beencoded to have any user entered '|' replaced by '~|' and any user entered '~' replaced by '~~' to distinguish them from the '|' that simulink adds to delimit model boundaries. Without this change it is possible to get a set of states where the blocknames wil not uniquely map back to the blocks from which they came.
The switch block can be set use one of three criteria u2 >= Threshold u2 > Threshold u2 ~= 0 If the data type of the middle input, u2, is boolean, then the block ignores the threshold and switches based on u2 >= 1, u2 > 0, or u2 ~= 0 which are all equivalent for a boolean input. When the switch block was set to criteria u > Threshold, the blocks behavior could be wrong in some cases. This would occur if zero-crossings were applicable. It could also occur if middle input was boolean, and the other ports used a common builtin data type. This error has been corrected. Also, when the data type of middle input is boolean and the threshold is effectively ignored, an clearer warning message is given.
In previous releases, clicking on signal lines caused inadvertant line branching when a context menu was expected. This release fixes the problem.
Perviously if the persistent UserData could not be loaded when loading a model the data was silently discarded. Now Simulink issues a awarning message indication that this is usually due to the directory containing the definition of the object not being on the path.