Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

tunable parameters with rtwbuild/TLC

221 views
Skip to first unread message

craq

unread,
May 24, 2016, 9:39:14 AM5/24/16
to
I am generating C++ code from a few simulink models using the Target Language Compiler (TLC) a.k.a. rtwbuild from the Real-time Workshop. Tunable parameters are being generated differently for some models than in others, and I am struggling to figure out the cause of this difference. My observations so far are as follows

For model_A.slx
1) in the configuration menu, under "Data Import/Export", the "input" option is deselected, and the text next to it says [t,u] and is grayed out.
2) in the configuration menu, under Optimization -> Signals and Parameters, the option "Inline parameters" is selected and the "configure" button next to it is clickable. When I click on it, I get a list of the variables from the workspace with type "Simulink.Parameter". These do not correspond to the tunable parameters for this model
3) in the generated code, the model_A_types.h file defines two structs, one (struct_5tQ7R3iuTqV70votfqV83G) which has the tunable parameters inside it, and
typedef struct Parameters_model_A_ Parameters_model_A;
model_A.h then defines
struct Parameters_model_A {
struct_5tQ7R3iuTqV70votfqV83G my_tunable_params;
}
// Block parameters (auto storage)
#ifdef __cplusplus

extern "C" {

#endif

extern Parameters_model_A model_A_P;

#ifdef __cplusplus

}
#endif


For model_B.slx
1) in the configuration menu, under "Data Import/Export", the "input" option is selected, and the text next to it calls some functions to load data into the workspace
2) in the configuration menu, under Optimization -> Signals and Parameters, the option "Inline parameters" is selected but the "configure" button next to it is NOT clickable.
3) in the generated code, the model_B_types.h file defines several structs, e.g. struct_dWWLqdINfH09c5EDOzoSpD
model_B.h then defines
// Model block global parameters (auto storage)
extern struct_dWWLqdINfH09c5EDOzoSpD rtP_my_params


I would like to make both models use the same naming convention for the parameters, since I want to create a generic wrapper function for both model_A and model_B. At the moment, the wrapper for model_A refers to model_A_P.my_param and the wrapper for model_B refers to rtP_my_params.my_param. I don't really care which convention is used. If anyone knows where the difference comes from, or can point me in the direction of where to look, that would be great.

Since I'm not sure where the difference arises, I am not sure how to create a simple example from these relatively complicated models, but that is what I will try next.

craq

unread,
May 25, 2016, 4:02:08 AM5/25/16
to
I have now managed to reproduce this in a simple example. The difference is that if I use referenced models as subsystems, then the parameter names get an added "rtP_" prefix.

So, I can possibly adapt my wrapper program to detect whether the simulink model uses referenced models, or... is there a setting in matlab to adjust this somehow?

craq

unread,
May 25, 2016, 6:04:10 AM5/25/16
to
my workaround for now is to include an empty referenced model in all of my simulink models. That way, parameters always have a consistent naming convention, with their workspace name prefixed by rtP_.

This solves my problem, but seems like a kind of ugly hack. If anybody has a better suggestion, or can point me towards documentation as to why parameters names change depending on whether there are referenced models, I would really appreciate it!

craq

unread,
Jun 21, 2016, 8:01:09 AM6/21/16
to
a better workaround, suggested by the Mathworks support team, is to set the class of the parameter to Simulink.Parameter in the matlab workspace, and to set the parameter's Storage Class to be "Exported Global". i.e.

my_params = Simulink.Parameter;
my_params.CoderInfo.StorageClass = 'ExportedGlobal';
my_params.Value.gain = 2;

which then generates C++ code in model_A.h
extern struct_dWWLqdINfH09c5EDOzoSpD my_params

where struct_dVW... is defined elsewhere as being composed of a "real_T" called gain.

The documentation explaining the functionality of the Storage Class can be found here:
http://de.mathworks.com/help/rtw/ug/use-parameter-objects-for-code-generation.html
or here
http://de.mathworks.com/help/rtw/ug/parameter-object-configuration-quick-reference-diagram.html
0 new messages