Code generated from Discrete model uses structures defined in rtw_continuous.h

Hi everyone.

Today I've been trying to generate and compile code from a model configured to use the Fixed Step (Discrete) solver, with Matlab Simulink 2023b. I am using the ert TLC, on a Windows11 64bits machine.

Last time i tried to do it, two months ago with 2022b, everything semmed to work fine. So far, the option Support: continuous time (in the Code Generation/Interface tab of the model parameters) was not checked.

Today i tried to do it again. This time, the code generation terminates normally but when i want to compile it, i get the errors "RTWSfcnInfo is undefined" and "SimTimeStep is undefined". These errors look logical since the header files where these structure are defined (rtw_solver.h and rtw_continuous.h) aren't included anywhere in my new generated code.

I compared the newly generated code and the previous one (which compiled fine) and indeed, i find usages of RTWSolverInfo and SimTimeStep that weren't there in the previous generated code.

Here is an extract of the new generated code :

/* Real-time Model Data Structure */
struct tag_RTM_Model_T {
  const char_T *errorStatus;
  RTWSolverInfo solverInfo;

  /*
   * Timing:
   * The following substructure contains information regarding
   * the timing information for the model.
   */
  struct {
    uint32_T clockTick0;
    time_T stepSize0;
    uint32_T clockTick1;
    SimTimeStep simTimeStep;
    time_T *t;
    time_T tArray[2];
  } Timing;
};

And here is the corresponding extract in the old generated code :

/* Real-time Model Data Structure */
struct tag_RTM_Model_T {
  /*
   * Timing:
   * The following substructure contains information regarding
   * the timing information for the model.
   */
  struct {
    uint32_T clockTick0;
  } Timing;
};

If i now check the checkbox "Support: continuous time", then the generated code now includes these two headers at the top of files, and the compilation succeeds.

I find this rather disturbing for several reasons :

1) How can the code generation step terminates with no error when the option Support: continuous time is not activated, whereas the generated code does not compile !?

2) Why does the generated code now uses these new Timing and RTWSolverInfo structures ? I thought maybe it was an evolution of version 2023b. Also I have changed my model quite a lot these last two months, so it might be something I did. Since the missing definitions are located in headers that are included only if i check "continuous time support", i thought maybe it was because my new model now contains continuous time blocks, but i couldn't find any (using this method : How do I find all continuous blocks in a model in order to replace them to use a discrete solver? - MATLAB Answers - MATLAB Central).

3) Having to check "continuous time support" sounds suboptimal since my model is (normally) 100% discrete, and it forces me to uncheck the option Remove error status field in real-time model data structure which is recommended to be checked for efficiency matters.

Thanks a lot for your help !

Clément

[Donghua]

Hello, I'm facing the same issue and couldn't find useful prompt duing the generation.

Despite setting with explicit 'no continuous time support', Embedded Coder still generates these codes.

[Aabha]

Hi @Clément,

I tried to reproduce this issue using a dummy discrete model, but I wasn't able to. Could you share the model that you are using?

[Clément]

Hi @Aabha.

Thanks for your help.

I found the culprit in my model. It was a clock block. Interestingly, it didn't appear when i searched for continuous blocks in my model using the snippet of matlab code i found there : How do I find all continuous blocks in a model in order to replace them to use a discrete solver? - MATLAB Answers - MATLAB Central).

But i found it using the Simulink option that colorizes wires according to their sample rate : in the "Legend" panel, under each different sample rate, there is a list of all the blocks outputing this particular sample rate. this is where i found it.

My guess is that you might be able to reproduce the bug using a simple discrete model containing an continuous clock and trying to generate C (ANSI) code with ERT tlc, and without checking the option "continuous time" in Generation/Interface settings tab. In my case, it terminated with no error but there was no occurence of "include rtw_continuous.h" i the generated code, resulting in errors when trying to cimpile it (since the code was usin structs defined there). For me, it is a bug. There should either be

1) an error at generation time, telling that you must check "continuous time support" in order to compile a model that contains continuous signals

2) a warning telling that the support of continuous time has been automatically activated

Have a good day.

Clément

[Clément]

@Donghua

You're probably in the same case as I were. You must have a block generating a continuous signal hidden in your model. Try finding it (and replacing it) using the method i mentioned in my previous comment.

[Donghua]

@Clément Hi Clément,

Thank you for your solution and explanation.

Yes, as you mentioned I did check the sample rate view and saw the continuous sample rate in the list.

However, in my case , even I did so, the block couldn't be found.

It must be something hidden in the model and with display error I thought.

I saved the model as a mdl format and checked the contents manually.

This time I found a 'Clock' block exactly inside my model, which has a bad property IOType: siggen, after removing this property the Clock block becomes visible on the panel.

This was quite interesting since Simulink generated( or my incorrect operations?) a bad block in the model and ignored the block while model is being loaded. However, the Embedded Coder recognized this model must be compiled with continuous time supporting and generated the code without warnings.

Donghua

Answer 1

[Harsh]

Hi @Clément,

As correctly pointed out by you in the comments, the fact that your new model now includes continuous-time structures like "RTWSolverInfo" and "SimTimeStep", is because of the inclusion of a "Clock" block. This block introduces continuous-time behavior, even if your solver is set to Fixed-Step (Discrete), which leads to the inclusion of continuous-time headers during code generation.

I am not able to reproduce the issue regarding no error being thrown while code generation using a dummy model named "clk_discrete_ert" in R2023b. The model has a "Clock" block connected to an "Out1" block. Here's the script with settings used to build the model -

model = 'clk_discrete_ert';  % Replace with your model's name
open_system(model);

set_param(model, ...
    'SolverType',            'Fixed-step', ...
    'Solver',                'FixedStepDiscrete', ...
    'StartTime',             '0', ...
    'StopTime',              '10');

cs = getActiveConfigSet(model);
set_param(cs, ...
    'SystemTargetFile',      'ert.tlc', ...
    'SupportContinuousTime', 'off', ...
    'GenerateReport',        'off');

% 6) Save and build
save_system(model);
rtwbuild(model);

The above script gives the following expected error -

This error is expected because of the "SupportContinuousTime" veing set to "off". Please share more details on how to reproduce your issue regarding not getting the above error.

Secondly, the script from the following MATLAB Answers page - https://www.mathworks.com/matlabcentral/answers/590491-how-do-i-find-all-continuous-blocks-in-a-model-in-order-to-replace-them-to-use-a-discrete-solver, will not work as it identifies all the blocks which have continuous states using the "states = Simulink.BlockDiagram.getInitialState(model)" function to get initial states. The "Clock" block will not be present in "states" dictionary as it does not maintain any internal state and only outputs continuous signals.

Use the following MATLAB script to scan your model for blocks with a sample time of [0 0], which indicates continuous-time behavior.

model = 'clk_discrete_ert';  % Replace with your model's name
open_system(model);
set_param(model, 'SimulationCommand', 'update');
blocks = find_system(model, 'Type', 'Block');
continuous_blocks = {};

for i = 1:length(blocks)
    try
        st = get_param(blocks{i}, 'CompiledSampleTime');
        if ischar(st)
            st = str2num(st);
        end
        if ~isempty(st) && isequal(st, [0 0])
            continuous_blocks{end+1} = blocks{i}; 
        end
    catch ME
        % Some blocks may not support CompiledSampleTime query
    end
end
disp('Continuous-time blocks:');
disp(continuous_blocks');

Ouput from running the above script-

Finally, in order to avoid using "continuous time support" use "Digital Clock" instead of the "Clock" block. It outputs time at discrete intervals and is compatible with fixed-step discrete solvers. This allows you to re-enable optimizations like "Remove error status field", improving code efficiency. Refert to the following documentation for "Digital Clock" - https://www.mathworks.com/help/releases/R2023b/simulink/slref/digitalclock.html

[Clément]

Hello Harsh. Thanks for your detailed analyses and the snippet to détecté continuons time behaving blocks. I found the Digital clock replacement earlier indeed, thanks anyway ! Regarding the fact that i had no error during code generation, i agree it is intriguing. Maybe it's a matter of version ? I am using MATLAB 2023b. Also a difference between your test and my case is that i used the Model Parameter window instead of using directives to set parameters. Regards, Clément