A failing slinky is another intriguing physics phenome that can be easily reproduced with MapleSim.

The bottom of a vertically suspended slinky does not move when the top is released until the slinky is fully collapsed.

To model this realistically in MapleSim, it is necessary to

• Establish a stretched equilibrium state at the start of the fall
• Avoid penetration of windings when windings collapse (i.e. get into contact)

The equilibrium state is achieved with the snapshot option. Penetration is avoided with the Elasto Gap component. Details can be found in the attached model.

A good overview of “Slinky research” is given here. The paper provides a continuous description of the collapse process (using an inhomogenous wave equation combined with contact modeling!!!) and introduces a finite time for the collapse of all windings. Results for a slinky are presented that collapses after 0.27s. The attached model has sufficient fidelity to collapse at the same time.

Real Slinkies also feature a torsional wave that precedes the compression wave and disturbs an ideal collapse. This can be seen on slowmo footage and advanced computer models. With a torsion spring constant at hand (are there formulas for coil springs?), it could also be modeled with MapleSim.

Falling_slinky.msim

Maple allows to extract, manipulate, and optimize equations from a MapleSim model. Code can be generated from the equations in various programming languages. To verify the code, C code can be imported back into the original MapleSim model and compared to the model.

This verification step is not an everyday task, but it is advisable before the code is used elsewhere (e.g., in a controller). This post summarizes helpfull links and provides an additional example with equations that are too large to be efficiently verified by code review.

Comparison to a physical model is demonstrated here on an older version of MapleSim (~2015). In newer versions the import has changed (basics are described in Tutorial 6.6: Using the External C Code/DLL Custom Component App). An external C compiler must be set-up to make the import work.

The attached MapleSim model verifies against an optimized custom component. Instead of manually entering and modifying the code as described in the Tutorial 6.6, the model uses a Maple worksheet that programmatically generates C code from Maple equations and modifies the C code (sets C definitions and parameters) to be usable for MapleSim’s External C/Library Block App.

The Maple worksheet to generate and modify C code has been improved in many details with support from MaplePrime users for which I would like to express my thanks.

C_code_generation_of_optimised_code_for_MapleSim.mw

C_code_generation_of_optimised_code.msim

I have polished up findings with custom components to share it here:

Optimized code generated with Maple’s codegen package cannot be used in the same way as it was possible with older versions of MapleSim’s Custom Component Template.

Intermediate variables `tx` (where x is an integer) of the optimized code are interpreted as physical parameters in the current template version and not as variables. This makes sense and is more consistent with MapleSim’s definition of variables and parameters, but leads to errors in MapleSim.

The attached model shows how optimized code can be generated for the current template and compares an older, still working (!) template with the new one.

The attached worksheet contains commands to programmatically generate optimized code for the current Custom Component Template.

CustomComponentTemplates_comparision.msim

Optimized_code_for_custom_component_template.mw

Combing a Prismatic Joint component with an Elasto Gap component does not always provide correct results. Incorrectly combined (red mass below), a force is generated although the distance between the flanges is greater than the relaxed spring length. A force is exerted (instead of no force is exerted as stated here) on the mass which leads to a smaler deflection (expected are 9.81 m).

This happened to me although I connected flange_a to flange_a and flange_b to flange_b in configruation A bellow. Configuration B works with inverted flanges and configuration C works with inverted unit vector of the prismatic joint. By reversing the direction of gravity, configuration A becomes a valid configuration and configurations B and C become invalid configurations.

It seems that in invalid configruations the value of the  flange distance s_rel can have a large magnitude but is negative in sign which generates significant forces although there is no contact of flanges.

So far for the observations.

Would a change of the contact condition

prevent invalid configurations or do we have to live with it for principal reasons that I am over looking?

If so, I don't see a foolproof method to avoid invalid configurations. Instead, I can only suggest measuring the flange distance of the Elasto Gap component as in the attached. If negative values of large amplitude occur, the configuration is invalid.

Assuming that a beginner would connect intuetively flange_a to flange_a and flange_b to flange_b, there is a chance of 50% that the configuration is invalid (A instead of C). This is too much to be acceptable, especially since verifying results in complex assemblies is often not possible.

It is worth noting that the contact condition comes from the underlying Modelica component and not from MapleSoft.

Prismatic_Joint_with_Elasto_Gap.msim

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
   
   Update: MapleSim 2022.2 has subtantially improved on this. This item could be removed from the list.
    
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.).