Thread Subject:

executable simulink with tunable transfer function

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

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.

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

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.

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

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.

"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

"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?

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

Phil.

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.