Real-Time Workshop V6.0 (R14) Fixed Bugs

Altering Execution Order in Subsystem Copies Caused Segmentation Violation

In Version 5.x, when a subsystem was copied and block execution order was altered in the copy or the original, a segmentation fault could result during code generation. This problem, which was associated with subsystem code reuse, has been fixed.

Block I/O Optimization

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.

Code for Logic Block with Single Input

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.

Code Generation Failure for Relational Operator Block

In Version 5, 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.

Code Generation for Data Store Memory Blocks

In Version 5.0, some models that contained Data Store Memory blocks could generate code that would not compile. This problem has been fixed.

Code Generation for Wide State Input Signals

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.

Code Generation from a Block Whose Output Is Connected to a Subsystem Input

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.

Code Reuse for Identical Atomic Subsystems

In Release 13, Real-Time Workshop sometimes failed to reuse the code for groups of identical nonvirtual subsystems when the function option was set to 'Reusable function'. This has been fixed.

Code-Reuse-Related Segmentation Violations Fixed

In previous releases, code generation could create illegal memory references that caused segmentation violations when compiling models and building targets. The code reuse feature for atomic subsystems, introduced in Release 13, was responsible for a number of these crashes, but only under special circumstances that are difficult to enumerate. Many of these issues are fixed in post-R13SP1 releases.

Custom Code in Configuration Sets Is Ignored by Accelerator, S-Function, and Model Reference Simulation Targets

Code placed in the Real-Time Workshop Custom Code pane of the Configuration Parameters dialog is ignored by the following targets:

Accelerator

Real-Time Workshop S-function target

Model reference simulation target

Custom Data Types with Constant Sample Time Blocks

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.

Data Store Read Block Generates Valid Code When Expression Folding Is Enabled

In Real-Time Workshop, 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.

Discrete States in a For/While Subsystem Reset Correctly

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.

Expression Folding and Selector Blocks

In Version 5.0, with Expression folding on, incorrect code could be generated for a Selector block. This has been fixed.

External Mode/Accelerator Signals Not Updated for Data Logging

In Release 13, for the simplest form of an enabled subsystem, signals that were marked for data logging were not updated when the system was enabled. This problem has been fixed in Release 14.

For Iterator Block With Expression Folding Now Produces Code That Compiles

Since Release 12.1, the For Iterator block produced uncompilable code when expression folding was on. Expression folding removed all code that would be in the output function and hence the system became completely empty. This problem has been fixed in Release 14.

If and Case Block Code Generation

The If block and Case blocks aborted code generation when the root model has continuous states and has a child subsystem with:

• continuous time blocks
• {if, case} block
• no continuous states

This problem has been fixed.

Include System Herarchy Numbers in Identifier Option

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.

Look-Up Table 2-D Code Generation for Repeated Zeros in Breakpoints

If the column breakpoints in a Look-Up Table 2-D block had repeated zeros, Real-Time Workshop would generate incorrect code in some circumstances. This has been corrected. A remaining limitation is that the number and position of zeros cannot change when breakpoints are tuned, or incorrect results will be obtained. To avoid this limitation, do not use repeated zeros in lookup tables when the number or position of zeros could change while the real-time code is running.

Merging Signals from Different Subsystems Now Generates Correct Code

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.

Multi-byte Characters in TLC Files Are Processed Correctly

A bug in Release 13 Service Pack 1 caused wrong answers and possibly crashes to occur when multi-byte characters (unicode) were included in TLC scripts. This has been fixed, restoring the correct handling in R13.

Multiport Switch Block Generates Correct Code for Wide Inputs

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.

No Name Clashing of Function-call Arguments of Reusable Subsystems and Global Identifiers

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.

Non-reusable Functions for Subsystem Library Links No Longer Mangle Function Names Unnecessarily

Previously, a library-reference atomic subsystem with code generation options set to "Function" and "Use Subsystem Name" would use the reference name for all instances. This created symbol clashes that Real-Time Workshop would resolve via inconsistent name mangling, which created tracability problems. Such subsystems now use their instance name.

Real-Time Workshop Now Generates Nonfinite Source Files

The nonfinite routines in rt_nonfinite.c and rt_nonfinite.h are now dynamically generated by Real-Time Workshop. In previous releases this code was a static file copied from MATLABROOT/rtw/c/src/.

rtw_info_hook Filename Generation

In R13SP1, if a user specified additional arguments in the RTW system target file field of the Simulation Parameters dialog, and any of these contained "/" or "\", Real-Time Workshop could derive an incorrect file name. For example, the user input ert.tlc - Isomewhere/somepath caused the incorrect hook file name somepath_rtw_info_hook.m to be generated instead of ert_rtw_info_hook.m. This has been fixed, and arguments for System Target Files may now contain the characters "/" and "\".

S-Function Target Now Uses Double-precision Accuracy for Sample Times on Inports

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.

Saturation Characteristics No Longer Required in rtw_info_hook M-files

Version 5.01 of Real-Time Workshop derives C-language implementation information for the current target from "hook files" (<target>_rtw_info_hook.m). In that release, it was necessary to specify information on saturation, as seen in the following code snippet:

 case 'cImplementation'
  
  % specify various C-language information

  value.ShiftRightIntArith   = true;
  value.Float2IntSaturates   = false;
  value.IntPlusIntSaturates  = false;
  value.IntTimesIntSaturates = false;

The Saturation information fields are no longer required. You can therefore simplify this code to:

 case 'cImplementation'
  
  % specify various C-language information
  value.ShiftRightIntArith = true;

For more information type 'edit example_rtw_info_hook.m' in MATLAB.

Note that rtw_info_hook files are no longer used in Release 14, as their functionality has been absorbed by configuration sets. This fix is provided in order to maintain compatibility.

Scopes Now Work with External Mode and Multitasking

In versions 4.1 and later Scopes might not display all signals when connected to Real-Time Workshop targets via External Mode. This problem was found only in multitasking code; singletasking targets displayed signals reliably in External Mode. This problem has been fixed in Version 6.0.

Simulation and Code Generation Do Not Match for Nested Artificial Algebraic Loops

Simulation and code generation do not match in models that contain nested artificial algebraic loops that contain an update function. This problem will be fixed in the Release 14 general release.

Simulation and Code Generation Results Do Not Match for Some Enabled Subsystems

In R14 Prerelease, the simulation and code generation results did not match for an enabled subsystem without a start function, and with initial values specified on its output ports and a constant value at its control port. This problem has been fixed in the final release.

Simulation and Generated Code ults in the Case of Initial Value Conflict

The virtual outports of a subsystem could be initialized incorrectly by Release 12 and 13 versions of Real-Time Workshop, causing the initial value of an outport to sometimes be incorrectly overwritten by other operations. This could result in differences between simulation outputs and outputs computed by generated code. This issue has been addressed, and the initial value is no longer being overwritten in cases where it had been previously.

Spaces in TLC Pathnames No Longer Abort Code Generation

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.

Subsystem Functions with Incompatible Argument Types in Generated Code

Starting in Version 5.0, an inlined atomic subsystem within a reused atomic subsystem that received a discontinuous input signal could generate code with incompatible types in certain cases. This has been fixed.

Support for N-d (N > 2) Canonical Parameters

In Version 5.x, when Real-Time Workshop generated code for n-d canonical parameters (e.g., N-D Lookup blocks), only the first two dimensions of the parameter were used to calculate the size of the argument to a reusable function. In rare cases this could prevent such functions from being reusable. This has been fixed, so that all of the dimensions are now used to compute the size of the argument.

TLC now supports single precision versions of NaN and Inf constants

TLC now allows single precision NaN's and Inf's to be represented as constants. e.g. rtInff, rtNaNf, rtInffi, rtNaNfi.

To Workspace and Scope Blocks Could Cause S-Function Targets to Fail to Generate

In Release 13, 'To Workspace' or 'Scope' blocks writing to any workspace variable that is also used as a block parameter by another block in the model prevented s-function targets from generating. This problem is fixed in Version 6.0 (Release 14).

Tunable Parameters with "context-sensitive" Data Type

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 double parameter 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 than double in these cases regardless of this change.

Unconnected output ports of If/Switch-Case can generate uncompilable code

When an If or Switch-Case block has an unconnected output port, it is possible that the RTW code generated from that model will fail to compile. The compile error will be "rtPrevAction not defined". This bug is fixed in this release.

Unreachable Disable Function Code for Enabled Subsystems

Starting with Version 5.0, Real-Time Workshop was generating unreachable disable function code for enabled subsystems in single-rate parents. This caused the output of the generated code not to match simulation results. The disable function code for such enabled subsystems is now reachable.