|
»Click here to display Table of Contents«
|
Co-simulation FAQs |
|
|
|
|
|
Co-simulation FAQs |
|
|
|
|
|
»Click here to display Table of Contents«
|
Co-simulation FAQs |
|
|
|
|
|
Co-simulation FAQs |
|
|
|
|
MotionSolve can directly co-simulate with:
| 1. | Simulink models: |
| a. | Driven from Simulink. |
| b. | Converted to a Simulink Coder model/library (formerly Real-Time Workshop). |
| 2. | DSHPlus models (see Fluidon: www.fluidon.com) |
| 3. | Certain tire and driver models (for example, FTire) |
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.altairhyperworks.com).
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 <HyperWorks_installation>\hwsolvers\motionsolve\bin\<platform>.
(platform = win32, win64, and so on).
In the current implementation, MotionSolve supports any number of Control_PlantInput and Control_PlantOutput elements per model.
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 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.
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).
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 section TCP/IP Co-simulation Overview in the topic Co-simulation Using TCP/IP.
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.
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.
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. See What are some best practices for co-simulation? for more information.
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:
<hyperworks_install_dir>/hwsolvers/motionsolve/bin/<platform>
…where <platform> = win32 for 32-bit Windows, win64 for 64-bit Windows, and so on.
The following must be done first:
| 1. | Save the MATLAB path so that it permanently finds the MotionSolve S-Function (File > Set Path…, Save). |
| 2. | Set the environment variables to call mbd_d.exe. |
| 3. | Set the environment variable MATLABROOT to specify the location of the top-level installation directory for MATLAB. |
For more information on these steps, see this topic above: What do I need to do prior to running a co-simulation with MotionSolve?
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
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.
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.
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.
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.
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.
