Thread Subject: Strategy for interfacing c-mex s-function with external model

I have a c-mex s-function block that is called from my Simulink model. This Simulink model also contains a block that contains a biomechanical model (it receives muscle activations as inputs, and outputs joint angles).

What I’m aiming to do: have my c-mex s-function (controller component) calculate activation output values that will, at each timestep, be applied to the biomechanical model. The biomechanical model will then calculate joint angle outputs, and return them to the c-mex s-function as inputs for the next timestep. From my current knowledge about this system, I believe that there are at least 2 possible ways to accomplish this:

    a) Have the mdlOutputs() function within my c-mex s-function calculate the output activation values at each timestep, which should then be applied to the biomechanical model block that receives input from this c-mex s-function block. (Question: I know that mdlOutputs() executes at every timestep; how can I assure that the activation values just calculated in this timestep are the values being passed to the biomechanical model block? And, can I assume that the biomechanical model block will execute at every timestep, each time it receives a new set of input values, or is there some timer or other trigger mechanism that needs to be set up to assure this?)

    b) Remove the biomechanical model block from my Simulink model. Instead, use a call to a function in an existing .dll that calls a non-Simulink version of this biomechanical model. Apparent advantage: it seems that I would have more control about when this model executes, rather than being tied to it executing following every mdlOutputs() execution at each timestep. (This is a concern, because I’m going to want to perform a series of episodes, with each episode consisting of an unknown number of mdlOutputs() executions, and it seems like flexibility in calling the model would be a good thing.) However, I could just be perceiving this function-call method as more “controllable” than the Simulink block method – can someone clarify whether there would be an advantage of using one method over the other?
          ~ One additional consideration: the .dll that contains the biomechanical model function I’d like to use is written in C++, whereas my c-mex s-function is, of course, in C. However, it doesn’t appear that there are many real syntax differences, apart from minor issues such as comment indicators, etc. In another part of my system, the “extern C” keyword is used to make C++ code compatible with my C code, so I’m thinking that this *may* be an option here, as well.

Thanks for any input you have about which of the 2 methods above makes more sense for what I’m trying to accomplish.

On 9 Jan, 21:34, "Kate J." <kmj.w...@gmail.com> wrote:


>           ~ One additional consideration: the .dll that contains the biomechanical model function I’d like to use is written in C++, whereas my c-mex s-function is, of course, in C. However, it doesn’t appear that there are many real syntax differences, apart from minor issues such as comment indicators, etc. In another part of my system, the “extern C” keyword is used to make C++ code compatible with my C code, so I’m thinking that this *may* be an option here, as well.

You should think very carefully through how you
will publish the C++ interface. Yes you are right
in that the 'extern C' keyword transforms the C++
code to be callable from C, but that only works
for free functions, not objects.

Depending on how far you will distribute your code,
there is an option to write you C and C++ code
independently, and compile it as C++ MEX. This
option might save you a lot of grief.

Rune

Thanks for your input, Rune. I'm just trying to determine what my best option is. Based upon your response, it seems like trying to call the biomechanical model function from the C++ dll might actually be a much more complicated way to do what I want. I think I'll stick with method (a).

On 9 Jan, 23:42, "Kate J." <kmj.w...@gmail.com> wrote:
> Thanks for your input, Rune. I'm just trying to determine what my best option is. Based upon your response, it seems like trying to call the biomechanical model function from the C++ dll might actually be a much more complicated way to do what I want. I think I'll stick with method (a).

If you already have the model as a DLL, then use that:
Connecting DLL modules is far easier if done directly,
as matlab / simulink introduces all kinds of additional
problems on their own.

My comments relate to writing new DLLs, not using
existing DLLs.

Rune

>> If you already have the model as a DLL, then use that:

Just to be clear, what I currently have is:
~ a Simulink model
~ a c-mex s-function, which gets called as a block within my Simulink model
~ a biomechanical model block within my Simulink model
~ a separate biomechanical model .dll that contains a function that I can theoretically call, to perform the same function as the biomechanical model block that's currently in my Simulink model -- BUT all of this .dll code is written in C++, and might require conversion to C.

Do you still recommend using the call to the biomechanical model function, if the .dll *isn't* yet compatible with my c-mex s-function? Thanks.

On 10 Jan, 00:05, "Kate J." <kmj.w...@gmail.com> wrote:
> >> If you already have the model as a DLL, then use that:
>
> Just to be clear, what I currently have is:
> ~ a Simulink model
> ~ a c-mex s-function, which gets called as a block within my Simulink model
> ~ a biomechanical model block within my Simulink model
> ~ a separate biomechanical model .dll that contains a function that I can theoretically call, to perform the same function as the biomechanical model block that's currently in my Simulink model -- BUT all of this .dll code is written in C++, and might require conversion to C.
>
> Do you still recommend using the call to the biomechanical model function, if the .dll *isn't* yet compatible with my c-mex s-function? Thanks.

First of all, you don't need to convert C++ code to C.
What that question is concerned, you have two options:

1) Export the C++ interface using the "extern C" keyword.
   This allows C linkers to use the object code compiled
   from C++ source code directly, but requires that you
   know what you do when you design the interface.

2) Write C code that uses the C++ dll, but compile and
   link it with a C++ compiler / linker combo. This
   requires that
     a) You have a C++ compiler / linker available
     b) have the same C++ set-up that was used to
        generate the dll.

As for compiling the MEX function, you can use the
C++ compiler if you have one. You are not forced to
use the C compiler.

Rune