Real-Time Workshop V6.1 (R14SP1) Fixed Bugs

Assertion Block Setting Taken Into Account for Reusable Systems

In Release 14, when determining whether a subsystem could be reused, Real- Time Workshop did not adequately take the Assertion block setting into consideration. If two similar subsystems contained Assertion blocks, and only one of the blocks had the assertion enabled, Real-Time Workshop could mistakenly decide that the two subsystems were reusable. As a result, Real-Time Workshop would generate only one body of subsystem code. This is fixed in Release 14SP1.

Asynchronous Task Only Models with Tornado Target No Longer Fail to Build

In Release 14, if a model had only asynchronous tasks, and you used the Tornado libary (vxlib1.tlc), function calls associated with asynchronous tasks were generated twice, and Real-Time Workshop could not build an executable. This is fixed in Release 14SP1.

Atomic Subsystem With Async Block No Longer Generates Segmentation Violation in Accelerator Mode

In Release 14, an atomic subsystem that included an Async block would generate a segmentation violation in accelerator mode, while the model worked fine in normal mode. This is fixed in Release 14SP1.

Block Parameter Option Added for Async Interrupt Block in vxlib1 to Correct Timer Restriction

In Release 14, the block library vxlib became obsolete and a new library, vxlib1, which includes improved asynchronous support, was added. Asynchronous tasks associated with the Async Interrupt block in the obsolete library always read absolute time from the base rate. Asynchronous tasks associated the Async Interrupt block in the vxlib1 maintained absolute time itself. To enable you to choose between using the base rate timer or your own timer, Release 14SP1 adds the option Manage own timer to the Block Parameter dialog for the Async Interrupt block in vxlib1.

Block Start Method Now Called Only Once in Generated Code

In Release 14, when a function-call subsystem block had a wide trigger, it was possible for the generated code to execute the start methods of that block and blocks it contained more than once during model initialization. A block's start method should never be called more than once, because it could have side effects, such as hardware initialization. This is fixed in Release 14SP1.

Bug with External Mode Signal & Triggering Dialog Fixed

In Release 14, the External Mode Signal & Triggering dialog did not open properly when a model contained viewers created with the Signal and Scope Manager. This is fixed in Release 14SP1.

Build Issues for Real-Time Workshop S-Function Targets (rtwsfcn.tlc) Addressed

Release 14SP1 addresses two issues with using the Real-Time Workshop S- function target in another model:

When used in a model that is being accelerated with the Simulink Accelerator, the S-function makefile located at pwd/model_sfcn_rtw/model.mk no longer needs to be present.

Symbol collisions that could occur when multiple S-functions exist in a model being built with Real-Time Workshop have been addressed.

Building Subsystems that Use Model Workspace Parameters

In Release 14, you could not generate code or an S-Function for a subsystem (right-click build) if the subsystem or any of the blocks inside the subsystem used parameters from the model's workspace. This is fixed in Release 14SP1.

C-API Now Works with Rapid Simulation Target

Prior to Release 14SP1, limitations in the Rapid Simulation (RSim) target code prevented you from using Real-Time Workshop C-API support. In this release, the problems have been fixed and RSim targets, as well as the GRT and ERT targets, can now invoke the the C-API.

Code for Single-Rate Subsystems in Asynchronous Function Calls Now Generated

In Release 14, the code for some single-rate subsystems, atomic subsystems, and enabled subsystems, was not generated if the subsystems were in an aysnchronous function call hiearchy. This is fixed in Release 14SP1.

Code Generation for Models with Constant Signals and Reusable Subsystems No Longer Fail

In Release 14, the Real-Time Workshop code generation process sometimes failed for models in which constant signals crossed reusable subsystem boundaries. This would happen only if the expression folding optimization was on. This is fixed in Release 14SP1.

Code Generation No Longer Fails for Models with Stateflow Data and External Mode Interface

In Release 14, code generation could fail for a model if the following two conditions were true:

• Code for an external mode interface is generated

The model has Stateflow data of machine scope

This problem is fixed in Release 14SP1.

Configuration Settings Link in HTML Report for Right-Click Subsystem Builds Fixed

In Release 14, if you used the right-click mechanism to build a subsystem, the link Configuration Settings at the Time of Code Generation in the Summary section of the generated HTML report would not work. This is fixed in Release 14SP1.

Constant Block Output in Start Function in Generated Code Now Matches Simulation

In Release 14, a Constant block did not always write its value in the Start function of its generated code. This behavior could be inconsistent with simulation behavior. This is fixed in Release 14SP1 such that the block's behavior is the same for code generation and simulation.

Correct Code Generated for While Subsystems and Assignment Blocks

In Release 14, if a while subsystem had states set to reset, was nested in another iterator system, and contained an assignment block, Real-Time Workshop could generate incorrect code. This happened when the While Iterator block did not need to keep track of the iteration number. This is fixed in Release 14SP1.

Custom Code Blocks for Periodic Systems Appearing in Asynchronous Systems

In Release 14, when you used a custom code block inside a periodic system, the code generated from that block could appear in the code generated for an asynchronous system, in addition to appearing in the periodic system. This is fixed in Release 14SP1.

Error Now Reported When Ground Block with Wide Output Signal Feeds Reusable Subsystem

Prior to Release 14SP1, Real-Time Workshop generated incorrect code if either of the following conditions existed:

• A reusable Subsystem block was fed by a Ground block that had a nonscalar output signal.

• Some input ports of a Subsystem block were not connected, either directly or indirectly, to actual (nonvirtual) signals.

In Release 14SP1, Real-Time Workshop reports an error if one of these conditions exists.

To correct the condition, make the following changes as they apply to your model:

• Set the Subsystem block's RTW system code option to Inline or Function.

• Replace the Ground block with a Constant block that has a value that specifies a vector of zeros.

• Connect unconnected input ports of the Subsystem block to Constant blocks that have a value that specifies a vector of zeros.

External Mode Messages No Longer Sent When Status Bar Is Not Present

In Release 14, if you removed the status bar from a model, get_time request and response messages would continue to be transmitted between the target and host, even though there was no visible clock to be updated. This was ineffecient. In Release 14SP1, get_time messages are not exchanged when the status bar is not visible.

ExtModeMexFile and ExtModeMexArgs Now Working With Certain Targets

In Release 14, you could not tune the external mode parameters ExtModeMexFile and ExtModeMexArgs for targets derived from GRT or ERT targets. This is fixed in Release 14SP1.

From Workspace Block No Longer Generates Incorrect Code or Produces Segmentation Violation for Rsim Target

In Release 14, when used for with the Rsim target, the From Workspace block generated incorrect code or generated a segmentation violation as follows.

• If the data parameter was a structure, the block's generated code could produce incorrect results. This is fixed in Release 14SP1.

• If the data structure used included a nondouble data type, the block's generated code produced a segmentation violation. In Release 14SP1, if the data structure uses built-in data types there are no problems with code generation. However, the block generates an error during code generation if the data structure uses fixed-point data types.

Generated Code for Blocks Using Elapsed Time Now Correct and Complete

In Release 14, if a block required elapsed time (for example, a Discrete Integrator block), and its first parent subsystem that executed conditionally was single rate, the generated code for the block was incorrect or incomplete. This is fixed in Release 14SP1.

Generated Code for Models with Reusable Subsystems Now Compile Under External Mode

In Release 14, models configured to generate code for reusable subsystems to separate source files encountered compilation errors when external mode was enabled. This problem, which was caused by a missing header file, is fixed in Release 14SP1.

Hardware Characteristics Correctly Reflected in Generated Code

In Release 14, if options on the Hardware Implementation pane of the Configuration Parameters dialog were set as follows, the specified embedded hardware setting was not always correctly reflected in the generated code:

• The Device Type option in the Embedded hardware section was set to anything other than the default (Unspecified: assume 32-bit Generic).

• The Emulation hardware option was set to None.

This problem is fixed in Release 14SP1.

Invalid Code No Longer Generated for Assignment Block When an Input Port Is Scalar

In Release 14, Real-Time Workshop generated invalid code for the Assignment block when a user specified one input port as a matrix and the second input port as a scalar value. The block incorrectly treated the scalar value as matrix and tried to index into it.

This problem is fixed in Release 14SP1.

Local Variable Reuse No Longer Causes Real-Time Workshop to Generate Incorrect Code

In Release 14, Real-Time Workshop could generate incorrect code if you selected the Reuse block outputs option on the Optimization pane of the Configuration Parameters dialog. This is fixed in Release 14SP1.

Loop Generated in Initialization Function of Generated Code More Efficient

In generated code, a block's Dwork elements are usually set to zero in the initialization function. In Release 14, the set-to-zero operation always used a for loop, even if the width of a dwork was less than the specified roll threshold. This has been fixed in Release 14SP1 such that a loop is used only when the width of a dwork element is greater than or equal to the roll threshold.

MdlInitialize Restored for GRT Target Format

In Release 13SP1, MdlInitialize was generated for the GRT target and called in MdlStart. Any user code entered in the RTW->Initialize function would appear in MdlInitialize. In Release 14, MdlInitialize was removed and code entered in the RTW->Initialize function was inlined in MdlStart. In Release 14SP1, the Release 13SP1 behavior was restored.

Microsoft Visual C/C++ Compiler No Longer Displays Warnings When Compiling Generated Code

In Release 14, the Microsoft Visual C/C++ Compiler would generate the following warning, and several companion warnings, when compiling generated code on Windows:

"rt_logging_mmi.c(122) : warning C4090: 'function' : different 'const' qualifiers"

In Release 14SP1, these messages are no longer generated.

Model Blocks Lacking Inputs and Outputs No Longer Generate Uncompileable Code

In Release 14, when a Model block was specified as having neither inputs nor outputs, the code generated for the model containing it would fail to compile. This is fixed in Release 14SP1.

Model Blocks with Disable Functions Now Give Correct Answers

In Release 14, a Model block that was contained in an enabled subsystem and had a disable method would not have that method called in generated code. This would result in incorrect answers. In Release 14 Service Pack 1, this was corrected such that the disable method is called.

Model Reference Blocks in Asynchronous Function Call Subsystem Now Called

In Release 14, when you placed model reference blocks in an asynchronous subsystem, the blocks did not get called. This is fixed in Release 14SP1.

Models that Use Asynchronous Rates Now Execute Periodic Rate Correctly

In Release 14, an asynchronous rate in a model could cause the task counter for a subrate to overflow due to the counter having an incorrect data type size. This condition occurred when all of the following conditions applied:

• The model used an asynchronous rate
• The model included multiple perodic tasks
• The ratio of the slowest rate to base rate is over 255

This is fixed in Release 14SP1.

Output and Update Functions of Single-Rate Subsystems Called Only in Task Associated with Subsystem Sample

In Release 14, if a model had an asynchronous task and a reusable single- rate subsystem that included user code, output and update functions in the single-rate subsystem were incorrectly called in all tasks. This is corrected in Release 14SP1; the output and update functions of the single-rate subsystem are now called only in the task associated with the subsystem sample time.

Parameter Names of Dead Zone Block Now Consistent in Generated Code

In Release 14, the variables representing the start and end of a dead zone in generated code for a Dead Zone block were labeled incorrectly. This is fixed in Release 14SP1.

Port-Based Sample Time S-Functions Now Work With Asynchronous Subsystems

In Release 14, you could not use an S-Function block with a port-based sample time in an asynchronous subsystem. This is fixed in Release 14SP1. You can now include such blocks in an asynchronous subsystem if the S-function specifies the option SS_OPTION_ALLOW_PORT_SAMPLE_TIME_IN_TRIGSS.

Quoted Strings Specified for User-Defined Target Options Handled Correctly

In Release 14, if you specified a quoted string, such as '1,2,3', for a user-defined target option, Real-Time Workshop would remove the outer quotes before passing the string to the Target Language Compiler command. This could result in a build failure with an error message similar to the following:

Error using ==> makertw.make_rtw                                           
Error using ==> tlc_c                                                      
Error: Missing variable or function.  

This is fixed in Release 14SP1. Real-Time Workshop no longer removes the outer quotes and quoted strings are handled correctly.

Rate Transition Block Behavior Now Predictable When Used With Blocks That Have Asynchronous Rate

In Release 14, the initialization value of a Rate Transition block output port could be unpredictable if the Rate Transition block was used to transfer data to or from a block with an asynchronous rate and either a non-ANSI C target or a non-zero initial condition was used. This is fixed in Release 14SP1.

Real-Time Workshop Optimizations No Longer Causing Build Failures

In Release 14, certain Real-Time Workshop optimizations could cause an error during the TLC process or generate code that failed to compile. This could happen when two or more reused systems were used in different contexts in a model. This is fixed in Release 14SP1.

Reused System with Muxed Inputs No Longer Generate Incorrect Code

In Release 13 and Release 14, if a system in a model was reused during code generation, and that system had any inputs that were muxed, Real-Time Workshop could generate incorrect code. This could happen if other seemingly identical systems have muxed inputs that have the same overall width, but are broken down into different regions. For example if a muxed input signal has a width of 4 for two systems, but in one system the signal is broken down as [1 1 2] and in another, seemingly identical system, the signal is broken down as [1 2 1], the systems could generate incorrect code. This is fixed in Release 14SP1.

RTW Template Makefile Issue When Compiling C++ S-Function Source Code on HPUX Fixed

Prior to Release 14SP1, compile errors could occur on specific platforms, such as HPUX, for noninlined S-Function C++ source code. For this release, Real-Time Workshop template makefiles have been updated to provide the proper C++ compiler options and C++ libraries.

rtwmakecfg.m Configuration Files Process Correctly in MATLAB Current Working Directory

S-functions use rtwmakecfg.m files to provide additional information for the build process, such as include and source paths. In Release 14, when the S-function mex file and corresponding rtwmakecfg.m file were in the current MATLAB working directory when you initited a build, Real-Time Workshop did not process the rtwmakecfg.m file. This is fixed in Release 14SP1.

S-Function Target Generates Error When Model Contains Variable Sample Time Blocks

The S-function target does not support models with variable sample times. Prior to Release 14SP1, Real-Time Workshop would generate an S- function for such models, but the resulting S-function would produce an error when executed. In this release, Real-Time Workshop generates an error for this issue when generating the S-function code.

S-Function Target No Longer Gives Wrong Answers or Segmentation Violations

In Release 14, the S-function target did not correctly determine whether the generated S-function could inherit a sample time. This bug could cause generated S-functions to give wrong answers or to cause segmentation violations when executed. In Release 14SP1, the problem has been fixed by improving the logic for determining if a generated S-function can inherit a sample time, using the same logic as is applied to Model blocks. See "Inherited Sample Time for Referenced Models" in the Real-Time Workshop documentation for details on determining when the sample time is inherited.

Segmentation Violation During Code Generation

In Release 14, Real-Time Workshop could fail to generate code and produce the following stack trace:

 
[0] libmwcg_ir.so:cg_var_type  
[1] libmwsimulink.so:RTWCGDiscontInput::getIdxVarFromActSrc     

This bug is fixed in Release 14SP1.

Shift Right on Signed Integer as Arithmetic Shift Setting Correctly Honored

The Hardware Implementation pane of the Configuration Parameters dialog provides the setting Shift right on a signed integer as arithmetic shift. Real-Time Workshop uses this setting to generate C code that makes correct and efficient use of the right shift operator. In Release 14, Real-Time Workshop ignored this setting and always generated C code tailored to an arithmetic implementation of the signed right shift operator. If the implementation was actually logical, then the generated code was incorrect.

In Release 14SP1, this problem is fixed. For Simulink and Stateflow models, Real-Time Workshop generates C code that is correctly tailored to the implementation of signed shift right as specified on the Hardware Implementation pane.

Signals Now Passed Through Enable Block When Downstream Block Requires its Input To Be Global in Real-Time Workshop

Prior to Release 14SP1, if an Enable block had an output port and the block being driven by output signal required it's input to be global data in Real-Time Workshop, the signal driving the Enable block's port could end up missing from the global block IO. This would result in wrong answers or uncompileable code. This is fixed in Release 14SP1.

Simulation and Code Generation Results for Model Blocks with Custom ERT Targets and Single output/update On Now the Same

In Release 14, simulation and code generation results for models containing model blocks could be different for models that met the following conditions:

• Used a custom target derived from the ERT target

• Had the Single output/update function option on the Real- Time Workshop/Interface pane of the Configuration Parameters dialog set for the referenced model

This is fixed in Release 14SP1.

Simulink Data Objects: RTWInfo.CustomAttributes Now Initialized Correctly

In Release 14, for user-defined data classes that use custom storage classes (CSCs), the RTWInfo.CustomAttributes property did not get initialized correctly when the objects were first created. By default, the property was initialized as [] instead of SimulinkCSC.AttribClass_PackageName_Default.

This did not cause problems in Release 14 because the 'Default' CSC does not have any custom attributes. However, if you add custom attributes for this CSC in the future, then existing classes will fail to initialize correctly.

To ensure forward compatibility, use the Simulink data class designer to regenerate your user-defined data classes in Release 14SP1.

Simulink No Longer Fails to Run Periodic Blocks in Atomic Subsystems That Include an Asynchronous S-Function Block

In Release 14, Simulink could fail to run a periodic block in an atomic subsystem if the subsystem included an asynchronous S-function block. This condition is fixed in Release 14SP1.

Simulink No Longer Generates Segment Violation When Signal & Scope Manager Places Periodic Block in Asynchronous Subsystem

In Release 14, if the Signal & Scope Manager placed a block with a periodic sample time in an asynchronous subsystem, a segmentation violation would result when Simulink tried to report the sample time mismatch.

This is fixed in Release 14SP1. Simulink is now able to report an error message, indicating that you should not include a periodic block in an asynchronous subsystem, either manually or with the Signal & Scope Manager.

Single-Rate Subsystems With Different Sample Rates Can Be Reused If Not Using Absolute Time

In Release 14, all instances of an atomic subsystem had to run at the same sample rate for Real-Time Workshop to generate that subsystem as reusable. Otherwise, Real-Time Workshop defined a function for each rate. This limitation was independent of whether the subsystem had a sample time dependence (for example, as for an integrator).

In Release 14SP1, Real-Time Workshop can generate reusable code for a single-rate subsystem if instances of the subsystem run at different sample times as long as the subsystem does not use absolute time.

State Variables in Folded Expressions Now Produce Same Results from Simulink and Real-Time Workshop

In Release 14, results from generated code could deviate from simulation results when state variables were used in folded expressions. This is fixed in Release 14SP1, such that expression folding is over- ridden in such circumstances.

Support Added for Nonfinite Elements in Single-Precision Parameter Values

In previous releases, Real-Time Workshop did not support parameter values that were single-precision vectors that included nonfinite elements (for example, single([1 2 inf 3]). The following Target Language Compiler error would occur:

 "A non-homogenous vector was passed to GENERATE_FORMATTED_VALUE"

In Release 14SP1, Real-Time Workshop supports nonfinite elements in single-precision parameter values.

Switch Block Code Generation Failure Corrected

In Release 14, code generation for the Switch block could fail if both of the following conditions existed:

• The middle input was not a scalar value.

• The criteria for passing the first input was u2~=0.

This is fixed in Release 14SP1.

Time to Update Diagram No Longer Changes When S-Function Replaces Subsystem

In Release 14, if you replaced a subsystem with bus inputs or outputs with a generated S-function, the model would take longer to finish updating the diagram than it would before replacing the subsystem. This is fixed in Release 14SP1.

Transport Delay Block Now Behaves the Same in RSim Target and Accelerator

Prior to Release 14SP1, the behavior of Transport Delay blocks in the Rapid Simulation (RSim) target was different from the behavior in the Accelerator, such that the history buffers were allowed to grow. This has been fixed such that the behavior in the RSim target and the Accelerator is the same. This is in accordance with the intent of the RSim target as a nonreal-time simulation tool, as opposed to a real-time code generation tool.

Unary Minus of Boolean Value in Fcn Block Now Produces Correct Result

In Release 14, if a Fcn block used an expression that applied a unary minus operator to a Boolean value, such as -(u(1)<0), Real-Time Workshop could generate code that produced an incorrect numerical answer. This is fixed in Release 14SP1.

Uncompileable Code Error for Reusable Action, Enable, or Iterator Subsystem Corrected

In Release 13 and Release 14, when an Action, Enable, or Iterator subsystem that was declared as a Reuseable function used canonical input or output in its start function, one of the following would result, depending on the relative number of canonical inputs/outputs between the system and its parent:

• The generated code would not compile

• An error would occur in the TLC phase

This is fixed in Release 14SP1.

Undesirable Expression Folding Corrected

In Release 14, Real-Time Workshop could generate code with expressions folded into macros that evaluated input more than once. The macros include rt_MIN, rt_MAX, rt_ABS, rt_SGN and rt_SATURATE. This is fixed in Release 14SP1.

User Code in Subsystems that Execute Conditionally Now Guarded

In Release 14, when you included a user-written custom code block in a subsystem that executed conditionally and the generated code for the subsystem function was empty, Real-Time Workshop did not generate a guard for the condition. Instead, Real-Time Workshop placed the custom code directly in the subsystem function. This is fixed in Release 14SP1.

User Control of rt Model Name Prefix Checking Improved

To ensure that Real-Time Workshop could generate code for any Simulink model that you could simulate, an error check was added to Simulink in Release 14 that disallowed names with the prefix rt. This naming restriction was implemented to avoid possible name collisions with identifiers generated by Real-Time Workshop.

In Release 14SP1, you have more control over how Real-Time Workshop handles such name collisions. Using the "rt" prefix for identifiers option on the Diagnostics/Data Integrity pane on the Configuration Parameters dialog, you can specify the conservative error checking made available in Release 14, or you can specify that a warning or no response be generated for reasons such as backward compatibility. The default setting is error, which provides the Release 14 behavior. Other options include warning and none (inactive).