622 Reputation

17 Badges

2 years, 321 days

MaplePrimes Activity

These are Posts that have been published by C_R

MapleSim is a mature product. The rich component library leaves little room for improvement for wide range of applications. It is understandable that latest product releases focused on specialized toolboxes and performance improvements.

Here is what I think could be beneficial for many users, which is not related to performance, but can help improve the user experience:

  1. Crossing connection lines: A view option to render a crossing connection line with an arc at the crossing point of two connection lines of the same type. Right-click on a connection line might be enough.

    -> To avoid misinterpretations of routing in crowded model diagrams
  2. Parameters: An option to populate or reset changes in the parameter pane to the parameter default settings view and vice versa

    -> When testing or optimizing a model, sometimes changed parameters should become default values or be reset. Doing this manually is error prone and takes time.
  3. Component flip: Selecting more than one component including connection lines and applying a flip to all of them

    -> When building a model, it can happen that a nicely laid out arrangement of components needs to be mirrored or rotated in its entirety. Doing this component by component and connection by connection is a lot of work that can be saved by this option.
  4. Initial conditions: An option in the view menu to highlight components where ICs have been changed from ignore to treat as guess or to strictly enforce

    -> ICs are set for many purposes. In addition to defining ICs needed for simulations, this can include extracting equations, testing different model states, or temporarily "immobilizing" a model during assembly, to name a few. Undoing a tentative change can easily be forgotten. Combining existing models that work on their own into a new more complex model often results in an overly constrained model that either cannot be assembled or does not simulate.
    In debugging a model, ICs of all components must be individually inspected. This takes time. A quick overview that shows components where ICs are not set to ignore would be very helpful in debugging models.
  5. Undo Create subsystem: A reverse operation that inserts the contents of a subsystem into a parent subsystem.

    -> With the evolution of a model it is sometimes useful to exclude or include existing components from or to a subsystem. For this purpose, an undo create subsystem operation should preserve existing connections. A time saver.
  6. Subsystem ports: An option to align a subsystem port to the drawing grid to remove “micro” steps in connection lines

    -> For perfectionists who do not have the time to learn (and remember) how to fine-tune at the component level
  7. A history or log function of user actions changing a model, its parametrization or internal state.

    -> Often a model does not simulate at all or as desired after modifications. Restoring to a configuration that worked by undo only goes back to the last simulation performed. In such a situation, only reloading the latest file version and redoing modifications may restore the desired model, parametrization, or state. This takes time and migth be unsuccessful. A record of user actions would be a great help.
    History or log information in file format could also help MapleSim support to reproduce an error.

For me personally, reducing errors (4. > 7. > 2.) would improve the use experience much more than layouting aids (3. > 1., 5., 6.).

MapleSim is a fantastic tool to model multi-domain physical systems at a level that was unthinkable not so long ago. This post is about a simple problem that can be solved by hand, but where I failed with MapleSim using online resources.

For some time, I have been looking for answers to two questions:

  • How to control which variables (and parameters) are included in MapleSims equation exports? This question is crucial to derive forward and inverse kinematics.
  • Can the Equation Extraction App (in principle) provide a similar set of equations than the Multibody Analysis App? This question is rather academic until multidomain exports are desired (which the Multibody Analysis can’t provide).

The attached model helped me to clarify a few things and discover a real hidden secret (at least it was for me). I hope it can help others.

The model is a rather simple 3DOF mechanism. The task was to get a set of equations to derive the two rotations and the one displacement of the mechanism as a function of x,y,z coordinates.

After watching videos and inspecting models from the model gallery on inverse kinematics, I placed motion drivers for the input variables, added sensors for the output variables and wrapped the mechanism into a subsystem. However, as explained in more detail in the attachment, the set of exported variables was incomplete in both apps (AEs exports in the Equation Extraction Export and Position Constraints in the Multibody Analysis Export). Furthermore, the number of extracted equations did not match the three degrees of freedom.

After numerous trials it turned out that in addition to the motion drivers and sensors, initial conditions (ICs) had to be set. This is the hidden secret.  The crucial initial conditions (detailed in the attachment) are not required to assemble and run the model. So, introducing them temporarily for equation extraction is not obvious and never came to my mind. Setting ICs is, if I am not completely mistaken, also not highlighted in the documentation. This little trick of additionally setting initial conditions answered the above questions positively (at least for this 3DOF mechanism). In fact, it worked so well that all other failed attempts of conditioning the model for equations extraction worked immediately:

  • Immobilizing the assembly with a Fixed Frame (using parameters for the fixed frame position to represent input variables; the fixed frame can be inside or outside the subsystem model).
  • Using one Prescribed Translation component Instead of 3 motion drivers
  • Using variables to pass motion signals into the model subsystem instead of using signals and ports (using From variable and To Variable components)

These attempts underline the effort and the time spend to get the relevant equations for that simple problem. As it turned out, all approaches work but are not even required for the mechanism. The key to success was setting the ICs of the joints.  One can even strip the model down to its skeleton (removing all motion drivers and sensors as in the screen shot bellow) and still get the desired simple set of equations, provided the ICs are set.


It has to be noted, that the mechanically coupled (highlighted in yellow) prismatic joints contributed to the problems: MapleSim does not seem to take this mechanical constraint into account (as I would have expected). The ICs of both coupled components must be set to get the three equations containing all desired in and output variables.

If my finding is correct and of general relevance, I like to suggest including such kind of tips and tricks in training or reference material.  From an application engineer or developers’ perspective, knowing the underlying algorithms, its probably obvious what has to be done. But from a user’s perspective MaplsSim is a black box that works magically well in most cases. If it does not, trial and error is often the only alternative to make it work, because models are either too complex or too confidential to be shared with others.   

What I am addressing here is only the initial step of getting the desired equations. There is more to master. Save manipulation of equations too big to be inspected visually is also important. This has been well covered in several videos. Unfortunately, the quality of some of the footage does not allow to capture details of Maple commands. If possible, such material should be updated or replaced.

Overall, a collection of tips&tricks and dos&don’ts could establish some kind of best practice in deriving kinematics. If others would share their experience and findings, we all could save allot of time. A collection of valuable posts, questions, models, videos, and webinars could be a start. This collection not necessarily has to meet the high Maple standards of mathematical exactness and consistency. Engineers also accept pragmatic solutions to solve a problem.

If my findings are incorrect or you have better advise, please let us know.


Explorer 1 was the first satellite sent into space by the United States. It was a scientific instrument that led to the discovery of the Van Allen radiation belt. In order to keep its orientation, the satellite was spin stabilized. Unexpectedly, shortly after launch, Explorer 1 flipped the axis of rotation. The animation below shows, on the left, Explorer 1 in its initial state after launch, rotating about the axis of minimum moment of inertia. On the right side, 100 minutes later in the simulation, Explorer 1 rotates about the axis of maximum moment of inertia. This unintended behavior could not be explained immediately. Finally, structural damping in the four whip-like antennas was made responsible for the flip (explained here).

The flip can be reproduced with MapleSim using flexible beam components with damping enabled. Without damping and without slight angular misalignment at launch the flip does not manifest.

The simulation is only of qualitative nature since data of the antennas could not be found. On images of Explorer 1, the antennas look prebend and show large deflections of about 45 degrees under gravity. Since rotation of the satelite stretches the antennas, no modeling of large deflections needed to be considered in the simulation and rather stiff antennas (2 mm in diameter) without spheres at their ends were used. (Modeling large deflections with high fidelity might only be considered if the unfolding process of the antennas at launch is of interest. This should be modeled with several flexible beam components.)  

The graph bellow shows the evolution of the angular velocity in x direction. Conservation of angular momentum reduces the angular velocity when the satellite starts flipping towards a rotation about the axis of maximum moment of inertia.

Not long ago such simulations would have been worth a doctoral thesis. Today its rather straight forward to reproduce the flip with MapleSim.

Not so easy is the calculation of energy and angular momentum (for the purpose of observing how well numerics preserve physical quantities in rather long calculations. After all, the solver does not know the physical context). Such calculations would require access to the inertia matrix of the cylinder component including a coordinate transform into the frame of reference where the vector of rotation can be measured.

In case such calculations are possible with MapleSim, it would be nice if someone can update the model or at least indicate how calculations can be done.



On a side note: I learned from the flip in an excellent series of lectures on dynamics. Wherever our professor could, he came up with animation in hardware. In this case, he could only provide an exciting story about the space race and sometimes fruitful mistakes in science. That’s why I still remember it.

Although not mentioned in the documentation, the flexible beam component of MapleSim allows for simulation of large deflections.  

In the animation, a flexible beam is loaded with a moment (red arrow) at its free end. Assuming an Euler-Bernoulli beam and slow loading (i.e., no dynamic forces), the beam should deform to an arc of constant radiusNot only the deformation of the beam can be described analytically, also the path (red trace) of the free end follows an analytical curve.


I used this test case to get a better understanding of nonlinearities observed in an oscillating system using flexible beams (https://www.mapleprimes.com/posts/215718-Mode-Coupling-With-Flexible-Beams-). The system required tuning of the structure to develop mode coupling. This could not be explained by linear theory. It was unclear whether the large deflections (nonlinear kinematics of the beam) themselves or the implementation of the flexible beam component were responsible for that.  


What I have learned so far with the test case using only default settings: 

  • For moderate deflections there is no difference to textbook formulas.
  • Up to 15 degrees rotation of the end frame, the difference between observed displacement and the Bernoulli beam stays bellow 5%.  
  • Up to 30 degrees rotation of the end frame (as in the mode coupling example) the trace of the end frame conforms well with the analytical path.
  • To simulate very large deflections beyond 45 degrees rotation, the beam needs to be segmented to closely follow the analytical path.  

For those that are unsure about the fidelity of their models, I can suggest increasing the numbers of flexible beam components and to compare. I did this in the case of the mode coupling example and noticed no difference. So, the component was not responsible for the nonlinearities. It were the kinematics.

It's unclear whether this good performance in large deflections was intended or is a byproduct of the sophisticated multibody dynamics under the hood.  Maybe an expert can tell more.

Overall, to what I have seen the (static) performance was very satisfying. Judging dynamic performance is much more difficult. Has anyone experience to share with that?




is what I have used.


As a student I came across an amazing lab experimentA T-type structure with two masses attached to it showed a sudden change in oscillation mode.  


With MapleSim I was able to reproduce the experiment.

At the time I was told that this perplexing phenome happens because there are always imperfections. 


Today we would probably say that the symmetry has to be broken. The attached example has two parameter sets that a) break symmetry of boundary conditions and b) by structural asymmetry (i.e imperfection). Asymmetry in the initial conditions should also be possible (but I could make work with flexible beams). 

Compared to coupled oscillators that exchange energy via a coupling spring, this example exchanges energy via masses. In fact in its simplest implementation only one mass and two elastic structures are required for this type of mode coupling. MapleSim multibody library offers plenty of possibilities to demonstrate thisFlexible beams are not required. However, flexible beams show mode coupling beautifully and allow a simple reproduction in real life. For that the worksheet contains a parameter set to build a real model with steel wires. Tuning by adjusting the length of the vertical post is required since nonlinearities already shift frequencies in the model. 


I would be interested in other cool examples of mode coupling. I am also interested in solutions for flexible beams that impose asymmetry in the initial conditions. To keep it realistic at the start, the T should be bend as one would bend it with a fingertip in x direction. It would be even more realistic if the arms are flexed by gravity with zero velocity at the start of the simulation. How can this be done? 



1 2 Page 1 of 2