Thetanoperator used to returnNan+iNanfor large complex input liketan(1000i). Nowtan(1000i)returns the correct answer,i.
Axes text objects are now visible on the Mac.
uint8(2 - i) used to return a complex result with zero imaginary part.
Now a real result is returned.
The fwrite function can now save uint64 and int64 values.
Previously it worked only
on DEC Alpha; now it works on all supported MATLAB platforms.
In Release 13, sorting a sparse row vector or sorting a sparse matrix along its rows, using the command sort(S,2), resulted in a segmentation violation. This has been fixed in this release.
Theverfunction ignores the case of arguments supplied to it. That is,ver signalandver Signalboth display version information for the Signal Processing Toolbox.
In previous releases, there was an inefficiency where sometimes block outputs were incorrectly defined as global rather than local. The code ran slower than necessary, but there were no inaccuracies or noticeable flaws as a result. This did not occur every time; it was dependent on the previous state of an internal register.
This issue is fixed, resulting in faster code in cases that were previously problematic.
In Version 5.x, the code generated for a Logic block with a single
vectorized input could needlessly occupy a superfluous for
loop. This caused redundant (but still correct) computations. This problem
has been fixed.
In Version 5.x, code generation can fail under certain conditions for the Relational Operator and MinMax blocks when expression folding is enabled and input to the Relational Operator block comes from a MinMax block. This has been fixed.
In Version 5.0, some models that contained Data Store Memory blocks could generate code that would not compile. This problem has been fixed.
In certain block configurations, code generation and acceleration failed when wide state signals were emitted to a block. This could happen, for example, when an exported state port from an Integrator block fed into a Relay block. This was a regression in Version 5.0 and has been fixed.
Previously, an error occurred when expression folding was on and code was generated from a model that contained a block whose output was connected to a subsystem input. This problem only occurred for blocks that had expression folding switched off in their TLC file, as was the case for the Delay and Data Store Read blocks. This problem has been fixed.
In Version 5.x, a bug caused code generation to abort for models with custom data type blocks with constant sample times. The error occurred when the Inline parameters checkbox was selected. This has been fixed.
When a block with discrete states, such as a Unit Delay block, was placed in a For or While Iterator Subsytem, the Initial Conditions of the states were not being set when the subsystem was called, in code generated by Real-Time Workshop. This is fixed.
In Version 5.0, the Include system hierarchy numbers in Identifier option in the General code appearance options pane was having no effect on code appearance. This has been fixed, so that when the option is checked, identifiers include system hierarchy numbers.
In prior releases the Merge block generated an inacessible local system output where when its source blocks are in different functions. To resolve this issue buffer allocation is now called recursively when Merge block input signals cross system boundaries.
In earlier releases, under certain conditions a Multiport switch with a scalar control port input and wide vector data inputs would cause code generation to fail. This is fixed.
In Version 5.0, it was possible for the names of the function-call arguments of reusable subsystems to clash with one another, as well as with global identifiers. Real-Time Workshop now ensures the names of the arguments are unique with respect to one another and do not duplicate global identifiers.
When generating an S-Function target for a model or a subsystem, prior versions of Real-Time Workshop truncated any sample times used in inports to 8 digits of accuracy. In Version 6 this limitation is removed, as the code now uses full double precision on inport sample times.
In Version 5.x, if a TLC directory's pathname includes a space, Real-Time
Workshop code generation can fail due to -I flags being
parsed incorrectly. This problem has been fixed.
As part of our effort to unify our handling of floating-point and fixed- point modeling, the way in which parameter data types are handled has been modified:
- All tunable parameters with unspecified data type (i.e., data type is
double) will now be treated as “context-sensitive”. That is, the data type used for these parameters will be determined by their usage in the model.- All tunable parameters that have a non-double data type will be declared using the specified data type, and a run-time type cast will be added in the generated code as necessary.
- All inlined parameters (not tunable) will be treated as “context- sensitive” (no change).
Backwards Compatibility: It is possible that this change may create backwards compatibility problems, although we are not expecting these to be very frequent or significant.
The most likely problem case is where a tunable
doubleparameter is used in a number of different "contexts" throughout a model. This is not permitted and an error message will be issued. However, it is worth noting that if this case were supported it would always result in the downcasting of parameters; the recommended solution would be for users to specify the parameter's data type to be something other thandoublein these cases regardless of this change.
Failures occurred in ASAP2 file generation when custom storage classes were used in the model. This problem has been fixed.
Code generation failures occurred for models containing masked
subsystems with fixed-point parameters having either a custom storage
class, or any storage class other than Auto. Such failures
occurred when generating the parameter tuning API (see "C API for
Parameter Tuning" in the Real-Time Workshop documentation). This problem
has been fixed.
When MAT-file logging is enabled, static data structures are declared and used to log data. Static data is incompatible with the 'Generate reusable code' option, because that option implies that the generated code must be reentrant. Therefore, the ERT options 'MAT-file logging' and 'Generate reusable code' are no longer permitted to be selected simultaneously. If both options are selected, a diagnostic or error action is taken. The action taken (none/warning/error) is determined by the 'Reusable code error diagnostic' option.
Starting in Release 12.1, generation of S-functions with the ERT target could fail for models containing parameters with Custom storage class. This problem has been fixed.
Previously, if a block connected to an input of a Merge block inport is reduced (e.g., removed by Block Reduction optimization), a segmentation fault occurred during code generation. To fix this problem, blocks connected to the inputs of Merge blocks are no longer reduced.
Code generation could fail when generating code from a subsystem if any of the subsystem's inputs or outputs were if fixed point data type and the signal name referenced a Simulink.Signal object with non-auto storage class. This problem has been fixed.
Some block outputs that could have been declared as local variables were defined as global, non-reusable storage. This problem is fixed, improving code efficiency.
A memory leak while using the FDATool graphical user interface has been fixed.
In the previous release, updating a model containing a certain type of block diagram pattern could cause a memory access (SEGV) error. Patterns that could cause this error typically consist of an accumulator pattern (e.g., a two-port Sum block with a feedback through a Unit Delay block) connected directly or indirectly along with other inputs to a Mux block whose output is connected to more than one block requiring contiguous signal input (i.e., blocks that require that all elements of an input signal occupy adjacent locations in memory). This release fixes the problem.
In the previous release, updating a model containing a certain type of block diagram pattern could cause a memory access (SEGV) error. Patterns that could cause this error typically consist of an accumulator pattern (e.g., a two-port Sum block with a feedback through a Unit Delay block) connected directly or indirectly along with other inputs to a Mux block whose output is connected to more than one block requiring contiguous signal input (i.e., blocks that require that all elements of an input signal occupy adjacent locations in memory). This release fixes the problem.
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.
Under certain scenarios, Simulink 4.0 and later versions reused a block output data buffer when it should not have done so, thus corrupting data and resulting in invalid simulation and code generation results. This problem has been fixed.
Depending on signals visible, there had been a possibility of corrupting a model by changing the index (the port number) of a signal. The new version fixes all known problems associated with changing the port number (index).
In Release 5.0 and 5.0.1, either continuous or fixed-step models could miscount steps when start time was large and/or step size was small. After around 10e8 steps, major steps could be skipped or the model could freeze due to a limitation of the timing engine. The current fix increases the threshold for this behavior to at least 10e12 major steps or more. A complete fix is planned for a future release of Simulink.
Previously, pressing CTRL-C during a Real-Time Workshop build or Stateflow S-function build rendered the status window inoperable. This is now fixed.
In previous releases, when attempting to report an illegal rate transition error (for example, as a result of a model update), Simulink could crash or identify the wrong port as being involved in the illegal rate transition. This behavior occurred in multirate models with rate transition errors between blocks with multiple input and/or output ports. This release fixes the problem.
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.
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.
Version 6.0 includes the following new attributes for Simulink.Signal objects:
- Dimensions
- Sample time
- Sampling mode
- Data type
- Complexity
Simulink checks the consistency of these attributes against the values set on the ports/dwork elements associated with each signal object.
Note: If an attribute is set as "auto"/-1 (not specified), then no consistency checking is done.
When transitioning from a block sampled at 0.1 to a block sampled at 0.3 using the Rate Transition block, the following error occured:
Error reported by S-function 'rate_transition' in block 'untitled/Rate Transition': The sample time of the output port 0.3s must be an integer multiple of the input port sample time 0.1sThis error condition is fixed.
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.
If fixed-point logging is turned on, the Sign block does not do zero crossing detection regardless of whether zero-crossing detection is enabled for the block. This change makes the behavior of the Sign block consistant with that of other fixed-point-capable blocks that do zero- crossing detection.
You must install Real-Time Workshop if you install either Simulink or Simulink Performance tools. This dependency will not be required in future Betas or final release.
In Release 13, code generation aborted for the case of a Switch block configured with the 'Criteria for passing first input' set to'u2 ~=0', with vector inputs of width greater than theRollThreshold(5). Code generation aborted with the following message:%exit directive: Real-Time Workshop Fatal in block: "/B_1_28", block type "Switch": No parameters to roll.This is fixed in Release 14. The Accelerator also failed for similarly configured Switch blocks.
Unified blocks might causes segmentation violations if singnals input to these blocks are discontiguous and the discontiguous signals are also fed into other blocks that require contiguous signals. This has been fixed.
In Version 5.x, the Accelerator failed to operate for the case of a Switch block configured with the 'Criteria for passing first input' set tou2 ~=0, with vector inputs having width greater than theRollThreshold(5). The Accelerator aborted with the message%exit directive: Real-Time Workshop Fatal in block: "/B_1_28", block type "Switch": No parameters to roll.This has been fixed in the current release.
In Simulink Performance Tools 5.0, running Simulink Accelerator would check out an Embedded Coder license if one was present (but would not fail if one was not). This check-out has been eliminated.
The View Setup panel in the Custom Views folder of the Simulink Tools Manager has a table to add subplots to the LTIViewer. In the third column of this table you can include titles for the plots. However, when you enter a title into the table and then click the Display View button, the new title does not appear in the LTI Viewer window. This is planned to be fixed in the final release.
In previous versions of the coverage tool an error was produced whenever a logic block was configured with a single vector input and MCDC coverage was enabled. This release fixes the problem and correctly reports coverage