The Abs block is designed to have the same data type for its input and its output. The block accepts all non-Boolean Simulink built-in data types and all Fixed-Point Blockset data types with one restriction: Fixed-Point Blockset data types must have a bias of zero. These rules were not completely implemented in Release 13; that has been corrected.
The output data type of a Switch or Multiport Switch block should be the same as the input signal data type with the greatest positive range to ensure that the output port can accommodate any possible input value. In previous releases, if the inputs of a Switch or Multiport Switch block consisted of signals of both type single and double, Simulink set the data type of the output port to type single. This was incorrect because signals of type double have a much larger positive range than signals of type single. This release corrects this bug.
In Real-Time Workshop 5.0, an invalid base address was saved in the global
memory map for models that generate a constant data structure
(rtC). This has been fixed.
In Release 13, if a model contained reuseable atomic subsystems that were empty or without states, then an incorrect base address would be stored in the global memory map for the system's DWork vector. This has been fixed.
In Release 13, non-reusable code was generated for the following model:
If a signal directly crossed the system boundary of a reused, then an inlined, then another reused subsystem, the second reused subsystem ("C") would be called with arguments that are globaly accessed. This caused System "A" not to be reusable and resulted in invalid code. This has been fixed.
Invalid code was generated for following model, wheresignal_1is a scalar signal directly connected to the Stateflow library chart.
The incorrect code generally resulted in incorrect answers because the wrong signal memory addresses were read by the chart. This could result in a segmentation fault should the address be out of the program space. This problem has been fixed.
Real-Time Workshop 5.0 was generating invalid code for continuous and discrete state space blocks with discontiguous inputs (e.g., when the signal entering the block was the output of a Mux or Bus Creator block). This caused generated code to produce different answers than those obtained from simulations. This has been remedied.
In Real-Time Workshop 5.0, the Data Store Read block could generate invalid code when expression folding was enabled. This has been remedied, by disallowing expression folding for that block.
In Real-Time Workshop 5.0, the RTW optionInclude system hierarchy number in identifierscaused Dwork with non-auto storage class to have its identifiers mangled (manipulated to be unique). This is no longer the case. The behavior of the optionInclude data type acronym in identifierhas also been changed so as not to mangle the identifier of dwork with non-auto storage class.
With multiple models or libraries open, selecting or deselecting
the Buffer reuse checkbox in the General code generation
options of the Real-Time Workhop pane would sometimes cause an error
message to be displayed, or sometimes set the option on the wrong model.
This problem has been corrected.
In Release 13, the generated code of a model with triggered subsystems located within a reused subsystem block was incorrect, due to an initialization problem. In the model below, Subsystems A1 and A2 are reused atomic subsystems with triggered subsystem inside. The generated code did not initialize the trigger signalsignal_1of the Subsystem block A2, which resulted in incorrect behavior. This has been fixed.
In prior releases, inputs and outputs of noninlined S-functions could not have storage classImportedExternPointer. This restriction has been eliminated for scalar inputs and outputs of that storage class. However, for the time being, in order to use a wide input or output of storage classImportedExternPointer, only non-inlined S- functions may be used.
In Real-Time Workshop 5.0 it was possible for invalid code to be generated for For and While Iterator blocks when expression folding was enabled. This has been remedied, by disallowing expression folding for such blocks.
Real-Time Worksop 5.0 incorrectly generated a reusable function when two systems were identical except that in one system a signal was declared as SimulinkGlobal (testpointed) but in the other the signal was auto. As a result, the generated code might not compile. This has been remedied by adding testpointed signals to the checksum, so that systems with such signals will not be reused.
In Real-Time Workshop Embedded Coder 3.0, the code generation option 'Integer code only' did not correctly detect floating point types in a model. This was a regression from previous releases and has been corrected. The option now raises an error if any non-integer data or expressions are encountered during code generation.
Real-Time Workshop now unconditionally generates initialization code if the initial condition (IC) parameter of a block is tunable. This fixes a problem where an optimization prevented generation of code to initialize the states of delays and discrete integrators, where the IC parameter is equal to zero. If such a parameter is tunable, this optimization would prevent the parameter from being tuned to a non-zero value.
With expression folding enabled, it was possible that the code generated for the Delay block could be invalid. This was a regression from release 12.1 and has been corrected.
When theGenerate reusable codeoption is on, the generated code represents scalar root inports as arguments passed to the main model function(s) by value. This causes invalid code to be generated if a Stateflow chart is wired to a root inport.To avoid this, Real-Time Workshop Embedded Coder now raises an error if a Stateflow chart is wired directly to a root model inport and 'Generate reusable code' is selected.
The Abs block is designed to have the same data type for its input and its output. The block accepts all non-Boolean Simulink built-in data types and all Fixed-Point Blockset data types with one restriction: Fixed-Point Blockset data types must have a bias of zero. These rules were not completely implemented in Release 13; that has been corrected.
In the previous release, when attempting to report an illegal rate transition error (for example, as a result of a model update), Simulink could crash or misidentify the port involved in the illegal rate transition. This behavior, which occured in multirate models with rate transition errors between blocks with multiple input and/or output ports, has been fixed.
The previous release of Simulink contained a bug that allowed the input of a subsystem that was both enabled and triggered to be driven by a block with a rate different from the trigger rate. This created an illegal rate transition in multi-tasking mode. Now Simulink generates an appropriate rate transition error message in such situations.
In the previous release, attempting to save a model that contained linked Signal Builder blocks caused an error. The new version of the block is fully compatible with libraries.
The output data type of a Switch or Multiport Switch block should be the same as the input signal data type with the greatest positive range to ensure that the output port can accommodate any possible input value. In previous releases, if the inputs of a Switch or Multiport Switch block consisted of signals of both type single and double, Simulink set the data type of the output port to type single. This was incorrect because signals of type double have a much larger positive range than signals of type single. This release corrects this bug.
In previous releases, updating a diagram containing an Enable Port block with its States when enabling parameter set toresetcaused Simulink to reset the parameter to its default value,held. This caused the model to produce incorrect answers. This problem has been fixed.