In charts with Execute at Initialization turned on, accessing chart parameters in the chart entry function (i.e., default transition paths of the chart or state entry function) yielded incorrect results. This is now fixed.
Stateflow models containing multiple parameter data with the same name but parented by multiple states caused internal assertion errors during code generation. This is now fixed.
Stateflow models containing charts with exported graphical functions with vector/matrix input/ouput data generated uncompilable code during simulaton as well as RTW code generation. This is now fixed.
Fixed-point autoscaling tool did not work on Stateflow data without Simulink Verfication and Valication license. This is now fixed.
In earlier releases hitting the Delete key while resizing a Stateflow object would throw an assertion. This has been fixed.
In charts with the property Execute At Initialization turned on, accessing chart input data or calling exported graphical functions from another chart during chart's initialization is illegal as it may cause unpredictable results. In the previous releases, these erroneous usages were silently tolerated causing unrepdicatble results. These cases are now detected and warnings are produced at simulation/code-generation time to help clean up the model.
Japanese characters entered in Stateflow truth table UI used to get corrupted on model save. Subsequent loads of this model resulted in complete loss of truth-table data. This is now fixed.
Parse diagram and Parse options from the Stateflow editor Tools menu caused the whole model to be compiled, instead of checking the Stateflow chart(s) for syntax errors only. This is now fixed.
In the previous release, Stateflow and Embedded MATLAB added support for inherited data sizes, types, and complexities. The major restriction on this feature was that inherited data properties were not allowed in libraries. This restriction has been lessened, but not yet entirely removed. Inherited data properties are allowed in libraries if all instances of said library chart have the same data properties. If a chart is used only once in a given model, this will always work, however, in the case where multiple instances of a chart are in the same model, all data sizes, types, and complexities must be identical.
Stateflow data created using the toolbar in the Stateflow editor (Add->Data->Input from Simulink...) used to have its complexity set to inherited. Stateflow, however, does not support complex data. This means that inheriting complex data would cause erroneous code to be generated.Additionally, library charts did not support inherited properties, so if a chart with data of inherited complexity was made into a library, a confusing error about complex data was reported. This problem has been fixed and Stateflow data now always have complexity turned off.
A common workflow employed by large teams working on the same project involves zipping up an entire directory containing models and generated code and copying to another machine with a different MATLAB installation directory.In this situation, Stateflow incremental code-generation was not detecting this change in MATLAB root and the previously generated makefiles did not work and caused strange compilation errors. This is now fixed by regenerating the makefiles on detecting a change in the MATLAB installation directory.
Stateflow models with custom-code failed to compile with lcc when MATLAB was installed in a directory with spaces on Windows. This is now fixed.
Historically, Stateflow has generated code for all charts in a library, regardless of need. There are many consequences of this, which include (a) not being able to have an exported graphical function of the same name in multiple library charts, and (b) unnecessary library size and compile overhead. Stateflow now only generates code for the library charts that are in use by the main machine, allowing for such multiple definitions and more lightweight libraries.
In previous releases, supertransitions were not being returned when querying the State object's sourcedTransitions or outerTransitions properties. This has been fixed.
The chart property No Code Generation for Custom Target is now removed from the Chart Properties dialog box, because it is no longer relevant and not supported.
Stateflow charts with expressions containing custom-code c-function calls and bit-shift operators caused assertions during code-generation. In the following example, "fpga_read()" is a custom-code function whose return type is unknown to Stateflow code-generator.
test = int8(fpga_read(0x07) >> 5);Stateflow coder needs to know the return type of the function "fpga_read()" in order to properly implement the shift-operation. In previous releases, this resulted in an assertion error. We now detect this case and generate a proper error pointing out the work-around which is to wrap the function- call in an appropruate cast statement. For example, if it is known that fpga_read() returns an int16 type, then rewrite the above expression as follows:
test = int8(int16(fpga_read(0x07)) >> 5);This int16() cast is used by the Stateflow code generator to implement an appropriate bit-shift operation in the generated code.
Charts containing local events generated uncompilable code with code-reuse turned on. Specifically, the event broadcast functions were generated as void-void functions as below when their callee functions needed arguments for Dwork and other data (look below for an example):
static void positionctrl_broadcast_Act_OFF_(void) { uint8_T b_previousEvent; b_previousEvent = _sfEvent_positionctrl_; _sfEvent_positionctrl_ = positionctrl_event_Act_OFF_Ev; positionctrl_c1_positionctrl(rtu_PosRef, rtu_PosFbk, localB, localDW); _sfEvent_positionctrl_ = b_previousEvent; }This is now fixed.
The use of bit-fields in chart structure is controlled by Stateflow bit-field settings in the Optimizations page of RTW ConfigSet. The generated code was using unsigned int for these types instead of the Mathworks type uint32_T. Though this did not affect correctness, it affected readability of the generated code. This is now fixed.
When the model contained a parameter with an exported storage class and a Stateflow machine parented exported data with the same name, the name collision was not detected at code generation. This was causing uncompilable code to be generated. This is now fixed by generating a proper error message during code generation about the name collision, so that one of these symbols could be renamed by the user.
In the previous release, RTW code generation sometimes failed when the model contained one or more Stateflow charts with no output data and one or more test- pointed local-data or states. The error message displayed on the MATLAB command window had the following signature.
Error: File: d:\R14\matlab\rtw\c\tlc\mw\capi.tlc Line: 359 Column: 44 Undefined identifier constString Error: File: d:\R14\matlab\rtw\c\tlc\mw\capi.tlc Line: 359 Column: 62 The + operator only works on numeric argumentsThis problem is now fixed.
Stateflow charts containing floating point computations were not flagged when "Integer code only" flag set on the RTW ConfigSet. These are now detected and error messages pointing to the illegal floating point use are generated during code generation process.
Stateflow models containing "MinMax" blocks named "min" or "max" generated uncompilable code due to name collisions. This is now fixed.
Temporary data in graphical functions intitialized from workspace, generated code wherein the global parameter data with the same name was shadowed, resulting in code that looked like this:
static real_T tmp_MyFunc(real_T In) { real_T MyPrm; MyPrm = MyPrm; /* Value X */ ... ...This is now fixed by assigning a unique name to the temporary data MyPrm in the generated code.
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |