Co-simulation FAQs

What types of co-simulation does MotionSolve support?

MotionSolve can support other interfaces by making use of its broad user-subroutine support. If you would like more information on this, please contact your local Altair representative or Altair support (www.altair.com).

Do I need to compile the S-Function library used for Simulink-driven co-simulation?

No, you do not need to compile the S-Function library. The S-Function libraries for co-simulation with MotionSolve are already created and called one of the following:

mscosim – for SMP communication (Shared Memory)

mscosimipc – for IPC communication (Inter-Process Communication, via TCP/IP sockets)

and are located under <installation>\hwsolvers\motionsolve\bin\<platform>.

How many Control_PlantInput's and Control_PlantOutput's can/should I have in my model to run a co-simulation?

In the current implementation, MotionSolve supports any number of Control_PlantInput and Control_PlantOutput elements per model.

How do I create Control_PlantInput's and Control_PlantOutput's in MotionView?

You can create a Control_PlantInput or Control_PlantOutput by creating a Solver Array and setting the type to Plant Input or Plant Output. See the Control Entities toolbar to find a Solver Array:

How do I use the input signals to MotionSolve (plant inputs) to apply to my model?

Use a PINVAL() function to apply the inputs to the model in an expression (for example, Force = pinval(1234,1)). Do not use VARVAL(), as its value is close to PINVAL(), but it is not updated in exactly the same manner.

Does the order of the inputs to/outputs from the Simulink S-Function matter?

Yes, the order of the inputs and outputs listed in the Control_Plantlnput and Control_PlantOutput statements must be in the same order as that of the signals used by the Simulink inputs and outputs. Use a Mux and Demux block to collate and expand the signals. If multiple Control_PlantInput's or Control_PlantOutput's are used, the order is determined by how they are listed in the MotionSolve model (for example, by line number, from top to bottom).

What types of communication does MotionSolve support for co-simulation?

MotionSolve supports both shared memory (via threads, rather than IPC between processes) and TCP/IP sockets for communication. This is selected by choosing the appropriate S-Function library name. TCP/IP also requires an additional setup. For more information on how to setup your model for TCP/IP communication, see the topic Co-simulation Using TCP/IP.

How do I choose between TCP/IP and shared memory communication?

The fastest communication is usually achieved via the shared memory option. TCP/IP is recommended for cases where you want to run on MotionSolve and Simulink on different machines.

Can I run MotionSolve and Simulink on different machines?

Yes, by using TCP/IP communication via sockets. This allows you to run MotionSolve on one machine and Simulink on another. TCP/IP communication is platform independent, so there may also be different types of machines.

The communication is accomplished by associating IP addresses with the input signals to MotionSolve and Simulink.

What is the difference between zero-order, first-order, and second-order hold for data interpolation?

These different hold methods are a way of sampling a continuous system. A zero-order hold samples a value and holds it as a constant value for one sample period. A first-order hold is a linear interpolation or extrapolation of two values, while second-order is a quadratic interpolation or extrapolation of three values.

How do I run a co-simulation on command line (batch mode)?

MotionSolve allows you to call a Simulink model that has been prepared to run co-simulation with MotionSolve (see the tutorial MV-7002: Co-simulation with Simulink for an example on how to prepare the models). You can run the model by calling the MotionSolve executable (mbd_d.exe.) directly, which is located in the installation directory <install_dir>/hwsolvers/motionsolve/bin/<platform>

Here's an example of how to call the MotionSolve executable and the arguments to call a batch co-simulation:

C:\sim_temp>"C:\Program Files\Altair\12.0\motionsovle\bin\win64\mbd_d.exe"
Usage:   mbd_d <source>.{xml|py|pyc|acf|mdl} <target>.mrf [<usrsub_dll>]
Purpose: Run as the main driver for a complete Pre->Solve->Post process.
{} Select one item. [] Optionally select the item.
<source>.mdl - Simulink model file (for batch-mode co-simulation)
<target>.mrf - MotionSolve output MRF file
<usrsub_dll> - Optional usersub dll filename

So, the final command looks something like this:

C:\sim_temp>"C:\Program Files\Altair\12.0\hwsolvers\motionsolve\bin\win64\mbd_d.exe" my_simulink_model.mdl output.mrf

What are the advantages/disadvantages of co-simulation using Simulink versus creating a library from a Simulink model via the Simulink Coder (Real-Time Workshop) and co-simulating the combined system this way?

Co-simulation via the Simulink interface allows the Simulink user to make any of the changes to the Simulink model that are desired, including model topology (how blocks are connected, which ones are used, settings, and so on) and model parameters.

Generating a library from a Simulink model via the Simulink Coder (Real-Time Workshop) requires an extra license at the time of library generation. It generates a single file that represents the Simulink model, but the model topology is fixed until a new library is generated. This library protects intellectual property and does not require any Mathworks license to run after it is created. This method also usually runs faster than using the Simulink interface, but it depends on the model.

Does the Simulate command in the MotionSolve model (.xml) need to be synched with the settings found in Simulate (end time) when driving the co-simulation from Simulink?

Yes, generally. Each solver will run according to the amount of time specified by its simulation parameters. So, to complete a co-simulation, set the end time to be the same between both solvers. See Simulate::end_time parameter in the MotionSolve model.

<Simulate
analysis_type       = "Transient"
end_time            = "2."
print_interval      = "0.01"
/>

Please note that Simulate::print_interval is used to write MotionSolve files.

My co-simulation in Simulink gave an error, and I fixed it, but the simulation gives wrong results. How can I fix this?

The first thing you can try is to issue a "clear mex" command in the MATLAB command window. This will unload the S-Function (mex) library, and Simulink will reload it again for the subsequent analysis. If this does not work, try restarting MATLAB/Simulink with a fresh session.

What are some best practices for co-simulation?

• Run each model alone first: Before attempting co-simulation, make sure each model runs on its own, preferably with the driving inputs that would be similar to what would be seen in the co-simulation.
• Accuracy of inputs/outputs: In the coupled system with co-simulation, make sure that both solvers are providing accurate data as inputs to each other, or else the simulation may have inaccurate results and/or run poorly. For example, if MotionSolve is providing velocities as inputs to Simulink (which uses these to compute a force) then you should make sure that the velocities from MotionSolve are as accurate as possible and vice versa. If using the default values for the dynamic analysis in MotionSolve (which uses DSTIFF I3 (Index 3)) these solver settings do not perform error control on velocities. Instead, you may want to consider using DSTIFF SI2, which does perform error control and velocities and may provide a much more accurate answer. See the Param_Transient statement for more details, especially with regard to the Comment 11, "Have my results converged?". In the end, review the outputs that are generated by each solver and make sure that the results have converged, which is likely best done by running the each model by itself to study this before combining them for co-simulation.
• Hold_order for inputs/outputs: MotionSolve allows you to specify how values are either interpolated or extrapolated in the co-simulation via the Control_PlantInput and Control_PlantOutput hold order parameters, as described previously. Choosing a non-zero hold order for interpolation is usually safe, as both values for the beginning and end times are already available, and will likely help increase accuracy and/or performance. However, choosing a hold order for extrapolation is usually a bit riskier with regards to accuracy and stability of the system, since extrapolation is trying to predict values beyond what is already known from the solver. If you choose a hold_order for extrapolation of 1 or 2 and you see that the system response is poor, try reducing the hold order to 1 or 0 to see if the system response stabilizes.
• Stabilizing a co-simulation: If all else fails, you can try to reduce the maximum integration time step for one or both solvers. This slows the simulation, but may help provide the most accurate/stable values to each solver. If this fails, review the inputs to each solver and make sure that the results are smooth and reasonable - discontinuous (non-smooth) inputs are often a source of solver failure.

I have a discrete (only, no continuous states) model in Simulink, and the co-simulation fails. What might be wrong?

Check that your sampling_period in the Control_PlantInput and Control_PlantOutput statements in the MotionSolve model are set to a non-zero value. If these are set to zero (0), or unset, then the Simulink model will not work due to an incompatibility in the sample time specification.

I have several MATLAB installations on my machine. Which one will MotionSolve use while co-simulating?