Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
executable simulink with tunable transfer function

Subject: executable simulink with tunable transfer function

From: Georg

Date: 20 Jul, 2009 11:59:03

Message: 1 of 10

Hi everyone,

my simulink model exists of:

Const---Gain---Transfer_Fcn---To_File

generating the executable:

set_param('my_model ','RTWInlineParameters','on');
set_param('my_model ','TunableVars','K,den,num');
set_param('my_model ','TunableVarsStorageClass','Auto,Auto,Auto');
set_param('my_model ','TunableVarsTypeQualifier',' , , ');

rtwbuild('my_model ');
param_struct = rsimgetrtp('my_model ','AddTunableParamInfo','on');
save params.mat param_struct

Now my problem is when I execute the file it is not possible to change the num/den when the length is not the same as in my generated .exe


load params.mat;
param_struct = rsimsetrtpparam(param_struct,'K',K,'den',1,'num',[2 1]);
save params.mat param_struct
system('my_model -p params.mat')

??? Error using ==> setOneRTPParam at 153
The variable val has the wrong number of elements to set parameter num.

My second consideration was to set the models workspace to a mat-file

hws = get_param(mdlName,'modelworkspace');
hws.DataSource = 'MAT-File';
hws.FileName = 'params';
hws.saveToSource;
rtwbuild(mdlName);

But when I change something before starting the executable:

hws = get_param('my_model ','modelworkspace')
hws.assignin('K', K);
hws.saveToSource;
system('my_model')

the changes were not applied

anybody a clue?
/georg

Subject: executable simulink with tunable transfer function

From: Phil Goddard

Date: 20 Jul, 2009 17:01:03

Message: 2 of 10

There's a technical and a business reason for not being able to change the length of num or den in the rsim executable.

technical: the c-code doesn't do malloc or calloc. In the code the appropriate array lengths are assigned and during execution it is checked that the num/den lengths match the expected lengths. If they don't then an error is thrown because the memory allocated and the data being attempted to use don't match.

business: if you could change the lengths then you create an exe that allowed someone else do what simulink does -- allow you to design not just the filter gains but also the actual filter. From a (MathWorks) business perspective that's not a good thing because you could go into competition with them.
 
> But when I change something before starting the executable:
>
> hws = get_param('my_model ','modelworkspace')
> hws.assignin('K', K);
> hws.saveToSource;
> system('my_model')
>
> the changes were not applied

This doesn't work because the exe version is using data in the parameter structure that is part of the c-code (or loaded from a .mat file is you use the -p option), not the workspace of the mdl.

Phil.

Subject: executable simulink with tunable transfer function

From: Georg

Date: 21 Jul, 2009 15:10:21

Message: 3 of 10

Thanks for the quick answer Phil!

I solved the problem by using a (hopefully) long enough num/den.
But know this error occurs
??? Error using ==> rtwgen
Algebraic loops are not supported in generated code.
...should mention that now the transferfunction is feed back

when I make num/den not tunable there is no error, or I've to put a Memory block in the loop, then I can build the the model. Is this a proper solution?

anyway, when I run the executable the output-file contains just NANs. simulated in Simulink the output file is correct!?

can you give me a piece of advise?

/georg

Subject: executable simulink with tunable transfer function

From: Phil Goddard

Date: 22 Jul, 2009 14:48:01

Message: 4 of 10

I'm very suprised that the same model, with the same data and settings, gives different results in simulation and with RSIM -- in fact I don't believe it.
I also don't believe that making the transfer function non-tunable gets rid of an algebraic loop.
For any given TF there is either an algebraic loop or there is not.

In short, if you are getting different results in simulation to RSIM then you are not doing the same thing in simulation and RSIM.

There is a section of the doc that deals with algebraic loops and suggests 2 or 3 different ways to eliminate them.
Note that by adding the memory block you are changing the dynamics of your system - this may or may not be appropriate depending on your situation.

Phil.

Subject: executable simulink with tunable transfer function

From: Georg

Date: 22 Jul, 2009 15:01:55

Message: 5 of 10

Hi again!

to break the problem down to the root:

a simple simulink model with one transfer function num=1 den=[1 1]
I build the model; execute the model with changed parameter den=[0 1]
than the output file contains just NaN's.

I suppose, that the zero is not exact zero
how can I avoid this problem??

appreciate any suggestions

Subject: executable simulink with tunable transfer function

From: Phil Goddard

Date: 22 Jul, 2009 15:37:02

Message: 6 of 10


In simulation, the transfer function block checks (amongst other things) that the TF is causal and also strips out leading zeros from the num and den.
(You can verify that by putting in different num's and den's and seeing what the dialog block allows and how the entered values get displayed on the block icon.)

When you code generate, RTW takes the num and den (which must be allowable values or the model won't build) and creates a structure of the appropriate size to store their values.
The algorithm that it uses in the c-code that represents the TF block will use all elements of the structure (it doesn't know, and can't know automatically, that some of the leading elements are zeros that they should be ignored).
If you put "bad" values into the TF then the code is just going to try to use them.

The reason you are getting NaN's is because the values are _exactly_ zero.
If you look at the generated yourModelName.c, and look for the MdlDerivatives function, and follow the logic of the code, you'll see that there is a 0/0 in there and hence the result is NaN.

Essentially your are trying to do something that RTW is not designed for.

There is no automtic way to get the generated code to recognize that you are trying to do something "bad".
The only thing to do would be for you to go into the code after it has been generated, implement your own MdlDerivatives routine that checks for leading zeros and if they exist ignore them, then use the yourModelName.bat file to do the compilation.

Phil.

Subject: executable simulink with tunable transfer function

From: Georg

Date: 28 Jul, 2009 15:55:20

Message: 7 of 10

"Phil Goddard" <philNOSPAM@goddardconsulting.ca> wrote in message <h47bmu$q8q$1@fred.mathworks.com>...
>
> In simulation, the transfer function block checks (amongst other things) that the TF is causal and also strips out leading zeros from the num and den.
> (You can verify that by putting in different num's and den's and seeing what the dialog block allows and how the entered values get displayed on the block icon.)
>
> When you code generate, RTW takes the num and den (which must be allowable values or the model won't build) and creates a structure of the appropriate size to store their values.
> The algorithm that it uses in the c-code that represents the TF block will use all elements of the structure (it doesn't know, and can't know automatically, that some of the leading elements are zeros that they should be ignored).
> If you put "bad" values into the TF then the code is just going to try to use them.
>
> The reason you are getting NaN's is because the values are _exactly_ zero.
> If you look at the generated yourModelName.c, and look for the MdlDerivatives function, and follow the logic of the code, you'll see that there is a 0/0 in there and hence the result is NaN.
>
> Essentially your are trying to do something that RTW is not designed for.
>
> There is no automtic way to get the generated code to recognize that you are trying to do something "bad".
> The only thing to do would be for you to go into the code after it has been generated, implement your own MdlDerivatives routine that checks for leading zeros and if they exist ignore them, then use the yourModelName.bat file to do the compilation.
>
> Phil.

Thx Phil!

Finally I solved the problem by manipulating the c-code. You don't have to implement a new MdlDerivatives but do something in the MdlStart routine

left shift the den/num x times
x is the number of leading zeros in the denominator

so th problem is solved with just a few lines of code

georg

Subject: executable simulink with tunable transfer function

From: Murat Kalkan

Date: 30 Nov, 2012 22:42:08

Message: 8 of 10

"Georg" wrote in message <h41m67$7nf$1@fred.mathworks.com>...
> Hi everyone,
>
> my simulink model exists of:
>
> Const---Gain---Transfer_Fcn---To_File
>
> generating the executable:
>
> set_param('my_model ','RTWInlineParameters','on');
> set_param('my_model ','TunableVars','K,den,num');
> set_param('my_model ','TunableVarsStorageClass','Auto,Auto,Auto');
> set_param('my_model ','TunableVarsTypeQualifier',' , , ');
>
> rtwbuild('my_model ');
> param_struct = rsimgetrtp('my_model ','AddTunableParamInfo','on');
> save params.mat param_struct
>
> Now my problem is when I execute the file it is not possible to change the num/den when the length is not the same as in my generated .exe
>
>
> load params.mat;
> param_struct = rsimsetrtpparam(param_struct,'K',K,'den',1,'num',[2 1]);
> save params.mat param_struct
> system('my_model -p params.mat')
>
> ??? Error using ==> setOneRTPParam at 153
> The variable val has the wrong number of elements to set parameter num.
>
> My second consideration was to set the models workspace to a mat-file
>
> hws = get_param(mdlName,'modelworkspace');
> hws.DataSource = 'MAT-File';
> hws.FileName = 'params';
> hws.saveToSource;
> rtwbuild(mdlName);
>
> But when I change something before starting the executable:
>
> hws = get_param('my_model ','modelworkspace')
> hws.assignin('K', K);
> hws.saveToSource;
> system('my_model')
>
> the changes were not applied
>
> anybody a clue?
> /georg

Hi everyone;

I tried this code in Matlab R2011a, but it gives an error in system('my_model -p params.mat') line. I think the "-p" argument is not supported in R2011.
Is there a solution for this problem?

Subject: executable simulink with tunable transfer function

From: Phil Goddard

Date: 30 Nov, 2012 23:31:08

Message: 9 of 10

The -p option is still supported in R2012b (so it was also in R2011a/b) so that it not the problem.

Phil.

Subject: executable simulink with tunable transfer function

From: Murat Kalkan

Date: 3 Dec, 2012 16:55:12

Message: 10 of 10

Thank you for your reply;

I tried again and Matlab throw an error:
Unexpected command line argument: -p

Do you have an idea?

"Phil Goddard" <phil@goddardconsulting.ca> wrote in message <k9bfjs$q4o$1@newscl01ah.mathworks.com>...
> The -p option is still supported in R2012b (so it was also in R2011a/b) so that it not the problem.
>
> Phil.

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us