@one man 

It’s about doing inverse kinematics without involving equations.

Acausal modeling allows to swap inputs and outputs of a (computer) model. On the contrary, in a conventional block diagram of a system (and corresponding computer tools) the flow of information always goes from input to output. Strictly speaking acausal models do not have input and output. A model can be simulated in forward and backward direction (https://www.youtube.com/watch?v=YZWhMQ-0cEE&t=19s @ 17 min explains why and how). Exploiting this for inverse kinematics is new and not obvious (i.e. inventive).

I took the term "Inverse Model" from https://www.youtube.com/watch?v=X0OZ9EM6dns (@ ~7min). I have not found anything better or more appropriate yet.

Inverse models are useful for studies in an early conceptual design phase. Deriving equations is the next step.  Can the method for deriving equations to which you refer be used for parallel kinematics (e.g. a stuart platform in the video above)?

Thank you for pointing out the method of dimensional reduction. I was not aware of it.

Could you provide an example how Maple prints in your setting and what you want to achieve?

@phil2  @Joe Riel Thank you for the comments!

An example for the suggestions (1) and (6)

For (1): In the example above, it is unclear how the rigid body frames connect to each other (see highlight A). Highlighting by selecting the connection lines (the observer needs a MapleSim installation for that) reveals only one crossing point at E.

A closer look shows that the renderer inserts gaps between the connection lines, depending on which line is in front of the other.

With that in mind, I have reconsidered my original suggestion of an arc, which looks to me old fashioned and can lead to overlap with other drawing items. My new simplified suggestion of modulating the width of already existing gaps would look like that:

Filling of micro gaps (at F for example, see above) should be optional for those who don’t need to see the underlining routing information and prefer uninterrupted lines wherever possible. (For lines connected to the same flange or port, I see no need for gaps to be displayed.)

This revised suggestion in its simplest implementation (no gap filling) would only widen a gap at a crossing point. No right click needed. The existing renderer already decides how and where to put gaps when it encounters crossing connection lines. -> The implementation should be moderate.

For (6): Why micro step adjustment is not straight forward. Changing the size of component C (originally the size of B without micro steps, after fine tuning at the component level) yields micros steps (D). To fix that I would now prefer to have a snap to grid option for the port that snaps to the Main subsystem grid. Snapping ports to the grid at the component level (see view below) only works if the size (measured in grid units) of the dashed bounding box (circumscribing all components of the subsystem, highlighted bellow) is in a certain ratio to the port position G on the bounding box. I have not worked out a formula, but integers seem to play an important role. I have worked out that a bounding box five times larger than the component icon in the main menu works in many cases. With such a fine-tuning effort, the component can now be moved around without creating micro steps as in the case of disabling snap to grid (and later enabling). I reserve disabling snap to grid only for some MapleSim components that come with ports that are for some reason not aligned to the grid (see H). Can't these be alligned by default?

I have a snap to grid preference and would therefore welcome any easier and intuitive alignment. But this is clearly a nice to have compared to (4) and (7).

For (2): My intention was to suggest a kind of synchronization of parameter default settings and the parameter pane. Storing current parameters does store both, the parameters in the parameter pane and the parameter default setting as they are.

What synchronizes in one direction is entering a new value in the default parameter settings. What does not work is resetting the parameter pane to the default parameters. Values and units must be entered again in the default parameter settings. Synchronizing in the direction from the parameter pane to the default paramters is not possible at all.

The compare options are beneficial for parameter changes within a session or between models that are not too different. In all cases a good parameter reference set must exist. When models are merged or attempted to simulate for the first time, there is nothing to compare to that worked.

For 7: A log file would record the sequence of user actions including changes of parameters and ICs (and could possibly in future releases even replay the user actions of analysis purposes).  

For (4): Instead of suggesting an unspecific better and more intelligent algorithm that anticipates any kind of use errors I thought of visual aids for performing quick sanity checks. Any help on mastering and managing ICs would have a very positive impact on the user experience.

Excellent content and presentation on text book level! In the absence of a Mapleprimes bookmark function, have put this among my favorites as a real favorite.

@Joe Riel 

Yes, flipping horizontally in your example would also reverse the direction of flow from right to left.

Your example addresses another use case that I did not mention: Aligning the direction of flow in a subsystem to the parent subsystem. Having the ports in a component oriented in the same way as the parent subsystem improves readability when "zooming" by double click into a component. Example: After structuring a model with subsystems (some of them might come from other models) it turns out that rearranging of subsystems in the main subsystem matches better to the real-world configuration. This most likey will induce reversed flow/orientation in some subsystems.

Another motivation that I did not mention for a flip (or a rotation) is reducing the number of crossing connection lines.

It is difficult to anticipate all such instances for a layout modification in advance.

Creating a model is often much faster than getting it to the point where it can be presented to third parties (e.g., a customer) or professionally documented for future use. In general it would be great if we could save time on that.

When I think about it, better readability (reduced number of flips in orientation and avoidance of crossing connection lines) is more important to me than preserving a polished layout (which was my original intention in listing 3).

@AjayMenon 

Happy to help. If possible, consider sharing a (preferably simplified) model that produces the error.

@AjayMenon 

To convert a signal with discontinuities into a continuous signal, it is possible to pass it through a continuous signal block.  This process is similar to a microcontroller performing the convolution and outputting numerical values to a digital-to-analog converter connected to an analog signal conditioning circuit (e.g., usually a low-pass filter).

These components have a finite impulse response characteristic that causes some delay, just as your convolution causes delay because it uses a sequence of data values from the past but none from the future (which MapleSim has to integrate timestamp by timestamp).

If such an overall delay is acceptable, you are probably fine to find a solution. If not, you are looking for a kind of predictive modeling that foresees the future. This is possible in principle with MapleSim, but not at the component level.

Regarding the capabilities of Modelica, I am not the right person to ask. The custom component of MapleSim (which converts Maple symbolic commands to Modelica code) is probably not capable of converting the expression you specified to Modelica code. Have you tried it?

You are asking interesting questions (related to digital controllers providing symmetric convolution filters that I am interested in). I hope you get more answers here. If not, I would contact support.

@bmartin 

I thought the mouseover message indicates the action (like the "attach probe" icon). From my point of view, it would make sense to swap the mouseover text. The action and the state would match better. A small detail to consider if you plan to update the Analysis window. This is less important than a back button to the MapleSim window (like the Show Simulation Results button, just in the other direction). Navigating a crowded taskbar is distracting and takes time.

Anyway, the second image above shows more variables than probed. I would have expected to see no RE since they are not probed and maybe TV_13 additionally to TY_11 since they both have probes attached.

No problem with the delay and thanks for following up on this.

@wswain 

You raise a good point: The context menu should be able to do the conversion. I got the command from support on exactly the same topic. If the context menu would even work on separapte terms of an ouput only in rare cases the mighty unit package has to be involded in unit conversion.

@bmartin 

I just observered two minor (?) related details that I want to bring to your attention. The moderator can decide if this is worth branching off.

Display only probed variables displays real input (RE) and to real variables (TV) that are not probed.

Why are RE and TV displayed?

For comparision display all model variables only displays non zero RE (RE_9 is zero) variables.

If all variables means "all used variables for simulation", why is TV_11 not listed?
 

@vv 

I misinterpreted the error message "Error, (in EllipticK) numeric exception: division by zero". I thought it was the numeric integration. Printing EllpitcK shows that Maple prints the error message before any arithmetic is performed.
Using the references you provided, I found that even EllipticK can give the expected output.

For me it would have been better if EllipticK would output both the error message and infinity + undefined*I. This would prevent arithmetics with oo and additionally provide a symbolic result.

Download devisionbyzero_alternative_output.mw

@bmartin 

The error is not reproducible enough for me to send to support. Until I can show something, I will not pretend that it is a bug. It is not impossible that it is a use error or an unfortunate combination of model design, parameters and initial conditions. Let's leave it open.

Thanks again for the helpful information.

@bmartin 

Thank you for following up on this. Can I assume that there is an incomplete correspondence between the variables and states listed in the “computing initial values” section in the output console and the "all model variables" section in the simulation results?

This might help me find a bug that is driving me crazy. The output console is informative, but difficult to get an overview. The all variables section provides a better overview.

Any "strange" variables listed could indicate an error.

@Axel Vogt 

I did not know that an online version existed. A quick look showed that this special case cannot be looked up easily. Some calculations are required to make the connection to the Maple definitions. This is also the case with my old textbooks. Interesting in itself, but unfortunately not something I could spend too much time on. Providing quick solutions to integrals is one of the reasons I use Maple.

Now I can much better appreciate the work that has gone into Maple's integration capabilities and special functions. I hope they will continue the work.

Thanks for providing the link!

@vv 

I will suggest Maplesoft to update EllipticK to handle such special cases.

Thank you!