Thread Subject: How to call Simulink model block from within c-mex s-function?

I have a system that consists of a Simulink model containing 2 main blocks:
        ~ my c-mex s-function block, which contains a controller that calculates muscle activation outputs
        ~ a biomechanical model block, which takes the c-mex s-function’s activation outputs as input, and calculates joint angles as outputs that then get fed back into the c-mex s-function block.

My c-mex s-function code contains a mdlOutputs() function, which executes at every timestep. I had originally planned to calculate the muscle activation values within mdlOutputs(), and then apply them to the biomechanical model block at each timestep.

However, given that I have recently determined that my controller actually requires the execution of the biomechanical model block *before* some of the other calculations are performed (because the results of the activations applied at that timestep need to be used to calculate position error & other metrics in order to update the controller), I’m wondering whether there is a way for me to call the biomechanical model block from *within* mdlOutputs(), so that I can get the outputs from the biomechanical model block to use within the remainder of the mdlOutputs() function.

Is there a way to do this? I imagine that I’ll have to, at minimum, rearrange my Simulink model so that my biomechanical model block no longer receives the c-mex s-function block’s outputs as its inputs. Is there a way to call/access the biomechanical Simulink block from within my c-mex s-function code, rather than having to wait until mdlOutputs() finishes executing? I appreciate any suggestions.

On 10 Jan, 20:35, "Kate J." <kmj.w...@gmail.com> wrote:
> I have a system that consists of a Simulink model containing 2 main blocks:
>         ~ my c-mex s-function block, which contains a controller that calculates muscle activation outputs
>         ~ a biomechanical model block, which takes the c-mex s-function’s activation outputs as input, and calculates joint angles as outputs that then get fed back into the c-mex s-function block.
>
> My c-mex s-function code contains a mdlOutputs() function, which executes at every timestep. I had originally planned to calculate the muscle activation values within mdlOutputs(), and then apply them to the biomechanical model block at each timestep.
>
> However, given that I have recently determined that my controller actually requires the execution of the biomechanical model block *before* some of the other calculations are performed (because the results of the activations applied at that timestep need to be used to calculate position error & other metrics in order to update the controller), I’m wondering whether there is a way for me to call the biomechanical model block from *within* mdlOutputs(), so that I can get the outputs from the biomechanical model block to use within the remainder of the mdlOutputs() function.
>
> Is there a way to do this? I imagine that I’ll have to, at minimum, rearrange my Simulink model so that my biomechanical model block no longer receives the c-mex s-function block’s outputs as its inputs. Is there a way to call/access the biomechanical Simulink block from within my c-mex s-function code, rather than having to wait until mdlOutputs() finishes executing? I appreciate any suggestions.

I can't help you solve your problems, but just
comment that these are the kinds of problems that
just don't happen if you do everything from C(++)
as we discussed yesterday.

So do keep an open mind, and evaluate how much
hazzle it is to get what you ask for here done,
compared to doing everything in C(++).

Rune

Thanks for your input, Rune. I'm trying to weigh the advantages/costs of doing it each way. If I determine that there isn't a {simple} way to access the Simulink biomechanical model block from within my c-mex s-function, I'll probably end up using my function from the C++ .dll. I appreciate your response.

Does your biomechanical block need to be called both before _and_ after the controller (s-function) block?
One of your posts earlier this week indicated that it was _only_ after the controller.
This post says (at least some of) the functionality needs to be done _before_ the controller but doesn't say if it needs to be done afterwards too.

If it needs to be done _after_ (as per an earlier post, but superceded one), then your option a (in the earlier post) is the way that Simulink works, so there's nothing special about what you described.
You'd need a Unit Delay on the biomechanical outputs that are fed back into the controller to shows that those values are to be used at the _next_ controller update time, but otherwise you have a very standard feedback system.

If it needs to be done _before_ (as per this post), then you need to read up on Function Call subsystems.
The controller S-Function needs to output a function call signal that will feed the trigger port of a Triggered Subsystem.
The Triggered Subsystem will do its stuff and present values at the input of the controller that the controller will then use at the current time step.

If you think of this in terms of code (rather than a SImulink model) then its the same as making a function call with returns some numbers that can be used for subsequent calculation at this time step.

If the controller and the biomechanical system need to talk with each other multiple times (i.e. twice or more) then you are in effect perfroming an optimization, looking for values for the inputs and outputs that simultaneously make sense.
This will be harder to achieve, but is achievable nonetheless.

Nothing you've described can't be done in Simulink without resorting to pure C++.

Phil.

The last sentence of my previous post is somewhat ambiguous.
>
> Nothing you've described can't be done in Simulink without resorting to pure C++.
>

It should say that what you've described can be done in Simulink.
There is no need to think that you need to resort to using purely C++.

Phil.

Thanks so much for your detailed response, Phil.

>> Does your biomechanical block need to be called both before _and_ after the controller (s-function) block?

I've discovered that I will need to call the biomechanical model block *within* my c-mex s-function, so that the model block executes and returns its return values for the c-mex s-function to perform further calculations on. So, it seems like I should use a function-call subsystem. Thanks for the recommendation -- it was just what I was looking for.

It's good to know that it's *possible* to do all of this processing exclusively within Simulink. Do you know if there are any advantages/disadvantages to doing it one way or the other (i.e. using the C++ .dll biomechanical model function vs. using a function-call subsystem to access the biomechanical model block)? One concern I currently have is speed; on the PC on which I intend to eventually perform human trials with this system, the animation of the biomechanical system is expected to display in real time; however, currently, it is running slow. Would using the C++ .dll option speed things up, or do these 2 methods have similar speed properties?

On 10 Jan, 23:45, "Kate J." <kmj.w...@gmail.com> wrote:

> Do you know if there are any advantages/disadvantages to doing it one way or the other (i.e. using the C++ .dll biomechanical model function vs. using a function-call subsystem to access the biomechanical model block)?

The main trade-off witrh matlab vs C(++) is
ease of programming (for the programmer) vs
run-time speed:

- Matlab (and offspring) is easy toprogram for
  most people, but runs slowly.
- C++ takes years to learn, but produces - in the
  hands of a skilled programmer - very fast code.

In between there are all kinds of compromises, like
the ones you are investigating.

So if speed is a concern (e.g. measuring) you might
want to consult a local computing centre. Matlab
is OK for getting prototypes up and running quickly,
but is not optimum for heavy-duty work.

Rune

Thanks for your input, Rune. I do have access to a high-performance computing cluster, but it won't be useful for the real-time human-interation data collection that I'll need to do. Your summary of the speed tradeoffs was useful.

On 11 Jan, 00:07, "Kate J." <kmj.w...@gmail.com> wrote:
> Thanks for your input, Rune. I do have access to a high-performance computing cluster, but it won't be useful for the real-time human-interation data collection that I'll need to do. Your summary of the speed tradeoffs was useful.

You might want to consult the people who run the
high performance computers. 20 years ago heavy-
duty workstations had the power of the notebook
you use to read emails. In those days that capacity
cost $100,000 or more. So one spent the extra
cash necessary to hire experts to run the computers.

While your laptop gets you that kind of performance
at a fraction of the price, you still need the
expert skills to bring that processing power to bear.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <b8d54d27-824e-4744-887d-3807bd2b9383@p16g2000yqd.googlegroups.com>...
> On 10 Jan, 23:45, "Kate J." <kmj.w...@gmail.com> wrote:
>
> > Do you know if there are any advantages/disadvantages to doing it one way or the other (i.e. using the C++ .dll biomechanical model function vs. using a function-call subsystem to access the biomechanical model block)?
>
> The main trade-off witrh matlab vs C(++) is
> ease of programming (for the programmer) vs
> run-time speed:
>
> - Matlab (and offspring) is easy toprogram for
> most people, but runs slowly.
> - C++ takes years to learn, but produces - in the
> hands of a skilled programmer - very fast code.
>
> In between there are all kinds of compromises, like
> the ones you are investigating.
>
> So if speed is a concern (e.g. measuring) you might
> want to consult a local computing centre. Matlab
> is OK for getting prototypes up and running quickly,
> but is not optimum for heavy-duty work.
>
> Rune

All this is true and would be relevant if the OP was taking about modelling in MATLAB.
But they are not -- they are using Simulink.

Simulink Coder (the mechanism for converting a Simulink model to c-code) is a completely different technology, related in no way, to the MATLAB Coder.
Simulink Coder generates C-code -- no MCR, no thin wrapper around the MATLAB Engine -- true stand alone C-code designed specifically for running on embedded targets (as well as there being a few other "targets" such as an exe, and an S-function).

The description given (by the OP) is a very standard Model Based Design approach for using Simulink to model and simulate (in non-real time) and then covert to embeddable code to run in true/hard real-time.

Phil.

Thanks for the clarification, Phil.