Including Out-of-Scope Parameters within M S-functions

Hello community.

I've recently picked up a project from a PhD student who has been working on an estimator within Simulink. He uses Matlab S-functions for the estimator and model block, and has a separate script where he defines 100+ constant parameters.

As it stands, in order for the script to be able to recognize these parameters he reruns this parameter script during each callback function (initialize, update, outputs, etc.). This takes up 40% of my simulation time, and I'd like to remove it.

Is there a way to include common parameters within the S-Function without passing them, preferably from the workspace? They are frequently tuned, so its nice having a script file that sets them all, as opposed to an incredibly long set of arguments. Or I could save them all as a .mat file, but then I'd like to be able to just load it once somewhere and go rather than reload it during every callback function. Thanks!

Answer 1

[Kaustubha Govind]

It looks like these parameters are not actually registered as S-function parameters - is that correct? It seems like they are used as local variables in each callback. The right way to deal with this is to register each variable as a Dialog Parameter (in particular, refer to the section on Tunable Parameters). In this case, you simply have to load the variables into the mask workspace, or model workspace, or base workspace for the S-function to pick up the variable. The values may be tuned during simulation - if they are changed in the workspace, you will need to run set_param('modelname', 'SimulationCommand', 'update') (or Ctrl+D) for the model to notice the updated values. Alternatively, you can directly use SET_PARAM to update the block dialog parameters, to force the model to use the new parameter values starting at the top of the next time-step.

[Jeremy]

Thanks for the links! This is probably what I'll do in the meantime, though it was what I was hoping to avoid just for time's sake...

Answer 2

[Walter Roberson]

You could read them at initialization time, and store them in persistent variables.

I am seeing hints that there is a new-ish approach to this involving "work vectors". I have seen a few examples posted, but I have not read about them, so I do not know what the advantages over persistent variables would be.

[Kaustubha Govind]

Persistent variables should not be used to store state in S-functions, because this can cause issues if there are multiple instances of the same S-function in a model - this is where work vectors come in - they are essentially similar to persistent variables, but are scoped to the instance of the S-function. However, for this particular situation, I think registering tunable parameters on the S-function is the right approach.

[Jeremy]

I was hoping to avoid using the tunable parameters approach since there are so many variables, and I'd also have to change their instances in the S-function code. But I might make them a structure to make it less cumbersome...

Thanks for the *pointer to work vectors! I don't think I can apply them directly since the code is currently a level-1 matlab s-function, though if I convert it in the future I'll keep that in mind. Thanks!